@tcrawley for the JDK 9 reflection patch, do we need to handle non-reflective access as well? As in: for paths that generate properly linked non-reflective bytecode that pass through getMethods() do those need to have tighter criteria for linkage/emission?

@ghadi the restrictions only apply to reflective access, but I'm not familiar with the paths you are referring to - are they holding a reference to a method object obtained reflectively, then invoking it?

as in, when we emit non-reflective (invokevirtual/invokeinterface/invokestatic) bytecode that calls a method on a class, but the class is inside a non-exported package

that works in JDK8 but not in JDK9

I'll cook up an actual scenario

it's the same exact problem as the reflective access

yeah, if that fails, we'll have to cook up a solution. It would be different though, since it would have to be a compile-time vs run-time check

which may mean asking the module system if the class is public

which would mean Java9-specific code

(I don't see a great way around MRJARs, and I don't think MRJARs are that bad. Just more upfront work for us.)

I agree, but will admit to being intimidated by the idea of getting it all working with mvn