Welcome to java2typescript Discussions!

[mike-lischke]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[JuergenMutschall]

Hi Mike,

my name is Jürgen Mutschall, located in Mannheim. I am looking for transpiling some serious packages from java to typescript, especially from the eclipse context.

I tried to use java2typescript, but there are some questions:

• I can see, that you are actively working on the jest unit tests for the runtime library. What do you think about the status/quality of the provided runtime lib?
• I tried to write a simple Hello World conversion example, but run into multiple errors in JavToTypeScript class (e.g. missing "undefined" checks). Finally I got something working. What is your proposal for a good directory layout. I am a little irritated by the "import ... from "./java/java" vs "import ... from "../.../../java".
• Last question: Do you have a roadmap? What would be the most important next steps I may help?

Regards
Jürgen

[mike-lischke]

Hey Jürgen, greetings from Chemnitz to Mannheim :-) Glad someone started trying the converter out (beside me).

• I can see, that you are actively working on the jest unit tests for the runtime library. What do you think about the status/quality of the provided runtime lib?

Tbh. I just started writing unit tests, so there are not many yet. I already generated test specs for every JDK shim I have, but they are mostly empty yet. So, I cannot say much about the quality.

• I tried to write a simple Hello World conversion example, but run into multiple errors in JavToTypeScript class (e.g. missing "undefined" checks). Finally I got something working. What is your proposal for a good directory layout. I am a little irritated by the "import ... from "./java/java" vs "import ... from "../.../../java".

Note that I have not run any application using the converted Java code. It's still early in the process, as I'm doing kinda dual development. I improve the generation part of the converter, while trying to get the ANTLR4 runtime to build. But since this is a pretty big task, I'm just in the middle of the entire thing and need to finish the pure syntax issues first, before I even can think of running the code.

• Last question: Do you have a roadmap? What would be the most important next steps I may help?

Would be great if you start helping! The general idea currently is to convert that mentioned ANTLR4 Java code to TS as automatically as possible, thereby improving the converter tool to make this a smooth task. In parallel I create the JDK shims as I need them to make the TS code compile. Once the runtime compiles I can start using it in a demo application.

Since it is probably too complicated for you to improve the converter (and there isn't so much to do anymore) the best help would be to write more unit tests to bring the coverage to > 80% and you create your own app testing the conversion and the result. We can then discuss what's needed additionally or where something went wrong.

How does this sound to you?

[mike-lischke]

About the folder layout: you are completely free to structure your application. All you need is a folder containing the JDK shims somewhere close to your application code. Once the JDK shim has reached a good state I plan to publish it on NPM and you can use it as a node module instead. But for now you need the shim sources in your app. Currently I have both repos side by side in my project folder and created a symlink in the ANTLR4 project to the java2ts lib folder. Because I designed that so that you can use Java like qualifiers, all you have to do is to import java, then use the qualifiers for the actual types.

About inconsistencies let's talk in your new issue you have opened.

[JuergenMutschall]

I tried to transpile https://hamcrest.org/JavaHamcrest/, only the core part, version 1.3, as a base for the junit4 library.
This is a small but complex piece of code.

I understand, that the java2typescript transpiler is in a very early stage, but maybe my findings may help.

• final on methods is transpiled to readonly
• fully qualified classes are not correctly resolved
• the use of "object" instead of "Object" or "any" ist sometimes inconsistent.
• there are several wrapper classes missing for Java constructs that have different functionality in Typescript, e.g. Iterator
• constructor code is often broken
• instanceof not correctly used, especially on value types
• in this special case very annoying: java.util.regex.Matcher is not generic

IMHO the most important issues are a consistent wrapper model for java constructs that cannot be transpiled 1:1 to typescript, e.g. Iterator and Iteratable, maybe an additional class layer would help in some areas.
The second important issue is the handling of value types vs. class types: the transpiler is often not aware of the differences
Some minor, but very annoying issues: namespace handling, spurious disfunctional generated code fragements,.
...

The transpiler is not mature enough to open issues for every topic.

[mike-lischke]

Thanks for the feedback Jürgen,

I tried to transpile https://hamcrest.org/JavaHamcrest/, only the core part, version 1.3, as a base for the junit4 library. This is a small but complex piece of code.

Is it this part you tried: https://github.com/hamcrest/JavaHamcrest/tree/master/hamcrest/src/main/java/org/hamcrest/core?

I understand, that the java2typescript transpiler is in a very early stage, but maybe my findings may help.

Yes, definitely welcome! I haven't come around to run the generated code yet, so I had no opportunity to create full JDK shims yet.

• final on methods is transpiled to readonly

OK, certainly a side effect of transforming final class members.

• fully qualified classes are not correctly resolved

That must be a bug and has to be fixed.

• the use of "object" instead of "Object" or "any" ist sometimes inconsistent.

any is banned from all my TS and JS sources, so I wonder where you saw this. Can you give me an example of inconsistencies?

• there are several wrapper classes missing for Java constructs that have different functionality in Typescript, e.g. Iterator

Absolutely! The JDK shims are completed as they are needed. I'm not going to convert the entire JDK to Typescript, and for sure not upfront :-)

However, the Iterator interface exists and is already implemented in e.g. java.util.ArrayListIterator. The TS type Iteratable is the same as the one for Java, so all shims that extend/implement Iterable also have the native TS symbol iterator implemented to allow their use in for loops and spread operations.

• constructor code is often broken

That needs investigation. Anything that stands out there for you?

• instanceof not correctly used, especially on value types

Also here, an example would be good. Or let me know the Java source and I'll run it through the converter.

• in this special case very annoying: java.util.regex.Matcher is not generic

According to the Java documentation is java.util.regex.Matcher not generic. But the implementation is almost fully missing.

IMHO the most important issues are a consistent wrapper model for java constructs that cannot be transpiled 1:1 to typescript, e.g. Iterator and Iteratable, maybe an additional class layer would help in some areas.

Iterator wrapper code is good IMO. Need to see what failed for you to figure out what can be improved.

The second important issue is the handling of value types vs. class types: the transpiler is often not aware of the differences

I guess I need to run conversion on that code too, to see what's wrong. But first I want to finish conversion of the ANTLR4 code.

Some minor, but very annoying issues: namespace handling, spurious disfunctional generated code fragements,. ...

Same here.

The transpiler is not mature enough to open issues for every topic.

Well, I'd prefer if issues were opened, so I can handle one case after the other. Such lists tend to get not fully handled if they take longer to fix the individual entries and organizing work is a bit more complicated.

Anyway, thanks again for your feedback. There's certainly a long way to go with that tool

[mike-lischke]

I think I should also make this more explicit: the goal for this tool is not to create a Java runtime in Typescript, that's just a side task. The main goal is to convert Java code to running TS code (provided the necessary runtime exists, be it the shims I wrote or any other port/wrapper).

[JuergenMutschall]

I used the src lib from junit4:
https://github.com/junit-team/junit4/tree/main/lib
The idea was:
If I can transpile the hamcrest core, it would be easy to transpile junit4 and then I can transpile java and their accompaniing junit tests to verify the correctness (partial) of the transpiled code. IHMO it would be cumbersome to rethink new unit tests in jest.

Same for an working TS runtime. Did you think about using the Google JRE emulation or the J4TS fork of it as a starting point?

Every kind of shim, runtime lib, emulation, ... follow a strict "mapping model" for src-->target language.
Your "feature" doc is a good starting point for such a model, but a more strict "mapping" would help. E.g. how are value types handled? A "Long" is transpiled as a class, but I found no shim. E.g the "CodePoint as a Number" is a nice idea from a performance perspective, but fails to provide the needed character operations. Currently a manual mapping from char to number functionality and vice versa is needed, a Typescript class with static methods/functions would not be very heavy to handle this.
A more general description/definition of your "type boxing/mapping" approach would be great.

[mike-lischke]

Same for an working TS runtime. Did you think about using the Google JRE emulation or the J4TS fork of it as a starting point?

Damn, I looked up and down the net to find something that would spare me the work of writing the converter and could not find any. Thanks for these pointers.

I played a bit with the JRE emulation and j4ts. Ran the hello world app etc. But I can for the live of me not get enough information from the documentation to decide if that is something useful for my situation, even though it sounds like it would. The module j4ts was better to understand and I could inspect the code. Unfortunately, it does not include many things like file system emulators. I know, it's for web browsers, but for my use case it's essential to have that. Additionally, probably due to the way it was created (via JSweet), it looks very inefficient (Char arrays are represented as string arrays, surrogates are not properly handled, byte arrays use number[] instead of native JS arrays etc.).

So I guess, even though all of that is pretty exciting, I'll continue with my approach.

Every kind of shim, runtime lib, emulation, ... follow a strict "mapping model" for src-->target language.

Where do you see such a "model" for the Google emulator or j4ts? They have only minimal docs about compatibility.

Your "feature" doc is a good starting point for such a model, but a more strict "mapping" would help. E.g. how are value types handled? A "Long" is transpiled as a class, but I found no shim. E.g the "CodePoint as a Number" is a nice idea from a performance perspective, but fails to provide the needed character operations. Currently a manual mapping from char to number functionality and vice versa is needed, a Typescript class with static methods/functions would not be very heavy to handle this. A more general description/definition of your "type boxing/mapping" approach would be great.

Thanks for the suggestions! Keep in mind I write the Java shims only when I need them. So far I had not yet seen a use case for that in the code I'm converting. My hope is that other people start using the converter and add shims as they need them. Likely for standard types there will be shims sooner or later, however.

Types which have no expression in TS (like char) cannot be used as is, for obvious reasons. Wrappers for Char, Long, etc. can be written, no doubt. Someone just needs to find time and interest to do so. I'm also currently rethinking my decision to use native Object/object and String/string TS types. At least for the classes we can provide shims, which also would then be able to provide the necessary APIs (including basic hashCode and equals support).

Autoboxing besides what TS does already will not be available, and determining the resulting type of an expression just from parsing it is a pretty difficult task, so the user has to add explicit boxing manually.

[JuergenMutschall]

The GWT JRE emulation doc is here: https://www.gwtproject.org/doc/latest/RefJreEmulation.html Especially the java.lang.* should be quite interesting for your approach. A good implementation of Object, String, StringBuffer, Char, … The most recent implemention is in https://github.com/google/j2cl But everything is build with j2cl/gwt in mind, so you have to add a callable API, described here: https://github.com/google/j2cl/blob/master/docs/jsinterop-by-example.md#calling-java-from-javascript I think the hard work for emulation of std functionality, value types is done and well tested (Good unit tests are included!) Using the jre lib to bootstrap a full-functional java “user code” transpiler to Typescript becomes quite feasible. I would like to see a java to typescript transpiler that uses the google j2cl/jre to leverages the blackbox approach to a more whitebox approach you are reaching for. What do you think? *Von:* Mike Lischke ***@***.*** *Gesendet:* Donnerstag, 20. Oktober 2022 19:17 *An:* mike-lischke/java2typescript *Cc:* JuergenMutschall; Comment *Betreff:* Re: [mike-lischke/java2typescript] Welcome to java2typescript Discussions! (Discussion #1) Same for an working TS runtime. Did you think about using the Google JRE emulation or the J4TS fork of it as a starting point? Damn, I looked up and down the net to find something that would spare me the work of writing the converter and could not find any. Thanks for these pointers. I played a bit with the JRE emulation and j4ts. Ran the hello world app etc. But I can for the live of me not get enough information from the documentation to decide if that is something useful for my situation, even though it sounds like it would. The module j4ts was better to understand and I could inspect the code. Unfortunately, it does not include many things like file system emulators. I know, it's for web browsers, but for my use case it's essential to have that. Additionally, probably due to the way it was created (via JSweet), it looks very inefficient (Char arrays are represented as string arrays, surrogates are not properly handled, byte arrays use number[] instead of native JS arrays etc.). So I guess, even though all of that is pretty exciting, I'll continue with my approach. Every kind of shim, runtime lib, emulation, ... follow a strict "mapping model" for src-->target language. Where do you see such a "model" for the Google emulator or j4ts? They have only minimal docs about compatibility. Your "feature" doc is a good starting point for such a model, but a more strict "mapping" would help. E.g. how are value types handled? A "Long" is transpiled as a class, but I found no shim. E.g the "CodePoint as a Number" is a nice idea from a performance perspective, but fails to provide the needed character operations. Currently a manual mapping from char to number functionality and vice versa is needed, a Typescript class with static methods/functions would not be very heavy to handle this. A more general description/definition of your "type boxing/mapping" approach would be great. Thanks for the suggestions! Keep in mind I write the Java shims only when I need them. So far I had not yet seen a use case for that in the code I'm converting. My hope is that other people start using the converter and add shims as they need them. Likely for standard types there will be shims sooner or later, however. Types which have no expression in TS (like char) cannot be used as is, for obvious reasons. Wrappers for Char, Long, etc. can be written, no doubt. Someone just needs to find time and interest to do so. I'm also currently rethinking my decision to use native Object/object and String/string TS types. At least for the classes we can provide shims, which also would then be able to provide the necessary APIs (including basic hashCode and equals support). Autoboxing besides what TS does already will not be available, and determining the resulting type of an expression just from parsing it is a pretty difficult task, so the user has to add explicit boxing manually. — Reply to this email directly, view it on GitHub <#1 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI3XVIGATSIYFWL5EQ2BTYLWEF5BXANCNFSM6AAAAAARAJK754> . You are receiving this because you commented.Message ID: ***@***.***

…

[mike-lischke]

The GWT JRE emulation doc is here: https://www.gwtproject.org/doc/latest/RefJreEmulation.html Especially the java.lang.* should be quite interesting for your approach. A good implementation of Object, String, StringBuffer, Char, … The most recent implemention is in https://github.com/google/j2cl

Currently I still have trouble to understand how to use that. I don't see TS code in the repository, only Java code. How can I convert all that to a node module or at least a library of TS files? That's what I'm missing in the documentation.

But everything is build with j2cl/gwt in mind, so you have to add a callable API, described here: https://github.com/google/j2cl/blob/master/docs/jsinterop-by-example.md#calling-java-from-javascript

The next thing which escapes my mind: why would I want to call a Java API? I want to call TS APIs.

I think the hard work for emulation of std functionality, value types is done and well tested (Good unit tests are included!) Using the jre lib to bootstrap a full-functional java “user code” transpiler to Typescript becomes quite feasible.

Yes, sounds good, but the learning curve seems steep and my gut feeling is that without someone explaining all the principles you are lost. The documentation alone is nearly useless.

I would like to see a java to typescript transpiler that uses the google j2cl/jre to leverages the blackbox approach to a more whitebox approach you are reaching for. What do you think?

Interesting idea, yes. Just need something to start with. The "Getting Started" section does neither explain how to set up a a real project (that section telling me to copy the sample project and then I'm done is a joke) nor what's exactly required to take a Java library and convert it actually. Shall I have the sources of the package somewhere or just the package file? Does it need Java on the target machine? How to structure the project and run the conversion? Nothing is really explained.

After all your TS app needs a node module or importable library. That's the ultimate goal and hence the main question is: how to generate a node module from a Java package? Do you know enough of GWT to answer these questions?

Thanks

[JuergenMutschall]

Hi Mike, some years ago, I developed software using GWT. Google moved on to j2cl and angular and a community process took over to improve GWT from v1 over v2 to currently nearly finished GWT3. I am waiting now for 3-4 years for the j2cl community is releasing a gwt v1.0 based on j2cl. To answer your questions I will try the current working status and will give you an update about the results in the next days. Regards Jürgen P.S: I you like to exchange messages in “Deutsch” please send an direct mail email to ***@***.*** *Von:* Mike Lischke ***@***.*** *Gesendet:* Freitag, 21. Oktober 2022 00:06 *An:* mike-lischke/java2typescript *Cc:* JuergenMutschall; Comment *Betreff:* Re: [mike-lischke/java2typescript] Welcome to java2typescript Discussions! (Discussion #1) The GWT JRE emulation doc is here: https://www.gwtproject.org/doc/latest/RefJreEmulation.html Especially the java.lang.* should be quite interesting for your approach. A good implementation of Object, String, StringBuffer, Char, … The most recent implemention is in https://github.com/google/j2cl Currently I still have trouble to understand how to use that. I don't see TS code in the repository, only Java code. How can I convert all that to a node module or at least a library of TS files? That's what I'm missing in the documentation. But everything is build with j2cl/gwt in mind, so you have to add a callable API, described here: https://github.com/google/j2cl/blob/master/docs/jsinterop-by-example.md#calling-java-from-javascript The next thing which escapes my mind: why would I want to call a Java API? I want to call TS APIs. I think the hard work for emulation of std functionality, value types is done and well tested (Good unit tests are included!) Using the jre lib to bootstrap a full-functional java “user code” transpiler to Typescript becomes quite feasible. Yes, sounds good, but the learning curve seems steep and my gut feeling is that without someone explaining all the principles you are lost. The documentation alone is nearly useless. I would like to see a java to typescript transpiler that uses the google j2cl/jre to leverages the blackbox approach to a more whitebox approach you are reaching for. What do you think? Interesting idea, yes. Just need something to start with. The "Getting Started" section does neither explain how to set up a a real project (that section telling me to copy the sample project and then I'm done is a joke) nor what's exactly required to take a Java library and convert it actually. Shall I have the sources of the package somewhere or just the package file? Does it need Java on the target machine? How to structure the project and run the conversion? Nothing is really explained. After all your TS app needs a node module or importable library. That's the ultimate goal and hence the main question is: how to generate a node module from a Java package? Do you know enough of GWT to answer these questions? Thanks — Reply to this email directly, view it on GitHub <#1 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI3XVIGITIFHB5YN43IPHHDWEG65PANCNFSM6AAAAAARAJK754> . You are receiving this because you commented.Message ID: ***@***.***

…

[mike-lischke]

Hey Jürgen,

some years ago, I developed software using GWT. Google moved on to j2cl and angular and a community process took over to improve GWT from v1 over v2 to currently nearly finished GWT3. I am waiting now for 3-4 years for the j2cl community is releasing a gwt v1.0 based on j2cl. To answer your questions I will try the current working status and will give you an update about the results in the next days.

I'm thankful for your effort to help me with that, but I think I have met my decision, while thinking about that last night. And that decision is: continue the current way. Reasons:

• GWT and j2cl require massive Java and Maven knowledge I don't have.
• j4ts makes this a lot simpler, but still relies on j2cl and what that supports (ie. no file system support).
• The generated code is pretty inefficient.
• Adding what I need in addition to what exists already would require that I either do it myself or write Java classes which then are transpiled to JS/TS, which would essentially require a lot of knowledge out of my expert (read: comfort) zone.
• It's really alluring to have a read-to-use TS JRE emulation, but what exists is really not up to the mark.
• Writing my own JRE gives me full control over everything. I can easily and quickly fix bugs and can add additional functionality which is not part of the JRE, to make integration into TS easier.
• And I do not have to dig into Maven, JSweet, GWT, j2cl and j4ts, which would cost me a lot of extra time.

Anyway, this was a great discussion Jürgen and if you like to contribute to this project you are highly welcome!

Thanks, Mike

[mike-lischke]

@JuergenMutschall For your information. I have now created an own repository for the JRE emulation and published the jree node package.