Tighter OpenJDK Integration for TeaVM
114 views
Skip to first unread message
ScraM Team
Mar 26, 2021, 8:49:25 PM3/26/21
to TeaVM
I'm currently investigating options for integrating TeaVM more tightly with OpenJDK, with the goal to make it easier and lower-friction for people to try TeaVM with their codebases.
So far, jpackage seems like a good possibility. ( https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpackage.html )
jpackage has options for converting JARs into a platform-ready bundle, like an EXE or MSI for windows, a DMG for MacOS, or a DEB or RPM for Linux. These are specified via a "--type" command-line option.
It seems that jpackage could get an extra type option "js" that invokes TeaVM to convert the input bytecode JAR files to a single WAR file (with JS and HTML). The "js" type could use the same folder structure as current TeaVM-generated WARs, since each type is allowed its own internal structure. ( https://docs.oracle.com/en/java/javase/14/jpackage/packaging-overview.html#GUID-DAE6A497-6E6F-4895-90CA-3C71AF052271 )
jpackage supports specification of a main class with a main() method, with optional parameters, which fits nicely with TeaVM.
To increase TeaVM usage, it would be best for TeaVM to be bundled with jpackage in the OpenJDK. However, I think the licensing is incompatible. OpenJDK's GPLv2 (with classpath exception) is apparently not able to accept Apache v2-licensed code, like TeaVM. (per https://en.wikipedia.org/wiki/Apache_License#Compatibility ) So unless TeaVM is relicensed to GPLv2 with classpath, or OpenJDK is relicensed to GPLv3, combining the codebases appears to be blocked.
Barring relicensing of TeaVM or OpenJDK, we need another option. One possibility is to have jpackage download TeaVM on the fly. Especially if cached, this seems feasible.
One more option is to require TeaVM be downloaded and installed somewhere. Perhaps jpacakge could search for it in the local maven cache. Other jpackage types have requirements that certain software be installed, but this will reduce adoption, so this should be our last resort.
If you've read this far, thank you! I think jpackage provides a good opportunity to increase TeaVM adoption, and increase the number of JVM developers deploying their code in the browser. After looking into more details and taking into account your feedback, I plan to take this to the OpenJDK mailing list, hopefully resulting in a JEP (Java Enhancement Proposal).
vic-cw
Mar 29, 2021, 4:40:20 AM3/29/21
to TeaVM
Thank you very much for trying to think of more ways to make it easier to use TeaVM!
I think I don't get exactly what problem you are tackling. Would you mind explaining what workflow is currently impossible, or difficult, and how it would look like ideally with the kind of solution you are looking for?
ScraM Team
Mar 29, 2021, 9:19:38 PM3/29/21
to TeaVM
The main problem is awareness. The second is confidence.
I agree, people who are sufficiently motivated and trusting can easily find and get started with TeaVM today. For me, it was the ease of using the maven archetypes that made it trivial to get started and quickly realize that TeaVM was the solution I'd been looking for.
One of the great things about integration with the JDK would be the awareness that comes from being a new JDK feature. Articles are written, podcasts are made, and online conferences are awash in descriptions of even the tiniest new feature in OpenJDK. Allowing users to deploy to the browser again would, I suspect, be big news.
The second, and perhaps more important reason long-term is confidence. You and I know that TeaVM is rock-solid. And due to it only needing to target JavaScript language features that were available 5+ years ago, the browser support for TeaVM-generated JS is guaranteed to work for a long time to come. However, a common theme I see in discussions is, "Is this a toy?" or, "Is this maintained?" You'd think with over 2500 commits, an active forum, and several large projects (from Codename One to Snapkit to edu.cospaces.io), that wouldn't be a question any more. However, anything bundled with the JDK comes with implied endorsement from numerous organizations. Oracle of course, but even Microsoft these days is making significant contributions to Java and supporting it on their cloud. Amazon, now home to James Gosling, also has their own OpenJDK distribution, Corretto. As a bundled part of jpackage, people and organizations considering using TeaVM would see that it is being delivered from multiple "enterprise" vendors.
I have the draft JEP partially written. I'll post it somewhere soon, possibly a github repo just for this purpose. That should make it easier for review and proposed edits. And when the time comes, I can reference it from the OpenJDK mailing list posting.
vic-cw
Mar 30, 2021, 4:56:55 AM3/30/21
to TeaVM
Thanks a lot for your answer, and thanks a lot for taking the time to make it clearer!
If I understand correctly, your proposal is not to add any particular feature, but to "bundle" TeaVM within OpenJDK.
My difficulty in understanding might come from a misunderstanding on my part of what OpenJDK is. I thought OpenJDK was just an open source version of the Java standard library.
If there is more to it then I don't know anything about it so I can't really imagine what "bundling" TeaVM into it would mean.
In any case, definitely spreading the word about TeaVM, and making people trust it is the main bottleneck to its growth, so it would be the most useful thing to do!
ScraM Team
Mar 31, 2021, 12:07:05 AM3/31/21
to TeaVM
The first draft is now here: https://frequal.com/TeaVM/openjdk/jep-draft1.html
OpenJDK does include an implementation of the Java standard library. It also includes the standard Java tools (java, javac, javadoc, etc.). Full list here: https://docs.oracle.com/en/java/javase/16/docs/specs/man/index.html
One of the tools, jpackage, seems perfect for TeaVM, as described in the draft JEP.
vic-cw
Mar 31, 2021, 4:18:47 AM3/31/21
to TeaVM
Congrats for the high quality writing!
Just one ask, for the sake of making TeaVM as agnostic as possible to other choices: as of now it seems that several (minor) choices are influenced by a choice of build system, or a choice of server side framework, which are not imposed by TeaVM. I am thinking of the "Maven repository", which I guess you mean is local in the Dependencies section, and of the "war" bundling extension.
I don't use TeaVM with Maven, and it is not required. I also don't use war files, I am guessing this is a Spring thing?
In any case, I think it would hurt TeaVM to give the false impression that users would be forced into a build system or a server-side framework.
These are minor choices, but I think in terms of communication it could create big misunderstandings.
Apart from that nothing to say, I don't understand much of jpackage, and the draft seems very well written
ScraM Team
Mar 31, 2021, 9:53:40 PM3/31/21
to TeaVM
Yes, thanks, I will make changes based on what you've noted. Look for them in an upcoming draft 2.
Maven definitely won't be required. The JDK is build-tool-agnostic and this proposal doesn't intend to change that. However, for people who have used TeaVM with a build tool, the JAR files are likely already downloaded and cached, ready for use. It would be wasteful (and slower) to redownload them when they are already on the filesystem. Perhaps jpackage could look in the cache folders (repositories) for several build tools to accommodate more users.
I will change the document to say it will offer 2 packaging options, one ZIP and one WAR. WAR is JAR with a few additional requirements for deploying the app in app servers like Tomcat. And JAR is a ZIP with a few standard conventions. :-) So jpackage will output a ZIP for easy installation in any web server (or hosting service like itch.io), and WAR for easy installation in Java app servers.
ScraM Team
Mar 31, 2021, 10:31:20 PM3/31/21
to TeaVM
ScraM Team
Apr 3, 2021, 12:32:13 PM4/3/21
to TeaVM
Draft 3 is now ready:
Updates:
- Example of command-line usage
- High-level design: How the additions will be implemented in jpackage
- Additional details for optimization and locale options
- Added list of unsupported jpackage options
- More info on testing (but still open questions)
I expect to produce one or two more drafts, then send this over to the appropriate OpenJDK mailing list in a week or two.
ScraM Team
Apr 14, 2021, 10:49:18 PM4/14/21
to TeaVM
The final draft is complete, feedback is appreciated:
Updates:
- Finalized section on testing
- Several small fixes and clarifications
If you have input, please provide it soon. I plan to post this on the OpenJDK mailing list early next week.
ScraM Team
Apr 25, 2021, 7:32:52 PM4/25/21
to TeaVM
I've posted this on the core-libs-dev mailing list:
Reply all
Reply to author
Forward
0 new messages