soywiz

And maybe findbugs blacklisting issues with kotlin prior to 1.2 bytecode rewritting.

I think it comes from here: https://github.com/jtransc/gdx-backend-jtransc/blob/master/gdx-backend-jtransc/resources/limebuild.cmd If you have to change it, go ahead

https://stackoverflow.com/questions/43068608/xcrun-error-unable-to-find-utility-packageapplication-not-a-developer-tool/43935071#43935071

This task should address this PR too: https://github.com/jtransc/jtransc/pull/191

What about replacing field access by a couple of synthetic synchronized methods getter/setter and implement it as a programfeature for targets that do not implement volatile in a more performant...

The most basic primitive is the enter/exit monitor. The idea is to provide those two functions in N native class and use defines to chose the right implementation (when suitable)....

Yep thats why i want to support haxe target too. Until all that effort is backported we need to support haxe too. But even later i dont see problems supporting...

@intrigus I don't know how to debug this, so I have added a boolean `CppGenerator.ENABLE_TYPING` to toggle it so you can check the generated code. Maybe you can figure out...

Random thought: Instead of ``` struct java_lang_Object : public gc {} struct java_lang_String : public java_lang_Object {} ``` --> Could this work? And do `new final_java_lang_String` but casting to `base_`....

HelloWorld test crashes in ArrayList.addAll if you toggle ENABLE_TYPING