JDK9 encapsulation problem

[Stephen Felts]

This is a general problem with utility programs.  This isn't, unlike the sample, something where I can just re-code it to use the public interface.  The utility program isn't checking to see what is public and what is not.  It looks up the class and invokes on it, creating or opening the object.  Then the object is used for further operations.  The class is public.  We grep'ed the entire code base looking for an import or dynamic reference to the internal API but obviously didn't find it.

This is an interpreted language where obj = clzz.open();  obj.method2() is invoked in a general purpose way.

 

Class clzz = Class.forName("clzz");

Method m = clzz.getMethod("open");

Object obj = m.invoke(null);

Method m2 = obj.getClass().getMethod("method2");

m.setAccessible(true);

m2.invoke(obj);

 

If this problem isn't fixed in the JDK, then I might have code that works in JDK 9 and is broken when someone decides to re-implement something directly using an internal package in JDK 10.

 

 

 

 

-----Original Message-----
From: Peter Levart [mailto:peter.levart at gmail.com] 
Sent: Friday, September 09, 2016 11:54 AM
To: Stephen Felts; jigsaw-dev at openjdk.java.net
Subject: Re: JDK9 encapsulation problem

 

Hi Stephen,

 

 

On 09/09/2016 04:30 PM, Stephen Felts wrote:

> We have an application that is running into a problem with a utility program.  Below is a standalone reproducer.

> 

>   

> 

> The program does not import the SPI package sun.nio.ch - it isn't 

> aware of

> 

> it, and SocketChannel.isConnected() is a public method of a public 

> type. In

> 

> short, it does not break any law of encapsulation, so call

> 

> setAccessible(true) should be OK.

 

Ok, but...

 

> 

>   

> 

> import java.lang.reflect.Method;

> 

>   

> 

>   

> 

> public class JDK9Nio {

> 

>    public static void main(String args[]) throws Exception {

> 

>      call();

> 

>    }

> 

>   

> 

>    public static void call() throws Exception {

> 

>      Class clzz = Class.forName("java.nio.channels.SocketChannel");

> 

>      Method open = clzz.getMethod("open");

> 

>      Object obj = open.invoke(null);

> 

>      Method isConn = obj.getClass().getMethod("isConnected");

 

...This is a classical reflection anti-pattern. What program should be doing to call the public and exported SocketChannel.isConnected() method is the following:

 

Method isConn = SocketChannel.class.getMethod("isConnected");

 

obj.getClass().getMethod(...) is rarely what is desired. What you get back is a Method object for method declared in a package-private class. 

That's why setAccessible() was needed. And now in JDK 9, this class is also in a non-exported package, so setAccessible() does not help any more. But I see your point. It worked before and is not working any more...

 

> 

>      isConn.setAccessible(true); // OK with JDK8, fail with JDK9

> 

>      System.out.println(isConn.invoke(obj));

> 

>    }

> 

> }

> 

>   

> 

>   

> 

> java JDK9Nio

> 

> Exception in thread "main" 

> java.lang.reflect.InaccessibleObjectException: Unable to make member 

> of class sun.nio.ch.SocketChannelImpl accessible:  module java.base 

> does not export sun.nio.ch to unnamed module @3857f613

> 

>          at 

> jdk.internal.reflect.Reflection.throwInaccessibleObjectException(java.

> HYPERLINK "mailto:base at 9-ea/Reflection.java:414"base at 9-ea/Reflection.java:414)

> 

>          at 

> java.lang.reflect.AccessibleObject.checkCanSetAccessible(HYPERLINK "mailto:java.base at 9-e"java.base at 9-e

> a/AccessibleObject.java:174)

> 

>          at 

> java.lang.reflect.Method.checkCanSetAccessible(HYPERLINK "mailto:java.base at 9-ea/Method.j"java.base at 9-ea/Method.j

> ava:192)

> 

>          at 

> java.lang.reflect.Method.setAccessible(HYPERLINK "mailto:java.base at 9-ea/Method.java:186"java.base at 9-ea/Method.java:186)

> 

>          at JDK9Nio.call(JDK9Nio.java:14)

> 

>          at JDK9Nio.main(JDK9Nio.java:6)

> 

>   

> 

>   

> 

>   

> 

> It's easy to say that the program should be re-written and the setAccessible is not necessary but this is a utility program over which the application has no control (a jython script).

> 

> What's ugly is that the internal implementation is showing through to the application.

 

Maybe there could be a solution in supporting such sloppy programming though. If the reflective invocation is performed to a virtual method, then the JVM virtual dispatch chooses the method declared in the most specific class regardless of what the Method object used is telling about the method's declaring class. So if there exists at least one matching method declared in the hierarchy of types comprising the runtime type of the object upon which the method is being invoked, and such method is accessible to the invoker, such invocation could be allowed. The rationale is simple: if the invocation dispatches to the same method for distinct Method objects, it should also succeed or not succeed consistently regardless of which Method object was used to perform the invocation.

 

But such access check would surely be much slower. It's better to just fix the program (if you can :-( ).

 

Regards, Peter

 

> 

>   

> 

> Many people especially tool makers have this problem:

> 

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318

> 

> https://netbeans.org/bugzilla/show_bug.cgi?id=258952

> 

> https://netbeans.org/bugzilla/show_bug.cgi?id=262765

> 

> http://mail.openjdk.java.net/pipermail/quality-discuss/2015-November/0

> 00468.html

> 

> https://community.oracle.com/thread/3937249

> 

>   

> 

>