On Wed, Sep 21, 2016 at 7:13 PM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> I conducted some testing to try to run Java 9 modular JRE on OSv (java.base)
> and it requires changing java.cc to make runjava.jar get loaded by system
> classloader instead of extension classloader. It turns out that was
> extension classloader is removed from Java 9 (more specifically Java 9 will
> not start if lib/ext is present).
>
> Does anybody remember what was the reason to load runjava.jar by extension
> classloader instead of explicitly setting java.class.path to the path of the
> jar and thus loading using the system loader?

The reason is explained in the commit which introduced the change:

commit 72c64ce02268d0e497e3c8866c00a2b3b9eb5962
Author: Tomasz Grabiec <tgrab...@cloudius-systems.com>
Date:   Fri Jun 6 17:24:59 2014 +0200

    java: make runjava.jar domain all-privileged

    When application installed a SecurityManager, child protection domains
    would have been declined the right to read files from their jar. This
    was making apache derby fail with this:

    java.util.MissingResourceException: Can't find bundle for base
name org.apache.derby.loc.drda.messages, locale en
        at 
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1499)
        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1322)
        at java.util.ResourceBundle.getBundle(ResourceBundle.java:795)
        at 
org.apache.derby.iapi.tools.i18n.LocalizedResource.setResource(LocalizedResource.java:184)
        at 
org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(LocalizedResource.java:311)
        at 
org.apache.derby.iapi.tools.i18n.LocalizedResource.getTextMessage(LocalizedResource.java:273)
        at 
org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java:3536)
        at 
org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java:3492)
        at 
org.apache.derby.drda.NetworkServerControl.installSecurityManager(NetworkServerControl.java:705)

    The bundle actually exists and resides in derbynet.jar but since we
    have a SecurityManager installed and runjava.jar domain, which is a
    parent of derbynet.jar, does not have permissions for reading other
    jars than itself we fail on permission check inside the class
    loader. When the same code is run on the host it passes the check
    because derbynet.jar is invoked directly from an all-privileged
    context. I think the solution is to make our runjava.jar
    all-privileged by default. One way to do that is to grant the
    permissions explicitly in the java.policy file, or put runjava.jar in
    the extensions directory (/usr/lib/jvm/jre/lib/ext). The latter is
    simpler so I went with that approach.


If I understand runjava
> classloading related logic in the "isolated JVM" mode it uses special
> OsvSystemClassLoader which then ends up creating child AppClassLoader for
> each app. I think it would work if runjava.jar was loaded by regular system
> classloader instead of the extension one. I could test that but I wonder if
> there were some gotchas with apps  running in Tomcat or other J2E app
> servers.
>
> Another observation is that MultiJarLoader or "isolated JVM" mode will only
> work if Java 9 JRE image (created by jlink) contains java.beans module (same
> applies to Java 8 compact profiles).
>
> Modular JRE - http://openjdk.java.net/jeps/220 (look for Removed: The
> extension mechanism)
> jlink - http://openjdk.java.net/jeps/282
> http://openjdk.java.net/jeps/200
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to