1 2 Previous Next 24 Replies Latest reply on Apr 21, 2017 6:26 AM by tomjenkinson

    JTA API on Java 9 ?

    sannegrinovero

      Hello all,

      we've been testing various projects on Java 9, which is now including jigsaw, the modules system.

       

      The Java9 default modules include a module named "java.transaction" and this exports the "javax.transaction" package.

       

      This implies that *any* class in that package will be resolved by loading from that module exclusively, so when either compiling code or attempting to run any code which refers to, for example javax.transaction.Synchronization you'll get a ClassNotFoundException, even though I have the JTA API from Narayana on the regular classpath.

       

      Unless jigsaw changes, the solution for this is to have an alternative module and override the "java.transaction" module at boot time with our custom module (using the -upgrademodulepath parameter at JVM boot). An alternative would be to use -Xpatch to inject additional classes.

       

      Either way, testing on Jigsaw is becoming quite a challenge so I'd hope the Narayana team could help us by taking ownership of this one? We're currently unable to continue testing most Hibernate projects, it would be great to have some Java9 preview modules for the common JavaEE APIs.

       

      Not least, I'm wondering how this will work for every other consumer so it would be great to start experimenting with a new-gen API package.

       

      Thanks,

      Sanne

        • 1. Re: JTA API on Java 9 ?
          tomjenkinson

          Hi Sanne,

           

          It sounds like something we will need to look at but I haven't looked yet so don't know enough about the problem yet. Perhaps if you have a small test case you could raise a JBTM for us to look into?

           

          Thanks for the report,

          Tom

          • 2. Re: JTA API on Java 9 ?
            sannegrinovero

            Hi Tom,

            I hope the following test will be enlightening, it's as simple as copying these two source files.

            You will also need a JTA API jar, I'm sure you might have some around ;-) I've been using this one:

            https://repository.jboss.org/nexus/service/local/repositories/central/content/org/jboss/spec/javax/transaction/jboss-tra…

             

            ==== Main.java ====

            public class Main {

             

               public static void main(String[] args) {

                  Class clazz = SecondClass.class;

                  clazz.getMethods();

                  System.out.println("All good");

               }

             

            }

            ==== EOF ====

            ==== SecondClass.java ====

            import javax.transaction.Synchronization;

             

            public class SecondClass {

             

               public void registerSynchronization(Synchronization synchronization) {

               }

             

            }

            ==== EOF ====


            Use good old "javac" from command-line, you'll notice you can compile fine with Java 8, and if you run it with Java 8 you'll correctly print the "All good" message.


            Now try run it with Java9, build 111 (you can get it from https://jdk9.java.net/download/)

            You'll see:

            • the class files you compiled with Java 8 will fail at runtime
            • It fails to compile it too


            I'm intentionally avoiding Maven, Surefire and JUnit as they've made the errors way more confusing: this minimal example was boiled out from a quite more complex build failure.


            See also:

            Unexpected ClassnotFoundException on reflective Class#getMethod

            • 3. Re: JTA API on Java 9 ?
              mmusgrov

              I am looking into the upgrdademodulepath approach. The packaged module file jmods/java.transaction.jmod only contains class files but I would like to look at the source for the module descriptor (the src.zip in the jdk-9 download does not contain any module descriptor files). Do you know where can I find the sources for the module descriptor files?

              • 4. Re: JTA API on Java 9 ?
                mmusgrov

                I implemented the approach of patching the java.transaction platform module with the missing classes:

                 

                  java -Xpatch:<patch dir> -mp <module lib> -m <module>

                 

                where <patch dir> contains the missing classes. Although this works it requires an exploded patch directory which is fine for testing but no good for real users.

                • 5. Re: JTA API on Java 9 ?
                  tomjenkinson

                  Thanks Mike, although it is reassuring that the Xpatch works as you say it would seem the upgrademodulepath might be an interesting avenue of investigation. Sanne, do you have any tips on how to create a module that is suitable for this? I found the source for java.transaction module (I think) jdk9/dev/jdk: b2a69d66dc65 /src/java.transaction/share/classes/

                   

                  Maybe adinn might have some ideas?

                   

                  What I can't understand is why JSE is including JEE apis - reading your link it suggests there will be further updates on that soon.

                  • 6. Re: JTA API on Java 9 ?
                    mmusgrov

                    I do have such a module but it requires the application to "require java.rmi" (seems like transitive dependencies are not automatically resolved and am investigating that).

                    • 7. Re: JTA API on Java 9 ?
                      adinn

                      I believe JSE has been including these JEE APIs for some time and we have been lucky to be able to get away with providing our own (ask david Lloyd for more details). However, it looks to me like Sanne has found a much bigger problem here: by exposiing a subset of the javax.transaction classes in the JSE module the JDK seems to be stopping anyone else form providing other classes required by JEE which need to in the same package.

                       

                      It's all very well to note that you can work around this with -Xpatch or -upgrademodulepath on the java command line but a workaround is no solution for what is essentially a design error. I think this issue needs to be raised with both the early access team and the jigsaw team. Sanne can you post a summary of what the issue is to both to the eatly access team and to jpms-spec-comments@openjdk.java.net. The latter is to report jigsaw isssues which Mark Reinhold needs to consider adding to the expert group's list at http://openjdk.java.net/projects/jigsaw/spec/issues/.

                      • 8. Re: JTA API on Java 9 ?
                        sannegrinovero

                        Yes I agree with adinn the problem is quite wider. I had posted these thoughts about the practicality of JavaEE APIs being broken, or at least not easily implementable without being changed, on the jigsaw mailing list before opening the discussion here:

                        - http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007156.html

                         

                        Alan Bateman's answer is very interesting:

                        - Unexpected ClassnotFoundException on reflective Class#getMethod

                         

                        If I understand him correctly, it seems the jigsaw team is aware of this and offer a technical solution, however if I understand him correctly that is not very appealing for us.

                         

                        In terms of WildFly, I'm sure we can customize the bootstrap scripts to pass some custom options and do the hard work for end users to not have to be bothered, but this all seems very inconvenient for JavaSE users too, as one would have to figure the right combination of options to pass to the JVM depending on the technologies being used.. there's plenty of usage of JavaEE APIs (or other de facto standards) in "embedded mode".

                         

                        A common use case coming to mind is to start a unit test from the IDE. It's great that IDEs know how to boot a JUnit test (or a TestNG test), and other frameworks can hook up into this, but I fear it's going to be a slow and huge effort to get to this same ease of use, i.e. for Hibernate users, or any other Narayana embedded user, etc..

                         

                        So, yes I came here in hope we could start figuring out the impact. Especially here as the JTA API seems more affected than others: you have to share the package namespace with a JavaSE module, and it gets even more complex if you "enter the tunnel" as other modules in JavaSE require packages from the JavaSE module which are not availble in the JTA API.

                         

                        tomjenkinson

                        sorry no I'm not familiar with packaging and/or redistribution of jigsaw modules. It looks like a jar works just fine as a container for now, I think it would be nice to distribute some experimental "works for now" jar to see how far we can get with that with testing across other projects.

                        • 9. Re: JTA API on Java 9 ?
                          mmusgrov

                          Sounds like a good plan but in the meantime attached is a replacement module (plus test). You just need to run the script to build (and test) the module.

                           

                          Warning: the zip contains a single script which starts with "rm -rf mlib mods src" so make sure you run it from a clean directory.

                          1 of 1 people found this helpful
                          • 10. Re: JTA API on Java 9 ?
                            adinn

                            Hi Sanne,

                             

                            Please send the comments in your last posting (and, maybe, also a response to Alan Bateman's reply) to  jpms-spec-comments@openjdk.java.net. You need to clarify the use cases that are problematic and whatever difficulties the current proposed solution (-Xpatch, -upgrademodulepath or - -addmods java.se.ee) would entail in those use cases. These must get added to the jigsaw issues list asap. It is very important that the jigsaw team accurately record and track how their design decisions impinge on both EE container devs and EE users.

                            • 11. Re: JTA API on Java 9 ?
                              adinn

                              Now I'm talking to myself :-)

                               

                              I just posted (opportunistically) to hotspot-dev where this problem was mentioned wrt Common Annotations.

                               

                                http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022435.html

                               

                              Sanne, can you please follow up to  jpms-spec-comments@openjdk.java.net.

                              1 of 1 people found this helpful
                              • 12. Re: JTA API on Java 9 ?
                                sannegrinovero

                                All, great news: this now works fine without the end users needing to learn about exotic switches to the java bootstrap.

                                 

                                The decision of the Jigsaw team was to "hide" all the modules of the basic Java platform which conflict with the JavaEE APIs; so the package name "javax.transaction" - no longer exposed to the end user's classpath - can be resolved over normal ways, i.e. looking for jars on the user's classpath.

                                 

                                Probably a good idea to keep this in mind though: the platform still includes the "other" Class definition for some types which your API redefines. I don't expect much trouble out of these as these should only be used by other JavaSE modules, and should never leak to application's namespace.

                                 

                                I tested Java 9's Jigsaw build 9-ea+114-2016-04-19-162931.javare.4880.nc, which includes these latest improvements. N.B. the main distribution of Java 9 now includes Jigsaw since build 111, but even OpenJDK build 114 does NOT include these improvements: you have to download the builds produced by the Jigsaw team.

                                 

                                So I'd suggest to keep testing, for now make sure you grab the build from https://jdk9.java.net/jigsaw/.

                                 

                                To tease you all a bit: there are several other "interesting" changes.. not least I'm having trouble now with some Date/Time Duration computation tests, it seems like rounding is giving different results, at least were we used to intentionally trigger an overflow.

                                 

                                mmusgrov thanks a lot for creating those modules! No longer needed now, but it has been very useful for me to understand things.

                                • 13. Re: JTA API on Java 9 ?
                                  tomjenkinson

                                  Thanks for reporting back Sanne - much appreciated.

                                  • 14. Re: JTA API on Java 9 ?
                                    mmusgrov

                                    sannegrinovero how does this decision help with applications that need to depend on both java.corba and jta transactions. The issue in this case is:

                                     

                                    java.corba requires java.transaction and this dependency will override the users' classpath. Since the java.transaction module does not include classes like javax.transaction.Synchronization we end up in the same situation, ie if my app needs both corba and transactions then running with --addmods java.corba will still produce the error NoClassDefFoundError: javax/transaction/Synchronization

                                    1 2 Previous Next