jsweet and TreeMap implementation

[enricostara]

Hi,

as agreed, I tried to remove the J4TS dependencies from my application. I can compile successfully but my app stops working correctly.

First point I could see is that TreeMap seems non yet implemented in JSweet, could you confirm?

Many thanks, Enrico

[renaudpawlak]

When not using J4TS, JSweet uses the RemoveJavaDependenciesAdapter to erase JDK calls and replace them with inlined TypeScript code.

TreeMap is at least partially implemented, as you can see here. All the supported map methods and their TypeScript replacement can be seen here. It may also help that you look at these tests. Here you can see all what is guaranteed to work with JSweet (without J4TS), because all the tests are passing.

So... if your program does not run, it is possible that you use some JDK method/class that is partially implemented. Then you should at least have a runtime error (when you run the program). Sometimes, you don't get a compile-time error because the generated code sometimes erase typing for simplicity... that's bad but it's a lot of work to deal with all the JDK.

To fix it, what you should should do is to analyse the JS error that happens when you run the program and see if you can understand from which generated code it comes from. Then we can fix the adapter to support what is missing... You can send me the stack trace and generated code if you don't see anything.

[enricostara]

Thanks for the prompt support. I can see no error, this is because that the treemap is correctly transpiled as a common HashMap. Therefore the application is running without any error but not as expected because the TreeMap is not running as treemap (sorted) but only as normal map. What I could do is trying to remove the treemap and rewrite that part in order to avoid the sorting.

[renaudpawlak]

True. I should have remembered and mention this point to you. If you call keySet, it does not preserve the ordering... So, yes, if you don't want to modify the adapter to support tree maps better, then you should avoid relying on sorted maps. BTW, this extension should eventually be implemented (when time will allow). Please note that this sort of extensions (adapters) can be hot-deployed and a new version of the transpiler would not required.

[enricostara]

I'll try to have a look on adapters, but which are the real benefits of stopping using J4TS? Are there any performance concerns (memory footprint, speed)?

[renaudpawlak]

To use or not to use J4TS, that is the question ;)

We could elaborate endlessly on memory footprint or performance. But really there is no straight answer to this. It will depend on how you use the JDK APIs, and what functions you use. If you use JDK specific APIs intensively, you will most probably benefit using J4TS. I have been compiling Java libs such as AWT geom with and without J4TS and have not noticed any obvious performance impacts (here is the version without J4TS runtime)

The actual benefit of not using J4TS is that you can drop all dependencies to Java APIs, which means more interoperability with the JavaScript world. Any JavaScript program will be able to use your JSweet APIs (and conversely), with no conversion overhead. Typically a Java List<?> will translate to a pure JavaScript array and a Java Map<String,?> will translate to a pure JavaScript object, which means you can use them "as is" from JavaScript.

So my advice would be: if you intend to interoperate with the JavaScript world at some point (for instance give access to your API to JavaScript developers, or use a JavaScript framework such as Angular or Knockout with your JSweet-transpiled objects), then do not use J4TS. I believe it is safer to not use J4TS in most cases because you never know... On the other hand, use J4TS if you know you will use JDK APIs intensively and don't care about interoperating.

In an ideal world, using J4TS or not should be rigorously equivalent and you should just be able to switch it on and off depending on what you need. It is almost the case, but unfortunately it is not completely true because the current support of adapters is partial (obviously, you have noticed it with the TreeMap support). Also J4TS does not support at all some APIs that are partially supported by adapters (for instance input streams, reflection, ...). The point of JSweet 2 being that you can improve that support yourself by writing your own adapters.

[enricostara]

Thanks a lot for the long and complete explanation!

Basically I'm writing a java application in my spare time that uses Babylon.js (3D library) as front-end and this is why I started using your stunning framework.

At this moment I didn't find any interoperability concerns using both BabylonJs and J4TS and therefore my open question was only if I could have any performance issues. Then I'll do some performance tests removing J4TS and I'll give you a feedback.