package listing?

[BobHanson]

Is there a package listing for what Java classes are supported?

javax, in particular?
dialogs, applets, other awt GUI components?
image handling?
toolkit?
plaf?
java.lang.Thread?
java.util.stream.*?

[gkdn]

We support basic Java Standard Library; we don't try to emulate a VM so things like threading etc. not available.

Limitations has summary of what is emulated:
https://github.com/google/j2cl/blob/master/docs/limitations.md

The list of classes are similar to GWT but the source of JRE emulation itself has most up-to-date / accurate information for J2CL:
https://github.com/google/j2cl/tree/master/jre/java

[BobHanson]

Ah, OK, thanks. I just missed the obvious java/java/ package!

So additional limitations, I think:

java.awt - not supported
java.io - missing File, FileSystem, BufferedInputStream, BufferedReader, DataInputStream, ObjectOutputStream (but has Serializable?), several other classes
java.lang - missing Thread*
java.security - minimal support includes SHA256Digest, MessageDigest
java.sql - not supported (just Date, Time, and Timestamp)
java.text - not supported (just ParseException)
java.util.reflect - not supported
java.util.regex - not supported
java.util.stream about 50% complete
java.util.zip - not supported
javax - not supported

Is that about right?

[gkdn]

Yes that sounds correct.

[niloc132]

Looks right:

• Browsers don't have synchronous IO (you can cheat/lie about it with async/await style code, but performance will ... vary.).
• When transpiling directly to JS (as opposed to splitting up work and using shared array buffers or postmessage between workers) there is only one thread to operate on.
• Producing JS that can be optimized by closure-compiler prevents going too deeply into runtime reflection.
• java.text packages include a lot of data that cannot be easily optimized away. (GWT historically supported a different API that was easier to optimize/dce. Many of these have been updated to work with j2cl, but not all yet.)

I think java.util.stream is more than 50%, though certainly not 100%. No actual parallel support (owing to JS not being multi-threaded), but those methods are still present. Deficiencies here are in methods introduced in Java 9+ (Stream is missing iterate/dropWhile/takeWhile/ofNullable/mapMulti, Collectors is missing flatMapping/filtering/toUnmodifiableMap/toUnmodifiableSet/toUnmodifiableList/teeing), or do you see more that is lacking? https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/package-summary.html#class-summary

[BobHanson]

Yes, thank you. I was asked how java2script/SwingJS transpiling works compared to j2cl. For the answer that, see

java2script/java2script#209

[gkdn]

J2CL (or the earlier GWT) is not a full JVM emulation and not intended to be.

It provides practical level Java language emulation which requires emulating some amount of Java standard library. So it is not a good candidate for porting your some existing full swing app or as a replacement for Java Applet container.

It is essentially enables some or full portion of your app using Java language with Java semantics. There are multiple reasons that you might want that; for example you want to develop regular JS apps and just love Java and related tooling or because you have some code you want to share between your Server, Android etc.

The performance and code size is super critical since this emulation is downloaded and running every day in billions of users' browsers. The overhead can be couple of kilobytes (depending how much you use from Java stdlib emulation). For reference a full box2d example is ~20kb, and the performance usually is same or better than a hand optimized JS version.

[BobHanson]

Thanks for that description. A very different purpose, for sure. I really appreciate your taking the time to explain this to me.

Optimization of java2script similarly allows for packaging just the classes used, though that is a bit more complicated due to allowances for real-time class loading and reflection in JavaScript that java2script allows for. I'm not sure what a "full box2d" example is, but I'm sure that java2script has more base overhead, since it is much more GUI oriented. For example, https://chemapps.stolaf.edu/jme/jme_JME-core.html (about 50 user classes) transfers about 750 kb. About 180 kb of that is the non-Java JavaScript side of the operation. And about half of that is jQuery. So, not including jQuery, I would say java2script base download is around 90 kb.

Maybe this is a accurate comparison:

j2cl leverages Java non-GUI/non-filesystem-related classes for use in JavaScript applications that generate their own GUI and other unsupported features typical of standard Java programs. j2cl is not for producing Java stand-alone programs that also run in JavaScript.

java2script/SwingJS enables full traditional stand-alone Java GUI applications or applets to also run in JavaScript in browsers with minimal (still Java-compatible) adjustments -- only enough to allow for the more asynchronous, single-threaded nature of JavaScript, and, coincidentally, may even make the Java programs themselves run faster. Basically, java2script provides a full transpilation of Java classes into JavaScript, and SwingJS provides an "HTML5 platform look-and-feel" package that creates HTML5 counterparts for java.awt.* and javax.swing.* GUI classes as well. So from a Java programmer perspective all the GUI design is still done in Java; the browser operation is more like an additional look-and-feel.

It really is a totally different relationship between the Java and JavaScript between the two ideas. Interesting!