RFR JDK-8181425: Reflection API defend against issues with internal VM derived value type

[Maurizio Cimadamore]

Hi Mandy - overall looks very good. One question - is this code correct?

public static Class<?> loadValueTypeClass(Class<?> vcc, String className) {
  113         if (!isValueType(vcc)) {
  114             throw new IllegalArgumentException(vcc.getName() + " is a derived value class");
  115         }
  116         return JLA.loadValueTypeClass(vcc.getModule(), vcc.getClassLoader(), className);
  117     }


If so, doesn't that lead to contradiction when called from the one below:

90     public static Class<?> getValueTypeClass(Class<?> x) throws ClassNotFoundException {
   91         if (isValueType(x)) {
   92             throw new IllegalArgumentException("Expected Value Capable Class");
   93         }
   94         return loadValueTypeClass(x, getValueTypeClassName(x.getName()));
   95     }

In other words, getValueTypeClass seems to test that the incoming class 
is a VCC, then passes it along to loadValueTypeClass, which seems to 
test the opposite condition.

Am I missing something?

Maurizio

On 20/06/17 21:31, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8181425/webrev.00/index.html
>
> This patch changes Class::forName to not to return DVT classes
> and also disallows reflection API get members of a DVT class.
> ClassLoader::loadClass should probably be changed and I can
> fix that separately.
>
> I added a couple of new tests and also fix the MVT tests with
> GPL header rather than GPL+CP header.
>
> Mandy