The attached patch updates flavor to teavm 0.11. The full commit message:
Update to teavm-0.11.0 and switch to jakarta API
Dependencies were bumped as far as possible before running into
incompatibilities with teavm. API changes between teamvm 0.6 and 0.11
were integrated.Notes:
- example:
- Switched to jakarta.ws.rs, jakarta.persistence, jakarta.servlet
APIs from the corresponding javax APIs- Marked OrderStatus enum as JsonPersistable as required by
the json module- Added string based setter for OrderDTO#status as currently the
binding does not convert between the JS/HTML side string and the
Java side enum- expr:
- Update TypeInferenceTest to account for changed marker interfaces
in newer JDKs.
in newer JDKs.- json:
- IntArrayDeserializer not creates an int[] instead of a long[] as
before- For generics deserialization (i.e. List<type>) the wrong type was
used as target for deserialization </type>- The java primitives need to be special cased when deserializing them
- The JSON *Node objects wrap exising JS objects and thus need to be
marked @JSClass(transparent = true), the Node base class gained
cast helper methods- rest:
- Switched to jakarta.ws.rs APIS from the corresponding javax APIs
- routing:
- Account for the possibility, that DATE typed param fails to parse
and thus must be reported as null- widgets:
- Fix rendering of calender selector
Co-authored-by: Alexey Andreev konsoletyper@gmail.com
Thank you for submitting this! I will take a look. A couple of questions:
* Does this preserve Java 8 compatibility?
* Does this require service interfaces to upgrade to the jakarta.* packages to continue to work?
No, target is set to 11 in the parent pom. This change was introduced by the first set of changes done by Alexey. I kept this in as I don't see value in keeping compatibility with an ancient java version.
Changes are necessary for the teavm facing parts. These must be updated. It might be possible to recognize both variants, but I don't think it is worth it. Oracle broke JavaEE, long live JakartaEE.
You can see an example of a mixed setup in the tests for the rest client (/rest/src/test/java/org/teavm/flavour/rest/test/TestService.java). That test runs in a server, that uses the legacy packages, but the teavm parts is covered by the jakarta packages.
Thank you again for the patch! I am going to apply it in several smaller changes. Some, like the routing changes, seem to be universally applicable, so I will commit them first.
For the Jakarta EE changes, I will be planning a strategy to not break existing Java 8/Java EE customers. I value backwards compatibility highly and I think this is one of the many features which sets Flavour apart from the competition. I will look at whether this can be done with different Java packages in one maven artifact, or whether I need to provide different artifacts for JavaEE and JakartaEE.
Thanks once more for the changes, I expect the first parts of them (routing, etc.) will make it to SVN in the next week or two, with a maven central release to follow.
I've been running my own Flavour build on 0.11.0 for a while now, but I justed tested the latest 2.0.0-SNAPSHOT and it works great.