4 Replies Latest reply on Mar 10, 2017 1:38 AM by andrea.biasillo

    Java 9 and EJB

    andrea.biasillo

      I tried to run my application (front-end developed in Java Swing, server developed with EJB deployed on Wildfly 8) with Java 9.

      When the client tries to establish an EJB connection got the following exception:

       

      09:53:42,358 INFO  [xnio] XNIO version 3.2.0.Final

      09:53:42,465 INFO  [nio] XNIO NIO Implementation Version 3.2.0.Final

      09:53:42,507 DEBUG [nio] Started channel thread 'Remoting "config-based-naming-client-endpoint" I/O-1', selector sun.nio.ch.WindowsSelectorImpl@4b4a5caf

      RmiServiceFactpry ExceptionInInitializerError

      java.lang.ExceptionInInitializerError

          at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:148)

          at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:106)

          at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:465)

          at org.jboss.naming.remote.client.ejb.RemoteNamingStoreEJBClientHandler.associate(RemoteNamingStoreEJBClientHandler.java:78)

          at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.<init>(RemoteNamingStoreV1.java:71)

          at org.jboss.naming.remote.protocol.v1.VersionOne.getRemoteNamingStore(VersionOne.java:50)

          at org.jboss.naming.remote.protocol.Versions.getRemoteNamingStore(Versions.java:55)

          at org.jboss.naming.remote.client.RemoteContextFactory.createVersionedStore(RemoteContextFactory.java:73)

          at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:202)

          at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)

          at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)

          at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)

          at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)

          at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)

          at java.naming/javax.naming.InitialContext.lookup(Unknown Source)

          at com.dataloy.client.core.RmiServiceFactory.createRemote(RmiServiceFactory.java:105)

          at com.dataloy.client.core.RmiServiceFactory.getServiceImpl(RmiServiceFactory.java:96)

          at com.dataloy.core.AbstractServiceFactory.getService(AbstractServiceFactory.java:58)

          at com.dataloy.DataloyEngine.getService(DataloyEngine.java:198)

          at com.dataloy.DataloyEngine.login(DataloyEngine.java:548)

          at com.dataloy.client.login.LoginPanel.doLogin(LoginPanel.java:511)

          at com.dataloy.client.login.LoginPanel.access$500(LoginPanel.java:56)

          at com.dataloy.client.login.LoginPanel$5.run(LoginPanel.java:452)

      Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make java.io.OptionalDataException(boolean) accessible: module java.base does not "opens java.io" to unnamed module @312002a1

          at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)

          at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)

          at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Unknown Source)

          at java.base/java.lang.reflect.Constructor.setAccessible(Unknown Source)

          at org.jboss.marshalling.Marshalling$OptionalDataExceptionCreateAction$1.run(Marshalling.java:385)

          at org.jboss.marshalling.Marshalling$OptionalDataExceptionCreateAction$1.run(Marshalling.java:381)

          at java.base/java.security.AccessController.doPrivileged(Native Method)

          at org.jboss.marshalling.Marshalling$OptionalDataExceptionCreateAction.<init>(Marshalling.java:381)

          at org.jboss.marshalling.Marshalling$OptionalDataExceptionCreateAction.<init>(Marshalling.java:376)

          at org.jboss.marshalling.Marshalling.<clinit>(Marshalling.java:374)

          ... 23 more

       

      I see there is some problem with the new module management introduced in Java 9, but I cannot understand what I should do.

      Regards, Andrea

        • 1. Re: Java 9 and EJB
          ctomc

          Well Java 9 is not done yet, it is still EA as in early access.

          As such expect lots of "unknown" problems with it when running existing application.

           

          The problem you see is related to jigsaw - modular system in JDK, it is related to the changes in how reflection works.

           

          We do test latest WildFly code with JDK9 early builds, some changes to make it work on JDK9 are are already part of WildFly 10.1

          Said all this, we know how you can make it work with latest builds, but this workarounds are not necessary to work with WildFly 8.

           

          this is set of parameters you need to pass to JVM to make most of app server and its testsuite work.

          --add-exports=java.base/sun.nio.ch=ALL-UNNAMED

          --add-opens=java.base/java.lang=ALL-UNNAMED

          --add-opens=java.base/java.lang.reflect=ALL-UNNAMED

          --add-opens=java.base/java.security=ALL-UNNAMED

          --add-opens=java.base/java.math=ALL-UNNAMED

          --add-opens=java.base/java.io=ALL-UNNAMED

          --add-opens=java.base/java.net=ALL-UNNAMED

          --add-opens=java.base/java.util=ALL-UNNAMED

          --add-opens=java.base/java.util.concurrent=ALL-UNNAMED

          --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED

          --add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED

          --add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED

          --add-opens=java.management/javax.management=ALL-UNNAMED

          --add-opens=java.management/javax.management.openmbean=ALL-UNNAMED

          --add-opens=java.naming/javax.naming=ALL-UNNAMED

          --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED

          --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED

          you can also see that in wildfly/pom.xml at master · wildfly/wildfly · GitHub

           

          For your exact case, i think you would at least need

          --add-exports=java.base/sun.nio.ch=ALL-UNNAMED

          --add-opens=java.base/java.lang=ALL-UNNAMED

          --add-opens=java.base/java.lang.reflect=ALL-UNNAMED

          --add-opens=java.base/java.io=ALL-UNNAMED

          --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED

          But as I said, that applies to latest versions of components.

          • 2. Re: Java 9 and EJB
            dmlloyd

            Note that this is just a temporary workaround.  We are working on ensuring that our libraries work with Java 9, and that Java 9 works with our libraries, by continued participation in JCP expert groups.

            • 3. Re: Java 9 and EJB
              andrea.biasillo

              Thank you Tomaz and David for your answers!

               

              What I am trying to do now is to continue to run Wildfly 8 with Java 8 and  run the client (JavaWS/Swing connected to Wildfly via EJB) with Java 9. Do you think that those VM parameters can help?

               

              Many regards,

              Andrea

              • 4. Re: Java 9 and EJB
                andrea.biasillo

                I tried to run Wildfly 8 against Java 9, but as you thought it did not work. I got work Wildfly 10 with Java  adding the parameterd that you suggested, it works fine, also my application. What still does not work is the client, I tried to add the suggested parameters to the jnlp file produced by the server but the client  failed to validate signing of launch file. Not very clear why, I have to investigate