few java 9 jigsaw pointers and thoughts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

few java 9 jigsaw pointers and thoughts

Romain Manni-Bucau
Hey guys,

not sure anyone tried to run tomee on java 9 but wondered if j9 module
system was kind of "fixed" since it was really broken last time i tested
and tried to run our simple-singleton sample today.

Have to admit I tend to think it is a feature breaiking java ecosystem but
here is a few more pragmatic feedback and how we can make this module
running:

- (easy) ORB/corba is not exported by default so we need to check by
reflection we can access it or not, I guess the fix for us is to remove
corba reference from our codebase, AFAIK it is not used and no more needed.
- (medium) bytecode reading: our current code base can read until java 8
bytecode and we need to upgrade xbean-asm-shaded and xbean-finder-shaded
(xbean snapshot is ready). We also need to upgrade the finders we have in
our codebase to ASM6 (java 9) but nothing hurting a lot - that's what we do
for each new java version.
- (unknown) we need all our dependencies to upgrade
- (open and likely hard if it takes into account our full stack) to run the
simple-singleton example I needed to add jaxb dependency (alternative is to
activate the module) and open a few modules, typically:

--add-modules java.logging --add-opens
java.logging/java.util.logging=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED

This globally request to add to our code the missing permission in the JVM
(keep in mind i ran simple-singleton which doesnt cover much of our
codebase/stack). The issue is this option is on the JVM so we can hide it
in tomee in catalina scripts and in arquillian through RemoteServer but for
embedded tests we'll require the user to do it.

We can likely rework a bit our code to not require them all (some are easy
to workaround like the logging one or the GET_PACKAGE usage for @Vetoed)
but when we'll start to create a module-info.java ourself and our stack
we'll not just be in the unamed module merged but in several modules we'll
need to maintain these references exactly like we did when we were still
handling OSGi and even if maven helps a bit it breaks the ability to change
a little bit the stack (it was common to upgrade cxf for instance) since it
depends if cxf export is stable or not.

I'm not yet sure how we want to tackle it. Good news is "yes it will work".
Bad one is "yes it will mess up each version".

I fear jigsaw can't be removed from java 9 anymore (not sure why to be
honest) but I start to wonder if we should do a system (subclassloader?) to
completely bypass it and keep user experience smooth.

Anyone having some other feedback?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Reply | Threaded
Open this post in threaded view
|

Re: few java 9 jigsaw pointers and thoughts

Bjorn Danielsson
Hi Romain and everyone,

I have just recently become aware of this issue with Java 9,
and I'm not sure I understand everything yet. But my spontaneous
reaction is that a classloader hack would be an acceptable solution,
because it's easy to understand for ordinary devops people.

Does anyone know if the Tomcat core team has been discussing this?
I haven't had time to follow any of the lists for ages unfortunately,
and googling has not been very helpful to me.

--
Bjorn Danielsson
Cuspy Code AB


Romain Manni-Bucau <[hidden email]> wrote:

> Hey guys,
>
> not sure anyone tried to run tomee on java 9 but wondered if j9 module
> system was kind of "fixed" since it was really broken last time i tested
> and tried to run our simple-singleton sample today.
>
> Have to admit I tend to think it is a feature breaiking java ecosystem but
> here is a few more pragmatic feedback and how we can make this module
> running:
>
> - (easy) ORB/corba is not exported by default so we need to check by
> reflection we can access it or not, I guess the fix for us is to remove
> corba reference from our codebase, AFAIK it is not used and no more needed.
> - (medium) bytecode reading: our current code base can read until java 8
> bytecode and we need to upgrade xbean-asm-shaded and xbean-finder-shaded
> (xbean snapshot is ready). We also need to upgrade the finders we have in
> our codebase to ASM6 (java 9) but nothing hurting a lot - that's what we do
> for each new java version.
> - (unknown) we need all our dependencies to upgrade
> - (open and likely hard if it takes into account our full stack) to run the
> simple-singleton example I needed to add jaxb dependency (alternative is to
> activate the module) and open a few modules, typically:
>
> --add-modules java.logging --add-opens
> java.logging/java.util.logging=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
>
> This globally request to add to our code the missing permission in the JVM
> (keep in mind i ran simple-singleton which doesnt cover much of our
> codebase/stack). The issue is this option is on the JVM so we can hide it
> in tomee in catalina scripts and in arquillian through RemoteServer but for
> embedded tests we'll require the user to do it.
>
> We can likely rework a bit our code to not require them all (some are easy
> to workaround like the logging one or the GET_PACKAGE usage for @Vetoed)
> but when we'll start to create a module-info.java ourself and our stack
> we'll not just be in the unamed module merged but in several modules we'll
> need to maintain these references exactly like we did when we were still
> handling OSGi and even if maven helps a bit it breaks the ability to change
> a little bit the stack (it was common to upgrade cxf for instance) since it
> depends if cxf export is stable or not.
>
> I'm not yet sure how we want to tackle it. Good news is "yes it will work".
> Bad one is "yes it will mess up each version".
>
> I fear jigsaw can't be removed from java 9 anymore (not sure why to be
> honest) but I start to wonder if we should do a system (subclassloader?) to
> completely bypass it and keep user experience smooth.
>
> Anyone having some other feedback?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
Reply | Threaded
Open this post in threaded view
|

Re: few java 9 jigsaw pointers and thoughts

Romain Manni-Bucau
2017-03-20 21:17 GMT+01:00 Bjorn Danielsson <
[hidden email]>:

> Hi Romain and everyone,
>
> I have just recently become aware of this issue with Java 9,
> and I'm not sure I understand everything yet. But my spontaneous
> reaction is that a classloader hack would be an acceptable solution,
> because it's easy to understand for ordinary devops people.
>
>
Hmm, not sure it would be easy cause it can lead to bypass the JVM for the
JVM classes so can be quite tricky to get right (and slower at startup)


> Does anyone know if the Tomcat core team has been discussing this?
> I haven't had time to follow any of the lists for ages unfortunately,
> and googling has not been very helpful to me.
>
>
They worked with Java core dev to make their code passing but I don't think
the overall system (jvm+server+apps+libs) has been discussed.


> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> Romain Manni-Bucau <[hidden email]> wrote:
> > Hey guys,
> >
> > not sure anyone tried to run tomee on java 9 but wondered if j9 module
> > system was kind of "fixed" since it was really broken last time i tested
> > and tried to run our simple-singleton sample today.
> >
> > Have to admit I tend to think it is a feature breaiking java ecosystem
> but
> > here is a few more pragmatic feedback and how we can make this module
> > running:
> >
> > - (easy) ORB/corba is not exported by default so we need to check by
> > reflection we can access it or not, I guess the fix for us is to remove
> > corba reference from our codebase, AFAIK it is not used and no more
> needed.
> > - (medium) bytecode reading: our current code base can read until java 8
> > bytecode and we need to upgrade xbean-asm-shaded and xbean-finder-shaded
> > (xbean snapshot is ready). We also need to upgrade the finders we have in
> > our codebase to ASM6 (java 9) but nothing hurting a lot - that's what we
> do
> > for each new java version.
> > - (unknown) we need all our dependencies to upgrade
> > - (open and likely hard if it takes into account our full stack) to run
> the
> > simple-singleton example I needed to add jaxb dependency (alternative is
> to
> > activate the module) and open a few modules, typically:
> >
> > --add-modules java.logging --add-opens
> > java.logging/java.util.logging=ALL-UNNAMED
> > --add-opens=java.base/java.lang=ALL-UNNAMED
> >
> > This globally request to add to our code the missing permission in the
> JVM
> > (keep in mind i ran simple-singleton which doesnt cover much of our
> > codebase/stack). The issue is this option is on the JVM so we can hide it
> > in tomee in catalina scripts and in arquillian through RemoteServer but
> for
> > embedded tests we'll require the user to do it.
> >
> > We can likely rework a bit our code to not require them all (some are
> easy
> > to workaround like the logging one or the GET_PACKAGE usage for @Vetoed)
> > but when we'll start to create a module-info.java ourself and our stack
> > we'll not just be in the unamed module merged but in several modules
> we'll
> > need to maintain these references exactly like we did when we were still
> > handling OSGi and even if maven helps a bit it breaks the ability to
> change
> > a little bit the stack (it was common to upgrade cxf for instance) since
> it
> > depends if cxf export is stable or not.
> >
> > I'm not yet sure how we want to tackle it. Good news is "yes it will
> work".
> > Bad one is "yes it will mess up each version".
> >
> > I fear jigsaw can't be removed from java 9 anymore (not sure why to be
> > honest) but I start to wonder if we should do a system (subclassloader?)
> to
> > completely bypass it and keep user experience smooth.
> >
> > Anyone having some other feedback?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
>