Saturday, June 27, 2026

🧰 Building a Practical Java Utility Library: Exploring common_java

 When working across multiple Java applications, one problem appears again and again:

you keep rewriting the same “basic but essential” components.

common_java is a lightweight utility-style library that groups these repeated concerns into reusable modules — from validation and caching to HTTP, database helpers, and email utilities.

Let’s walk through what this library provides.

📦 1. Project Overview

The library is organized into clear functional packages:

  • validator → input validation logic
  • string → string utilities
  • cache → in-memory caching (including LRU cache)
  • network → HTTP and IP utilities
  • http → URL fetch example app
  • alert → email composition and sending
  • database → JDBC helpers and result handling
  • properties → config loading utilities

This is a classic “common utilities” architecture: each package solves a real-world repetitive backend problem.

✅ 2. Validation Layer

Key classes:

  • Validator
  • EmailValidator

This layer focuses on ensuring data correctness before processing.

Typical responsibilities:

  • checking input format
  • validating email structure
  • centralizing reusable validation rules

💡 Design idea:
Instead of scattering validation logic across services, it is centralized.

Example concept:

Validator.isNotNull(value);

EmailValidator.isValid(email);

🧵 3. String Utilities

Hex.java

This likely provides:

  • hex encoding / decoding
  • conversion between byte arrays and hex strings

💡 Why it matters:
Hex utilities are commonly needed in:

  • encryption
  • networking
  • debugging binary data

⚡ 4. Cache System (Most Interesting Part)

Core classes:

  • Cache
  • LRUCache
  • CacheElement
  • Node
  • LinkedListNode
  • DoublyLinkedList
  • DummyNode
  • CacheApp

🧠 What this module shows

This is a classic LRU Cache implementation using:

  • Hash-based lookup (likely via Cache)
  • Doubly linked list for ordering
  • Node abstraction for entries

🔁 LRU Cache concept

Least Recently Used (LRU) cache works like this:

  • Recently used items stay in memory
  • Old unused items are removed first

🧱 Data structure design

This design typically combines:

  • HashMap → O(1) access
  • Doubly Linked List → O(1) insert/remove

💡 Why multiple node classes?

  • Node → base structure
  • LinkedListNode → real element
  • DummyNode → sentinel node (simplifies edge cases)

This shows clean separation of concerns in data structure design.

🚀 Why this module stands out

This is not just a utility — it’s a fully custom cache engine, useful for:

  • performance optimization
  • memory control
  • backend caching strategies

🌐 5. Network Utilities

Classes:

  • HttpUtil
  • HttpClientApp
  • HttpResponse
  • HttpResponseCode
  • IP

What this module does

It likely provides:

  • HTTP GET/POST helpers
  • response wrapper object
  • HTTP status code abstraction
  • IP-related utilities

💡 Design strength

Instead of directly using low-level HTTP calls everywhere, the library:

✔ wraps HTTP logic
✔ standardizes response handling
✔ centralizes error handling

This improves consistency across projects.

📧 6. Email / Alert System

Classes:

  • Email
  • EmailAddress
  • EmailBody
  • EmailAttachment
  • SMTP
  • EmailApp

What this represents

A structured email system with:

  • strongly typed email components
  • separation of:
    • recipient (EmailAddress)
    • content (EmailBody)
    • attachments (EmailAttachment)
  • SMTP abstraction

💡 Why this design is good

Instead of passing raw strings:

sendEmail(to, subject, body)

You model email as an object:

Email email = new Email(...)

This improves:

  • readability
  • validation
  • maintainability

🗄️ 7. Database Utilities

Classes:

  • DatabaseManager
  • DatabaseStatementManager
  • StatementUtil
  • Jdbc
  • Result
  • RStoListMap

What this module solves

JDBC in Java is powerful but verbose.

This module likely simplifies:

  • connection handling
  • statement execution
  • result set mapping

💡 Key idea: abstraction over JDBC

Instead of repeating boilerplate:

Connection conn = ...
PreparedStatement stmt = ...
ResultSet rs = ...

You centralize it into utilities.

🔁 RStoListMap

This likely converts:

ResultSet → List<Map<String, Object>>

This is extremely useful for:

  • APIs
  • JSON conversion
  • dynamic queries

⚙️ 8. Configuration Utilities

ConfigApp

This likely handles:

  • loading .properties files
  • environment configuration
  • app-level settings

💡 Why it matters:

Every Java system needs config loading, and centralizing it avoids duplication.

🌍 9. HTTP Example App

UrlFetchApp

This is likely a demo or utility showing:

  • fetching URL content
  • using HttpUtil

This acts as:

a usage example of the network module

🧠 Overall Design Observations

✔ Strengths

1. Clear modular separation

Each package has a single responsibility.

2. Real-world utility coverage

It covers:

  • validation
  • caching
  • HTTP
  • email
  • database

This is basically a mini backend toolkit.

3. Strong focus on reusability

Everything is designed to be reused across projects.

🚀 Final Summary

common_java is essentially a personal backend utility framework that helps reduce repetitive Java boilerplate across projects.

It demonstrates:

  • practical backend engineering patterns
  • data structure implementation (LRU cache)
  • abstraction over JDBC and HTTP
  • structured email handling
  • reusable validation logic 
 

Wednesday, June 3, 2026

Run macOS in linux docker container

To be able to run macOS in linux docker container to access macOS applications without switch back and forth makes life easy. This project allow you to do that. The instruction given is very tricky, so I have written a step by step how to begin.


0. This is the main project which we will work on. Essentially we need to build an image where the image is not found in dockerhub at the moment.

```

$ git clone  https://github.com/sickcodes/Docker-OSX

$ cd Docker-OSX

$ docker build -t docker-osx:naked -f Dockerfile.naked .

```


1. Start the macOS installer, this will take some times. If clone repository OpenCorePkg is slow , add this `-v "<USERNAME>/macos/OpenCorePkg:/home/arch/OSX-KVM/OpenCorePkg"` to the command below. But make sure you have clone the repository before https://github.com/acidanthera/opencorepkg

```

$ docker run -it \

    --device /dev/kvm \

    -p 50922:10022 \

    -v /tmp/.X11-unix:/tmp/.X11-unix \

    -e "DISPLAY=${DISPLAY:-:0.0}" \

    -e GENERATE_UNIQUE=true \

    -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \

    -e SHORTNAME=monterey \

    sickcodes/docker-osx:latest    

```


2. In the mean time, get the container id and note the container id

```

$ docker ps

```


3. A qemu screen will appear, click on `macOS Base System`. wait the messages loading is complete.




4. Once at the installer screen is up, then to erase the biggest disk. You can name the disk any name because it is not important. Example `my_macos_vd`.




5. Then reinstall the macOS. Pick the disk that you erase in step 4. This installation will take a long time. Approximately 1hour in my host machine.

6. Inspect the container and get the directory where we will copy out the disk. 
```
$ docker inspect 0a0fdebac3ac | grep Upper
                "UpperDir": "/var/lib/docker/overlay2/11043fba8b6ed2e4ffeaeb8a439d791f03081cd785a9a14e60024dc3e6c4f461/diff",
```

7. Once installation is done, power down the container. 

8. Based on the step 6, the value of `UpperDir`, now copy the `mac_hdd_ng.img` to another directory in your host. Any directory will do. I pick `~/macos/`
```
$ sudo su -
# cd /var/lib/docker/overlay2/11043fba8b6ed2e4ffeaeb8a439d791f03081cd785a9a14e60024dc3e6c4f461/diff
# ls -lh ./home/arch/OSX-KVM/mac_hdd_ng.img
-rw-r--r-- 1 jason jason 37G Jun  2 20:43 ./home/arch/OSX-KVM/mac_hdd_ng.img
# cp ./home/arch/OSX-KVM/mac_hdd_ng.img </home/USERNAME/>/macos/
```

9. Update the file permission to your username correctly. 
```
$ cd ~/macos/
$ sudo chown jason:jason mac_hdd_ng.img
$ chmod 664 mac_hdd_ng.img
```

10. Now start the container using the virtual disk, the local built naked image to finish the OS setup/configuration. It will takes more than 30 minutes to complete at least.

```
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "/home/jason/macos/mac_hdd_ng.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/Docker-OSX/master/custom/config-nopicker-custom.plist \
    -e SHORTNAME=monterey \
    docker-osx:naked
```  
to speed up the container, add the below parameters to the command above if your host hardware support it.
```
    -m 10g \
    --cpus="8.0" \
    --gpus all \
    --device /dev/nvidia0 \
    --device /dev/nvidia-uvm \
    --device /dev/nvidia-uvm-tools \
    --device /dev/nvidiactl \
```

11. Once started, get the container id again. After the mac os setup/configuration is finish, then stop the container. Note that during this step, OS reboot is expected.

```
$ docker ps
```




12. Now every time to start the container
```
$ docker start <container id from step 11>
```




It is a pity that the macOS after Monterey does not work. If you managed to make it work, I would like to know and please contact me!