Re: Exporting - the wrong default?

On 29.07.2016 16:55, David M. Lloyd wrote: On 07/29/2016 09:20 AM, dalibor topic wrote: Is it safe to assume that all potentially headache inducing Guns and Bullets are always kept under lock in non-public classes? Of course, that's why we had non-public classes in the first place. OK, le

Re: Exporting - the wrong default?

On 29/07/16 21:13, Alex Buckley wrote: > Mark already discussed with Jason how a container can rewrite > descriptors as modules are being spun up [1] so I'm struggling to see > the problem unless there is some burning desire to rewrite the > descriptor by hand prior to run time. I can understand th

Re: Flag missing with "requires java.base"?

On 29/07/16 19:34, Alex Buckley wrote: > On 7/29/2016 12:48 AM, Andrew Dinn wrote: >> It might be worth pointing out at this stage in the discussion that >> ACC_SYNTHETIC was never given a hard and fast meaning whose logic >> transcends the vagaries of what javac decided to use it for -- citation

Re: RFR 8157135, Fix module dependencies javax/* EE tests

On 31/07/2016 23:48, Felix Yang wrote: Hi all, please review the patch for some tests, which explicitly declare module dependencies to EE modules. Bug: https://bugs.openjdk.java.net/browse/JDK-8157135 Webrev: http://cr.openjdk.java.net/~xiaofeya/8157135/webrev.00/ This is a partial fix

Re: RFR 8162782: jlink ResourcePool.releaseProperties should be removed

On 31/07/2016 20:29, Sundararajan Athijegannathan wrote: Hi, I'll handle that issue in another fix. Okay. One thing with the current patch is that the try/catch in releaseProperties isn't clear. Also in ResourcePoolEntry, where it defines TOP, it says "jdk image directory" then I assume it

Re: Exporting - the wrong default?

On 08/01/2016 05:40 AM, dalibor topic wrote: On 29.07.2016 16:55, David M. Lloyd wrote: On 07/29/2016 09:20 AM, dalibor topic wrote: Is it safe to assume that all potentially headache inducing Guns and Bullets are always kept under lock in non-public classes? Of course, that's why we had n

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

Hi Masayosh, Alan, Thanks for looking at the change. I suppose application containers are already accustomed to invoke ResourceBundle.clearCache(ClassLoader) when undeploying an application so that the corresponding ClassLoader can get GCed right away. But there's a change in the semantics of

Re: Exporting - the wrong default?

Hi, On 07/26/2016 06:42 PM, Stephen Colebourne wrote: If the default does not change, then I assume the tools will effectively work around it. ie. that Maven will have an option to export all packages not explicitly hidden. Anything else would be far too annoying for development. Stephen PS, I

SPI for customizing modules?

Jigsaw Experts, It seems the only way to customize modules is not to use --module-path. It seems if I want to customize, I have to load myself. Right or wrong? I am looking for an SPI where I can customize any non-JDK module. I believe this would be easier than the current path I am on. I'd rathe

Issue with an automatic module

Hi i was trying to play around latest jigsaw version in order to adapt an open source projet that i developed and i found the following issue. When using a jar containing a class with no package, the modulefinder is failing to create its module descriptor. It guesses that it is an automatic m

Re: Exporting - the wrong default?

To echo David, there is a complaint by me in these archives how I still find it difficult to remember that "public" is no longer being public. I feel the same way today still. The word "public" means "for everyone" so it's always jarring to have it no longer mean what it should mean in normal Engli

Re: Exporting - the wrong default?

I don't think public ever meant "public to the world". In Java 1->8 it means "visible to those who can see the containing scope". If you declare a public inner class in a private (or package-private) class, then those who cannot access the outer type also cannot access the public inner class.

Re: Exporting - the wrong default?

Stephane, please take my words within context. I wasn't being too technical; just merely using "public to the world" with regards to exporting packages. However, I appreciate your technical eye to get the details right. Thanks for the broader explanation. Cheers, Paul On Mon, Aug 1, 2016 at 10:58

Re: Issue with an automatic module

On 01/08/2016 08:37, charbel yazbeck wrote: Hi i was trying to play around latest jigsaw version in order to adapt an open source projet that i developed and i found the following issue. When using a jar containing a class with no package, the modulefinder is failing to create its module de

Re: RFR 8162782: jlink ResourcePool.releaseProperties should be removed

I had moved that try..catch code to read module descriptor from elsewhere. When I removed that try..catch, I got test failures. Found another lurking issue on reading descriptor from compressed resources! Fixed that [ImagePluginStack.LastPoolManager] and removed try..catch. All tests pass now. Als

RE: Issue with an automatic module

hi I was just trying the following sample: ModuleFinder finder = ModuleFinder.of(path); //path points to the location of a jar with an unnamed module finder.findAll().forEach(System.out::println); Layer parent = Layer.boot(); Configuration cf = parent.configur

Re: Issue with an automatic module

On 01/08/2016 12:01, charbel yazbeck wrote: hi I was just trying the following sample: ModuleFinder finder = ModuleFinder.of(path); //path points to the location of a jar with an unnamed module finder.findAll().forEach(System.out::println); I see nar-maven-plugin-3.0.0.ja

Re: SPI for customizing modules?

On 01/08/2016 08:29, Paul Benedict wrote: Jigsaw Experts, It seems the only way to customize modules is not to use --module-path. It seems if I want to customize, I have to load myself. Right or wrong? I am looking for an SPI where I can customize any non-JDK module. I believe this would be ea

Re: RFR 8162782: jlink ResourcePool.releaseProperties should be removed

On 01/08/2016 09:31, Sundararajan Athijegannathan wrote: I had moved that try..catch code to read module descriptor from elsewhere. When I removed that try..catch, I got test failures. Found another lurking issue on reading descriptor from compressed resources! Fixed that [ImagePluginStack.Last

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

On 7/17/2016 7:05 PM, harold seigel wrote: Hi, Please review these Hotspot VM only changes to process the seven module-specific options that have been renamed to have gnu-like names. JDK changes for this bug will be reviewed separately. Descriptions of these options are here

Re: Exporting - the wrong default?

On 2/08/2016 1:58 AM, Stephane Epardaud wrote: I don't think public ever meant "public to the world". In Java 1->8 it means "visible to those who can see the containing scope". If you declare a public inner class in a private (or package-private) class, then those who cannot access the outer type