[go: up one dir, main page]

Menu

#10 Update to teavm 0.11.0

1.0
open
nobody
None
2025-07-10
2025-02-21
linuxfun
No

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

1 Attachments

Discussion

  • Andrew Oliver

    Andrew Oliver - 2025-02-22

    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?

     
    • linuxfun

      linuxfun - 2025-02-23

      Does this preserve Java 8 compatibility?

      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.

      Does this require service interfaces to upgrade to the jakarta.* packages to continue to work?

      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.

       
  • Andrew Oliver

    Andrew Oliver - 2025-06-08

    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.

     
  • Andrew Oliver

    Andrew Oliver - 2025-06-08
    • Milestone: 0.3.1 --> 1.0
     
  • Chandler Griscom

    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.

     

Log in to post a comment.