transformer
piranha
transformer | piranha | |
---|---|---|
3 | 21 | |
101 | 188 | |
1.0% | 0.0% | |
8.5 | 8.9 | |
6 days ago | 7 days ago | |
Java | Java | |
GNU General Public License v3.0 or later | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
transformer
-
JEP 430: String Templates (Preview) Proposed to Target Java 21
> Oracle's "license change" was to open source the entire JDK for the first time in Java's history
The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments.
> and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace.
It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer).
- What are the options to migrating existing code to support the Jakarta EE API?
-
The Javax to Jakarta mess, it's even worse than I thought
There are tools to rewrite JARs and classes, the most complete probably being Eclipse Transformer, that is apparently used by the Payara application server to rewrite EARs dynamically at deployment time.
piranha
-
Quarkus 3.0 final released!
You can still mix and match APIs at will with EE. This is what you do on Tomcat mostly, but also with Piranha Cloud (https://piranha.cloud), and to a degree even with Open Liberty.
- Piranha Cloud 22.11 released!
-
GlassFish 7 M8 released! (passing Jakarta EE 10 TCK)
Not necessarily. Piranha Cloud is an implementation of the Servlet API that is not a container.
- Helidon 3.0 Released!
-
Java News Roundup: OpenJDK, Jakarta EE 10, WildFly, Apache Tomcat Updates
Piranha Cloud uses the Java Module system extensively. See https://piranha.cloud
- Piranha 22.2 released!
- Piranha 22.1.0 released!
- GitHub Projects to Contribute
- Piranha 21.11 released!
- Piranha 21.6.0 released!
What are some alternatives?
jakarta-transformer-plugin
Apache Tomcat - Apache Tomcat
mail-api - Jakarta Mail Specification project
Jetty - Eclipse Jetty® - Web Container & Clients - supports HTTP/2, HTTP/1.1, HTTP/1.0, websocket, servlets, and more
JavaGuide - 「Java学习+面试指南」一份涵盖大部分 Java 程序员所需要掌握的核心知识。准备 Java 面试,首选 JavaGuide!
nanohttpd - Tiny, easily embeddable HTTP server in Java.
WildFly - WildFly Application Server
Apache TomEE - Apache TomEE
open-liberty - Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
BowlerStudio - A Full-Stack Robotics Development Environment
oshi - Native Operating System and Hardware Information
moditect - Tooling for the Java Module System