Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

Sent from my iPad > On Aug 4, 2016, at 11:18 PM, Alan Bateman wrote: > >> On 04/08/2016 10:33, Patrick Reinhart wrote: >> >> Hi Paul, >> >> I was quit busy lately and this comes a bit late, I guess you do not have >> less work ;-) >> >> On 15.07.2016 17:10, Paul Sandoz wrote: When I u

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

On 04/08/2016 10:33, Patrick Reinhart wrote: Hi Paul, I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) On 15.07.2016 17:10, Paul Sandoz wrote: When I understand you correctly here we should concentrate on the public methods naming firstly? I initially w

Re: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation

> On Aug 4, 2016, at 6:36 PM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163116 Looks fine and it’s right to use the os.name from java.base module descriptor to determine the tar

Re: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation

On 04/08/2016 18:36, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163116 No cross platform test added. Existing test fixed to use java.base/module-info.class. Also, piggybacking to fix FileC

Re: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation

+1 /Claes On 08/04/2016 06:36 PM, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163116 No cross platform test added. Existing test fixed to use java.base/module-info.class. Also, piggybackin

RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation

Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163116 No cross platform test added. Existing test fixed to use java.base/module-info.class. Also, piggybacking to fix FileCopierPluginTest to avoid catching PluginException. -Sund

RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

Hi Paul, I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) On 15.07.2016 17:10, Paul Sandoz wrote: >> When I understand you correctly here we should concentrate on the public >> methods naming firstly? I initially was not sure, what a proper naming >> for th

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

Hi Masayoshi, Just a thought. What if RB.clearCache(classLoader) was specified as equivalent to RB.clearCache(classLoader.getUnnamedModule()) ? I think that would be backwards compatible... Regards, Peter On 08/02/2016 05:30 PM, Masayoshi Okutsu wrote: Hi Peter, Thanks for bringing up the

Re: RFR 8146721: FileCopierPlugin should not create fake module

On 04/08/2016 04:47, Sundararajan Athijegannathan wrote: Fixed: http://cr.openjdk.java.net/~sundar/8146721/webrev.01/ This looks okay, for now at least, but I assume having the resource in /java.base/other will need to be examined once other issues (like per module man pages, the top section

Re: Exporting - the wrong default?

On 02.08.2016 19:43, Eric Johnson wrote: So we really want a place where people can start using modules at compile time, and choose to opt into module boundary enforcement at runtime. I think that Alex goes a bit into all that in the unnamed and automatic module sections in his JVM Language Su

Re: RFR(L) 8136930: Simplify use of module-system options by custom launchers

Hi, Please review this update for this fix. This webrev only shows the changes since the last webrev. These changes include: 1. Fix forJDK-8162415 - the JVM now prints the following message when ignoring a property and PrintWarnings

Re: RFR 8146721: FileCopierPlugin should not create fake module

Fixed: http://cr.openjdk.java.net/~sundar/8146721/webrev.01/ Thanks, -Sundar On 8/4/2016 4:22 PM, Jim Laskey (Oracle) wrote: > Fix grammar on FileCopierPluginTest.java: "We didn't add any .class resources > of java.base module!” > > +1 > > > >> On Aug 4, 2016, at 6:10 AM, Sundararajan Athijega

Re: RFR 8146721: FileCopierPlugin should not create fake module

Fix grammar on FileCopierPluginTest.java: "We didn't add any .class resources of java.base module!” +1 > On Aug 4, 2016, at 6:10 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8146721/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8

Re: ResourceBundleProvider(s) design

On 08/04/2016 11:21 AM, Peter Levart wrote: If the providing module declares the service type, then the consuming module will have an explicit dependency on the providing module, which also defeats the purpose of service provider's implicit coupling. I take this back. The service type is reso

ResourceBundleProvider(s) design

Hi, I would like to ask about why java.util.spi.ResourceBundleProvider is designed they way it is. I'm questioning the design of the following part of specification: "The provider service type is determined by {@code basename+"Provider"}." Why is that necessary? It requires that provid

RFR 8146721: FileCopierPlugin should not create fake module

Please review http://cr.openjdk.java.net/~sundar/8146721/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8146721 Thanks, -Sundar