Code style for Java
Java keeps its platform spelling at the API surface. The convention shows up in structure, errors and the generator.
Rules and reasons
- Public and protected API, and anything that implements or extends platform types, follows Java conventions: PascalCase types, camelCase methods, ALL_CAPS constants. Reason: callers and tools expect it.
- Private helpers may use snake_case only where the surrounding module already does. Do not mix styles inside one class without a comment saying why.
- Expected business outcomes are return types (Optional, a result type, sealed variants). Exceptions belong at documented boundaries such as framework callbacks and remote I/O.
- One main concept per compilation unit; no catch-all util packages.
- Braces: Allman by default. A module may adopt Google or Oracle style entirely if its README says so.
Generator mapping
| Canonical | Java |
|---|---|
load_url (method) | loadUrl() |
web_view_configuration (type) | WebViewConfiguration |
js_accessible (annotation) | @JsAccessible |
minimal_ui (constant) | MINIMAL_UI |
Names that belong to Swing or the JDK keep their own spelling, for example setSize.
Example
WebViewConfiguration configuration =
WebViewConfiguration.hardwareAccelerated()
.licenseKey(System.getenv("LICENSE"));
JWebView page = new JWebView(configuration);
page.navigation().loadUrl("https://example.com");This is the draft Idiomatic Java spelling of the planned JWebView API, which is not released. The same example in both spellings is on the API style page.
Counter-arguments
- Google's Java guide requires K&R braces, two-space indentation, UpperCamelCase classes and lowerCamelCase methods. It allows underscores in JUnit test method names, for example transferMoney_deductsFromSource. Own-line braces and local snake_case helpers are exceptions to the most widespread Java style, and every one of them is a cost for newcomers.
- Formatters and static analysis for Java assume the platform style; each deviation needs configuration and maintenance.