August 2016 - core-libs-dev

RFR 8164705: Remove pathname canonicalization from FilePermission
by Weijun Wang 11 Oct '16

11 Oct '16

Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and leads to confusing results when symlinks are involved. The code change above removes the canonicalization. This means FilePermission on "/the/current/working/directory/x" no longer implies that on "x". Since this might bring quite some compatibility risk, the code change includes some tweaks in permission checking to make sure an app is still able to read "x" when the FilePermission granted is on "/the/current/working/directory/x". However, we still hope the policy to be updated to be consistent of how a file is actually accessed. No tweak is devoted to make granting "/this/is/a/symlink" to imply reading of "/the/actual/target/file", because we think it should not. This is quite a big behavior change. If it breaks your app/lib, or does not work with your customized security manager or policy implementation, please let us know. Feel free to provide any feedback. Finally, a new system property "jdk.filepermission.canonicalize" is introduced and it can be "true", "false", or "compat". The out-of-box default is "compat", which means no canonicalization with check tweaks. Thanks Max

3 11

RFR 9: JEP 290: Filter Incoming Serialization Data
by Roger Riggs 03 Oct '16

03 Oct '16

Please review the design, implementation, and tests of JEP 290: Filter Incoming Serialization Data[1] It allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. The JEP[1] has more detail on the background and scope. The core mechanism is a filter interface implemented by serialization clients and set on an |ObjectInputStream|. The filter is called during the deserialization process to validate the classes being deserialized, the sizes of arrays being created, and metrics describing stream length, stream depth, and number of references as the stream is being decoded. A process-wide filter can be configured that is applied to every ObjectInputStream. The API of ObjectInputStream can be used to set a custom filter to supersede or augment the process-wide filter. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ SpecDiff: http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream… http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter… Comments appreciated, Roger [1] JEP 290: https://bugs.openjdk.java.net/browse/JDK-8154961

8 36

RFR(L): 8151179: address issues raised by JCK team on JEP 274 API
by Michael Haupt 28 Sep '16

28 Sep '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151179 Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/ The change addresses concerns about the JEP 274 API that were raised by the JCK team. One consequence is that the convenience wrappers for the generic loop combinator are now somewhat restrictive about the handles passed to them as arguments. They have to be created with the appropriate matching signatures. This minor inconvenience is easily overcome by utilising available API such as MethodHandles.constant(), .empty(), or .dropToMatch(). In case the full handle signature inference power is desired, the generic loop combinator, MethodHandles.loop(), still provides this. Most of the changes affect the API documentation, but the behavioural changes in some of the methods also reflect on the pertaining tests. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

3 7

RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code
by Seán Coffey 22 Sep '16

22 Sep '16

Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html -- Regards, Sean.

4 14

Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions
by Stefan Bodewig 20 Sep '16

20 Sep '16

Hi, I've been told to ask for advice here. Over the past few weeks we've adapted the Apache Ant code base to JDK 9 well enough that Ant's own test suite works - almost. The onyl remaining issue really goes back to Java 1.7 and JAXP 1.4 when secure processing was introduced. If you are running an XSLT transform and it needs extensions - say the Xalan redirect extension - you can't do it if a SecurityManager has been set. https://bz.apache.org/bugzilla/show_bug.cgi?id=51668 This is causing quite a few problems for users running Ant from within IDEs which typically install SecurityManagers. One such instance it Ant's own <junitreport> task which uses XSLT and the redirect extension. Back in Java 1.7 we "solved" the problem with a hack. We simply disable secure processing mode via reflection https://github.com/apache/ant/commit/fe829a9d0fa679df3ae2cc4803e5236ed2ed5c… The module system now breaks the hack as we can no longer access the necessary field via reflection. Before we try to find new clever or stupid workarounds we may as well ask for advice on how to do it properly. This is our use-case: The user wants to execute Ant's <xslt>-Task from within Eclipse which has installed a SecurityManager and the transform requires an extension. How can we make this work? Cheers Stefan

2 7

RFR: 8153654: Update jdeps to be multi-release jar aware
by Steve Drach 16 Sep '16

16 Sep '16

Hi, Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with “version #/“ where version # is 9, 10, etc. webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/ <http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ <http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/> issue: https://bugs.openjdk.java.net/browse/JDK-8153654 <https://bugs.openjdk.java.net/browse/JDK-8153654> Thanks Steve

3 11

Review Request: JDK-8157464: StackWalker.getCallerClass() should not filter out non-invoker frames
by Mandy Chung 14 Sep '16

14 Sep '16

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.00/index.html StackWalker::getCallerClass() is specified to return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass(). StackWalker::getCallerClass() is not used by any @CallerSensitive method. Instead one intended usage of StackWalker::getCallerClass() is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). MethodHandle for @CS method behaves as if the caller is the lookup class. The actual caller class may not be the lookup class which is left as implementation details. This patch adjusts the stack walker to return the same caller as jdk.internal.reflect.Reflection::getCallerClass. Mandy

3 11

RFR: 6543126: Level.known can leak memory
by Daniel Fuchs 13 Sep '16

13 Sep '16

Hi, Please find below a fix for: 6543126: Level.known can leak memory https://bugs.openjdk.java.net/browse/JDK-6543126 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.00 This is a fix for a long standing issue: Level maintains a list of know levels which has strong references to any created levels. Because the references are strong references, they prevent the garbage collection of levels, level classes, and level class loaders. This fix changes the KnownLevel class to extend WeakReference<Level> in order to only retain a weak reference to custom level instances. best regards, -- daniel

5 34

Participating on https://bugs.openjdk.java.net/browse/JDK-8156070
by Jonathan Bluett-Duncan 12 Sep '16

12 Sep '16

Hi all, My name is Jonathan, and it's my first time posting to this mailing list. I'm writing to you all as I'm rather interested in contributing to this area of the OpenJDK. Particularly, I'm thinking I'd quite like to help out with one of the subtasks for the Immutable Collections enhancements <https://bugs.openjdk.java.net/browse/JDK-8156070>. However I don't have specific ideas and I don't know which of the subtasks would most closely match my skills and knowledge, so I wondered if I could have some guidance as to what I could do and how I can get started. FYI, I've partially read the contribution instructions <http://openjdk.java.net/contribute/>, and I just submitted an OCA earlier today, so I don't expect to be actually ready to participate until I hear back from Oracle, but nonetheless I'd like to try to get the ball rolling as soon as possible. Kind regards, Jonathan Bluett-Duncan

10 22

RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group"
by Ramanand Patil 08 Sep '16

08 Sep '16

Hi all, Please review this trivial fix which addresses the mentioned 2 bugs. Bugs: 1. https://bugs.openjdk.java.net/browse/JDK-8160951 2. https://bugs.openjdk.java.net/browse/JDK-8160958 Webrev: http://cr.openjdk.java.net/~rpatil/8160951%2b8160958/webrev.00/ Only test/TEST.groups is modified to add these tests to the required group. Regards, Ramanand.

2 2