db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5840) Clean up compiler warnings introduced by using Java 5 language features
Date Fri, 13 Jul 2012 15:25:35 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413816#comment-13413816

Knut Anders Hatlen commented on DERBY-5840:

I found that I got a sealing violation error when I tried to start the network server with
"java -jar derbynet.jar start" after applying the 03-aa patch:

$ java -jar derbynet.jar start
Fri Jul 13 16:12:58 CEST 2012 : Security manager installed using the Basic server security
Exception in thread "main" java.lang.ExceptionInInitializerError
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:186)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1008)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:711)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2226)
	at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:352)
Caused by: java.lang.SecurityException: sealing violation: package org.apache.derby.mbeans
is sealed
	at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:388)

The JUnit tests would fail for similar reasons if derbynet.jar appeared before derby.jar on
the classpath.

The reason was that org.apache.derby.mbeans.VersionMBean ended up both in derby.jar and derbynet.jar,
and it should only be in derby.jar.

NetworkServerControlImpl has a reference to VersionMBean.class, and so it did before the patch:

        final Object versionMBean = mgmtService.registerMBean(
                           new Version(

When I disassembled the old and the new version of the NetworkServerControlImpl class, I found
that the old version, compiled with target level 1.4, had no reference to VersionMBean.class,
only to the string "org.apache.derby.mbeans.VersionMBean". The byte code would dynamically
load the class when the code that referenced it was invoked. Since there's no reference to
the class, classlister couldn't find it. When compiled with target level 1.5, on the other
hand, the byte code would have a direct reference to the class instance, and that enables
classlister to find the dependency.

I think the fix is to make classlister ignore the org.apache.derby.mbeans package when building
the list of classes to include in derbynet.jar. It already has a list of other engine packages
to exclude, so we could add the package to that list.
> Clean up compiler warnings introduced by using Java 5 language features
> -----------------------------------------------------------------------
>                 Key: DERBY-5840
>                 URL: https://issues.apache.org/jira/browse/DERBY-5840
>             Project: Derby
>          Issue Type: Improvement
>          Components: Miscellaneous
>    Affects Versions:
>            Reporter: Rick Hillegas
>         Attachments: derby-5840-01-aa-compatibilityTests.diff, derby-5840-02-aa-compatibilityTests-again.diff.txt,
> Using Java 5 language features forces us to compile code at level 5 or higher. At this
level, the compiler raises warnings not seen at lower levels. This issue is a place to discuss
and attach cleanup to eliminate these warnings.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message