[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20

["Richard N. Hillegas (Jira)" <ji...@apache.org>]

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

Richard N. Hillegas commented on DERBY-7149:
--------------------------------------------

The breakage in CacheManagerMBeanTest is caused by a security enhancement in the JVM. RMI-initiated deserialization has been locked down. A new filter must be relaxed in order to deserialize information exposed by our MBeans, when running the beans remotely over RMI. The filter is declared by the following Oracle-specific property in $JAVA_HOME/conf/management/management.properties:

{noformat}
com.sun.management.jmxremote.serial.filter.pattern
{noformat}

Open JDK build 20-ea+27-2213 sets this property as follows:

{noformat}
com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!*
{noformat}

The filter cannot be overridden on the boot command line via a system property. The filter can only be relaxed by hacking the JVM, that is, by editing $JAVA_HOME/conf/management/management.properties.

But this filter must be relaxed in order to use our MBeans over RMI in order to examine the page and statement caches. The following brute-force, bulk relaxation works:

{noformat}
com.sun.management.jmxremote.serial.filter.pattern=*
{noformat}

I have not dug further into this to discover whether our MBeans would work with a narrower filter, tailored to a few specific classes. Our MBeans are not particularly useful and I don't think many applications use them. I regard our MBeans as a proof of concept which someone could build on. No-one has done so. I do not see much value in investing more work in a rarely used feature which is becoming harder to use.

The following links explain something about this JVM behavior change:

  https://bugs.openjdk.org/browse/JDK-8283093

  https://bugs.openjdk.org/browse/JDK-8295938

I intend to modify CacheManagerMBeanTest so that it skips the failing tests when the default, restrictive filter is in place. I think it would also be a good idea to modify our MBean documentation to describe this problem and its workaround.


> Make it possible to build and test Derby cleanly with JDK 20
> ------------------------------------------------------------
>
>                 Key: DERBY-7149
>                 URL: https://issues.apache.org/jira/browse/DERBY-7149
>             Project: Derby
>          Issue Type: Task
>          Components: Build tools
>    Affects Versions: 10.17.0.0
>            Reporter: Richard N. Hillegas
>            Assignee: Richard N. Hillegas
>            Priority: Major
>         Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, derby-7149-01-ac-deprecateURLconstructor.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)