JungleConfig’s native on-disk representation is called JConfig001. It is a plain-text, line-oriented format designed to be readable by humans, diff-friendly in version control, and safe for values that contain arbitrary characters — including JSON blobs, ISO dates, and strings with spaces or punctuation. Every configuration entry is stored as a self-describing triple of key, type tag, and URL-encoded value.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/himansaBro/JungleConfig/llms.txt
Use this file to discover all available pages before exploring further.
Structure
A JConfig001 file begins with the magic headerJConfig001 on its own line. Each subsequent non-blank line encodes a single entry in the form:
: in the line to split the key from the type tag, then locates the first = in the line to split the type tag from the encoded value. Because keys are validated to never contain : or =, these two positions unambiguously delimit all three fields. Values may contain : and = freely once URL-decoded — the URL encoding on disk ensures they never interfere with parsing.
A realistic config file looks like this:
NativeConverter.decode() method reads this file, strips the JConfig001 header line, splits each remaining non-blank line by the first : and first =, and URL-decodes the value segment. The NativeConverter.encode() method reconstructs the file from the in-memory TypeMap, writing the magic header first and then one line per entry.
Encoding
Values are encoded withjava.net.URLEncoder (using StandardCharsets.UTF_8) before being written to disk, and decoded with java.net.URLDecoder on read. Under standard URL encoding, space characters become + and special characters such as &, =, #, and non-ASCII bytes become %XX percent-escape sequences.
This means any string value is safe to store — including multi-line JSON, ISO-formatted timestamps, Base64 strings, and values that happen to contain = signs. For example, a POJO serialized to JSON such as {"id":1,"name":"Alice"} is stored as:
{"id":1,"name":"Alice"} transparently on read.
Type Tag
The middle field between: and = is the type tag. JungleConfig records this as the Java class simple name of the value — for example, String, Integer, Boolean, UUID, LocalDate, LocalDateTime, or LocalTime.
When a type does not have a registered built-in adapter and the fallback serialization is enabled (the default), JungleConfig uses Jackson to serialize the object to JSON and stores the type tag as Json. This covers POJOs, List, Map, and other collection types. On read, Jackson deserializes the JSON back to the requested type.
Key Constraints
Keys are validated byNativeConverter before every write. A key must not contain any of the following characters:
| Forbidden character | Reason |
|---|---|
: (colon) | Used as the separator between key and type tag |
= (equals sign) | Used as the separator between type tag and value |
\n (newline) | Each entry occupies exactly one line |
.), slashes, underscores, hyphens, and non-ASCII characters. Dotted key names such as app.server.port are a popular convention for organizing related settings into logical groups.
Encrypted Format
When usingJungleConfig.EncryptedConfig(file, password), the JConfig001 text produced by NativeConverter is passed through an AES-256/GCM encryption layer before being written to disk. The on-disk layout (before Base64 encoding) is:
SecureRandom on every write, so the on-disk Base64 string changes even when the plaintext config has not changed. The key is derived from the password and salt using PBKDF2WithHmacSHA256 at 100,000 iterations, producing a 256-bit AES key.
On read, the Base64 string is decoded, the salt and IV are extracted, the key is re-derived using the same password, and the GCM cipher decrypts the ciphertext back to the plaintext JConfig001 document that the parent NativeConverter then parses normally.