hg: jigsaw/jake/langtools: 8162713: Develop new tests for "export dynamic" feature

Changeset: 078fb7cea81c Author:anazarov Date: 2016-07-29 19:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/078fb7cea81c 8162713: Develop new tests for "export dynamic" feature ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java !

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

Ahh. I now see that paragraph you're referencing. I somehow was glossing over that and giving more attention to the attributes section where that distinction wasn't called out. That's a great help Alex, thanks for your direction. Cheers, Paul On Fri, Jul 29, 2016 at 2:27 PM, Alex Buckley

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

Okay. So I was hoping to look at any module-info.class and determine whether "requires java.base" was source code explicit or merely a compiler shim. I understand this particular "requires" is ACC_MANDATED, but it seems there is not a way to trace back to the actual source code. I consider this a

hg: jigsaw/jake/langtools: 9 new changesets

Changeset: 9f8da995da88 Author:vromero Date: 2016-07-19 11:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f8da995da88 8161383: javac is looking for operator symbols at the wrong place Reviewed-by: mcimadamore !

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

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, Neal Gafter in a thread I was involved in many

Re: Exporting - the wrong default?

On 29/07/2016 15:55, David M. Lloyd wrote: This is better than the alternative suggestion: just export everything to everybody, defeating the point of the security measure in the first place. Just to check. Do you mean `exports dynamic *` or some variant of? If so then it would mean that

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

+1 > On Jul 29, 2016, at 11:42 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8162782/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8162782 > > Thanks, > > -Sundar >

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

I just checked release file in custom image generated by jlink. It has OS_NAME, OS_ARCH (may be after current cleanup). JAVA_HOME is missing. I'll add that. PS. Should I do that separate fix or part of the current fix? Thanks -Sundar On 7/29/2016 8:16 PM, Alan Bateman wrote: > On 29/07/2016

Re: Exporting - the wrong default?

On 07/29/2016 09:20 AM, dalibor topic wrote: On 28.07.2016 16:59, David M. Lloyd wrote: You don't have to add new public packages to the exported list, because exporting all by default is a safe/sane default as well as being intuitive. Is it safe to assume that all potentially headache

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

On 29/07/2016 15:42, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8162782/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8162782 Sundar - is this this time to address JDK-8159487 too? -Alan

RFR 8162782: jlink ResourcePool.releaseProperties should be removed

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

Re: Exporting - the wrong default?

On 28.07.2016 16:59, David M. Lloyd wrote: You don't have to add new public packages to the exported list, because exporting all by default is a safe/sane default as well as being intuitive. Is it safe to assume that all potentially headache inducing Guns and Bullets are always kept under

Re: Missing sources stepping through Jigsaw code?

On Fri, Jul 29, 2016 at 1:11 PM, dalibor topic wrote: > On 29.07.2016 12:51, Mario Torre wrote: >> >> Rather than justifying it, let's just assume the policy doesn't make >> any sense, and live with it then :) > > > If you base your analysis on an incorrect premise [0]

Re: Exporting - the wrong default?

On 28/07/16 23:05, Alex Buckley wrote: > Down-thread, Alan asked for examples of the changes you've made to a 3rd > party's descriptor, but I think you're raising "descriptor baked into a > 3rd party jar" as a concern for modules delivered in the future rather > than for JAR files you have on hand

Re: Missing sources stepping through Jigsaw code?

On 29/07/2016 11:54, Andrew Dinn wrote: : Well, that's very interesting but it wasn't this code that was missing, rather a significant swathe of the core JDK runtime classes. From what I can tell then src.zip, going back to JDK 1.1 at least, didn't ever include all .java sources. Aside from a

Re: Missing sources stepping through Jigsaw code?

On 29.07.2016 13:05, Andrew Dinn wrote: Hmm, that algebra of effort vs needs encompasses a net increase in effort on Oracle's part to modify the default OpenJDK build process to /not/ include the jdk.internal class sources in src.zip? In this case, as Alan noted, it's a policy we follow. I

Re: Missing sources stepping through Jigsaw code?

On 29.07.2016 12:51, Mario Torre wrote: Rather than justifying it, let's just assume the policy doesn't make any sense, and live with it then :) If you base your analysis on an incorrect premise [0] you shouldn't be too surprised when you arrive at conclusions that don't make any sense.

Re: Missing sources stepping through Jigsaw code?

On 29/07/16 11:25, dalibor topic wrote: > On 29.07.2016 11:43, Andrew Dinn wrote: > . . . > The latter group does have the option of producing their own builds > based off the source code in corresponding OpenJDK forests to address > needs currently not served, being able to strike their own

Re: Missing sources stepping through Jigsaw code?

On 29/07/16 11:06, Alan Bateman wrote: > I thought there was an FAQ on this but I can't find it. It comes up > periodically but basically Oracle builds do have some code and modules > that are not in OpenJDK, the deploy area (Java Web Start for example) > mostly. Oracle builds have include the FX

Re: Missing sources stepping through Jigsaw code?

On Fri, Jul 29, 2016 at 12:51 PM, Mario Torre wrote: > This is just a Company wide policy that doesn't make any sense but we > can't seem to be able to change into a reasonable one. Specifically > for Jigsaw, and especially the first and last points I mentioned, this > is

Re: Missing sources stepping through Jigsaw code?

On Fri, Jul 29, 2016 at 12:25 PM, dalibor topic wrote: > On 29.07.2016 11:43, Andrew Dinn wrote: >> >> Jigsaw code from a debugger. Not everyone involved is in a position to >> build (and keep on rebuilding) a Jigsaw JDK9 release from scratch. > > > Broadly speaking,

Re: Missing sources stepping through Jigsaw code?

On 28/07/16 19:11, Alan Bateman wrote: > On 28/07/2016 19:04, Jason T. Greene wrote: >> Wow! That's very unfortunate. If there's no way to correlate a source >> snapshot to an OpenJDK binary; that's going to be a very strong >> motivator for using a thirdparty build. >> > The `release` file in the

hg: jigsaw/jake/jdk: 62 new changesets

Changeset: d04ea07c1629 Author:dl Date: 2016-07-15 13:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d04ea07c1629 8159924: Various improvements to StampedLock code Reviewed-by: martin, psandoz, rriggs, plevart, dfuchs !

hg: jigsaw/jake/jaxp: 6 new changesets

Changeset: f2d71c6f6c01 Author:joehw Date: 2016-02-16 10:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f2d71c6f6c01 8148872: Complete name checking Reviewed-by: dfuchs, lancea, ahgross !

hg: jigsaw/jake/nashorn: 9 new changesets

Changeset: 56ddb77ac9df Author:attila Date: 2016-07-19 13:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/56ddb77ac9df 8160953: Update build-nagen-eclipse task to work with JDK 9 Reviewed-by: lagergren, sundar ! make/build-nasgen.xml ! make/build.xml Changeset:

hg: jigsaw/jake/hotspot: 34 new changesets

Changeset: ac07d96ce9b5 Author:amurillo Date: 2016-07-01 16:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ac07d96ce9b5 Merge Changeset: 01bd72306fdf Author:amurillo Date: 2016-07-02 00:26 + URL:

hg: jigsaw/jake: 8 new changesets

Changeset: c073cf42ffd2 Author:amurillo Date: 2016-07-01 16:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c073cf42ffd2 Merge Changeset: 177fbeb6fdef Author:amurillo Date: 2016-07-08 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/177fbeb6fdef

hg: jigsaw/jake/corba: 5 new changesets

Changeset: 75f2ddcbe5d6 Author:msheppar Date: 2016-01-25 22:32 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/75f2ddcbe5d6 8079718: IIOP Input Stream Hooking Reviewed-by: rriggs, ahgross, coffeys, skoivu !

Re: automatically downloading and enabling a jigsaw module

On 29/07/2016 09:22, Jochen Theodorou wrote: : To start off I guess there would be a small gateway program, that handles the command line arguments and issues the download of the modules. What comes after that? Is it as easy as spawning a new class loader and load the modules in that loader

Re: Exporting - the wrong default?

I've read very good ideas and I think that we are very close to a reasonable solution for the majority of use cases. I have imagined how I would organize my source code in a modular world and this is how I see a possible solution using your good ideas: 1) I agree completely with Rémi on

automatically downloading and enabling a jigsaw module

Hi all, as some may know Groovy has this @Grab feature, which works only partially in JDK9, because of the change of not using an URLClassLoader anymore for the startup class loaders. Now I am of course wondering what the exact requirements are for a program to get a module jar from the

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

On 28/07/16 19:57, Paul Benedict wrote: > Alex, I thank you for repeating the explanation again, but I find your > definition hard to accept. To me, something that's synthetic is > manufactured. If the compiler automatically shims my class file with an > export to "java.base", that sounds pretty

Re: Two questions regarding implementing ModuleFinder

On 28/07/16 18:03, Alan Bateman wrote: > On 28/07/2016 16:59, Andrew Dinn wrote: > when converting the URI to a URL, we'll get that fixed. Thanks. That's good to know. > But to your question then the module location is used as the CodeSource: > > * This URI, when present, is used as the