Support for Java APIs [originally: Add support for java.lang.Math]

[dasa]

It'd be great to have as much support for java.lang.Math as possible.

[renaudpawlak]

This request raises a fundamental question.

The JSweet focus and guideline is to allow JavaScript programming from Java. It gives access to all JavaScript APIs. For instance, jsweet.lang.Math is the JavaScript API for math... the one actually used when running with JavaScript.

Such a guideline implies that the support of Java APIs should remain minimalistic, at least for 2 reasons:

1. supporting both Java and JavaScript is often redundant and confusing for programmers (for instance the Math API is very similar for both environments, so why having both?)
2. the more we support Java APIs, the more tempting it gets to try to reuse legacy Java code in JSweet, which leads to a path we don't want to take, because it has already be taken by GWT and we know already where it will take us

That said, supporting some simple java APIs for convenience in not excluded, but I think that it should be made very clear to programmers that they are doing something out of the primary use case. I believe that such support should be available as some sort of "plugins" and that the programmers should willingly enable them. This should be a feature to be planed for next releases. In an ideal solution, any programmer should be able to write its own API support as a plugin.

In the meantime, at this point, please try to use the JavaScript APIs in http://www.jsweet.org/core-api-javadoc/. When something feels really clumsy from Java, just report it and we will try to make it more natural by supporting a subset of a Java API for instance...

[metrospiegel]

It might be a good idea to have Java libraries like java.lang.Math supporting the migration. Wich you can later in the process gradually get rid of. Maybe even with compiler waring support (deprecated).

It would allow the step wise migration from Java to JavaScript. Even if this was not the focus of JSweet.

[renaudpawlak]

Ok. I hear you. I like the way you put it. Migration is to be a quite important use case.

There are two ways to think about migration (compatibility to Java):

1. we allow the calls to Java (maybe with an annotation @AllowJava) and we add a JS runtime to support these calls (this it what GWT and most frameworks do... I don't like it too much and it is not really migration).
2. we define some transformational mapping so that some calls to Java are mapped to JS calls by the transpiler at compile-time.

Personally I prefer solution 2, because it avoids the runtime and because potentially the transformations can be applied once to the source code to perform the migration instead of having to do it manually (you can then use the produced source code as your new source code).

What do you think? Would it cover what you had in mind?

[metrospiegel]

2) is definitly the cleaner one. And would work perfectly well with java.lang.Math which this issue is about.

And i don't want to highjack it. But people will probably by and by ask for more than java.lang.Math. For those cases 2. might end up being to complex to handle in the transformation, so that a library (like the ones from GWT/Dragome/java2script) is then the simpler way. Maybe with an inline mechanism for native methods like the one from java2script. It is then also easier for people to contribute (maybe in a seperate project, not to conterminate jsweet).

In the end, I would like to migrate EMF (Eclipse Modeling Framework) to neat and sleak javascript. So that i can use it with things like Angular.js . And i have looked in all corners (java2script, dragome, TeaVM, doppio jvm, GWT) and where not happy. I have even written my own rudimentary java2dart transpiler. Someone also tried a reimplementation of EMF in javascript, and it does not do.

[renaudpawlak]

@metrospiegel : you also added this comment:

"It concerns a same problem of me as #27 (EMF migration). Here my example:

@jsRename({"insertBooleanAt"}) void insertAt(int pos, Boolean val) { ... } @jsRename({"insertStringAt"}) void insertAt(int pos, String val) { ... }

However, i just also discovered the instanceof limitation, which does not belong here but poses also a problem for what i want to do. So maybe the scope of JSweet is really diffrent than i thought and hoped. Which would make also my other posts obsolete."

[renaudpawlak]

Guys, if you are looking for a way to run existing Java programs in JavaScript, JSweet is not the right project. As I keep repeating, JSweet is just a Java syntax layer to TypeScript/JavaScript.

As you said it, metrospiegel, there are other projects of which it is the main goal (GWT, Dragome, TeaVM), but your EMF example shows well the difficulties/limitations of these approaches (BTW, have you tried DukeScript?). This is why I don't want JSweet to move toward this slippery slope...

However, as I said, I hear your issue about helping migrating. I understand that it can be useful to help the programmers to migrate from Java to JavaScript. But IMO, supporting more Java API and constructs (such as "instance of" for interfaces) will not help. It will even make the situation worse, because it will make people believe that they don't need to migrate and that they can keep their old-fashioned Java code. I prefer having a well-scoped approach on that matter, so that people get disappointed UP-FRONT, rather than after months of work trying to use GWT or any equivalent approach (you can also read "Reason 8" in that post.

IMO, reporting errors when a construct is not supported in JavaScript is already some help for migrating. If there are too many errors, we could allow plugins to refactor the code to help the migration so that the programmers don't need to do it all manually. But I don't really believe in a fully automatized solution.

I am currently looking around to see what would be the best/simplest way to support such plugins. In any case, I believe that you would have to refactor your original code to make it work.

[renaudpawlak]

J4TS project and version 1.1.0 (coming next week) will bring more answers to supporting Java, still keeping the original JSweet spirit :)