Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

On 6/15/18 12:45 PM, Alan Bateman wrote: On 15/06/2018 20:14, mandy chung wrote: Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01/ This

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

On 15/06/2018 20:14, mandy chung wrote: Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01/ This looks okay (although "valid $java.home"

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

Hi Mandy The test that was added seems fine. Best Lance > On Jun 15, 2018, at 3:14 PM, mandy chung wrote: > > Alan, Lance, > > I added a test case for JDK-8205116 in > test/langtools/tools/jdeps/Options.java. > > Updated webrev for JDK-8205116 only: >

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01/ Mandy On 6/15/18 10:47 AM, Alan Bateman wrote: On 15/06/2018 17:34, mandy chung wrote: A

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

On 15/06/2018 17:34, mandy chung wrote: A simple cleanup to remove unused qualified exports in java.base. The webrev also includes a fix for JDK-8205116 (jdeps --system $java.home fails) that I uncovered through this process where I ran `jdeps --check java.base --system $java.home` on the JDK

Re: Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

On 15/06/2018 17:12, mandy chung wrote: This patch cleans up the list of upgradeable modules kept in test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take out the modules that have been removed. Looks okay to me. -Alan

Re: Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

Looks good to me. -- Kevin On 6/15/2018 9:12 AM, mandy chung wrote: This patch cleans up the list of upgradeable modules kept in test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take out the modules that have been removed. thanks Mandy ---

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

Hi Mandy, The changes look good Best Lance > On Jun 15, 2018, at 12:34 PM, mandy chung wrote: > > JDK-8205116

Review Request JDK-8200121: Remove unused qualified exports in java.base

A simple cleanup to remove unused qualified exports in java.base. The webrev also includes a fix for JDK-8205116 (jdeps --system $java.home fails) that I uncovered through this process where I ran `jdeps --check java.base --system $java.home` on the JDK binaries on several platforms. Webrev

Re: Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

+1 > On Jun 15, 2018, at 12:12 PM, mandy chung wrote: > > This patch cleans up the list of upgradeable modules kept in > test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take > out the modules that have been removed. > > thanks > Mandy > > ---

Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

This patch cleans up the list of upgradeable modules kept in test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take out the modules that have been removed. thanks Mandy --- a/test/jdk/jdk/modules/etc/UpgradeableModules.java +++

Re: ModuleLayer#layers() and Configuration#configurations() produces non-topological ordering

On 15/06/2018 04:37, Luke Hutchison wrote: : This code represents a preorder DFS. The resulting order is *not* a topological sort ordering. This can lead to an ancestral layer being listed in the final ordering before a descendant layer. For example, consider these four layer -> parent

Re: ModuleLayer#layers() and Configuration#configurations() produces non-topological ordering

On Thu, Jun 14, 2018 at 10:37 PM, Luke Hutchison wrote: > The list allLayers should be changed to a LinkedList, allowing nodes to be > pushed onto the beginning of the list, so that the ordering doesn't have to A small quibble: LinkedList should normally never be used. You can push things on

Tracking OpenJDK 9's usage and adoption rate via Maven Central

Hi all, Several Adopt members have gotten together to look at answering the questions of what percentage of the most popular (TBD what most popular is) projects on Maven central can: 1. Run on Java9+ 2. Use Automatic-Module-Name 3. Use module-info.java As a side effect we're also working with