Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

2015-11-04 Thread Wang Weijun
I was talking with Vincent off the list, but it seems better to be back. Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778. > The new API is interesting but if it's not available in Java SE I'm afraid it > does not fit our use case. We cannot make JOS

Re: Implied readability + layers

2015-11-04 Thread Ali Ebrahimi
Hi, On Thu, Nov 5, 2015 at 1:33 AM, Alan Bateman wrote: > > > On 04/11/2015 16:26, Ali Ebrahimi wrote: > > : > > Yes, I got it. But should not upper level descriptors win over lower > descriptors regards to current configuration. > What I missed here? > > (Changing the subject line so that it's

Re: Implied readability + layers

2015-11-04 Thread Alan Bateman
On 04/11/2015 16:26, Ali Ebrahimi wrote: : Yes, I got it. But should not upper level descriptors win over lower descriptors regards to current configuration. What I missed here? (Changing the subject line so that it's clearer what this discussion is about). In your implied readability ma

hg: jigsaw/jake/hotspot: Fixed sun.misc issues in hotspot/test/testlibrary_tests/ctw

2015-11-04 Thread christian . tornqvist
Changeset: e1b2092789e5 Author:ctornqvi Date: 2015-11-04 12:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1b2092789e5 Fixed sun.misc issues in hotspot/test/testlibrary_tests/ctw ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary_te

Re: hg: jigsaw/jake/jdk: 2 new changesets

2015-11-04 Thread Ali Ebrahimi
Hi, On Wed, Nov 4, 2015 at 5:34 PM, wrote: > > > Changeset: fd7cc28c24c7 > Author:alanb > Date: 2015-11-04 13:59 + > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7 > > Improve finding source module when creating a layer > Expand test coverage for implied reada

Re: hg: jigsaw/jake/jdk: 2 new changesets

2015-11-04 Thread Alan Bateman
On 04/11/2015 15:55, Ali Ebrahimi wrote: Layer.findModule already do recursive search for modules in parent layers That is by name and so does not uniquely identify the module. The module descriptor is also not unique which is why further work is required to have the layer of the source modu

Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

2015-11-04 Thread dalibor topic
On 30.10.2015 16:29, Vincent Privat wrote: Hi, - Is it expected to allow external people to have the possibility to subscribe to JDK issues? See http://robilad.livejournal.com/139637.html cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089

Re: hg: jigsaw/jake/jdk: 2 new changesets

2015-11-04 Thread Ali Ebrahimi
Hi, On Wed, Nov 4, 2015 at 7:31 PM, Alan Bateman wrote: > > On 04/11/2015 15:55, Ali Ebrahimi wrote: > > > > Layer.findModule already do recursive search for modules in parent layers > > That is by name and so does not uniquely identify the module. The module > descriptor is also not unique whic

hg: jigsaw/jake/jdk: 2 new changesets

2015-11-04 Thread alan . bateman
Changeset: 8e0eb0540634 Author:alanb Date: 2015-11-04 13:45 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e0eb0540634 JT_HOME in test/Makefile out of date ! test/Makefile Changeset: fd7cc28c24c7 Author:alanb Date: 2015-11-04 13:59 + URL: http://hg.o

Re: Avoiding same-package conflicts

2015-11-04 Thread Alan Bateman
On 04/11/2015 07:45, Jeroen Frijters wrote: : In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)". Can you confirm this? Not quite, the requirem

Some API Change Suggessions

2015-11-04 Thread Ali Ebrahimi
Hi, I think some renaming can improves API and avoid some illegible future confusions. Candidates: 1) Configuration ===> LayerConfiguration or LayerConfig 2) Configuration.layer() ===> Configuration.parentLayer() This was confusing when I tried this: Configuration cfg = Configuration.resolve(

RE: Avoiding same-package conflicts

2015-11-04 Thread Jeroen Frijters
Alex Buckley wrote: > Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR > -- is just one possibility among many. I actually expect the main > obstacle to 1:1 migration to be not duplication of exported packages but > rather cycles between classes in the JARs. In your JavaOne t