Java field naming rules don't mesh well with user expectations for how JSON.stringify and friends work - for example it is totally legal for a Java subclass to hide a superclass's fields if not private, and if they are private, a subclass and superclass can have the same field name with no hiding at all. To compile these possible states to JS, some other naming has to be used to ensure consistency. This wouldn't so much be "disabling obfuscation", but "no longer guaranteeing correctness".
Roughly two options are available to you:
* Use a tool like AutoBeans or domino-jackson so that JSON can be created from your Java types, in a way that would be familiar to a Java developer
* Write your Java like a JS developer would, but annotate with JsInterop to indicate that you plan to always follow JS naming rules (only one constructor ever, no overloaded methods, etc)
If you're writing something quick and simple and never plan on it growing to more than a few properties, I'd lean towards jsinterop - just slap "@JsProperty" on the fields in question (non-long primitives, Boolean or Double boxed primitives, Strings, arrays, and other annotated types, never java collections etc) and call it good. If it may grow or you like your Java to make sense in Java, give domino-jackson a look to use most of the Jackson annotations and generate json marshalling code.