Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream
On 2016-09-02 08:09, Andrej Golovnin wrote: src/java.base/share/classes/java/lang/ClassLoader.java The constant RESOURCE_CHARACTERISTICS in the line 215 should be defined near the #streamOf()-method. The distance between the line 1412 where the #streamOf()-method is defined and the line 215 is just too huge. No problem, moved to the method itself Your patch seems to modify the JavaDocs of the methods #getParent(), #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how it is related to the issue you try to solve.> Was a merge issue, removed those test/java/lang/ClassLoader/resources/ResourcesFailureCase.java test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java The indentation is broken. You use tabs. But in JDK you must use spaces, see http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation Fixed those also. See updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 - Patrick
Re: RFR 8157992: Improve jlink help message on optimization-related options
On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8157992 "details" should have one "d" :-) Looks fine otherwise.
Re: Multiple versions of a non-exported dependency
On 01/09/2016 21:04, cowwoc wrote: Another possibility (not saying it's better, just putting it out there) is to do the following: 1. Provide a tool like "javah" that would generate module-info.java for non-modularized JAR files. Look at `jdeps --gen-module-info ..`. It's a starting point to create a source file that is easy to edit (see the slide decks). It's not difficult to write your own ModuleFinder that reads the module declaration from elsewhere if you really want. If you are willing to write a module declaration for each of the 100 JAR files on your class path then more power to you. To be honest, the feedback over the years has almost always been that developers don't want to take responsibility for libraries maintained by others. This usually means they won't want to write/maintain the module declaration for libraries that they won't own, or they don't know enough about the code in these components to be confident that the module declaration is correct. -Alan
Re: RFR 8157992: Improve jlink help message on optimization-related options
Cleas, Alan: Thanks for the reviews. Uploaded updated webrev for the record: http://cr.openjdk.java.net/~sundar/8157992/webrev.02/ And going ahead with push.. Thanks. -Sundar On 9/2/2016 1:42 PM, Alan Bateman wrote: > On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ >> for https://bugs.openjdk.java.net/browse/JDK-8157992 >> > "details" should have one "d" :-) Looks fine otherwise.
Re: Multiple versions of a non-exported dependency
On 09/02/2016 10:27 AM, Alan Bateman wrote: On 01/09/2016 21:04, cowwoc wrote: Another possibility (not saying it's better, just putting it out there) is to do the following: 1. Provide a tool like "javah" that would generate module-info.java for non-modularized JAR files. Look at `jdeps --gen-module-info ..`. It's a starting point to create a source file that is easy to edit (see the slide decks). It's not difficult to write your own ModuleFinder that reads the module declaration from elsewhere if you really want. If you are willing to write a module declaration for each of the 100 JAR files on your class path then more power to you. To be honest, the feedback over the years has almost always been that developers don't want to take responsibility for libraries maintained by others. This usually means they won't want to write/maintain the module declaration for libraries that they won't own, or they don't know enough about the code in these components to be confident that the module declaration is correct. -Alan Seems the main reason why automatic modules need to see the classpath UNNAMED module is there might be conflicting packages on that classpath which modularization would be non trivial (would require custom ModuleFinders, Layers and ClassLoader factories). Yes, automatic modules help in such scenarios. Will Java support classpath forever or there are plans to remove it? Asking because if classpath would be removed some time in the future such compromise (automatic modules) is just short term win affecting many key design decisions. Richard
Re: Multiple versions of a non-exported dependency
On 02/09/2016 10:35, Richard Opalka wrote: : Will Java support classpath forever or there are plans to remove it? Asking because if classpath would be removed some time in the future such compromise (automatic modules) is just short term win affecting many key design decisions. I'm not aware of any proposal to drop the class path, it's just too entrenched. Remember that we are retrofitting modules to a mature platform and so migration, compatibility, and interoperability have to be at the fore. -Alan.
Re: RFR 8157992: Improve jlink help message on optimization-related options
+1 > On Sep 2, 2016, at 6:10 AM, Sundararajan Athijegannathan > wrote: > > Cleas, Alan: > > Thanks for the reviews. Uploaded updated webrev for the record: > http://cr.openjdk.java.net/~sundar/8157992/webrev.02/ > > And going ahead with push.. > > Thanks. > > -Sundar > > > On 9/2/2016 1:42 PM, Alan Bateman wrote: >> On 02/09/2016 07:07, Sundararajan Athijegannathan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ >>> for https://bugs.openjdk.java.net/browse/JDK-8157992 >>> >> "details" should have one "d" :-) Looks fine otherwise. >
