> On Aug 27, 2017, at 4:07 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 27/08/2017 05:00, Russell Gold wrote: >> >> When you say it is open to all unnamed modules, do you mean open with >> warnings? How do you declare a module open? I don’t see that in the current >> module documentation. Why is it only open to unnamed modules, and how can we >> detect that a warning would be given? Our goal is to avoid the manipulations >> that will result in warnings (and therefore be forbidden in future versions >> of Java). > The packages that existed in JDK 8 and still exist in JDK 9 are open to code > on the class path (or more generally all unnamed) modules to allow existing > bad code to continue to work. There is a detailed note in JDK 9 release notes > [1] on this topic and there will be further details on this in the upcoming > JDK 9 docs. > > There isn't any programmatic way to know in advance if a warning will be > printed. It's easy to test if packages are open to only all unnamed modules > but this isn't enough - the reason is that packages can be opened explicitly, > via --add-opens`, and there won't be warnings there there an otherwise > illegal access to a member of the packages opened this way.
That’s unfortunate; I had hoped that one of the real advantages of the warning system was to allow us to degrade gracefully, putting in code that would continue to work the old way in JDK8 but use new mechanisms only when required. > >> >> This is not related to IIOP, but some proprietary deserialization, which was >> written using some rather nasty manipulations via reflection. The code in >> question allows us to detect that those tricks won’t work (without >> warnings), and gracefully degrade to an alternative, albeit slower, >> implementation. Because of the way it works, ReflectionFactory is >> insufficient. The goal is to recognize which reflection calls are likely to >> be permitted, and which are not. It is a step away from the current hack. In >> practice, it means that it works one way in JDK8 and a different way in JDK9 >> or later. > Have you looked at using multi-release JARs? I’m using them where I can; the problem is that the tooling isn’t there, yet. I have found numerous temporary solutions, but none of them allow for unit testing against both the old and new code, and most run into compatibility issues with various plugins. I use a multi-release jar in PFL, and am trying to add one to SimpleStub, but the tooling gaps make it very painful; however, the lack of a runtime ability to detect bad accesses means that the advantage of MR jars is diminished in several use cases, and I will look into other approaches. Thanks, Russ
