From stephen.felts at oracle.com Sun Apr 2 23:39:16 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Sun, 2 Apr 2017 16:39:16 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> Message-ID: <4ee7fedf-8422-4bde-995b-74fa985e953d@default> I agree with Andrew's position that if the argument is added in JDK9, it should default to allow dynamic loading of agents. Arguing from the position "Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options anyway, in order to expose internal APIs" isn't a valid argument IMO. Although migration to JDK 9 will be painful, I think that we will get to zero JDK 9 command line arguments. As proposed, this new argument will never go away. It's highly likely that customers will have scripts that they migrate from JDK 8 to JDK 9. We don't control that. And many developers don't use any scripts because for many cases, they don't care about the garbage collector or memory or whatever the scripts provide. But they do care about product functionality provided by an agent. -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Friday, March 31, 2017 5:46 AM To: Mark Reinhold Cc: jigsaw-dev at openjdk.java.net Subject: Re: Disallowing the dynamic loading of agents by default Hi Mark, On 30/03/17 16:38, mark.reinhold at oracle.com wrote: > // Moving the general discussion to jigsaw-dev for the record; // > bcc'ing {hotspot-runtime,serviceability}-dev for reference. > > Andrew, > > Thanks for your feedback on this topic [1][2][3]. ... and thank you for your considered reply. > First, we apologize for the way in which this topic was raised. Our > intent was to post a proposal for discussion prior to code review, but > unfortunately that review was posted prematurely (as is evident by its > inclusion of Oracle-internal e-mail addresses and URLs). Hmm, yes! I must say I didn't notice that. I appreciate the apology but it's not really necessary. I certainly didn't expect any explanation to omit some element of miscommunication and/or cock-up :-) > Second, I agree with your earlier analysis as to the security impact > of this change. If an attack is possible via this vector then closing > the vector would only slow the attack, not prevent it. Good, I am glad to hear there is not some terrible loop-hole at play that I am not aware of. > The motivation for this change is, however, not merely to improve the > security of the platform but to improve its integrity, which is one of > the principal goals of the entire modularity effort. ... Ok, I understand the motive here although I'm still not personally convinced by it. I'll come to the practical considerations below. Before that I'd like to address the question of integrity at a more abstract level. I'm certainly not against providing -XX+/-EnableDynamicAgentLoading as a command line option. I agree that it's probably useful for some users to have the option to completely lock down the platform to guarantee its integrity. It seems from what you say above that this lock-down option is only there to provide 'belt and braces'. In other words, it is only necessary to guard against a security breach that could be managed by other means (e.g. a failure to control what jars go into your classpath; a failure to control access to the JVM uid on on the JVM host machine). I cannot fault the idea of a belt and braces lockdown per se but I am still not convinced why that extra protection needs to be enabled /by default/. You specifically bring up the scenario where rogue code, once entered into the JVM, might use the attach API to raise its privilege level. "As things stand today, code in any JAR file can use the `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's running and, via that agent, break into any module it likes." Yet, you also acknowledge above that this merely constitutes an opportunistic escalation of a situation that is already a serious security breach in its own right. I don't think I follow the logic here. Are you saying that we need the extra braces because there is a real danger here? one that users cannot rightly always be expected to guard against? Or are you just being extra cautious. This is really the crux of the matter because that extra caution has to be weighed against the extra cost of lost opportunities to deploy agents in abnormal situations. n.b. I know in the case of Red Hat's middleware that this is a real cost which will definitely arise no matter how hard we work to educate users about the necessary advance preparation required. It is also a significant cost because it will damage our ability to resolve certain very difficult support issues where only an agent can provide the information needed. And that is above above and beyond the cost of the re-education task itself. I don't doubt other companies will be affected similarly. My mention above of 'abnormal' situations underlines why your argument about integrity is somewhat moot (to me). Yes, it is important to know that encapsulation means encapsulation -- at least, I agree that is so in /normal/ circumstances. However, agents are clearly not normal code performing the normal program operations of an application. Many agents are specifically designed fro deployment in abnormal situations and perform abnormal actions. That is precisely what provides the impetus to deploy agents dynamically. It is highly valuable in such circumstances, and only in those circumstances, to be able to allow privileged agent code to /selectively/ remove certain integrity barriers, even if -- perhaps, especially because -- any dismantling of the normal rules of operation only happens modulo the specific licence the agent has been crafted and configured to grant. Useful agents clearly scope the degree to which they perturb normality to achieve abnormal results. Careful and thoughtful users can (must) still feel safe that an agent is not going to do catastrophic damage to the running application and the integrity of its data and operation. Ironically, this means that deployment of my agent is actually a relatively normal (even if infrequent) procedure for many of our users. So, while I agree that platform (or even application) integrity is a valuable property to maintain in normal program operation, I don't think those concerns are warranted in the case of an agent that has been deliberately and carefully deployed by those in charge of an application. I suspect we are probably not going to agree about the proposed default on these grounds (and I also suspect I will not be the only one to disagree with your position). So, perhaps we would be better off moving on to pragmatic concerns. > I understand your points about the practical difficulties of having to > educate users about this new option and enhance startup scripts to use > the option only when invoking JDK 9. Isn't it already the case, > however, that migrating existing applications to JDK 9 is often going > to require the use of a few new options anyway, in order to expose internal APIs? > If so then would it really be that much more burdensome for users also > to think explicitly, at the same time, about whether they want to > enable dynamic agent loading? If the default is reset to allow dynamic loading then I am happy to fully endorse this change and see no significant consequences. If this change is going to happen with your proposed default then I would very much prefer it to be staged: introduce the flag in 9 but with the default being to allow dynamic loading of agents (i.e. default to the status quo); reset the default in 10 to disable loading. The benefit of that is aware JDK9 users can still use or ignore the option as they see fit unaware JDK9 users will not get hit by the change by surprise in JDK9 unaware JDK10 users may still get hit by surprise but by that stage any configuration option they add to their JDK10 scripts will be compatible if they need to switch back and forth between JDK10 and JDK9 implementers of agents and implementers of middleware that might benefit from using those agents have more time to prepare their users, limiting the potential for any such nasty surprise in JDK10 > This change would be disruptive to some but it's the best way we've > found, so far, to preserve platform integrity in the face of dynamic > agent loading. If there's a better way to do that, we'd like to know. No, I don't think there is a better mechanism, only a better default. That reflects my belief that, while 'preserving platform integrity' is a highly desirable goal, for most users it does not merit being pursued 'in the face of dynamic agent loading'. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From chris at hazelcast.com Mon Apr 3 06:28:02 2017 From: chris at hazelcast.com (Christoph Engelbert) Date: Mon, 3 Apr 2017 08:28:02 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <4ee7fedf-8422-4bde-995b-74fa985e953d@default> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> Message-ID: <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> Hi Mark, hi others, First of all, I understand the idea behind this change and I think it certainly makes sense but from my impression the default is wrong, as Volker already pointed out. Over the last few days I (with the help of others) put together a document (https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing ) to see wich tools are affected by this change. I want to apologize for the wording of the initial tweet, as Brian correctly pointed out on twitter, that asking for ?who thinks it?s a bad idea? doesn?t offer unbiased data, however the idea was not a voting but to collect those tools which rendered the tweet more as an engagement to add content to the document. Anyhow, apologies if this tweet came out the wrong way. Looking at APM, as Martijn, mentioned, I don?t see a lot of impact, as most APMs should be added right from the start of the JVM. On the other hand, however, it seems that there is a lot of tools (probably more on the ?devops? side of things), that are commonly added at runtime in case of a problem or error. Those tools would be greatly affected by the change and would require to commonly deactivate the new restriction which renders it kind of useless. That said it looks like the main group being affected by this change is not developers, as you seem to have mentioned in the initial mail, but operations. Furthermore I?m not sure I agree with ?if you have to tell customers to put additional flags on CL, one more is no problem? (as it sounded below). Normally you have to explain / fight over every single command line parameter that has to be set with the customers operations team (except those parameters are GC configs ;-). That means it?ll be really hard to explain why to deactivate something that undercuts the system security / integrity, as it will be put. Most interestingly, as the document points out, there will be ways to undermine the change by creating a remote thread (on Windows) or ptrace on Linux. There are certainly ways on each of the operating systems but it?ll make things even more insecure. I would like to see this still being enabled by default but recommended to be deactivated when non of those tools are required. That would come back to what Volker suggested: -XX:+DisableDynamicAgentLoading. Otherwise, from my point of view, most operations teams will have to activate dynamic loading anyways. As a final but short disclaimer: Hazelcast is not directly affected by this change but we see customers using debugging, profiling and tracing / reporting tools (same as APMs) that are added at runtime and they?re often required to create meaningful error reports for us. That?s why I care for this change, I guess a lot of people think the same way. Christoph Engelbert Manager Developer Relations > On 3. Apr 2017, at 01:39, Stephen Felts wrote: > > I agree with Andrew's position that if the argument is added in JDK9, it should default to allow dynamic loading of agents. > > Arguing from the position "Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options anyway, in order to expose internal APIs" isn't a valid argument IMO. Although migration to JDK 9 will be painful, I think that we will get to zero JDK 9 command line arguments. As proposed, this new argument will never go away. > > It's highly likely that customers will have scripts that they migrate from JDK 8 to JDK 9. We don't control that. > And many developers don't use any scripts because for many cases, they don't care about the garbage collector or memory or whatever the scripts provide. > But they do care about product functionality provided by an agent. > > > > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Friday, March 31, 2017 5:46 AM > To: Mark Reinhold > Cc: jigsaw-dev at openjdk.java.net > Subject: Re: Disallowing the dynamic loading of agents by default > > Hi Mark, > > On 30/03/17 16:38, mark.reinhold at oracle.com wrote: >> // Moving the general discussion to jigsaw-dev for the record; // >> bcc'ing {hotspot-runtime,serviceability}-dev for reference. >> >> Andrew, >> >> Thanks for your feedback on this topic [1][2][3]. > > ... and thank you for your considered reply. > >> First, we apologize for the way in which this topic was raised. Our >> intent was to post a proposal for discussion prior to code review, but >> unfortunately that review was posted prematurely (as is evident by its >> inclusion of Oracle-internal e-mail addresses and URLs). > > Hmm, yes! I must say I didn't notice that. I appreciate the apology but it's not really necessary. I certainly didn't expect any explanation to omit some element of miscommunication and/or cock-up :-) > >> Second, I agree with your earlier analysis as to the security impact >> of this change. If an attack is possible via this vector then closing >> the vector would only slow the attack, not prevent it. > > Good, I am glad to hear there is not some terrible loop-hole at play that I am not aware of. > >> The motivation for this change is, however, not merely to improve the >> security of the platform but to improve its integrity, which is one of >> the principal goals of the entire modularity effort. ... > > Ok, I understand the motive here although I'm still not personally convinced by it. I'll come to the practical considerations below. Before that I'd like to address the question of integrity at a more abstract level. > > I'm certainly not against providing -XX+/-EnableDynamicAgentLoading as a command line option. I agree that it's probably useful for some users to have the option to completely lock down the platform to guarantee its integrity. It seems from what you say above that this lock-down option is only there to provide 'belt and braces'. In other words, it is only necessary to guard against a security breach that could be managed by other means (e.g. a failure to control what jars go into your classpath; a failure to control access to the JVM uid on on the JVM host machine). > I cannot fault the idea of a belt and braces lockdown per se but I am still not convinced why that extra protection needs to be enabled /by default/. > > You specifically bring up the scenario where rogue code, once entered into the JVM, might use the attach API to raise its privilege level. > > "As things stand today, code in any JAR file can use the `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's running and, via that agent, break into any module it likes." > > Yet, you also acknowledge above that this merely constitutes an opportunistic escalation of a situation that is already a serious security breach in its own right. I don't think I follow the logic here. > > Are you saying that we need the extra braces because there is a real danger here? one that users cannot rightly always be expected to guard against? Or are you just being extra cautious. This is really the crux of the matter because that extra caution has to be weighed against the extra cost of lost opportunities to deploy agents in abnormal situations. > > n.b. I know in the case of Red Hat's middleware that this is a real cost which will definitely arise no matter how hard we work to educate users about the necessary advance preparation required. It is also a significant cost because it will damage our ability to resolve certain very difficult support issues where only an agent can provide the information needed. And that is above above and beyond the cost of the re-education task itself. I don't doubt other companies will be affected similarly. > > My mention above of 'abnormal' situations underlines why your argument about integrity is somewhat moot (to me). Yes, it is important to know that encapsulation means encapsulation -- at least, I agree that is so in /normal/ circumstances. However, agents are clearly not normal code performing the normal program operations of an application. Many agents are specifically designed fro deployment in abnormal situations and perform abnormal actions. That is precisely what provides the impetus to deploy agents dynamically. > > It is highly valuable in such circumstances, and only in those circumstances, to be able to allow privileged agent code to /selectively/ remove certain integrity barriers, even if -- perhaps, especially because -- any dismantling of the normal rules of operation only happens modulo the specific licence the agent has been crafted and configured to grant. Useful agents clearly scope the degree to which they perturb normality to achieve abnormal results. Careful and thoughtful users can (must) still feel safe that an agent is not going to do catastrophic damage to the running application and the integrity of its data and operation. Ironically, this means that deployment of my agent is actually a relatively normal (even if infrequent) procedure for many of our users. > > So, while I agree that platform (or even application) integrity is a valuable property to maintain in normal program operation, I don't think those concerns are warranted in the case of an agent that has been deliberately and carefully deployed by those in charge of an application. I suspect we are probably not going to agree about the proposed default on these grounds (and I also suspect I will not be the only one to disagree with your position). So, perhaps we would be better off moving on to pragmatic concerns. > >> I understand your points about the practical difficulties of having to >> educate users about this new option and enhance startup scripts to use >> the option only when invoking JDK 9. Isn't it already the case, >> however, that migrating existing applications to JDK 9 is often going >> to require the use of a few new options anyway, in order to expose internal APIs? >> If so then would it really be that much more burdensome for users also >> to think explicitly, at the same time, about whether they want to >> enable dynamic agent loading? > > If the default is reset to allow dynamic loading then I am happy to fully endorse this change and see no significant consequences. If this change is going to happen with your proposed default then I would very much prefer it to be staged: introduce the flag in 9 but with the default being to allow dynamic loading of agents (i.e. default to the status quo); reset the default in 10 to disable loading. The benefit of that is > > aware JDK9 users can still use or ignore the option as they see fit > > unaware JDK9 users will not get hit by the change by surprise in JDK9 > > unaware JDK10 users may still get hit by surprise but by that stage any configuration option they add to their JDK10 scripts will be compatible if they need to switch back and forth between JDK10 and JDK9 > > implementers of agents and implementers of middleware that might benefit from using those agents have more time to prepare their users, limiting the potential for any such nasty surprise in JDK10 > >> This change would be disruptive to some but it's the best way we've >> found, so far, to preserve platform integrity in the face of dynamic >> agent loading. If there's a better way to do that, we'd like to know. > > No, I don't think there is a better mechanism, only a better default. > That reflects my belief that, while 'preserving platform integrity' is a highly desirable goal, for most users it does not merit being pursued 'in the face of dynamic agent loading'. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From manovotn at redhat.com Mon Apr 3 12:17:21 2017 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 3 Apr 2017 08:17:21 -0400 (EDT) Subject: setAccessible() alternative with Jigsaw In-Reply-To: References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> Message-ID: <450953518.10388303.1491221841271.JavaMail.zimbra@redhat.com> Thanks for suggestion! I'll definitely look at that direction and see if it suffices. Matej ----- Original Message ----- > From: "Alan Bateman" > To: "Matej Novotny" , jigsaw-dev at openjdk.java.net > Cc: "Martin Kouba" > Sent: Friday, March 31, 2017 4:28:34 PM > Subject: Re: setAccessible() alternative with Jigsaw > > On 31/03/2017 14:46, Matej Novotny wrote: > > > Hello, > > > > I work on Weld, context dependency injection framework. > > Long story short - we need to generate proxies for classes - bytecode which > > we then "register" with the class loader using > > java.lang.ClassLoader#defineClass. > > > > Obviously, for this you need reflections - to load java.lang.ClassLoader, > > then to load the method itself, and most importantly, to make the method > > accessible cause it's `protected`. > > In JDK 9, this blows up as soon as you try to make the method accessible > > (invocation of setAccessible). > > > > Fair enough, but what is the "legitimate" alternative? > > I know I can --add-opens / --add-opens / --permit-illegal-access > > But all those just bypass the checks and don't really solve it. I am > > looking for an intended way to do such stuff. > > I am pretty sure there are many frameworks which need to do this in one way > > or the other. > > > > So far I have found workarounds which involve using `sun.misc.Unsafe` > > because there (for some reason) you are allowed to invoke setAccessible(). > > Is this the official intended backdoor? Because it sure does not look any > > safer/cleaner solution than the original one... > > > As Claes pointed out, look at Lookup.defineClass. It shouldn't be too > hard to imagine a future update of the CDI spec where there a select > variant that includes a Lookup to the target class with the @Inject > annotation. When using Weld outside of a container then I think there is > main code that obtains the WeldContainer and selects the types, that > might be a suitable place to extend to provide the Lookup to the library. > > MethodHandles.privateLookupIn might also be useful to know about, esp. > starting out when you don't want to make API changes and where the > user's code is on the class path or in open modules. > > -Alan > From Alan.Bateman at oracle.com Mon Apr 3 12:23:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 13:23:17 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> Message-ID: <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> On 03/04/2017 07:28, Christoph Engelbert wrote: > Hi Mark, hi others, > > First of all, I understand the idea behind this change and I think it certainly makes sense but from my impression the default is wrong, as Volker already pointed out. > > Over the last few days I (with the help of others) put together a document (https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing ) to see wich tools are affected by this change. A survey of the agents that support being loaded into a running VM is useful but I think would be more useful if it were expanded to capture: 1. Whether the agent depends on instrumentation of classes in core modules (java.base in particular). 2. Whether the agent is deployed as a library that load an agent into the current VM. The combination of #1 and #2 is the problem in the cross-hairs. There isn't any desire to disrupt out of process tools that load instrumentation agents into a target VM. -Alan. From Alan.Bateman at oracle.com Mon Apr 3 12:26:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 13:26:12 +0100 Subject: setAccessible() alternative with Jigsaw In-Reply-To: <450953518.10388303.1491221841271.JavaMail.zimbra@redhat.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <450953518.10388303.1491221841271.JavaMail.zimbra@redhat.com> Message-ID: <6f3a15d6-6f76-af86-eb09-3d54269b84b1@oracle.com> On 03/04/2017 13:17, Matej Novotny wrote: > Thanks for suggestion! > I'll definitely look at that direction and see if it suffices. > Good, and please report back your experiences. I could imagine you starting out using MethodHandles.privateLookupIn but it would be nice to get to the point where there is a select variant that allows a Lookup to be specified with the required access. -Alan From alan.bateman at oracle.com Mon Apr 3 13:47:36 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 03 Apr 2017 13:47:36 +0000 Subject: hg: jigsaw/jake/hotspot: JVMTI needs to allow for non-modifiable modules Message-ID: <201704031347.v33DlaUM009333@aojmv0008.oracle.com> Changeset: 52cdbd4a5999 Author: alanb Date: 2017-04-03 14:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 JVMTI needs to allow for non-modifiable modules ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp From russell.gold at oracle.com Mon Apr 3 14:15:58 2017 From: russell.gold at oracle.com (Russell Gold) Date: Mon, 3 Apr 2017 10:15:58 -0400 Subject: Lookup.defineClass In-Reply-To: References: <8ebf7397-9aea-4139-90be-0b7d2346380a@oracle.com> <089DA13B-E38E-40B6-8A5B-06E807C9B069@oracle.com> Message-ID: <1EEF0F2A-D9EF-4854-8BC1-442E158E0545@oracle.com> Upon further testing, this turns out to be less capable than the ?Unsafe? version - in particular, I cannot create a test stub in a closed package. The problem is that unit tests often need to do a number of things like this that make no sense in a production environment. The problem has to do with creating test stubs to take the place of JDK objects. In many cases, this requires access to package-protected classes or fields, as the JDK doesn?t provide clean interfaces for a lot of its functionality. In the past, we could do this by defining a subclass in the same package as the JDK class we needed to stub. That no longer works without command-line switches. Related to this, unit tests must often create stub classes specifically in thread context class loaders - but those classes are frequently not in the same package as the test code. This new feature doesn?t support that at all, and I don?t even see a way to use a command line switch to enable it. - Russ > On Mar 14, 2017, at 4:47 PM, Alan Bateman wrote: > > On 14/03/2017 17:37, Russell Gold wrote: >> Hi Alan, >> >> I am trying this in SimpleStub, and it seems to work for my current test cases if I do this: >>> MethodHandles.Lookup in = MethodHandles.privateLookupIn( baseClass, MethodHandles.lookup() ).dropLookupMode( MethodHandles.Lookup.PRIVATE ); >>> return in.defineClass(classBytes); >> >> My tests create stubs from public, package-private and protected classes. Is that what you are expecting? It seems a bit overly complex. > You get a full-power lookup on the "baseClass", passing your own lookup that proves you have access. Then you drop private access as it's not supported by defineClass at this time. So it looks right. > > >> >> In gmbal, I see that this may not suffice, as the current interfaces provide no way to supply a class to use as a base. Figuring out how those interfaces are being used might change my answer. >> > Could you add an overloaded register method to ManagedObjectManager to take the Lookup? > > -Alan From adinn at redhat.com Mon Apr 3 14:19:09 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Apr 2017 15:19:09 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> Message-ID: <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> On 03/04/17 13:23, Alan Bateman wrote: > On 03/04/2017 07:28, Christoph Engelbert wrote: > 1. Whether the agent depends on instrumentation of classes in core > modules (java.base in particular). > > 2. Whether the agent is deployed as a library that load an agent into > the current VM. > > The combination of #1 and #2 is the problem in the cross-hairs. There > isn't any desire to disrupt out of process tools that load > instrumentation agents into a target VM. Well, Byteman is definitely in the cross hairs by virtue of both counts if those are the criteria (but I still don't see Byteman as a problem that requires disruption :-) That said, I don't quite follow how your last statement relates to the proposed change. It reads to me as if EnableDynamicAgentLoading=true is intended to stop out of process loading of instrumentation agents like Byteman as well as foil code that hoists an agent into the current JVM process. Have I misread the proposed behaviour? Or have I read it right? (with the corollary, I assume, that here you are you merely setting out what you would prefer to implement in contrast to what you can actually achieve). Also, can you provide a reason why you are so agin agent-hoisting from within a JVM? Is there a reason why it is such a cardinal sin? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Mon Apr 3 15:50:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 16:50:17 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> Message-ID: <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> On 03/04/2017 15:19, Andrew Dinn wrote: > : > Well, Byteman is definitely in the cross hairs by virtue of both counts > if those are the criteria (but I still don't see Byteman as a problem > that requires disruption :-) > > That said, I don't quite follow how your last statement relates to the > proposed change. It reads to me as if EnableDynamicAgentLoading=true is > intended to stop out of process loading of instrumentation agents like > Byteman as well as foil code that hoists an agent into the current JVM > process. Have I misread the proposed behaviour? Or have I read it right? > (with the corollary, I assume, that here you are you merely setting out > what you would prefer to implement in contrast to what you can actually > achieve). > > Also, can you provide a reason why you are so agin agent-hoisting from > within a JVM? Is there a reason why it is such a cardinal sin? As Mark said, this discussion got off to a bad start. We might have to explain the issue again. Java SE 9 / JDK 9 brings strong encapsulation. The access control for the Java Language and VM has been extended to modules so that modules that don't want their internals to be accessed from code outside the module can do so. None of the core modules want their internals to be accessed so none of the core modules are open or open any packages. A consequence of this is that code on the class path or module path doesn't get to break in these modules. This is really nice but it exposes a lot of technical debt in existing code (as we've seen in mails here over the last 18 months). If libraries and applications can't break in then what about tools? Tools are special, they get the capability to instrument almost every class. As you know, their capabilities have been expanded in Java SE 9 / JDK 9 as all the tool APIs have been updated to support modules. This means they can instrument code in modules as well as modify modules to export or open packages to other modules. Now bring the attach API and late binding agents into the picture. This is where things blur and where the problem arises. A library can use the attach mechanism to load an agent into the current VM and break into any module. It's much easier in JDK 9 compared to previous releases because the jdk.attach module is resolved by default. All it takes is someone to post a solution on stackoverflow that spins a sneaky agent to leak the Instrumentation object to the library. It's just too easy to "migrate" existing reflection hacks. The attach mechanism was of course never intended to be used this way. It was meant for troubleshooting tools and profilers/similar to load agents into running VMs. Back in the JDK 6 then we did consider disallowing attaching to the current VM but didn't enforce it - one reason is that it's not hard to just fork a VM with tools.jar on the class path and connect back to the parent. So that is the context for the discussion. We need to find a good way to put the Genie back in its bottle. It may be that we have to disable attaching to the current or ancestor VMs. We may have to prohibit the instrumentation of core modules by late binding agents. We may have to do some disabling of agent loading. Maybe a combination. Suggestions and proposals are of course welcome. -Alan From rgransberger at gmx.de Mon Apr 3 15:54:06 2017 From: rgransberger at gmx.de (Rabea Gransberger) Date: Mon, 3 Apr 2017 17:54:06 +0200 Subject: ResourceBundle in Java 9 Module Message-ID: <5eeca71b-277b-ba6b-0b4e-00442a81ea41@gmx.de> Hello, while migrating example code to Java 9 Modules I ran into a problem: ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.messages"); System.out.println(bundle.getString("I18n.message")); The properties file path is: src\de\rgra\nl\messages.properties The code works on Java 8 and 9 when used on the Classpath. It fails in Java 9 when used in a module on the Modulepath with: Exception in thread "main" java.lang.NoClassDefFoundError: de/rgra/nl/Messages (wrong name: de/rgra/nl/messages) Changing it to uppercase M will work on Classpath and Modulepath (without changing the properties file to uppercase M): ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.Messages"); System.out.println(bundle.getString("I18n.message")); Can anybody explain to me why this happens? The example with run script can be found at: https://github.com/rgra/java9-module-refactoring/tree/master/resourcebundle --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus From reto.merz at abacus.ch Mon Apr 3 16:28:47 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Mon, 3 Apr 2017 18:28:47 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> Message-ID: <883259944-21059@kerio.abacus.ch> It was already suggested in another thread by Gregg Wonderly: Why not introduce a new method java.lang.SecurityManager#checkAttachAgent(x)? So the implementation can accept/reject an "attach agent request" dynamically at runtime. x could be some additional infos provided by the agent (eg: certificate). Reto Von: Alan Bateman An: Andrew Dinn Kopie: Gesendet: 03.04.2017 17:50 Betreff: Re: Disallowing the dynamic loading of agents by default On 03/04/2017 15:19, Andrew Dinn wrote: > : > Well, Byteman is definitely in the cross hairs by virtue of both counts > if those are the criteria (but I still don't see Byteman as a problem > that requires disruption :-) > > That said, I don't quite follow how your last statement relates to the > proposed change. It reads to me as if EnableDynamicAgentLoading=true is > intended to stop out of process loading of instrumentation agents like > Byteman as well as foil code that hoists an agent into the current JVM > process. Have I misread the proposed behaviour? Or have I read it right? > (with the corollary, I assume, that here you are you merely setting out > what you would prefer to implement in contrast to what you can actually > achieve). > > Also, can you provide a reason why you are so agin agent-hoisting from > within a JVM? Is there a reason why it is such a cardinal sin? As Mark said, this discussion got off to a bad start. We might have to explain the issue again. Java SE 9 / JDK 9 brings strong encapsulation. The access control for the Java Language and VM has been extended to modules so that modules that don't want their internals to be accessed from code outside the module can do so. None of the core modules want their internals to be accessed so none of the core modules are open or open any packages. A consequence of this is that code on the class path or module path doesn't get to break in these modules. This is really nice but it exposes a lot of technical debt in existing code (as we've seen in mails here over the last 18 months). If libraries and applications can't break in then what about tools? Tools are special, they get the capability to instrument almost every class. As you know, their capabilities have been expanded in Java SE 9 / JDK 9 as all the tool APIs have been updated to support modules. This means they can instrument code in modules as well as modify modules to export or open packages to other modules. Now bring the attach API and late binding agents into the picture. This is where things blur and where the problem arises. A library can use the attach mechanism to load an agent into the current VM and break into any module. It's much easier in JDK 9 compared to previous releases because the jdk.attach module is resolved by default. All it takes is someone to post a solution on stackoverflow that spins a sneaky agent to leak the Instrumentation object to the library. It's just too easy to "migrate" existing reflection hacks. The attach mechanism was of course never intended to be used this way. It was meant for troubleshooting tools and profilers/similar to load agents into running VMs. Back in the JDK 6 then we did consider disallowing attaching to the current VM but didn't enforce it - one reason is that it's not hard to just fork a VM with tools.jar on the class path and connect back to the parent. So that is the context for the discussion. We need to find a good way to put the Genie back in its bottle. It may be that we have to disable attaching to the current or ancestor VMs. We may have to prohibit the instrumentation of core modules by late binding agents. We may have to do some disabling of agent loading. Maybe a combination. Suggestions and proposals are of course welcome. -Alan From Alan.Bateman at oracle.com Mon Apr 3 16:32:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 17:32:22 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <883259944-21059@kerio.abacus.ch> References: <883259944-21059@kerio.abacus.ch> Message-ID: On 03/04/2017 17:28, Reto Merz wrote: > It was already suggested in another thread by Gregg Wonderly: > Why not introduce a new method > java.lang.SecurityManager#checkAttachAgent(x)? > So the implementation can accept/reject an "attach agent request" > dynamically at runtime. > x could be some additional infos provided by the agent (eg: certificate). The issue here is nothing to do with the security manager, assume no security manager in the picture. Also, FWIW, VirtualMachine.attach has always specified a security manager for the (probably rare) cases where a tool is run with a security manager. -Alan From mark.reinhold at oracle.com Mon Apr 3 16:35:00 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 09:35:00 -0700 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) Message-ID: <20170403093500.721331054@eggemoggin.niobe.net> Thanks for the continued feedback on this difficult issue. FYI: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html - Mark From Alan.Bateman at oracle.com Mon Apr 3 16:39:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 17:39:12 +0100 Subject: Lookup.defineClass In-Reply-To: <1EEF0F2A-D9EF-4854-8BC1-442E158E0545@oracle.com> References: <8ebf7397-9aea-4139-90be-0b7d2346380a@oracle.com> <089DA13B-E38E-40B6-8A5B-06E807C9B069@oracle.com> <1EEF0F2A-D9EF-4854-8BC1-442E158E0545@oracle.com> Message-ID: On 03/04/2017 15:15, Russell Gold wrote: > Upon further testing, this turns out to be less capable than the > ?Unsafe? version - in particular, I cannot create a test stub in a > closed package. The problem is that unit tests often need to do a > number of things like this that make no sense in a production > environment. > > The problem has to do with creating test stubs to take the place of > JDK objects. In many cases, this requires access to package-protected > classes or fields, as the JDK doesn?t provide clean interfaces for a > lot of its functionality. In the past, we could do this by defining a > subclass in the same package as the JDK class we needed to stub. That > no longer works without command-line switches. If I read this correctly then you are looking to define classes in java.lang and other packages of core modules, is that right? If so then they are deliberately not open and I assume the issue you are running into is that you can't get a Lookup to a target class with PACKAGE access. When testing the JDK then package private members can be exercised. The test runner for the JDK tests is "jtreg" and it arranges for the tests to be in the same loader/package by using the --patch-module. > Related to this, unit tests must often create stub classes > specifically in thread context class loaders - but those classes are > frequently not in the same package as the test code. This new feature > doesn?t support that at all, and I don?t even see a way to use a > command line switch to enable it. > I'm not sure that I understand the scenario. Do you control the TCCL? -Alan From adinn at redhat.com Mon Apr 3 16:44:43 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Apr 2017 17:44:43 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> Message-ID: <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> On 03/04/17 16:50, Alan Bateman wrote: >> Also, can you provide a reason why you are so agin agent-hoisting from >> within a JVM? Is there a reason why it is such a cardinal sin? > As Mark said, this discussion got off to a bad start. We might have to > explain the issue again. Sure, only I don't think I have misunderstood the existing explanations (that was what I wanted to check). However, I am not clear that I am getting the same, consistent explanation each time. > Java SE 9 / JDK 9 brings strong encapsulation. The access control for > the Java Language and VM has been extended to modules so that modules > that don't want their internals to be accessed from code outside the > module can do so. None of the core modules want their internals to be > accessed so none of the core modules are open or open any packages. A > consequence of this is that code on the class path or module path > doesn't get to break in these modules. This is really nice but it > exposes a lot of technical debt in existing code (as we've seen in mails > here over the last 18 months). Yes, it is really nice in many ways. But it is also not necessarily what everyone wants. One thing I am not clear on as regards that 'really nice' is whether anything in the JVM wants -- or even hopes -- to rely on module encapsulation never being broken in order to provide 'semantic' guarantees. That's different from relying on it to provide security guarantees. The sort of thing I am thinking about is, say, a module-wide global analysis in the JIT guaranteeing that a call argument will only ever be non-NULL, a positive int, or some such invariant that can fed into an optimization phase. I can understand how a switch to disable dynamic agent loading might be needed to underline that sort of guarantee. > . . . > Now bring the attach API and late binding agents into the picture. This > is where things blur and where the problem arises. A library can use the > attach mechanism to load an agent into the current VM and break into any > module. It's much easier in JDK 9 compared to previous releases because > the jdk.attach module is resolved by default. All it takes is someone to > post a solution on stackoverflow that spins a sneaky agent to leak the > Instrumentation object to the library. It's just too easy to "migrate" > existing reflection hacks. I think this is already very well known technology and the presence of the jdk.attach module in the runtime was never really much of a bar. The people who want to do this certainly don't have to look for sneaky solutions on stackoverflow. However, I still don't really see your point here. If people want to migrate existing reflection hacks then they can and will do so by switching off your proposed flag or adding the agent at startup. Are you perhaps concerned that users might have their hand forced by providers of library jars or middleware who hoist an agent into the JVM behind their backs? I think that would be rather a patronising view to take of the vast majority of producers and consumers of libraries and/or middleware. My belief is that anyone who attempted to provide a library or framework (open source or not) that disabled (some or all) modules by stealth would very soon be found out. I also believe they would immediately lose all (or, at least, most) of their prospective business from serious, paying customers. After all, that sort of behaviour *would* be a major security issue. As I mentioned in my reply to Mark it is critical for users to know exactly how any agent they load into their JVM is going to modify the access restrictions in place in the JVM so that they can be sue that use of the agent is safe (just as they need to know that any jars they place into the classpath are not going to do things like round down their costs and pocket the spare change in a bank account somwehere). Users don't just add stuff to their classpath without knowing what it does and why it is appropriate. Also, that doesn't mean there will be no market for code which advertises that it is going to change access controls. If users know what they are getting and know what the consequences are then I am sure there are cases where they can safely decide whether or not to use a library that opens up module access. It's the idea that people are going to be hoodwinked here -- if indeed that is your idea -- that I find rather difficult to follow. We seem to have moved from dynamic agent loading being a security issue that didn't seem to have a real basis to a 'users cannot be entrusted to look after their own classpath' issue that I find equally as baseless. Is there more to what you are saying that I have not grasped? > The attach mechanism was of course never intended to be used this way. > It was meant for troubleshooting tools and profilers/similar to load > agents into running VMs. Back in the JDK 6 then we did consider > disallowing attaching to the current VM but didn't enforce it - one > reason is that it's not hard to just fork a VM with tools.jar on the > class path and connect back to the parent. Well, I understand that this is not what you intended. However, i) it turns out to have been very useful that it does work this way and ii) stopping it doing so has a cost which needs to be taken into account -- at the very least by giving those who have been relying on it for quite some time to manage their business concerns to adjust to the change. > So that is the context for the discussion. We need to find a good way to > put the Genie back in its bottle. It may be that we have to disable > attaching to the current or ancestor VMs. We may have to prohibit the > instrumentation of core modules by late binding agents. We may have to > do some disabling of agent loading. Maybe a combination. Suggestions and > proposals are of course welcome. I'm very happy to consider all sorts of half-way houses or even -- in time -- the full change recommended in the original JIRA. For example, rejecting instrumentation in some specific set of bootstrap/JDK module classes (like, say, java.base) from an agent which has been dynamically loaded might well be a workable compromise -- that at least allows users to employ an agent to tweak any code that is in the classpath through their choice. However, whatever compromise we arrive at I'd certainly like time to adjust to it and hence prefer to see it happen in JDK10. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From chris at hazelcast.com Mon Apr 3 16:46:18 2017 From: chris at hazelcast.com (Christoph Engelbert - Hazelcast) Date: Mon, 3 Apr 2017 18:46:18 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> Message-ID: <819b0853-c582-7191-706a-e5462bce4052@hazelcast.com> Hey Alan, What about (just coming up with this idea, so most probably not thought through) using an async-signed agent system. Users would have to add trusted certificates to their local store (as you do with apt on Ubuntu for repositories) and agent being signed with a trusted key would have the same access as before, non trusted ones minimal access, maybe even no access at all. In this case it is more secure and has better integrity as you are free to allow some and not other (same as for the serialization whitelisting) and it is easier to explain to customers that if you want / expect to use certain tools in the new sandbox behavior you have to trust them upfront. I guess everybody is happy to trust a tool coming from a vendor I already use (and therefore trust). WDYT? *Christoph Engelbert Manager Developer Relations * Am 4/3/2017 um 5:50 PM schrieb Alan Bateman: > On 03/04/2017 15:19, Andrew Dinn wrote: > >> : >> Well, Byteman is definitely in the cross hairs by virtue of both >> counts >> if those are the criteria (but I still don't see Byteman as a >> problem >> that requires disruption :-) >> >> That said, I don't quite follow how your last statement relates >> to the >> proposed change. It reads to me as if >> EnableDynamicAgentLoading=true is >> intended to stop out of process loading of instrumentation agents >> like >> Byteman as well as foil code that hoists an agent into the >> current JVM >> process. Have I misread the proposed behaviour? Or have I read it >> right? >> (with the corollary, I assume, that here you are you merely >> setting out >> what you would prefer to implement in contrast to what you can >> actually >> achieve). >> >> Also, can you provide a reason why you are so agin agent-hoisting >> from >> within a JVM? Is there a reason why it is such a cardinal sin? > As Mark said, this discussion got off to a bad start. We might > have to explain the issue again. > > Java SE 9 / JDK 9 brings strong encapsulation. The access control > for the Java Language and VM has been extended to modules so that > modules that don't want their internals to be accessed from code > outside the module can do so. None of the core modules want their > internals to be accessed so none of the core modules are open or > open any packages. A consequence of this is that code on the class > path or module path doesn't get to break in these modules. This is > really nice but it exposes a lot of technical debt in existing > code (as we've seen in mails here over the last 18 months). > > If libraries and applications can't break in then what about > tools? Tools are special, they get the capability to instrument > almost every class. As you know, their capabilities have been > expanded in Java SE 9 / JDK 9 as all the tool APIs have been > updated to support modules. This means they can instrument code in > modules as well as modify modules to export or open packages to > other modules. > > Now bring the attach API and late binding agents into the picture. > This is where things blur and where the problem arises. A library > can use the attach mechanism to load an agent into the current VM > and break into any module. It's much easier in JDK 9 compared to > previous releases because the jdk.attach module is resolved by > default. All it takes is someone to post a solution on > stackoverflow that spins a sneaky agent to leak the > Instrumentation object to the library. It's just too easy to > "migrate" existing reflection hacks. > > The attach mechanism was of course never intended to be used this > way. It was meant for troubleshooting tools and profilers/similar > to load agents into running VMs. Back in the JDK 6 then we did > consider disallowing attaching to the current VM but didn't > enforce it - one reason is that it's not hard to just fork a VM > with tools.jar on the class path and connect back to the parent. > > So that is the context for the discussion. We need to find a good > way to put the Genie back in its bottle. It may be that we have to > disable attaching to the current or ancestor VMs. We may have to > prohibit the instrumentation of core modules by late binding > agents. We may have to do some disabling of agent loading. Maybe a > combination. Suggestions and proposals are of course welcome. > > -Alan From stephen.felts at oracle.com Mon Apr 3 17:23:30 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 3 Apr 2017 10:23:30 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> Message-ID: One of the key problems with the current proposal is the required use of the command line to enabled this feature. Alternative proposals (besides suggesting moving this to JDK10, which I agree with) have suggested other ways to configure the option. Since JDK9 has set the precedent of configuring options for a JAVA_HOME by using files under the conf directory, an alternative way to configure this would be to have a file under conf to do it (not tied to the security manager). Developers could then configure it once for all of their subsequent work. I know that I have functional QA tests that automatically set/unset conf options when running specific tests. -----Original Message----- From: Alan Bateman Sent: Monday, April 3, 2017 11:50 AM To: Andrew Dinn Cc: jigsaw-dev at openjdk.java.net Subject: Re: Disallowing the dynamic loading of agents by default On 03/04/2017 15:19, Andrew Dinn wrote: > : > Well, Byteman is definitely in the cross hairs by virtue of both > counts if those are the criteria (but I still don't see Byteman as a > problem that requires disruption :-) > > That said, I don't quite follow how your last statement relates to the > proposed change. It reads to me as if EnableDynamicAgentLoading=true > is intended to stop out of process loading of instrumentation agents > like Byteman as well as foil code that hoists an agent into the > current JVM process. Have I misread the proposed behaviour? Or have I read it right? > (with the corollary, I assume, that here you are you merely setting > out what you would prefer to implement in contrast to what you can > actually achieve). > > Also, can you provide a reason why you are so agin agent-hoisting from > within a JVM? Is there a reason why it is such a cardinal sin? As Mark said, this discussion got off to a bad start. We might have to explain the issue again. Java SE 9 / JDK 9 brings strong encapsulation. The access control for the Java Language and VM has been extended to modules so that modules that don't want their internals to be accessed from code outside the module can do so. None of the core modules want their internals to be accessed so none of the core modules are open or open any packages. A consequence of this is that code on the class path or module path doesn't get to break in these modules. This is really nice but it exposes a lot of technical debt in existing code (as we've seen in mails here over the last 18 months). If libraries and applications can't break in then what about tools? Tools are special, they get the capability to instrument almost every class. As you know, their capabilities have been expanded in Java SE 9 / JDK 9 as all the tool APIs have been updated to support modules. This means they can instrument code in modules as well as modify modules to export or open packages to other modules. Now bring the attach API and late binding agents into the picture. This is where things blur and where the problem arises. A library can use the attach mechanism to load an agent into the current VM and break into any module. It's much easier in JDK 9 compared to previous releases because the jdk.attach module is resolved by default. All it takes is someone to post a solution on stackoverflow that spins a sneaky agent to leak the Instrumentation object to the library. It's just too easy to "migrate" existing reflection hacks. The attach mechanism was of course never intended to be used this way. It was meant for troubleshooting tools and profilers/similar to load agents into running VMs. Back in the JDK 6 then we did consider disallowing attaching to the current VM but didn't enforce it - one reason is that it's not hard to just fork a VM with tools.jar on the class path and connect back to the parent. So that is the context for the discussion. We need to find a good way to put the Genie back in its bottle. It may be that we have to disable attaching to the current or ancestor VMs. We may have to prohibit the instrumentation of core modules by late binding agents. We may have to do some disabling of agent loading. Maybe a combination. Suggestions and proposals are of course welcome. -Alan From mandy.chung at oracle.com Mon Apr 3 17:27:45 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 10:27:45 -0700 Subject: ResourceBundle in Java 9 Module In-Reply-To: <5eeca71b-277b-ba6b-0b4e-00442a81ea41@gmx.de> References: <5eeca71b-277b-ba6b-0b4e-00442a81ea41@gmx.de> Message-ID: I created a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8177980 What platform are you running on? This works on linux but I can reproduce the problem on OSX (related to case-insensitive file system). Mandy > On Apr 3, 2017, at 8:54 AM, Rabea Gransberger wrote: > > Hello, > > while migrating example code to Java 9 Modules I ran into a problem: > > ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.messages"); > System.out.println(bundle.getString("I18n.message")); > > The properties file path is: > src\de\rgra\nl\messages.properties > > The code works on Java 8 and 9 when used on the Classpath. > > It fails in Java 9 when used in a module on the Modulepath with: > > Exception in thread "main" java.lang.NoClassDefFoundError: > de/rgra/nl/Messages (wrong name: de/rgra/nl/messages) > > Changing it to uppercase M will work on Classpath and Modulepath > (without changing the properties file to uppercase M): > > ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.Messages"); > System.out.println(bundle.getString("I18n.message")); > > Can anybody explain to me why this happens? > > The example with run script can be found at: > https://github.com/rgra/java9-module-refactoring/tree/master/resourcebundle > > > > --- > Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. > https://www.avast.com/antivirus > From rgransberger at gmx.de Mon Apr 3 17:29:00 2017 From: rgransberger at gmx.de (Rabea Gransberger) Date: Mon, 3 Apr 2017 19:29:00 +0200 Subject: ResourceBundle in Java 9 Module In-Reply-To: References: <5eeca71b-277b-ba6b-0b4e-00442a81ea41@gmx.de> Message-ID: <0DE56C68-7D60-45FE-9807-CF47850DC8EA@gmx.de> Hello Mandy, thank you. I did run it on Windows 10. > Am 03.04.2017 um 19:27 schrieb Mandy Chung : > > I created a JBS issue: > https://bugs.openjdk.java.net/browse/JDK-8177980 > > What platform are you running on? This works on linux but I can reproduce the problem on OSX (related to case-insensitive file system). > > Mandy > >> On Apr 3, 2017, at 8:54 AM, Rabea Gransberger wrote: >> >> Hello, >> >> while migrating example code to Java 9 Modules I ran into a problem: >> >> ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.messages"); >> System.out.println(bundle.getString("I18n.message")); >> >> The properties file path is: >> src\de\rgra\nl\messages.properties >> >> The code works on Java 8 and 9 when used on the Classpath. >> >> It fails in Java 9 when used in a module on the Modulepath with: >> >> Exception in thread "main" java.lang.NoClassDefFoundError: >> de/rgra/nl/Messages (wrong name: de/rgra/nl/messages) >> >> Changing it to uppercase M will work on Classpath and Modulepath >> (without changing the properties file to uppercase M): >> >> ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.Messages"); >> System.out.println(bundle.getString("I18n.message")); >> >> Can anybody explain to me why this happens? >> >> The example with run script can be found at: >> https://github.com/rgra/java9-module-refactoring/tree/master/resourcebundle >> >> >> >> --- >> Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. >> https://www.avast.com/antivirus >> > From scolebourne at joda.org Mon Apr 3 17:34:14 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 3 Apr 2017 18:34:14 +0100 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: <20170403093500.721331054@eggemoggin.niobe.net> References: <20170403093500.721331054@eggemoggin.niobe.net> Message-ID: On [1] the conclusion given the premise is not unreasonable. The file name can be easily changed by a developer or build tool to match the expected module name. However, it is the premise I strongly object to: "The fundamental problem here is that we're trying to infer a .. name..." Inferring a name (identifier) is generally a bad idea in any programming context, but especially so in this one where it will be baked into the compiled artifacts. Accepting that inferring a name is a fundamentally bad idea leads to examination of alternatives to automatic modules [3]. Such an examination yields an approach where a module only specifies dependencies on proper modules, with some ability to express that its dependencies are incomplete. This appears not to have been considered despite being equivalent in aiding migration yet avoiding any need to infer a name. As such, on [2], I find the new warnings to be little more than a sticking plaster on the wart of automatic modules. The need to add a disclaimer "Strongly advise developers never to publish, for broad use, explicit modules that require automatic modules" while a welcome recognition of the problem, merely serves to emphasise how broken the concept of automatic modules is. They simply should not be part of the Java platform, a millstone around our necks forevermore. All I hope the teams at Maven, Gradle, Sonatype, JFrog and others can work to ensure strong validation to exclude automatic modules from public repositories, although this is merely an attempt to lock the door after the horse has bolted. I also note that proposals to date do not provide strong guidance on module naming. As things stand, there is likely to be inconsistency in the choices made between projects. This is particularly galling given the extremely strong guidance about NPM and the need for namespaces [4] [5]. It is important to note the impact of what happens when projects collide due to lack of appropriate namespacing [6] [7]. While boring and verbose, reverse DNS is the approach that has served Java well for 20+ years, and should be strongly promoted here. Stephen [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html [2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011686.html [4] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-January/000537.html [5] https://github.com/npm/npm/issues/798 [6] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm [7] https://www.techdirt.com/articles/20160324/17160034007/namespaces-intellectual-property-dependencies-big-giant-mess.shtml On 3 April 2017 at 17:35, wrote: > Thanks for the continued feedback on this difficult issue. > > FYI: > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html > > - Mark From alasdair.nottingham at gmail.com Mon Apr 3 17:52:02 2017 From: alasdair.nottingham at gmail.com (Alasdair Nottingham) Date: Mon, 3 Apr 2017 13:52:02 -0400 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> Message-ID: <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> Hi, I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this proposal will affect us. Our Java Agent is used to update the bytecode of our classes to add in instrumentation for debug logging and performance monitoring. In general it is attached via -javaagent, which wont be affected by this proposal. However there is one case where we do a dynamic attach of this agent. There is an industry trend towards running the application server as an uber-jar using java -jar . To support this in Liberty (in common with other application servers) our main method extracts the app server to disk at startup before bootstrapping the server from extracted jar files. One of the jar files extracted in this way is our Java agent, so we use the attach API to attach it so we get monitoring and debug logging. I had been thinking of expanding this to use the attach api in preference to -javaagent because that gets rid of this spurious error message from the mac JVM: objc[56755]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x10f4464c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x110dbb4e0). One of the two will be used. Which one is undefined. As I understand it from the emails the issue is that the agent API is now more powerful in Java 9 and can be used to break modularity, and therefore there is a desire to restrict access to it to preserve the integrity of the modularity system. I?d like to add my support to Andrew?s points. I think they are well made and cover my concerns with the proposals well. I?d like to add my thoughts as well though. As I see it there are these 4 possible scenarios: 1) Java agent specified using -javaagent 2) Java agent dynamically added by same JVM 3) Java program uses a library that secretly dynamically adds a Java agent to do break modularity. 4) Java agent dynamically added using external tool The proposal does nothing to prevent the first scenario 1, and breaks everything using scenario 2 and 4 in the hope of preventing scenario 3. As a Java developer I can do what I want via scenario 1, so I have the magic bullets to break modularity. The downside is it requires collusion with the application user. I wish to remove the need for that collusion since it makes my application easier to use, so I prefer scenario 2. I agree with Andrew that scenario 3 is unlikely to be a serious issue. As a developer when I pick up libraries I have a good understanding of what they do and I either accept, or I do not the implications. Checking to see if a library attaches a Java agent is trivial since you just need to look for a manifest header. I?m going to know if a library does this. Personally I don?t care about scenario 4, but it seems scenario 4 is being broken merely to prevent someone shelling out to a new JVM that calls the attach API to attach the agent. The effect of this seems significant and negative. The fact that the enablement of the local jmx connector was highlighted as something not to break indicates that this is understood, but I don?t think the local jmx connector should have special status in this regard. As stated above I do care about scenario 2 because I need it. Disabling Java agents from being dynamically attached provides zero real protection because I would just have my uber-jar main method extract my server and then launch a new JVM using -javaagent. This is not good from a usability perspective, but it is certainly an option. The proposal appears to me to provide no protection for modularity, but makes my application less usable on Java 9, vs Java 8. As has been mentioned on this thread the people setting these options are the people least capable of understanding and getting them right. Mark did ask for alternative proposals, so other than the defer to a future release option, what about allowing a developer to put something in the manifest.mf to enable dynamic attachment from the same JVM? If there is a concern over all or nothing being too broad the manifest entry could list a hash of the agent jar so the developer has to know about the agent a-priori. I think this would solve scenario 3, but wouldn?t break scenario 2 or 4. It wouldn?t protect against the child JVM does the bad attach, but perhaps that can be solve with a less blunt instrument. Thanks Alasdair STSM - IBM WebSphere Liberty > On Apr 3, 2017, at 12:44 PM, Andrew Dinn wrote: > > On 03/04/17 16:50, Alan Bateman wrote: >>> Also, can you provide a reason why you are so agin agent-hoisting from >>> within a JVM? Is there a reason why it is such a cardinal sin? >> As Mark said, this discussion got off to a bad start. We might have to >> explain the issue again. > > Sure, only I don't think I have misunderstood the existing explanations > (that was what I wanted to check). However, I am not clear that I am > getting the same, consistent explanation each time. > >> Java SE 9 / JDK 9 brings strong encapsulation. The access control for >> the Java Language and VM has been extended to modules so that modules >> that don't want their internals to be accessed from code outside the >> module can do so. None of the core modules want their internals to be >> accessed so none of the core modules are open or open any packages. A >> consequence of this is that code on the class path or module path >> doesn't get to break in these modules. This is really nice but it >> exposes a lot of technical debt in existing code (as we've seen in mails >> here over the last 18 months). > > Yes, it is really nice in many ways. But it is also not necessarily what > everyone wants. > > One thing I am not clear on as regards that 'really nice' is whether > anything in the JVM wants -- or even hopes -- to rely on module > encapsulation never being broken in order to provide 'semantic' > guarantees. That's different from relying on it to provide security > guarantees. The sort of thing I am thinking about is, say, a module-wide > global analysis in the JIT guaranteeing that a call argument will only > ever be non-NULL, a positive int, or some such invariant that can fed > into an optimization phase. I can understand how a switch to disable > dynamic agent loading might be needed to underline that sort of guarantee. > >> . . . >> Now bring the attach API and late binding agents into the picture. This >> is where things blur and where the problem arises. A library can use the >> attach mechanism to load an agent into the current VM and break into any >> module. It's much easier in JDK 9 compared to previous releases because >> the jdk.attach module is resolved by default. All it takes is someone to >> post a solution on stackoverflow that spins a sneaky agent to leak the >> Instrumentation object to the library. It's just too easy to "migrate" >> existing reflection hacks. > > I think this is already very well known technology and the presence of > the jdk.attach module in the runtime was never really much of a bar. The > people who want to do this certainly don't have to look for sneaky > solutions on stackoverflow. However, I still don't really see your point > here. If people want to migrate existing reflection hacks then they can > and will do so by switching off your proposed flag or adding the agent > at startup. > > Are you perhaps concerned that users might have their hand forced by > providers of library jars or middleware who hoist an agent into the JVM > behind their backs? I think that would be rather a patronising view to > take of the vast majority of producers and consumers of libraries and/or > middleware. My belief is that anyone who attempted to provide a library > or framework (open source or not) that disabled (some or all) modules by > stealth would very soon be found out. I also believe they would > immediately lose all (or, at least, most) of their prospective business > from serious, paying customers. After all, that sort of behaviour > *would* be a major security issue. > > As I mentioned in my reply to Mark it is critical for users to know > exactly how any agent they load into their JVM is going to modify the > access restrictions in place in the JVM so that they can be sue that use > of the agent is safe (just as they need to know that any jars they place > into the classpath are not going to do things like round down their > costs and pocket the spare change in a bank account somwehere). Users > don't just add stuff to their classpath without knowing what it does and > why it is appropriate. > > Also, that doesn't mean there will be no market for code which > advertises that it is going to change access controls. If users know > what they are getting and know what the consequences are then I am sure > there are cases where they can safely decide whether or not to use a > library that opens up module access. It's the idea that people are going > to be hoodwinked here -- if indeed that is your idea -- that I find > rather difficult to follow. We seem to have moved from dynamic agent > loading being a security issue that didn't seem to have a real basis to > a 'users cannot be entrusted to look after their own classpath' issue > that I find equally as baseless. Is there more to what you are saying > that I have not grasped? > >> The attach mechanism was of course never intended to be used this way. >> It was meant for troubleshooting tools and profilers/similar to load >> agents into running VMs. Back in the JDK 6 then we did consider >> disallowing attaching to the current VM but didn't enforce it - one >> reason is that it's not hard to just fork a VM with tools.jar on the >> class path and connect back to the parent. > > Well, I understand that this is not what you intended. However, i) it > turns out to have been very useful that it does work this way and ii) > stopping it doing so has a cost which needs to be taken into account -- > at the very least by giving those who have been relying on it for quite > some time to manage their business concerns to adjust to the change. > >> So that is the context for the discussion. We need to find a good way to >> put the Genie back in its bottle. It may be that we have to disable >> attaching to the current or ancestor VMs. We may have to prohibit the >> instrumentation of core modules by late binding agents. We may have to >> do some disabling of agent loading. Maybe a combination. Suggestions and >> proposals are of course welcome. > > I'm very happy to consider all sorts of half-way houses or even -- in > time -- the full change recommended in the original JIRA. For example, > rejecting instrumentation in some specific set of bootstrap/JDK module > classes (like, say, java.base) from an agent which has been dynamically > loaded might well be a workable compromise -- that at least allows users > to employ an agent to tweak any code that is in the classpath through > their choice. > > However, whatever compromise we arrive at I'd certainly like time to > adjust to it and hence prefer to see it happen in JDK10. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From alan.bateman at oracle.com Mon Apr 3 17:54:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 03 Apr 2017 17:54:13 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704031754.v33HsDSQ018454@aojmv0008.oracle.com> Changeset: 4205f4220e41 Author: alanb Date: 2017-04-03 14:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4205f4220e41 Remove unused methods ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/Modules.java Changeset: 1655ceeb9ba3 Author: alanb Date: 2017-04-03 18:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1655ceeb9ba3 Instrumentation API needs to allow for non-modifiable modules ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java + src/java.instrument/share/classes/java/lang/instrument/UnmodifiableModuleException.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! test/java/lang/instrument/RedefineModuleAgent.java ! test/java/lang/instrument/RedefineModuleTest.java From mandy.chung at oracle.com Mon Apr 3 18:41:03 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 11:41:03 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ This revisits the OS name and arch in packaging JDK modules to extend the module descriptor with ModuleTarget class file attribute. We considered matching with the system properties. Linux x64 JDK can run on a system whose `os.arch` system property value can be `amd64` or `i586` or `x86_x64`. Similiarly, windows x86/x64 JDK can run on a system whose `os.name` system property starts with ?Windows? as the os.name property is set to "Windows XXX" for example "Windows Server 2012 R2?. It might be worth considering multiple OS arch values in ModuleTarget in the future. JDK bundle names are revised in JDK 9. This is a good alternative to be consistent with $OS-$ARCH value in the bundle names. This patch proposes to package JDK modules with OS name and arch to match the values as in JDK bundle names. jlink will generate the `release` file and set OS_NAME and OS_ARCH to those values. This also proposes to drop OS_VERSION to align with the ModuleTarget class file attribute. This shows the old and new value of OS_NAME/OS_ARCH properties in the `release` file: JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin osx Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 x64 sparcv9 sparcv9 arm arm32 aarch64 arm64 Mandy From Alan.Bateman at oracle.com Mon Apr 3 18:41:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 19:41:43 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> Message-ID: <73a374c3-9515-5d09-cdd2-5f56a46f739c@oracle.com> On 03/04/2017 18:52, Alasdair Nottingham wrote: > Hi, > > I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this proposal will affect us. Our Java Agent is used to update the bytecode of our classes to add in instrumentation for debug logging and performance monitoring. In general it is attached via -javaagent, which wont be affected by this proposal. However there is one case where we do a dynamic attach of this agent. There is an industry trend towards running the application server as an uber-jar using java -jar . To support this in Liberty (in common with other application servers) our main method extracts the app server to disk at startup before bootstrapping the server from extracted jar files. One of the jar files extracted in this way is our Java agent, so we use the attach API to attach it so we get monitoring and debug logging. I had been thinking of expanding this to use the attach api in preference to -javaagent because that gets rid of this spurious error message from the mac JVM: > > objc[56755]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x10f4464c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x110dbb4e0). One of the two will be used. Which one is undefined. Thanks for the mail on your usage. On the spurious message then this was this was JDK-8022291 and has been fixed since jdk-9+127. The change has also been back-ported to jdk8u-dev. -Alan From rafael.wth at gmail.com Mon Apr 3 18:49:55 2017 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 3 Apr 2017 20:49:55 +0200 Subject: Restriction of module redefineability in recent commit Message-ID: I just found out about this change to restrict redefining some modules: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 and I can only repeat my warning that this further restriction will make it harder to migrate to Java 9 and might break tools in the process. It does neither seem to me that a good alternative is offered if opening core modules is required to make a Java agent work. Is this change intending to freeze classes of java.base or to restrict exporting? If so, does this also affect the command line to change the properties of certain modules? Was an evaluation done how this change might impact existing tools? Thanks for explaining this change. Best regards, Rafael From greggwon at cox.net Mon Apr 3 18:58:55 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Mon, 3 Apr 2017 13:58:55 -0500 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <3bfu1v0164x5MXx01bfvJB> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <3bfu1v0164x5MXx01bfvJB> Message-ID: Again, I want to stress that from my position we are completely ignoring desktop Java users who will update Java to JDK 9 and never know that they?ve broken something by doing that. Java is not a server only enterprise deployed environment? Gregg > On Apr 2, 2017, at 6:39 PM, Stephen Felts wrote: > > I agree with Andrew's position that if the argument is added in JDK9, it should default to allow dynamic loading of agents. > > Arguing from the position "Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options anyway, in order to expose internal APIs" isn't a valid argument IMO. Although migration to JDK 9 will be painful, I think that we will get to zero JDK 9 command line arguments. As proposed, this new argument will never go away. > > It's highly likely that customers will have scripts that they migrate from JDK 8 to JDK 9. We don't control that. > And many developers don't use any scripts because for many cases, they don't care about the garbage collector or memory or whatever the scripts provide. > But they do care about product functionality provided by an agent. > > > > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Friday, March 31, 2017 5:46 AM > To: Mark Reinhold > Cc: jigsaw-dev at openjdk.java.net > Subject: Re: Disallowing the dynamic loading of agents by default > > Hi Mark, > > On 30/03/17 16:38, mark.reinhold at oracle.com wrote: >> // Moving the general discussion to jigsaw-dev for the record; // >> bcc'ing {hotspot-runtime,serviceability}-dev for reference. >> >> Andrew, >> >> Thanks for your feedback on this topic [1][2][3]. > > ... and thank you for your considered reply. > >> First, we apologize for the way in which this topic was raised. Our >> intent was to post a proposal for discussion prior to code review, but >> unfortunately that review was posted prematurely (as is evident by its >> inclusion of Oracle-internal e-mail addresses and URLs). > > Hmm, yes! I must say I didn't notice that. I appreciate the apology but it's not really necessary. I certainly didn't expect any explanation to omit some element of miscommunication and/or cock-up :-) > >> Second, I agree with your earlier analysis as to the security impact >> of this change. If an attack is possible via this vector then closing >> the vector would only slow the attack, not prevent it. > > Good, I am glad to hear there is not some terrible loop-hole at play that I am not aware of. > >> The motivation for this change is, however, not merely to improve the >> security of the platform but to improve its integrity, which is one of >> the principal goals of the entire modularity effort. ... > > Ok, I understand the motive here although I'm still not personally convinced by it. I'll come to the practical considerations below. Before that I'd like to address the question of integrity at a more abstract level. > > I'm certainly not against providing -XX+/-EnableDynamicAgentLoading as a command line option. I agree that it's probably useful for some users to have the option to completely lock down the platform to guarantee its integrity. It seems from what you say above that this lock-down option is only there to provide 'belt and braces'. In other words, it is only necessary to guard against a security breach that could be managed by other means (e.g. a failure to control what jars go into your classpath; a failure to control access to the JVM uid on on the JVM host machine). > I cannot fault the idea of a belt and braces lockdown per se but I am still not convinced why that extra protection needs to be enabled /by default/. > > You specifically bring up the scenario where rogue code, once entered into the JVM, might use the attach API to raise its privilege level. > > "As things stand today, code in any JAR file can use the `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's running and, via that agent, break into any module it likes." > > Yet, you also acknowledge above that this merely constitutes an opportunistic escalation of a situation that is already a serious security breach in its own right. I don't think I follow the logic here. > > Are you saying that we need the extra braces because there is a real danger here? one that users cannot rightly always be expected to guard against? Or are you just being extra cautious. This is really the crux of the matter because that extra caution has to be weighed against the extra cost of lost opportunities to deploy agents in abnormal situations. > > n.b. I know in the case of Red Hat's middleware that this is a real cost which will definitely arise no matter how hard we work to educate users about the necessary advance preparation required. It is also a significant cost because it will damage our ability to resolve certain very difficult support issues where only an agent can provide the information needed. And that is above above and beyond the cost of the re-education task itself. I don't doubt other companies will be affected similarly. > > My mention above of 'abnormal' situations underlines why your argument about integrity is somewhat moot (to me). Yes, it is important to know that encapsulation means encapsulation -- at least, I agree that is so in /normal/ circumstances. However, agents are clearly not normal code performing the normal program operations of an application. Many agents are specifically designed fro deployment in abnormal situations and perform abnormal actions. That is precisely what provides the impetus to deploy agents dynamically. > > It is highly valuable in such circumstances, and only in those circumstances, to be able to allow privileged agent code to /selectively/ remove certain integrity barriers, even if -- perhaps, especially because -- any dismantling of the normal rules of operation only happens modulo the specific licence the agent has been crafted and configured to grant. Useful agents clearly scope the degree to which they perturb normality to achieve abnormal results. Careful and thoughtful users can (must) still feel safe that an agent is not going to do catastrophic damage to the running application and the integrity of its data and operation. Ironically, this means that deployment of my agent is actually a relatively normal (even if infrequent) procedure for many of our users. > > So, while I agree that platform (or even application) integrity is a valuable property to maintain in normal program operation, I don't think those concerns are warranted in the case of an agent that has been deliberately and carefully deployed by those in charge of an application. I suspect we are probably not going to agree about the proposed default on these grounds (and I also suspect I will not be the only one to disagree with your position). So, perhaps we would be better off moving on to pragmatic concerns. > >> I understand your points about the practical difficulties of having to >> educate users about this new option and enhance startup scripts to use >> the option only when invoking JDK 9. Isn't it already the case, >> however, that migrating existing applications to JDK 9 is often going >> to require the use of a few new options anyway, in order to expose internal APIs? >> If so then would it really be that much more burdensome for users also >> to think explicitly, at the same time, about whether they want to >> enable dynamic agent loading? > > If the default is reset to allow dynamic loading then I am happy to fully endorse this change and see no significant consequences. If this change is going to happen with your proposed default then I would very much prefer it to be staged: introduce the flag in 9 but with the default being to allow dynamic loading of agents (i.e. default to the status quo); reset the default in 10 to disable loading. The benefit of that is > > aware JDK9 users can still use or ignore the option as they see fit > > unaware JDK9 users will not get hit by the change by surprise in JDK9 > > unaware JDK10 users may still get hit by surprise but by that stage any configuration option they add to their JDK10 scripts will be compatible if they need to switch back and forth between JDK10 and JDK9 > > implementers of agents and implementers of middleware that might benefit from using those agents have more time to prepare their users, limiting the potential for any such nasty surprise in JDK10 > >> This change would be disruptive to some but it's the best way we've >> found, so far, to preserve platform integrity in the face of dynamic >> agent loading. If there's a better way to do that, we'd like to know. > > No, I don't think there is a better mechanism, only a better default. > That reflects my belief that, while 'preserving platform integrity' is a highly desirable goal, for most users it does not merit being pursued 'in the face of dynamic agent loading'. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Mon Apr 3 19:01:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 20:01:22 +0100 Subject: jake -> jdk9/dev Message-ID: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> We have a number of changes accumulated in the jake forest that we need to bring to jdk9/dev soon. The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a bit disruptive for those using the JDK 9 EA builds and the new APIs. The revised proposed for #VersionsInModuleNames reverts a previous proposal so that digits are now preserved at the end of module names. We also have a minor update to JVM TI to java.lang.instrument to allow for unmodifable modules. This is to fix the inconsistency with unmodifable classes. It is independent of the ongoing discussion about java agents and no impact to agents using the draft APIs. That's all for now. The highest priority is to get the jlr.Module -> jl.Module move into jdk9/dev. As I mentioned in a mail last week, this requires a bit of coordination to meet up with the changes coming from the OpenJFX project. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#MoveModuleAndLayerClasses From greggwon at cox.net Mon Apr 3 19:03:32 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Mon, 3 Apr 2017 14:03:32 -0500 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <3sYq1v03X4x5MXx01sYrGp> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> Message-ID: <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> Alan, it is exactly this kind of comment from the team which just tears apart the whole view that you might actually be considering what everyone in the Java community needs. There are people who always deploy with a security manager because they are deploying Java on a network or with Subjects active or any number of other reasons why a SecurityManager might be active. I just feels like the team is completely out of touch with anyone who isn?t just running a web server or some other ?app? server on a cloud environment. Java is used in so many other ways. Just like you?ve found that people are using introspection to access parts of the Java runtime that you?d like for them not to use, people are using ALL of the features of Java in ways you apparently are not aware of, or don?t seem to have considered. The repeated dismissal of the SecurityManager and the whole missing focus on ?java users? as opposed to java developers is just amazing from my perspective? Gregg > On Apr 3, 2017, at 11:32 AM, Alan Bateman wrote: > > On 03/04/2017 17:28, Reto Merz wrote: > >> It was already suggested in another thread by Gregg Wonderly: >> Why not introduce a new method java.lang.SecurityManager#checkAttachAgent(x)? >> So the implementation can accept/reject an "attach agent request" dynamically at runtime. >> x could be some additional infos provided by the agent (eg: certificate). > The issue here is nothing to do with the security manager, assume no security manager in the picture. > > Also, FWIW, VirtualMachine.attach has always specified a security manager for the (probably rare) cases where a tool is run with a security manager. > > -Alan From alasdair.nottingham at gmail.com Mon Apr 3 19:11:37 2017 From: alasdair.nottingham at gmail.com (Alasdair Nottingham) Date: Mon, 3 Apr 2017 15:11:37 -0400 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <73a374c3-9515-5d09-cdd2-5f56a46f739c@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> <73a374c3-9515-5d09-cdd2-5f56a46f739c@oracle.com> Message-ID: Yes that is really good. I was really happy to see that. I can?t wait for a Java 8 release that contains the fix (u121 on the mac does not). The reason I brought it up is because that long standing weird error message is resolved using the attach api to add the agent. I?m sure I?m not the only person to have realized this. Alasdair > On Apr 3, 2017, at 2:41 PM, Alan Bateman wrote: > > On 03/04/2017 18:52, Alasdair Nottingham wrote: > >> Hi, >> >> I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this proposal will affect us. Our Java Agent is used to update the bytecode of our classes to add in instrumentation for debug logging and performance monitoring. In general it is attached via -javaagent, which wont be affected by this proposal. However there is one case where we do a dynamic attach of this agent. There is an industry trend towards running the application server as an uber-jar using java -jar . To support this in Liberty (in common with other application servers) our main method extracts the app server to disk at startup before bootstrapping the server from extracted jar files. One of the jar files extracted in this way is our Java agent, so we use the attach API to attach it so we get monitoring and debug logging. I had been thinking of expanding this to use the attach api in preference to -javaagent because that gets rid of this spurious error message from the mac JVM: >> >> objc[56755]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x10f4464c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x110dbb4e0). One of the two will be used. Which one is undefined. > Thanks for the mail on your usage. On the spurious message then this was this was JDK-8022291 and has been fixed since jdk-9+127. The change has also been back-ported to jdk8u-dev. > > -Alan From Alan.Bateman at oracle.com Mon Apr 3 19:21:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Apr 2017 20:21:40 +0100 Subject: Restriction of module redefineability in recent commit In-Reply-To: References: Message-ID: <6db2f66c-5b19-4b47-578c-78e84abf6760@oracle.com> On 03/04/2017 19:49, Rafael Winterhalter wrote: > I just found out about this change to restrict redefining some modules: > http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 and I can > only repeat my warning that this further restriction will make it harder to > migrate to Java 9 and might break tools in the process. It does neither > seem to me that a good alternative is offered if opening core modules is > required to make a Java agent work. > > Is this change intending to freeze classes of java.base or to restrict > exporting? If so, does this also affect the command line to change the > properties of certain modules? Was an evaluation done how this change might > impact existing tools? I mentioned this in another mail a few minutes ago. There has always been the notion of unmodifiable classes in both JVM TI and java.lang.instrument. JSR 163 defined a function + method in both APIs to test if a class is modifiable and all functions/methods that transformed classes could fail. As things stand then you cannot modify array primitive classes, ditto for VM anonymous classes. In the past then this was used to deal with interactions with class data sharing when classes in the archive could not be modified. For both API consistency reasons and to allow for cases that we can't anticipate now then the new JVM TI functions to update modules should allow for the possibility that a module is not modifiable. That should not be controversial. There are no unmodifiable modules and there should be no impact on agents making use of these functions. -Alan From eirbjo at gmail.com Mon Apr 3 19:33:12 2017 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 3 Apr 2017 21:33:12 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170330153845.72C9B96BD9@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> Message-ID: Hi, I can share three examples of agents I've developed the past few years where this change is or could have been disruptive to some extent: *JettyConsole:* JettyConsole takes war files and make them "executable" with java -jar by embedding the Jetty servlet container inside the war file. HTTP/2 support is implemented as an agent which uses dynamic agent loading to replace TLS implementation classes in the JDK at bootstrap to allow Jetty's HTTP/2 implementation to offer ALPN (required for H2). Changing this plugin to use a command line invoked agent would defeat the whole purpose of JettyConsole, which is to distribute a whole Java Servet webapp in a single binary artifact. The workaround would be to fork the JVM at startup. (Less relevant in the future since my understanding is that ALPN will be supported in JDK9..) *NotSoSerial* NotSoSerial is a Java Agent designed as a mitigation effort against Java deserialization attacks. NotSoSerial used dynamic agents, however mostly to ease unit testing. I was however in discussion with a pretty large platform vendor who were considering the option of deploying a hotfix to their customer using NotSoSerial's dynamic agent support. In the end, I think they ended up using just the command line agent. But from a security perspective, having the option of rolling out an emergency fix dynamically has some desired properties. *Skybar:* Skybar (presented at JVMLS15) is a code coverage instrumentation agent, built with a focus on performance. Skybar makes it is possible to record two "runs" of code and compare these runs afterwords. This can be very useful in troubleshooting weird production issues which can be extremely hard, expensive or even impossible to reproduce in a lab. In this mode, it's very useful to attach the agent dynamically, since you might not know that you need it until your system has been running for a while. Outside Skybar, I've been using dynamic agents multiple times in the past to instrument code (JDK or user) to troubleshoot shy issues in production. It's made a superhero for a day for several clients :-) Thanks, Eirik. On Thu, Mar 30, 2017 at 5:38 PM, wrote: > // Moving the general discussion to jigsaw-dev for the record; > // bcc'ing {hotspot-runtime,serviceability}-dev for reference. > > Andrew, > > Thanks for your feedback on this topic [1][2][3]. > > First, we apologize for the way in which this topic was raised. Our > intent was to post a proposal for discussion prior to code review, but > unfortunately that review was posted prematurely (as is evident by its > inclusion of Oracle-internal e-mail addresses and URLs). > > Second, I agree with your earlier analysis as to the security impact of > this change. If an attack is possible via this vector then closing the > vector would only slow the attack, not prevent it. > > The motivation for this change is, however, not merely to improve the > security of the platform but to improve its integrity, which is one of > the principal goals of the entire modularity effort. Integrity has > benefits for security and also for maintainability, of both the JDK > itself and of code that runs upon it, since it makes it clear exactly > which APIs are intended for external use, and which are not. > > To improve platform integrity we've strongly encapsulated (most) of the > internal APIs of the JDK. That can be, as we all know, a source of pain > for developers trying to get existing applications to run on JDK 9, so > we've provided workarounds via the encapsulation-busting `--add-opens` > and `--add-exports` command-line options and, recently, the temporary > but more powerful (and verbose) `--permit-illegal-access` option. > > There are no API equivalents to these command-line options [4]. That's > intentional: We want developers and deployers using Java out-of-the-box > to be assured that their code is only using APIs actually intended for > external use. They can choose explicitly to expose internal APIs, via > the command line, but then that's a deliberate choice that they make, and > they own the consequences. It's reasonable to allow this via the command > line since we assume that anyone with access to the command line already > has the power to corrupt the JDK in any way they please. > > The proposal to disable the loading of dynamic agents by default is one > more part of the overall integrity story. As things stand today, code in > any JAR file can use the `VirtualMachine.loadAgent` API to load an agent > into the JVM in which it's running and, via that agent, break into any > module it likes. Changing the default and providing a new command-line > option, in this case `-XX:+EnableDyanmicAgentLoading`, is consistent with > the other encapsulation-busting options we've introduced. It allows a > developer or deployer to choose to bend, if not violate, the integrity > of the platform, yet also to know that by default the platform is whole. > (Changing this default is also consistent, as Alan has noted, with the > original intent of the `VirtualMachine.loadAgent` API.) > > I understand your points about the practical difficulties of having to > educate users about this new option and enhance startup scripts to use > the option only when invoking JDK 9. Isn't it already the case, however, > that migrating existing applications to JDK 9 is often going to require > the use of a few new options anyway, in order to expose internal APIs? > If so then would it really be that much more burdensome for users also > to think explicitly, at the same time, about whether they want to enable > dynamic agent loading? > > This change would be disruptive to some but it's the best way we've > found, so far, to preserve platform integrity in the face of dynamic > agent loading. If there's a better way to do that, we'd like to know. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ > 2017-March/022948.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ > 2017-March/022951.html > [3] https://bugs.openjdk.java.net/browse/JDK-8177154 > [4] There are limited reflective APIs via which code in a module can > apply some of these operations to just that module, and via which > code that creates a module layer can do so for modules in that > layer, but none of these APIs can break into arbitrary modules. > From mark.reinhold at oracle.com Mon Apr 3 20:15:52 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 13:15:52 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <20170403131552.834209932@eggemoggin.niobe.net> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > ... > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 I suggest we use "amd64" instead of "x64" (or any other variants). "x64" is confusingly close to "x86", and while it's used by some companies (including Oracle), it's not used all that widely. "amd64" is better known, matches the long-standing value of the "os.arch" system property (on Linux and Windows, anyway) and, as a side benefit, honors the originators of the architecture. - Mark From simon at cjnash.com Mon Apr 3 20:35:30 2017 From: simon at cjnash.com (Simon Nash) Date: Mon, 03 Apr 2017 21:35:30 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403131552.834209932@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> Message-ID: <58E2B212.6080605@cjnash.com> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: > 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> >> ... >> >> This shows the old and new value of OS_NAME/OS_ARCH properties >> in the `release` file: >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin osx >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 x64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 > > I suggest we use "amd64" instead of "x64" (or any other variants). > "x64" is confusingly close to "x86", and while it's used by some > companies (including Oracle), it's not used all that widely. "amd64" is > better known, matches the long-standing value of the "os.arch" system > property (on Linux and Windows, anyway) and, as a side benefit, honors > the originators of the architecture. > > - Mark > I am not sure why we would change to osx for Mac when the Mac developers have recently dropped the Mac OS X terminology and changed it to macOS. Simon From stephen.felts at oracle.com Mon Apr 3 20:54:35 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 3 Apr 2017 13:54:35 -0700 (PDT) Subject: jake -> jdk9/dev In-Reply-To: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> References: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> Message-ID: The jlr.Module -> jl.Module can cause some other problems. ? It breaks source code compatibility that is totally unrelated to JDK9 (code that has been compiling for 20 years).? Unfortunately, the name Module is pretty popular ? I saw 7 occurrences of the following. ? $ cat Test.java import tmp.*; ? public class Test extends Module { } $ cat tmp/Module.java package tmp; ? public class Module { } $ javac Test.java tmp/Module.java Test.java:3: error: reference to Module is ambiguous public class Test extends Module { ????????????????????????? ^ ? both class tmp.Module in tmp and class java.lang.Module in java.lang match 1 error ? ? In addition to OpenFX, this also breaks standalone jaxws-rt. ? META-INF/versions/9/com/sun/xml/ws/api/server/SDDocumentSource.class META-INF/versions/9/com/sun/xml/ws/util/HandlerAnnotationProcessor.class ? If you need to handle the old and new classes, I used something like the following where ?module? used to be ?Module? instead of ?Object?. ? ??????????????? Object module = resolvingClass.getModule(); ??????????? ????if (module != null) { ??????????????????? Class c = null; ??????????????????? try? { ????????????????????? c = Class.forName("java.lang.reflect.Module"); ??????????????????? } catch (Exception ignore) { ????????????????????? try { ???????????????????? ???c = Class.forName("java.lang.Module"); ????????????????????? } catch (Exception ignore2) { ????????????????????? } ??????????????????? } ??????????????????? if (c == null) { ????????????????????? throw new IOException("Can't find Module class"); ?????? ?????????????} ??????????????????? try { ????????????????????? Method m = c.getMethod("getResourceAsStream", String.class); ????????????????????? InputStream stream = (InputStream)m.invoke(module, path); ????????????????????? if (stream != null) { ??????? ??????????????????return stream; ????????????????????? } ?????????????????? } catch (Exception e) { ?????????????????? } ?????????????????? Throw new Exception(?you lose?); ? ? -----Original Message----- From: Alan Bateman Sent: Monday, April 3, 2017 3:01 PM To: jigsaw-dev Subject: jake -> jdk9/dev ? We have a number of changes accumulated in the jake forest that we need to bring to jdk9/dev soon. ? The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a bit disruptive for those using the JDK 9 EA builds and the new APIs. ? The revised proposed for #VersionsInModuleNames reverts a previous proposal so that digits are now preserved at the end of module names. ? We also have a minor update to JVM TI to java.lang.instrument to allow for unmodifable modules. This is to fix the inconsistency with unmodifable classes. It is independent of the ongoing discussion about java agents and no impact to agents using the draft APIs. ? That's all for now. The highest priority is to get the jlr.Module -> jl.Module move into jdk9/dev. As I mentioned in a mail last week, this requires a bit of coordination to meet up with the changes coming from the OpenJFX project. ? -Alan ? [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#MoveModuleAndLayerClasses ? ? From john.r.rose at oracle.com Mon Apr 3 20:56:23 2017 From: john.r.rose at oracle.com (John Rose) Date: Mon, 3 Apr 2017 13:56:23 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> Message-ID: <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> On Apr 3, 2017, at 12:03 PM, Gregg Wonderly wrote: > > Alan, it is exactly this kind of comment from the team which just tears apart the whole view that you might actually be considering what everyone in the Java community needs. I think *this* comment is unfair to Alan. I read Alan as saying "don't assume that users can rely on an SM present". If I'm right, that is a far cry from tearing the community into parts. I think you would admit that not everyone uses SM. So you didn't ding Alan (who is doing really heroic work for the community) for simply reminding us that a SM-based approach would not serve the whole community equally. Did you impute some other motive to him? ? John From mandy.chung at oracle.com Mon Apr 3 21:07:39 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 14:07:39 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2B212.6080605@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> Message-ID: <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> > On Apr 3, 2017, at 1:35 PM, Simon Nash wrote: > > On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: > > I am not sure why we would change to osx for Mac when the Mac developers > have recently dropped the Mac OS X terminology and changed it to macOS. Just to be clear, there is no plan to change the value of the ?os.name? system property and its value is ?Mac OS X?. Changing the value of the system property ?os.name? would break existing applications. In JDK 8, OS_NAME in the release file is ?Darwin? which is what this patch would change. Mandy From kevin.rushforth at oracle.com Mon Apr 3 21:09:02 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 03 Apr 2017 14:09:02 -0700 Subject: jake -> jdk9/dev In-Reply-To: References: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> Message-ID: <58E2B9EE.70201@oracle.com> I note that Phil pushed the changes to OpenJFX in time for build 164 so that problem, at least, is resolved. -- Kevin Stephen Felts wrote: > The jlr.Module -> jl.Module can cause some other problems. > > > > It breaks source code compatibility that is totally unrelated to JDK9 (code that has been compiling for 20 years). Unfortunately, the name Module is pretty popular ? I saw 7 occurrences of the following. > > > > $ cat Test.java > > import tmp.*; > > > > public class Test extends Module { > > } > > $ cat tmp/Module.java > > package tmp; > > > > public class Module { > > } > > $ javac Test.java tmp/Module.java > > Test.java:3: error: reference to Module is ambiguous public class Test extends Module { > > ^ > > both class tmp.Module in tmp and class java.lang.Module in java.lang match > > 1 error > > > > > > In addition to OpenFX, this also breaks standalone jaxws-rt. > > > > META-INF/versions/9/com/sun/xml/ws/api/server/SDDocumentSource.class > > META-INF/versions/9/com/sun/xml/ws/util/HandlerAnnotationProcessor.class > > > > If you need to handle the old and new classes, I used something like the following where ?module? used to be ?Module? instead of ?Object?. > > > > Object module = resolvingClass.getModule(); > > if (module != null) { > > Class c = null; > > try { > > c = Class.forName("java.lang.reflect.Module"); > > } catch (Exception ignore) { > > try { > > c = Class.forName("java.lang.Module"); > > } catch (Exception ignore2) { > > } > > } > > if (c == null) { > > throw new IOException("Can't find Module class"); > > } > > try { > > Method m = c.getMethod("getResourceAsStream", String.class); > > InputStream stream = (InputStream)m.invoke(module, path); > > if (stream != null) { > > return stream; > > } > > } catch (Exception e) { > > } > > Throw new Exception(?you lose?); > > > > > > -----Original Message----- > From: Alan Bateman > Sent: Monday, April 3, 2017 3:01 PM > To: jigsaw-dev > Subject: jake -> jdk9/dev > > > > We have a number of changes accumulated in the jake forest that we need to bring to jdk9/dev soon. > > > > The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a bit disruptive for those using the JDK 9 EA builds and the new APIs. > > > > The revised proposed for #VersionsInModuleNames reverts a previous proposal so that digits are now preserved at the end of module names. > > > > We also have a minor update to JVM TI to java.lang.instrument to allow for unmodifable modules. This is to fix the inconsistency with unmodifable classes. It is independent of the ongoing discussion about java agents and no impact to agents using the draft APIs. > > > > That's all for now. The highest priority is to get the jlr.Module -> jl.Module move into jdk9/dev. As I mentioned in a mail last week, this requires a bit of coordination to meet up with the changes coming from the OpenJFX project. > > > > -Alan > > > > [1] > > http://openjdk.java.net/projects/jigsaw/spec/issues/#MoveModuleAndLayerClasses > > > > > From simon at cjnash.com Mon Apr 3 21:38:52 2017 From: simon at cjnash.com (Simon Nash) Date: Mon, 03 Apr 2017 22:38:52 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> Message-ID: <58E2C0EC.4000907@cjnash.com> On 03/04/2017 22:07, Mandy Chung wrote: >> On Apr 3, 2017, at 1:35 PM, Simon Nash wrote: >> >> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >> >> I am not sure why we would change to osx for Mac when the Mac developers >> have recently dropped the Mac OS X terminology and changed it to macOS. > > Just to be clear, there is no plan to change the value of the > ?os.name? system property and its value is ?Mac OS X?. > Changing the value of the system property ?os.name? would > break existing applications. > > In JDK 8, OS_NAME in the release file is ?Darwin? which is > what this patch would change. > > Mandy I understand that the os.name property value cannot be changed for compatibility reasons and therefore this name needs to stay as the "historic" Mac OS X. My comment was regarding the change of value for OS_NAME. Given that there is no compatibility issue here, does it make sense for the new value to be something that is no longer current in Apple terminology? Simon From mark.reinhold at oracle.com Mon Apr 3 21:39:25 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 14:39:25 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2B212.6080605@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> Message-ID: <20170403143925.120730340@eggemoggin.niobe.net> 2017/4/3 13:35:30 -0700, simon at cjnash.com: > On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>> >>> ... >>> >>> This shows the old and new value of OS_NAME/OS_ARCH properties >>> in the `release` file: >>> >>> JDK 8 JDK 9 >>> ----- ----- >>> OS_NAME Linux linux >>> SunOS solaris >>> Darwin osx >>> Windows windows >>> >>> OS_ARCH i386,x86 x86 >>> i586,amd64,x86_64 x64 >>> sparcv9 sparcv9 >>> arm arm32 >>> aarch64 arm64 > > I am not sure why we would change to osx for Mac when the Mac developers > have recently dropped the Mac OS X terminology and changed it to macOS. Agreed -- we should change OS_NAME from "Darwin" to "macos". - Mark From mandy.chung at oracle.com Mon Apr 3 21:50:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 14:50:52 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403143925.120730340@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> Message-ID: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> > On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: > > 2017/4/3 13:35:30 -0700, simon at cjnash.com: >> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>> >>>> ... >>>> >>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>> in the `release` file: >>>> >>>> JDK 8 JDK 9 >>>> ----- ----- >>>> OS_NAME Linux linux >>>> SunOS solaris >>>> Darwin osx >>>> Windows windows >>>> >>>> OS_ARCH i386,x86 x86 >>>> i586,amd64,x86_64 x64 >>>> sparcv9 sparcv9 >>>> arm arm32 >>>> aarch64 arm64 >> >> I am not sure why we would change to osx for Mac when the Mac developers >> have recently dropped the Mac OS X terminology and changed it to macOS. > > Agreed -- we should change OS_NAME from "Darwin" to "macos?. OK. Should the bundle names be updated to reflect this change? In any case, it is a separate issue. JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin macos Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 amd64 sparcv9 sparcv9 arm arm32 aarch64 arm64 Mandy From mark.reinhold at oracle.com Mon Apr 3 22:36:31 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 3 Apr 2017 15:36:31 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> Message-ID: <20170403223631.349F5A1A68@eggemoggin.niobe.net> 2017/4/3 9:44:43 -0700, Andrew Dinn : > On 03/04/17 16:50, Alan Bateman wrote: >> ... >> >> Java SE 9 / JDK 9 brings strong encapsulation. The access control for >> the Java Language and VM has been extended to modules so that modules >> that don't want their internals to be accessed from code outside the >> module can do so. None of the core modules want their internals to be >> accessed so none of the core modules are open or open any packages. A >> consequence of this is that code on the class path or module path >> doesn't get to break in these modules. This is really nice but it >> exposes a lot of technical debt in existing code (as we've seen in mails >> here over the last 18 months). > > Yes, it is really nice in many ways. But it is also not necessarily what > everyone wants. > > One thing I am not clear on as regards that 'really nice' is whether > anything in the JVM wants -- or even hopes -- to rely on module > encapsulation never being broken in order to provide 'semantic' > guarantees. That's different from relying on it to provide security > guarantees. The sort of thing I am thinking about is, say, a module-wide > global analysis in the JIT guaranteeing that a call argument will only > ever be non-NULL, a positive int, or some such invariant that can fed > into an optimization phase. I can understand how a switch to disable > dynamic agent loading might be needed to underline that sort of guarantee. That's exactly the kind of thing we want to enable, long-term, and one reason why integrity is worth improving aside from any considerations of security -- and why suggestions by others to "just use a security manager" if you care about such things are beside the point. (An even simpler example than the ones you mention is the fact that `final` doesn't mean "final" in the face of deep reflection. This either prevents or greatly complicates optimizations that are based on or enabled by constant folding, which is an awful lot of them.) In addition to future performance improvements, let's not forget about maintainability. Improved integrity allows those of us who maintain the JDK to change internal implementation details without having to worry about breaking user code. It allows users of the JDK to be confident that their code depends only on supported interfaces, so that they can more easily upgrade from one release to the next. We've all too often, over the last twenty years, had to back out internal changes because some popular library depended upon those internals. A common response to this concern is to say, "then don't use libraries that depend upon JDK internals!" Would that it were that simple. The hardest cases arise when some library A that depends on JDK internals is published, then it's used by library B, which in turn is used by library C, and that in turn is used by the immensely-popular library D, whose authors don't even know that library A depends on JDK internals. (They might not even know that D ultimately depends on A!). Then we fix a bug in the JDK that changes those internals, library D breaks, a large number of popular applications (or applications with important customers) stop working, and the cries and support escalations demanding that the change be reverted ensue. Anyway ... at the highest level, improving platform integrity is not just about improving security. It's also about improving performance, in the long term, and about improving the maintainability of everybody's code, even in the short term. >> . . . >> Now bring the attach API and late binding agents into the picture. This >> is where things blur and where the problem arises. A library can use the >> attach mechanism to load an agent into the current VM and break into any >> module. It's much easier in JDK 9 compared to previous releases because >> the jdk.attach module is resolved by default. All it takes is someone to >> post a solution on stackoverflow that spins a sneaky agent to leak the >> Instrumentation object to the library. It's just too easy to "migrate" >> existing reflection hacks. > > I think this is already very well known technology and the presence of > the jdk.attach module in the runtime was never really much of a bar. The > people who want to do this certainly don't have to look for sneaky > solutions on stackoverflow. However, I still don't really see your point > here. If people want to migrate existing reflection hacks then they can > and will do so by switching off your proposed flag or adding the agent > at startup. Sure, but both of those approaches require access to the command line, and we already have no choice but to trust those who have such access, so there's no additional risk (or sneakiness) there. > Are you perhaps concerned that users might have their hand forced by > providers of library jars or middleware who hoist an agent into the JVM > behind their backs? I think that would be rather a patronising view to > take of the vast majority of producers and consumers of libraries and/or > middleware. My belief is that anyone who attempted to provide a library > or framework (open source or not) that disabled (some or all) modules by > stealth would very soon be found out. I also believe they would > immediately lose all (or, at least, most) of their prospective business > from serious, paying customers. After all, that sort of behaviour > *would* be a major security issue. I wish I could share your optimism in this regard, but it's contrary to my experience. That a library does questionable things does not always dissuade people from using it. An instance of the scenario I described above, where you can read "popular applications" as "every major Java EE application server", occurred late in the development of JDK 5. Some obscure library was reaching into JDK internals. The fact that it did so was well-documented and (presumably) clear to its immediate users but did not prevent it from becoming widely used. It was apparent at the time that the true nature of this library surprised some of those responsible for higher-level components that depended indirectly upon it. So, yes, call it patronising if you like but we are concerned about enabling a library to self-attach and inject an agent which it uses to subvert strong encapsulation without the developer (or the deployer) knowing about it. I fully agree that sophisticated late-binding agents can have legitimate needs to break strong encapsulation, and that they should be permitted to do so in the full sight of their users. What I don't yet see is a way to enable those by default while at the same time disabling sneaky encapsulation-busting libraries whose inevitable inadvertent use will lead to maintenance headaches down the line. > As I mentioned in my reply to Mark it is critical for users to know > exactly how any agent they load into their JVM is going to modify the > access restrictions in place in the JVM so that they can be sue that use > of the agent is safe (just as they need to know that any jars they place > into the classpath are not going to do things like round down their > costs and pocket the spare change in a bank account somwehere). Users > don't just add stuff to their classpath without knowing what it does and > why it is appropriate. Again, I wish this were true, but it's not. Developers all too often just add stuff to the class path until things work or, more commonly, ask build tools to do that for them via dependency management. They ship the result and then, over time, others come to depend upon it. If developers and deployers have to to opt-in to breaking encapsulation on the command line then that at least makes it clear to someone trying to diagnose a failing system that something fishy might be going on. >> The attach mechanism was of course never intended to be used this way. >> It was meant for troubleshooting tools and profilers/similar to load >> agents into running VMs. Back in the JDK 6 then we did consider >> disallowing attaching to the current VM but didn't enforce it - one >> reason is that it's not hard to just fork a VM with tools.jar on the >> class path and connect back to the parent. > > Well, I understand that this is not what you intended. However, i) it > turns out to have been very useful that it does work this way and ii) > stopping it doing so has a cost which needs to be taken into account -- > at the very least by giving those who have been relying on it for quite > some time to manage their business concerns to adjust to the change. No argument there. >> So that is the context for the discussion. We need to find a good way to >> put the Genie back in its bottle. It may be that we have to disable >> attaching to the current or ancestor VMs. We may have to prohibit the >> instrumentation of core modules by late binding agents. We may have to >> do some disabling of agent loading. Maybe a combination. Suggestions and >> proposals are of course welcome. > > I'm very happy to consider all sorts of half-way houses or even -- in > time -- the full change recommended in the original JIRA. For example, > rejecting instrumentation in some specific set of bootstrap/JDK module > classes (like, say, java.base) from an agent which has been dynamically > loaded might well be a workable compromise -- that at least allows users > to employ an agent to tweak any code that is in the classpath through > their choice. That's an interesting option, and worth exploring further. It could, though, be troublesome for legitimate late-binding agents that instrument JDK internals. Is Byteman typically used in that way? - Mark From mark.reinhold at oracle.com Mon Apr 3 22:59:50 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 15:59:50 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> Message-ID: <20170403155950.542443262@eggemoggin.niobe.net> 2017/4/3 10:52:02 -0700, alasdair.nottingham at gmail.com: > I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, > and this proposal will affect us. Our Java Agent is used to update the > bytecode of our classes to add in instrumentation for debug logging > and performance monitoring. In general it is attached via -javaagent, > which wont be affected by this proposal. However there is one case > where we do a dynamic attach of this agent. There is an industry trend > towards running the application server as an uber-jar using java -jar > . To support this in Liberty (in common with other > application servers) our main method extracts the app server to disk > at startup before bootstrapping the server from extracted jar > files. One of the jar files extracted in this way is our Java agent, > so we use the attach API to attach it so we get monitoring and debug > logging. I had been thinking of expanding this to use the attach api > in preference to -javaagent because that gets rid of this spurious > error message from the mac JVM: > > objc[56755]: Class JavaLaunchHelper is implemented in both > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java > (0x10f4464c0) and > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib > (0x110dbb4e0). One of the two will be used. Which one is undefined. Is getting rid of this spurious message (which, as Alan observed, has been removed) your only motivation to load the agent dynamically? > ... > > I?d like to add my support to Andrew?s points. I think they are well > made and cover my concerns with the proposals well. I?d like to add my > thoughts as well though. Thanks. I think my reply to Andrew of a few minutes ago covers most of your points too, so I won't repeat myself here. > ... > > Mark did ask for alternative proposals, so other than the defer to a > future release option, what about allowing a developer to put > something in the manifest.mf to enable dynamic attachment from the > same JVM? If there is a concern over all or nothing being too broad > the manifest entry could list a hash of the agent jar so the developer > has to know about the agent a-priori. I don't see how this would address the scenario of a dynamically-loaded agent (for, say, performance monitoring) that's unknown to the original library or application developer. This seems to be an important use case. - Mark From mark.reinhold at oracle.com Mon Apr 3 23:10:00 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 16:10:00 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <20170403161000.636247171@eggemoggin.niobe.net> 2017/4/3 14:50:52 -0700, mandy.chung at oracle.com: >> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>> ... >>> >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology and changed it to macOS. >> >> Agreed -- we should change OS_NAME from "Darwin" to "macos?. > > OK. Should the bundle names be updated to reflect this change? Probably not worth doing at this late stage in 9; let's fix these in 10. > In any case, it is a separate issue. Yep. > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 Looks good. Thanks, - Mark From mark.reinhold at oracle.com Mon Apr 3 23:19:32 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 16:19:32 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> Message-ID: <20170403161932.679685703@eggemoggin.niobe.net> 2017/4/2 23:28:02 -0700, chris at hazelcast.com: > First of all, I understand the idea behind this change and I think it > certainly makes sense but from my impression the default is wrong, as > Volker already pointed out. > > Over the last few days I (with the help of others) put together a > document ... Thanks -- that's useful data. > Looking at APM, as Martijn, mentioned, I don?t see a lot of impact, as > most APMs should be added right from the start of the JVM. On the > other hand, however, it seems that there is a lot of tools (probably > more on the ?devops? side of things), that are commonly added at > runtime in case of a problem or error. Those tools would be greatly > affected by the change and would require to commonly deactivate the > new restriction which renders it kind of useless. >From your document it looks like it's mainly profilers that might need to transform core JDK classes. Do you have any sense as to whether the other types of agents can still be effective if they cannot transform core classes, an option that Andrew suggested? > That said it looks like the main group being affected by this change > is not developers, as you seem to have mentioned in the initial mail, > but operations. Furthermore I?m not sure I agree with ?if you have to > tell customers to put additional flags on CL, one more is no problem? > (as it sounded below). Normally you have to explain / fight over every > single command line parameter that has to be set with the customers > operations team (except those parameters are GC configs ;-). That > means it?ll be really hard to explain why to deactivate something that > undercuts the system security / integrity, as it will be put. That's a fair point. > Most interestingly, as the document points out, there will be ways to > undermine the change by creating a remote thread (on Windows) or > ptrace on Linux. There are certainly ways on each of the operating > systems but it?ll make things even more insecure. I think this is a red herring. If you have the power to ptrace a Java process then you can likely already do anything, and there's not much we can do to stop you. - Mark From mandy.chung at oracle.com Mon Apr 3 23:49:41 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 16:49:41 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403161000.636247171@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <20170403161000.636247171@eggemoggin.niobe.net> Message-ID: > On Apr 3, 2017, at 4:10 PM, mark.reinhold at oracle.com wrote: > > 2017/4/3 14:50:52 -0700, mandy.chung at oracle.com: >>> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >>> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>>> ... >>>> >>>> I am not sure why we would change to osx for Mac when the Mac developers >>>> have recently dropped the Mac OS X terminology and changed it to macOS. >>> >>> Agreed -- we should change OS_NAME from "Darwin" to "macos?. >> >> OK. Should the bundle names be updated to reflect this change? > > Probably not worth doing at this late stage in 9; let's fix these in 10. That's what I was thinking too. I created a JBS issue target for 10: Mandy From Alan.Bateman at oracle.com Tue Apr 4 06:27:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 07:27:44 +0100 Subject: jake -> jdk9/dev In-Reply-To: References: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> Message-ID: <39b7f704-7563-f2c6-cae1-ee1b55a11b0e@oracle.com> On 03/04/2017 21:54, Stephen Felts wrote: > The jlr.Module -> jl.Module can cause some other problems. > > It breaks source code compatibility > That's right, it's a source incompatible change (one that arises whenever a new type is added to java.lang.). The impact section of the proposal [1] has more details. -Alan [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-March/000663.html From Alan.Bateman at oracle.com Tue Apr 4 06:40:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 07:40:31 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2C0EC.4000907@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> <58E2C0EC.4000907@cjnash.com> Message-ID: <54e37f0b-b5d1-8d74-04a1-58bffa97c867@oracle.com> On 03/04/2017 22:38, Simon Nash wrote: > : > > My comment was regarding the change of value for OS_NAME. Given that > there is > no compatibility issue here, does it make sense for the new value to > be something > that is no longer current in Apple terminology? Just on compatibility then just to say that the `release` file is a supported interface. So changing the value of OS_NAME ("Darwin" -> "macos" and "SunOS" -> "solaris") might mean that scripts or tools that read it will need to be updated. Mandy will get this change documented in the release notes and I wouldn't expect updating scripts to deal with additional or new values should be a major issue. -Alan. From Alan.Bateman at oracle.com Tue Apr 4 07:42:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 08:42:06 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: On 03/04/2017 19:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osName).orElse(null) would be cleaner. I'm sure Volker or someone maintaining the AIX port will ask for jdk.tools.jlink.internal.Platform to be extended to handle that platform. -Alan. From magnus.ihse.bursie at oracle.com Tue Apr 4 08:04:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 10:04:22 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> On 2017-04-03 23:50, Mandy Chung wrote: >> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >> >> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>>> >>>>> ... >>>>> >>>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>>> in the `release` file: >>>>> >>>>> JDK 8 JDK 9 >>>>> ----- ----- >>>>> OS_NAME Linux linux >>>>> SunOS solaris >>>>> Darwin osx >>>>> Windows windows >>>>> >>>>> OS_ARCH i386,x86 x86 >>>>> i586,amd64,x86_64 x64 >>>>> sparcv9 sparcv9 >>>>> arm arm32 >>>>> aarch64 arm64 >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology and changed it to macOS. >> Agreed -- we should change OS_NAME from "Darwin" to "macos?. > OK. Should the bundle names be updated to reflect this change? > In any case, it is a separate issue. > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 If we are making changes to the original proposal from JDK-8175819, then I just want to add my few cents: Why change from the well-established "aarch64" to the virtually unused "arm64"? As far as I know, using the name "arm64" for the aarch64 platform is something that has only been done in the (recently opened) closed Oracle port. This change, however, proposes to change the value in the release file even for the open aarch64 port, which has always been known by that name. /Magnus > > Mandy > From adinn at redhat.com Tue Apr 4 08:59:56 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 09:59:56 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <4c1201e8-31a2-2f84-2ef3-1ae838dff353@redhat.com> On 03/04/17 19:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > This revisits the OS name and arch in packaging JDK modules > to extend the module descriptor with ModuleTarget class file > attribute. We considered matching with the system properties. > Linux x64 JDK can run on a system whose `os.arch` system > property value can be `amd64` or `i586` or `x86_x64`. > Similiarly, windows x86/x64 JDK can run on a system whose > `os.name` system property starts with ?Windows? as the > os.name property is set to "Windows XXX" for example > "Windows Server 2012 R2?. It might be worth considering > multiple OS arch values in ModuleTarget in the future. > > JDK bundle names are revised in JDK 9. This is a good > alternative to be consistent with $OS-$ARCH value in > the bundle names. This patch proposes to package JDK modules > with OS name and arch to match the values as in JDK bundle names. > jlink will generate the `release` file and set OS_NAME and > OS_ARCH to those values. This also proposes to drop > OS_VERSION to align with the ModuleTarget class file attribute. > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 arm64 is *not* a correct name for the AArch64 architecture. There is in fact no arm64 architecture. The latter name has been used to identify the Oracle-developed port but that fact does not sanction its use for OS_ARCH. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Apr 4 09:36:38 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 10:36:38 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> Message-ID: <734b38ef-d971-b59a-f2b7-8a41c269fae6@redhat.com> On 03/04/17 21:56, John Rose wrote: > On Apr 3, 2017, at 12:03 PM, Gregg Wonderly > wrote: >> >> Alan, it is exactly this kind of comment from the team which just >> tears apart the whole view that you might actually be considering >> what everyone in the Java community needs. > > I think *this* comment is unfair to Alan. I read Alan as saying > "don't assume that users can rely on an SM present". If I'm right, > that is a far cry from tearing the community into parts. I think > you would admit that not everyone uses SM. So you didn't ding Alan > (who is doing really heroic work for the community) for simply > reminding us that a SM-based approach would not serve the whole > community equally. Did you impute some other motive to him? Thank you for posting this, John. I am hoping that Gregg simply misread Alan's post because it definitely didn't merit the response it received. More generally, it certainly doesn't help anyone when constructive comments made by OpenJDK developers garner inattentive criticisms that fail to allow for honest intentions and/or acknowledge different and, potentially, competing needs. It's especially unfair to apply such criticism to Alan who for months has been extraordinarily diligent in investigating, considering and responding to those many competing needs. The same praise is due to many others in Oracle's OpenJDK team -- consider, for example, the highly valuable, longstanding efforts of the EA program team to identify and fix problems before JDK9 gets released. Oracle have been working very hard to ensure JDK9 is a success and to suggest otherwise is as misguided as it is unhelpful. This project would be in a dire state without the contributions of Oracle staff and I for one appreciate their contribution enormously. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From brianf at infinity.nu Tue Apr 4 09:38:37 2017 From: brianf at infinity.nu (Brian Fox) Date: Tue, 4 Apr 2017 10:38:37 +0100 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: <20170403093500.721331054@eggemoggin.niobe.net> References: <20170403093500.721331054@eggemoggin.niobe.net> Message-ID: Mark I think some of the assertions on the prevalence of the pom.properties is wrong. We pulled our own top 20 list based on download popularity and you can see it lines up well with your cited article: count | group_name | artifact_name ---------+----------------------------+--------------------- 9620458 | junit | junit 7660971 | org.slf4j | slf4j-api 5608458 | log4j | log4j 5542626 | commons-codec | commons-codec 5389851 | com.google.guava | guava 5357355 | commons-io | commons-io 5177092 | commons-logging | commons-logging 4936300 | org.apache.httpcomponents | httpclient 4874902 | org.apache.httpcomponents | httpcore 4756847 | commons-cli | commons-cli 4577052 | org.apache.commons | commons-lang3 4508856 | commons-lang | commons-lang 4430776 | com.fasterxml.jackson.core | jackson-core 4280673 | com.fasterxml.jackson.core | jackson-databind 4270501 | com.google.code.findbugs | jsr305 4140850 | com.fasterxml.jackson.core | jackson-annotations 3860911 | org.slf4j | jcl-over-slf4j 3410877 | org.springframework | spring-core 3062759 | org.springframework | spring-beans 2989047 | classworlds | classworlds However, only junit and the 2 spring modules are missing a pom.properties. The assertion that less than half the popular components don't have it seems provably incorrect. All the popular stuff is in Maven Central and again, 94% is a huge number, saying it doesn't cover much is just inaccurate. On Mon, Apr 3, 2017 at 5:35 PM, wrote: > Thanks for the continued feedback on this difficult issue. > > FYI: > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-April/000666.html > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-April/000667.html > > - Mark > From erik.joelsson at oracle.com Tue Apr 4 09:57:15 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 11:57:15 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: Hello, I don't quite understand this. In the proposition below it says osx, and x64, but in platform.m4 you generate macos and amd64. Does this then get translated again and why are we introducing yet another name for the operating system on Apple computers? /Erik On 2017-04-03 20:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > This revisits the OS name and arch in packaging JDK modules > to extend the module descriptor with ModuleTarget class file > attribute. We considered matching with the system properties. > Linux x64 JDK can run on a system whose `os.arch` system > property value can be `amd64` or `i586` or `x86_x64`. > Similiarly, windows x86/x64 JDK can run on a system whose > `os.name` system property starts with ?Windows? as the > os.name property is set to "Windows XXX" for example > "Windows Server 2012 R2?. It might be worth considering > multiple OS arch values in ModuleTarget in the future. > > JDK bundle names are revised in JDK 9. This is a good > alternative to be consistent with $OS-$ARCH value in > the bundle names. This patch proposes to package JDK modules > with OS name and arch to match the values as in JDK bundle names. > jlink will generate the `release` file and set OS_NAME and > OS_ARCH to those values. This also proposes to drop > OS_VERSION to align with the ModuleTarget class file attribute. > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 > > Mandy > From erik.joelsson at oracle.com Tue Apr 4 10:13:42 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 12:13:42 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <0112fc8f-0e4f-1c16-782c-fde330735453@oracle.com> Oh, I missed the further discussion before I posted this and the webrev was apparently updated in place to reflect that discussion. Please ignore my comment below. /Erik On 2017-04-04 11:57, Erik Joelsson wrote: > Hello, > > I don't quite understand this. In the proposition below it says osx, > and x64, but in platform.m4 you generate macos and amd64. Does this > then get translated again and why are we introducing yet another name > for the operating system on Apple computers? > > /Erik > > > On 2017-04-03 20:41, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> >> This revisits the OS name and arch in packaging JDK modules >> to extend the module descriptor with ModuleTarget class file >> attribute. We considered matching with the system properties. >> Linux x64 JDK can run on a system whose `os.arch` system >> property value can be `amd64` or `i586` or `x86_x64`. >> Similiarly, windows x86/x64 JDK can run on a system whose >> `os.name` system property starts with ?Windows? as the >> os.name property is set to "Windows XXX" for example >> "Windows Server 2012 R2?. It might be worth considering >> multiple OS arch values in ModuleTarget in the future. >> >> JDK bundle names are revised in JDK 9. This is a good >> alternative to be consistent with $OS-$ARCH value in >> the bundle names. This patch proposes to package JDK modules >> with OS name and arch to match the values as in JDK bundle names. >> jlink will generate the `release` file and set OS_NAME and >> OS_ARCH to those values. This also proposes to drop >> OS_VERSION to align with the ModuleTarget class file attribute. >> >> This shows the old and new value of OS_NAME/OS_ARCH properties >> in the `release` file: >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin osx >> Windows windows >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 x64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 >> >> Mandy > From adinn at redhat.com Tue Apr 4 10:45:02 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 11:45:02 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403223631.349F5A1A68@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> Message-ID: <22850907-b1e8-0605-288b-baa534cb4381@redhat.com> Hi Mark, Thanks again for another thoughtful and well-reasoned response. On 03/04/17 23:36, mark.reinhold at oracle.com wrote: > 2017/4/3 9:44:43 -0700, Andrew Dinn : >> One thing I am not clear on as regards that 'really nice' is whether >> anything in the JVM wants -- or even hopes -- to rely on module >> encapsulation never being broken in order to provide 'semantic' >> guarantees. . . . > > That's exactly the kind of thing we want to enable, long-term, and one > reason why integrity is worth improving aside from any considerations > of security -- and why suggestions by others to "just use a security > manager" if you care about such things are beside the point. > . . . Well, I am all for that sort of opportunity and I accept that it very much changes the balance of costs at play here that such opportunities exist. > > In addition to future performance improvements, let's not forget about > maintainability. Improved integrity allows those of us who maintain the > JDK to change internal implementation details without having to worry > about breaking user code. It allows users of the JDK to be confident > that their code depends only on supported interfaces, so that they can > more easily upgrade from one release to the next. We've all too often, > over the last twenty years, had to back out internal changes because > some popular library depended upon those internals. I also appreciate this argument but I would doubt that this applies to most (perhaps all) agents that break encapsulation barriers. Certainly, most users of Byteman normally must know that they are only doing so temporarily and contingently. Breaking encapsulation is frequently used during unit and integration testing to prove that an implementation satisfies certain invariants expected from the design (whether by tracing or injecting assertions). Of course, such a proof is only available via injected behaviour since the only other option to allow such validation a test time requires not encapsulating state and/or behaviour. However, it is equally clear that the presumed applicability of such invariants cannot extend beyond the point where redesign and re-implementation necessarily bring it into question. A similar story applies for tests relying on injection of faults. Breaking encapsulation at (sand-boxed or live) deployment time is used to investigate application and JDK runtime state. However, that is also, by its nature, an ad hoc and temporary process. The important thing is to understand what is happening in the code now deployed. Considerations as to what might change in future versions of the platform are hardly relevant. > > Anyway ... at the highest level, improving platform integrity is not just > about improving security. It's also about improving performance, in the > long term, and about improving the maintainability of everybody's code, > even in the short term. Ok, point taken. > >> Are you perhaps concerned that users might have their hand forced by >> providers of library jars or middleware who hoist an agent into the JVM >> behind their backs? . . . > > I wish I could share your optimism in this regard, but it's contrary to > my experience. That a library does questionable things does not always > dissuade people from using it. An instance of the scenario I described > above, where you can read "popular applications" as "every major Java EE > application server", occurred late in the development of JDK 5. Some > obscure library was reaching into JDK internals. The fact that it did so > was well-documented and (presumably) clear to its immediate users but did > not prevent it from becoming widely used. It was apparent at the time > that the true nature of this library surprised some of those responsible > for higher-level components that depended indirectly upon it. I may indeed be over-optimistic or simply swayed by a rather deluded democratic spirit but thank you for elucidating the sort of case you are considering. > So, yes, call it patronising if you like but we are concerned about > enabling a library to self-attach and inject an agent which it uses to > subvert strong encapsulation without the developer (or the deployer) > knowing about it. I fully agree that sophisticated late-binding agents > can have legitimate needs to break strong encapsulation, and that they > should be permitted to do so in the full sight of their users. What I > don't yet see is a way to enable those by default while at the same > time disabling sneaky encapsulation-busting libraries whose inevitable > inadvertent use will lead to maintenance headaches down the line. I appreciate the dilemma and indeed understand why it forms part of your rationale for the current proposal. > >> I'm very happy to consider all sorts of half-way houses or even -- in >> time -- the full change recommended in the original JIRA. For example, >> rejecting instrumentation in some specific set of bootstrap/JDK module >> classes (like, say, java.base) from an agent which has been dynamically >> loaded might well be a workable compromise -- that at least allows users >> to employ an agent to tweak any code that is in the classpath through >> their choice. > > That's an interesting option, and worth exploring further. It could, > though, be troublesome for legitimate late-binding agents that instrument > JDK internals. Is Byteman typically used in that way? Well, if it helps to provide the guarantees that the JDK runtime or core runtime wants in order to enable performance improvements then I'd certainly be /interested/ in a restriction that merely put certain classes out of reach of dynamic agents (assuming it also comes with an option to remove that restriction). Of course,-- to answer your question -- that would still present a problem for Byteman; it is often used to inject into core (java.base) classes. There are quite a few unit/integration testing scenarios where the ability to tweak the operation of core JDK runtime code is really useful. For example, injecting a THROW rule into class File to simulate an IOException is probably the poster-child for Byteman fault injection. The same also applies when using Byteman for runtime diagnosis. A very good example of that was when one of our customers kept finding that the first connection obtained from a connection pool would always fail with a connection error. Trace code injected into Thread.isInterrupted revealed the reason for the failure -- the application thread's interrupt state was already set before the open attempt. A stack backtrace call injected into Thread.setInterrupted showed that a 3rd party library was invalidly setting (and then not clearing) the interrupted state as part of application thread initialization. So, in summary: I'm interested in the option for a default setting to provide limited access to runtime and/or application classes from dynamically loaded agents -- it's an improvement on no access at all. However, on Byteman's account, I'd still really prefer the ability to support full access in the JDK9 time frame with a move to whatever more limited access is determined appropriate in JDK10 (for the reasons already mentioned). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Apr 4 10:51:43 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 11:51:43 +0100 Subject: jake -> jdk9/dev In-Reply-To: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> References: <33c38083-8731-333a-ff3d-cdf60551dcce@oracle.com> Message-ID: <2ba171b9-8e92-dbb8-bb35-2c087113858a@redhat.com> On 03/04/17 20:01, Alan Bateman wrote: > We have a number of changes accumulated in the jake forest that we need > to bring to jdk9/dev soon. > > The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a > bit disruptive for those using the JDK 9 EA builds and the new APIs. . . . Yes, please! I have been postponing a new Byteman release waiting for this :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From hannes.kegel at ej-technologies.com Tue Apr 4 11:14:19 2017 From: hannes.kegel at ej-technologies.com (Hannes Kegel) Date: Tue, 4 Apr 2017 13:14:19 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403161932.679685703@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <20170403161932.679685703@eggemoggin.niobe.net> Message-ID: Hi Mark, hi Alan, hi all, I am one of the developers of JProfiler and would like to share our thoughts and suggestions regarding this change. My understanding is that the goal is to prevent libraries from using agents to break access checks while not disrupting all other agent use cases as far as possible. I understand that the integrity of the module system is an important goal - on the other hand, our customers really rely on being able to dynamically attach to any JVM for troubleshooting, though. 1) Did you consider differentiating between native and java agents? First, I don't think using native libraries for all platforms would be a popular stackoverflow solution. Second, if a native library is in play it would be easier to just use JNI or call JVM functions directly to get what you want. So I think it would not harm the main goal to handle native agents like in Java 6 to 8. That would keep the class of full stack profilers available to Java users for troubleshooting. 2) Apart from that, restricting what a java agent can do in attach mode looks like a good compromise to us. We need to retransform java.base classes, though, and there are very interesting use cases for java agents, too. Think for example of a troubleshooting tool that monitors thread usage. It would most probably have to instrument java.lang. In the light of this argument, could you consider to narrow down the number of classes that cannot be retransformed, please? As methods cannot be added and access modifiers cannot be changed, I think protecting the classes that perform access checks like AccessibleObject and the respective method handle classes could be enough. I think an annotation to keep track of these classes would be great. Of course there are other ways to leak or modify internal data if retransforming classes is allowed, but they would be very hacky and I don't think library authors would be able to rely on them. If method adding or access modification is enabled in a future Java release, these type of modifications could be prevented for java.base. 3) If some retransformations would be allowed in java.base, you will still of course want to prevent that open or export edges are added. Read edges would be needed, though. redefineModule could throw an UnsupportedOperationException if open or export edges are added (similar to retransformClasses or the UNSUPPORTED_REDEFINITION error codes for retransforming classes with the native API). 4) A command line switch that removes the new restrictions on dynamic agents would be still needed, though. Thanks for your consideration, Hannes Kegel ej-technologies GmbH 2017-04-04 1:19 GMT+02:00 : > 2017/4/2 23:28:02 -0700, chris at hazelcast.com: >> First of all, I understand the idea behind this change and I think it >> certainly makes sense but from my impression the default is wrong, as >> Volker already pointed out. >> >> Over the last few days I (with the help of others) put together a >> document ... > > Thanks -- that's useful data. > >> Looking at APM, as Martijn, mentioned, I don?t see a lot of impact, as >> most APMs should be added right from the start of the JVM. On the >> other hand, however, it seems that there is a lot of tools (probably >> more on the ?devops? side of things), that are commonly added at >> runtime in case of a problem or error. Those tools would be greatly >> affected by the change and would require to commonly deactivate the >> new restriction which renders it kind of useless. > > From your document it looks like it's mainly profilers that might need > to transform core JDK classes. Do you have any sense as to whether the > other types of agents can still be effective if they cannot transform > core classes, an option that Andrew suggested? > >> That said it looks like the main group being affected by this change >> is not developers, as you seem to have mentioned in the initial mail, >> but operations. Furthermore I?m not sure I agree with ?if you have to >> tell customers to put additional flags on CL, one more is no problem? >> (as it sounded below). Normally you have to explain / fight over every >> single command line parameter that has to be set with the customers >> operations team (except those parameters are GC configs ;-). That >> means it?ll be really hard to explain why to deactivate something that >> undercuts the system security / integrity, as it will be put. > > That's a fair point. > >> Most interestingly, as the document points out, there will be ways to >> undermine the change by creating a remote thread (on Windows) or >> ptrace on Linux. There are certainly ways on each of the operating >> systems but it?ll make things even more insecure. > > I think this is a red herring. If you have the power to ptrace a Java > process then you can likely already do anything, and there's not much we > can do to stop you. > > - Mark From alasdair.nottingham at gmail.com Tue Apr 4 13:02:28 2017 From: alasdair.nottingham at gmail.com (Alasdair Nottingham) Date: Tue, 4 Apr 2017 09:02:28 -0400 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403155950.542443262@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> <20170403155950.542443262@eggemoggin.niobe.net> Message-ID: > On Apr 3, 2017, at 6:59 PM, mark.reinhold at oracle.com wrote: > > 2017/4/3 10:52:02 -0700, alasdair.nottingham at gmail.com: >> I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, >> and this proposal will affect us. Our Java Agent is used to update the >> bytecode of our classes to add in instrumentation for debug logging >> and performance monitoring. In general it is attached via -javaagent, >> which wont be affected by this proposal. However there is one case >> where we do a dynamic attach of this agent. There is an industry trend >> towards running the application server as an uber-jar using java -jar >> . To support this in Liberty (in common with other >> application servers) our main method extracts the app server to disk >> at startup before bootstrapping the server from extracted jar >> files. One of the jar files extracted in this way is our Java agent, >> so we use the attach API to attach it so we get monitoring and debug >> logging. I had been thinking of expanding this to use the attach api >> in preference to -javaagent because that gets rid of this spurious >> error message from the mac JVM: >> >> objc[56755]: Class JavaLaunchHelper is implemented in both >> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java >> (0x10f4464c0) and >> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib >> (0x110dbb4e0). One of the two will be used. Which one is undefined. > > Is getting rid of this spurious message (which, as Alan observed, has > been removed) your only motivation to load the agent dynamically? No, as I described the motivation for our first use of attach to add a Java agent was to address our uber-jar deployment. I wanted to use a single JVM, but I wanted the Java agent to be in the uber-jar and I did not want to have to require the end user to specify -javaagent as well as -jar. The user experience I wanted to enable was java -jar uber.jar, but still have the agent. While I was making this change I noticed that when I dynamically attached the agent I didn?t get the error message I included. As I didn?t know that the JDK bug had been finally fixed I was thinking of doing a dynamic attach simply to remove the error message. I?m assuming that if I thought this way it is likely someone else did also. > >> ... >> >> I?d like to add my support to Andrew?s points. I think they are well >> made and cover my concerns with the proposals well. I?d like to add my >> thoughts as well though. > > Thanks. I think my reply to Andrew of a few minutes ago covers most of > your points too, so I won't repeat myself here. > >> ... >> >> Mark did ask for alternative proposals, so other than the defer to a >> future release option, what about allowing a developer to put >> something in the manifest.mf to enable dynamic attachment from the >> same JVM? If there is a concern over all or nothing being too broad >> the manifest entry could list a hash of the agent jar so the developer >> has to know about the agent a-priori. > > I don't see how this would address the scenario of a dynamically-loaded > agent (for, say, performance monitoring) that's unknown to the original > library or application developer. This seems to be an important use > case. It doesn?t, and I didn?t intend to suggest it would. Essentially I was assuming that a remote attach and enable of a Java Agent would work, thus allowing performance monitoring to work, but it would close the aperture for a self-attach, that is agents that a developer has specifically blessed at the point the jar was built. This would ensure that if an app developer used a library that did something nefarious with an agent that the agent wouldn?t work without an app developer specifically acknowledging it. One of the problems Java has today is that it is very easy to end up depending on internals because the JVM has no modularity. It is one thing to end up using a Java API that is visible, but not intended to be used by an application, and another to explicitly break the modularity constraints in order to call API?s that are not intended to be accessible. If someone does write an agent, to break out of the modularity constraints, I do not think anyone can validly complain if a change breaks what they are doing. The creation of the agent is essentially an acceptance they have done something that could be broken at any time. Essentially I?m leaning back on I don?t think this is a likely vector for someone attempting to subvert the modularity system for the long term. Perhaps I?m just being too optimistic, but in my work on non-modular app servers, and modular app servers it is clear that if you put in place protection designed to stop accidental use (but not determined malicious use), then it causes people to think twice about breaking out of the constraints. > > - Mark From jan.lahoda at oracle.com Tue Apr 4 13:10:43 2017 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 04 Apr 2017 13:10:43 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201704041310.v34DAikK010444@aojmv0008.oracle.com> Changeset: b9942e7d5689 Author: jlahoda Date: 2017-04-04 15:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b9942e7d5689 Resolving one automatic module should resolve all automatic modules. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/AutomaticModules.java Changeset: 111beb5eb756 Author: jlahoda Date: 2017-04-04 15:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/111beb5eb756 8177857: javac ALL-SYSTEM should include incubating modules ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/tools/javac/modules/IncubatingTest.java From alan.bateman at oracle.com Tue Apr 4 14:14:30 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 04 Apr 2017 14:14:30 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704041414.v34EEVeY000713@aojmv0008.oracle.com> Changeset: 50b26c0e7cd8 Author: alanb Date: 2017-04-04 13:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50b26c0e7cd8 Patching doesn't need to drop hasher ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java Changeset: e047e62da9f8 Author: alanb Date: 2017-04-04 13:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e047e62da9f8 Fix typo in javadoc ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java From greggwon at cox.net Tue Apr 4 14:14:49 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Tue, 4 Apr 2017 09:14:49 -0500 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <4D2q1v03a1VUyRY01D2sya> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> <20170403155950.542443262@eggemoggin.niobe.net> <4D2q1v03a1VUyRY01D2sya> Message-ID: > On Apr 4, 2017, at 8:02 AM, Alasdair Nottingham wrote: > One of the problems Java has today is that it is very easy to end up depending on internals > because the JVM has no modularity. It is one thing to end up using a Java API that is > visible, but not intended to be used by an application, and another to explicitly break > the modularity constraints in order to call API?s that are not intended to be accessible. If > someone does write an agent, to break out of the modularity constraints, I do not think anyone > can validly complain if a change breaks what they are doing. The creation of the agent is > essentially an acceptance they have done something that could be broken at any time. > Essentially I?m leaning back on I don?t think this is a likely vector for someone attempting > to subvert the modularity system for the long term. Perhaps I?m just being too optimistic, but > in my work on non-modular app servers, and modular app servers it is clear that if you put in > place protection designed to stop accidental use (but not determined malicious use), then it > causes people to think twice about breaking out of the constraints. The business of ?allowing? access and ?knowing? the secret sauce being spread around by various dependent libraries is exactly why I keep bringing up the use of the SecurityManager. In environments where it is active, I would want to have to provide a permission for each and every agent or other access to details breaking modularity. That way, I?d be able to know that I care about what that library is doing. If those Permissions were classified on a web page somewhere as ?breaking? modularity, then the whole developer world would suddenly be able to be informed about what they were committing to. What would be possible, is to use a security manager to ?test? or ?check? what modularity breaking code was doing so that you could either grant the permissions, or reject the library and move to another path of solution. Using command line arguments feels like a ?Permission? grant. But making it more explicit in the code with separate Permissions, lets developers manage the dependency of one execution path while not granting access to others for example. Gregg From greggwon at cox.net Tue Apr 4 14:58:46 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Tue, 4 Apr 2017 09:58:46 -0500 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <49d41v01M4x5MXx019d6wk> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> Message-ID: <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> > On Apr 4, 2017, at 4:36 AM, Andrew Dinn wrote: > > On 03/04/17 21:56, John Rose wrote: >> On Apr 3, 2017, at 12:03 PM, Gregg Wonderly >> wrote: >>> >>> Alan, it is exactly this kind of comment from the team which just >>> tears apart the whole view that you might actually be considering >>> what everyone in the Java community needs. >> >> I think *this* comment is unfair to Alan. I read Alan as saying >> "don't assume that users can rely on an SM present". If I'm right, >> that is a far cry from tearing the community into parts. I think >> you would admit that not everyone uses SM. So you didn't ding Alan >> (who is doing really heroic work for the community) for simply >> reminding us that a SM-based approach would not serve the whole >> community equally. Did you impute some other motive to him? > > Thank you for posting this, John. I am hoping that Gregg simply misread > Alan's post because it definitely didn't merit the response it received. Alan said: > The issue here is nothing to do with the security manager, assume no security manager in the picture. But, I always have a security manager in the picture. It?s how I always grant access to various pieces of the JDK features to my application. It?s how I limit/grant access to the details that I care about my users being exposed to by using my software. So, saying that a SecurityManager doesn?t matter, when this is clearly a JVM security issue, just doesn?t fly for me. As I?ve already said, a command line argument can feel like a permission, but it is like AllPermission. It doesn?t help me manage what I am opening my users to. If I have to use the AllPermission for my users to deploy, and they are on a network, I?ve now opened them up to network penetration by other agents! That?s absolutely not acceptable to me. There should be a Permission mechanism at a high granularity of control, and grants to Jar files (which have been mentioned in another recent thread dealing with which modules can have agents inserted/active) make it possible to directly control all exposure from all paths of penetration. Gregg From mark.reinhold at oracle.com Tue Apr 4 15:12:15 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 08:12:15 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> Message-ID: <20170404081215.364493885@eggemoggin.niobe.net> 2017/4/4 1:04:22 -0700, magnus.ihse.bursie at oracle.com: > On 2017-04-03 23:50, Mandy Chung wrote: >> ... >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 > > If we are making changes to the original proposal from JDK-8175819, then > I just want to add my few cents: > > Why change from the well-established "aarch64" to the virtually unused > "arm64"? As far as I know, using the name "arm64" for the aarch64 > platform is something that has only been done in the (recently opened) > closed Oracle port. This change, however, proposes to change the value > in the release file even for the open aarch64 port, which has always > been known by that name. The trouble here is that "arm64" and "aarch64" are effectively synonyms for the ISA, but in the JDK we've wound up using them as the names of two different ports. A JMOD file built for the 64-bit ARM architecture will (one hopes) run equally well on either port. Which name should we use in JMOD files, "arm64" or "aarch64"? My sense is that "arm64" is more immediately understood by developers at large even if "aarch64" is more correct in the eyes of ARM Holdings plc, but I could be wrong. For what it's worth, the Linux distros aren't consistent: Debian-based distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". - Mark From javalists at cbfiddle.com Tue Apr 4 15:18:36 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 4 Apr 2017 08:18:36 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403223631.349F5A1A68@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> Message-ID: > On Apr 3, 2017, at 3:36 PM, mark.reinhold at oracle.com wrote: > >> The sort of thing I am thinking about is, say, a module-wide >> global analysis in the JIT guaranteeing that a call argument will only >> ever be non-NULL, a positive int, or some such invariant that can fed >> into an optimization phase. I can understand how a switch to disable >> dynamic agent loading might be needed to underline that sort of guarantee. > > That's exactly the kind of thing we want to enable, long-term, and one > reason why integrity is worth improving aside from any considerations > of security -- and why suggestions by others to "just use a security > manager" if you care about such things are beside the point. There has always been a conflict between optimization and the ability to make changes to the program at runtime. I don?t see this as an ?integrity? issue or related to modules. If a program (including a JDK) has been built with a certain level of optimization, then certain runtime changes either cannot be performed or will not have the intended effect. If, as an example that has been previously suggested, some agent needs to create a subclass of a final class, then the vendor of that agent needs to instruct their customers on how to ensure that their JDK/application can support this behavior. From david.lloyd at redhat.com Tue Apr 4 15:20:54 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 4 Apr 2017 10:20:54 -0500 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404081215.364493885@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: On 04/04/2017 10:12 AM, mark.reinhold at oracle.com wrote: > 2017/4/4 1:04:22 -0700, magnus.ihse.bursie at oracle.com: >> On 2017-04-03 23:50, Mandy Chung wrote: >>> ... >>> >>> JDK 8 JDK 9 >>> ----- ----- >>> OS_NAME Linux linux >>> SunOS solaris >>> Darwin macos >>> Windows windows >>> >>> OS_ARCH i386,x86 x86 >>> i586,amd64,x86_64 amd64 >>> sparcv9 sparcv9 >>> arm arm32 >>> aarch64 arm64 >> >> If we are making changes to the original proposal from JDK-8175819, then >> I just want to add my few cents: >> >> Why change from the well-established "aarch64" to the virtually unused >> "arm64"? As far as I know, using the name "arm64" for the aarch64 >> platform is something that has only been done in the (recently opened) >> closed Oracle port. This change, however, proposes to change the value >> in the release file even for the open aarch64 port, which has always >> been known by that name. > > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > equally well on either port. Which name should we use in JMOD files, > "arm64" or "aarch64"? My sense is that "arm64" is more immediately > understood by developers at large even if "aarch64" is more correct > in the eyes of ARM Holdings plc, but I could be wrong. > > For what it's worth, the Linux distros aren't consistent: Debian-based > distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". If you use "arm64" instead of "aarch64" then shouldn't you use "sparc64" instead of "sparcv9"? Same logic AFAICT. -- - DML From aph at redhat.com Tue Apr 4 15:22:50 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Apr 2017 16:22:50 +0100 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404081215.364493885@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: On 04/04/17 16:12, mark.reinhold at oracle.com wrote: > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > equally well on either port. Which name should we use in JMOD files, > "arm64" or "aarch64"? My sense is that "arm64" is more immediately > understood by developers at large even if "aarch64" is more correct > in the eyes of ARM Holdings plc, but I could be wrong. I think that you are wrong. > For what it's worth, the Linux distros aren't consistent: Debian-based > distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". The name of the processor architecture is "AArch64". The name of the Linux kernel architecture is "arm64"; the name of all of userspace is "aarch64", on all distros. The kernel is out of step here, for no better reason than Linus Torvalds didn't like "aarch64". Andrew. From adinn at redhat.com Tue Apr 4 15:45:07 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 16:45:07 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> Message-ID: <8430b24b-7f7b-71e5-f445-e66ee474a88e@redhat.com> On 04/04/17 15:58, Gregg Wonderly wrote: > Alan said: > >> The issue here is nothing to do with the security manager, assume >> no security manager in the picture. > > But, I always have a security manager in the picture. It?s how I > always grant access to various pieces of the JDK features to my > application. It?s how I limit/grant access to the details that I > care about my users being exposed to by using my software. So, > saying that a SecurityManager doesn?t matter, when this is clearly a > JVM security issue, just doesn?t fly for me. As I?ve already said, > a command line argument can feel like a permission, but it is like > AllPermission. It doesn?t help me manage what I am opening my users > to. If I have to use the AllPermission for my users to deploy, and > they are on a network, I?ve now opened them up to network penetration > by other agents! That?s absolutely not acceptable to me. That may be so but, as Alan said, there are many other Java users who have never had a security manager in the picture. You seem to be assuming that we can rely on users to correct that omission as an element of how we address this problem. I'd suggest that is just as questionable -- indeed, probably more so -- as assuming that we can rely on users to remember to reset the current proposed default to enable dynamic agents. Please try to assume that Alan might be arguing for a more nuanced position than the one you assumed when his argument appears to be making no sense to you. He is neither stupid nor ignorant of what a security manager can and cannot do. If anything he says leads you to question whether he is 'considering what everyone in the Java community needs' then it is probably merits you seriously reviewing and definitely confirming such an opinion before posting it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From blackdrag at gmx.org Tue Apr 4 15:51:31 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 4 Apr 2017 17:51:31 +0200 Subject: what is undesired usage of the Java API? Message-ID: <5b6cdce2-d173-8292-56d1-facee311a16e@gmx.org> Hi, I think the recent discussion about the agent loading mechanism do show one fundamental problem that many have with the changes through the restricted module system. That is, it is unclear what undesired usage of the Java APIs actually is. So let me write down an unfinished list as discussion base (jigsaw): (1) usage of internal modules, classes, methods or fields (2) transforming any of (1) (3) non-public elements are not to be accessed if normal Java does not allow for it compared with my personal old list (javaSE): * any sun.* classes well.. my extended list actually was (library): * any sun.* classes * requiring agents * requiring command line arguments * requiring special configurations And in my case, since I violate (1) in the jigsaw list, I get into trouble with my old library list. Which means I am in the confusing situation of having to do things now, that I considered bad before, because of jigsaw. Anyway... I am sure the jigsaw list above is something to be refined and I would love to see people helping me with that. bye Jochen From bob.vandette at oracle.com Tue Apr 4 16:03:41 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 4 Apr 2017 12:03:41 -0400 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404081215.364493885@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: > On Apr 4, 2017, at 11:12 AM, mark.reinhold at oracle.com wrote: > > 2017/4/4 1:04:22 -0700, magnus.ihse.bursie at oracle.com: >> On 2017-04-03 23:50, Mandy Chung wrote: >>> ... >>> >>> JDK 8 JDK 9 >>> ----- ----- >>> OS_NAME Linux linux >>> SunOS solaris >>> Darwin macos >>> Windows windows >>> >>> OS_ARCH i386,x86 x86 >>> i586,amd64,x86_64 amd64 >>> sparcv9 sparcv9 >>> arm arm32 >>> aarch64 arm64 >> >> If we are making changes to the original proposal from JDK-8175819, then >> I just want to add my few cents: >> >> Why change from the well-established "aarch64" to the virtually unused >> "arm64"? As far as I know, using the name "arm64" for the aarch64 >> platform is something that has only been done in the (recently opened) >> closed Oracle port. This change, however, proposes to change the value >> in the release file even for the open aarch64 port, which has always >> been known by that name. > > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. Well sort of ? We are only using arm64 as a configure option to enable building the unified ARM32/64 port and a label in Jira to identify which port a bug or RFE is related to. Both 64-bit ARM ports have been using aarch64 for the os.name property since day one and I think we should stick to this name in the release file to avoid any confusion. Bob. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > equally well on either port. Which name should we use in JMOD files, > "arm64" or "aarch64"? My sense is that "arm64" is more immediately > understood by developers at large even if "aarch64" is more correct > in the eyes of ARM Holdings plc, but I could be wrong. > > For what it's worth, the Linux distros aren't consistent: Debian-based > distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". > > - Mark From javalists at cbfiddle.com Tue Apr 4 16:27:46 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 4 Apr 2017 09:27:46 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403223631.349F5A1A68@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> Message-ID: > On Apr 3, 2017, at 3:36 PM, mark.reinhold at oracle.com wrote: > > In addition to future performance improvements, let's not forget about > maintainability. Improved integrity allows those of us who maintain the > JDK to change internal implementation details without having to worry > about breaking user code. It allows users of the JDK to be confident > that their code depends only on supported interfaces, so that they can > more easily upgrade from one release to the next. We've all too often, > over the last twenty years, had to back out internal changes because > some popular library depended upon those internals. > > A common response to this concern is to say, "then don't use libraries > that depend upon JDK internals!" Would that it were that simple. The > hardest cases arise when some library A that depends on JDK internals is > published, then it's used by library B, which in turn is used by library > C, and that in turn is used by the immensely-popular library D, whose > authors don't even know that library A depends on JDK internals. (They > might not even know that D ultimately depends on A!). Then we fix a bug > in the JDK that changes those internals, library D breaks, a large number > of popular applications (or applications with important customers) stop > working, and the cries and support escalations demanding that the change > be reverted ensue. Sounds to me like there are two different issues here. One issue is the ability to create a library that breaks when ?internal implementation details? of the JDK are changed. The other is the awareness of when one is depending upon such a library. It should be clear that it is impossible to prevent libraries from depending upon internal implementation details and impossible to always be aware of when a library is so dependent. You will always have to worry about breaking user code, but maybe you can worry less. A realistic goal would be to reduce the likelihood of a developer accidentally depending upon internal implementation details. Another would be to make it more likely that when a developer chooses to depend upon implementation details (sometimes necessary if the goal is to have code that works on already deployed platforms) that the dependence uses a mechanism that is detectable by static examination of the library. These goals may be related. Perhaps a developer would be less likely to create an avoidable dependence knowing that users would be aware of it. These goals can be accomplished by erecting barriers but also providing well defined and statically visible bypasses, of which there are several long standing examples. Perhaps more control of these bypasses is needed. Perhaps some kind of module permission scheme would help. If I release a version of a library that bypasses a barrier (for reasons that are hopefully temporary), I should be willing to statically declare my need to do so (just as ?apps? declare their need to access the network, etc.). If I release a runtime tool that needs to bypass a barrier, perhaps my users should be willing to use a security manager that allows my tool to do what it needs. (I understand the desire for a solution that does not require a security manager, but I?m less clear on why one should not allow a security manager to participate in the solution.) In this regard, I find ?integrity? as a concept or goal to be misleading or even meaningless. By erecting more barriers are you actually ?improving integrity?? I don?t think so. The ability to write implementation-dependent code remains and always will remain. A barrier can have a benefit: reducing accidental or hidden implementation dependencies. But a barrier can also have a cost, which, ironically, is to cause existing code to break in the new JDK! So, worry is conserved, at least temporarily. From Alan.Bateman at oracle.com Tue Apr 4 16:28:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 17:28:32 +0100 Subject: 8177530: Module system implementation refresh (4/2017) Message-ID: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. There are a number of smaller changes, summarized in JDK-8177530 [2]. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8177530/1 The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames [2] https://bugs.openjdk.java.net/browse/JDK-8177530 From mark.reinhold at oracle.com Tue Apr 4 16:35:57 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 09:35:57 -0700 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: <20170404093557.376393610@eggemoggin.niobe.net> 2017/4/4 8:22:50 -0700, aph at redhat.com: > On 04/04/17 16:12, mark.reinhold at oracle.com wrote: >> The trouble here is that "arm64" and "aarch64" are effectively synonyms >> for the ISA, but in the JDK we've wound up using them as the names of >> two different ports. >> >> A JMOD file built for the 64-bit ARM architecture will (one hopes) run >> equally well on either port. Which name should we use in JMOD files, >> "arm64" or "aarch64"? My sense is that "arm64" is more immediately >> understood by developers at large even if "aarch64" is more correct >> in the eyes of ARM Holdings plc, but I could be wrong. > > I think that you are wrong. > >> For what it's worth, the Linux distros aren't consistent: Debian-based >> distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". > > The name of the processor architecture is "AArch64". The name of the > Linux kernel architecture is "arm64"; the name of all of userspace is > "aarch64", on all distros. The kernel is out of step here, for no > better reason than Linus Torvalds didn't like "aarch64". Thanks for the background -- I wasn't aware of that. Given that "os.arch" is "aarch64" for both ports, as Bob points out, then we should use "aarch64" in JMOD files as well. This does raise another question, though: Should we use "aarch32" instead of "arm32" for the 32-bit ARM architecture? - Mark From aph at redhat.com Tue Apr 4 16:39:17 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Apr 2017 17:39:17 +0100 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404093557.376393610@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> <20170404093557.376393610@eggemoggin.niobe.net> Message-ID: <921dba93-4497-55b4-3ac4-dd3c6c559deb@redhat.com> On 04/04/17 17:35, mark.reinhold at oracle.com wrote: > This does raise another question, though: Should we use "aarch32" > instead of "arm32" for the 32-bit ARM architecture? Probably not. I believe that "aarch32" is historical revisionism coming from ARM: it didn't exist as a name before AArch64 came out. AFAICR... Andrew. From bob.vandette at oracle.com Tue Apr 4 16:47:50 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 4 Apr 2017 12:47:50 -0400 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404093557.376393610@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> <20170404093557.376393610@eggemoggin.niobe.net> Message-ID: <963C74B3-377C-40C4-8D0A-73CF506D035C@oracle.com> > On Apr 4, 2017, at 12:35 PM, mark.reinhold at oracle.com wrote: > > 2017/4/4 8:22:50 -0700, aph at redhat.com: >> On 04/04/17 16:12, mark.reinhold at oracle.com wrote: >>> The trouble here is that "arm64" and "aarch64" are effectively synonyms >>> for the ISA, but in the JDK we've wound up using them as the names of >>> two different ports. >>> >>> A JMOD file built for the 64-bit ARM architecture will (one hopes) run >>> equally well on either port. Which name should we use in JMOD files, >>> "arm64" or "aarch64"? My sense is that "arm64" is more immediately >>> understood by developers at large even if "aarch64" is more correct >>> in the eyes of ARM Holdings plc, but I could be wrong. >> >> I think that you are wrong. >> >>> For what it's worth, the Linux distros aren't consistent: Debian-based >>> distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". >> >> The name of the processor architecture is "AArch64". The name of the >> Linux kernel architecture is "arm64"; the name of all of userspace is >> "aarch64", on all distros. The kernel is out of step here, for no >> better reason than Linus Torvalds didn't like "aarch64". > > Thanks for the background -- I wasn't aware of that. > > Given that "os.arch" is "aarch64" for both ports, as Bob points out, > then we should use "aarch64" in JMOD files as well. > > This does raise another question, though: Should we use "aarch32" > instead of "arm32" for the 32-bit ARM architecture? 32 bit ARM is a bit more challenging since OS vendors sometime encode the architecture version (armv5, armv6, armv7) and endianess into the uname -p output. aarch32 has special meaning (it?s the arch for running 32-bit arm instructions on an armv8 processor.) and I haven?t seen any use of arm32. I suggest we stick with arm. Bob. > > - Mark From adinn at redhat.com Tue Apr 4 17:23:00 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 18:23:00 +0100 Subject: what is undesired usage of the Java API? In-Reply-To: <5b6cdce2-d173-8292-56d1-facee311a16e@gmx.org> References: <5b6cdce2-d173-8292-56d1-facee311a16e@gmx.org> Message-ID: <16b33421-dec9-76ff-e815-480ac0035b08@redhat.com> On 04/04/17 16:51, Jochen Theodorou wrote: > I think the recent discussion about the agent loading mechanism do show > one fundamental problem that many have with the changes through the > restricted module system. That is, it is unclear what undesired usage of > the Java APIs actually is. > > So let me write down an unfinished list as discussion base (jigsaw): > (1) usage of internal modules, classes, methods or fields > (2) transforming any of (1) > (3) non-public elements are not to be accessed if normal Java does not > allow for it I am afraid it's not so simple. When using Byteman to diagnose a problem in an app, usages (2) and (3) are very often needed to be sure what is going wrong. This can happen at the point where the app calls into a library or even the JDK and does something like pass bad data in. It is sometimes only possible to prove that this has happened if you can trace internal execution or inject assertions that the library/JDK code does not itself include (invariably for performance reasons). It can also happen because there is actually something wrong in the library/JDK code. Yes, we live in an imperfect world. Indeed, the same thing can also happen during integration or unit testing and Byteman is useful at these stages for much the same reason. Obviously when you have ironed out many problems in code there is no need for any guarantee that certain invariants apply to internal states. However, that Nirvana is rarely if ever reached (never mind the problem of maintaining such bliss). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From lois.foltan at oracle.com Tue Apr 4 19:03:37 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 4 Apr 2017 15:03:37 -0400 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: <628bc23b-4a23-385b-ab4c-1cdf24886194@oracle.com> Hi Alan, Hotspot changes look good. One minor comment, can you move the definition of java/lang/Module at line #93 in hotspot/src/share/vm/classfile/vmSymbols.hpp up to a new line after #58 which is java/lang/Package? I wouldn't need to see another webrev for this. Thank you, Lois On 4/4/2017 12:28 PM, Alan Bateman wrote: > As I mentioned on jigsaw-dev yesterday, we have accumulated a number > of changes in the jake forest and would like to bring the changes into > jdk9/dev for jdk-9+165. > > Most of the changes in this update are the move of Module and friends > from java.lang.reflect to java.lang. This is mostly a mechanical update. > > We also have the update to the derivation of automatic modules to no > longer ignore trailing digits in modules names, this is to align JDK 9 > with the updated proposal for issue #VersionsInModuleNames [1]. > > There are a number of smaller changes, summarized in JDK-8177530 [2]. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > > The changes are currently based on jdk-9+163 and will be rebased > before pushing to jdk9/dev. > > The corresponding update to jtreg is already in the code-tools/jtreg > repo and will be tagged (I assume as jtreg4.2-b07) before this > integration. Once it is tagged then we'll rev'ing the requiredVersion > in each TEST.ROOT. > > -Alan > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames > [2] https://bugs.openjdk.java.net/browse/JDK-8177530 > > > From mandy.chung at oracle.com Tue Apr 4 20:28:38 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Apr 2017 13:28:38 -0700 Subject: Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ This is a simple fix. ResourceBundle::getBundle should handle LinkageError that may be thrown by Class.forName when finding a class. Mandy From lance.andersen at oracle.com Tue Apr 4 20:31:42 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 4 Apr 2017 16:31:42 -0400 Subject: Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class In-Reply-To: References: Message-ID: +1 > On Apr 4, 2017, at 4:28 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ > > This is a simple fix. ResourceBundle::getBundle should handle LinkageError that may be thrown by Class.forName when finding a class. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Tue Apr 4 21:13:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Apr 2017 14:13:42 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <2DD2517B-4D06-4C29-8EE6-734225507A2D@oracle.com> > On Apr 4, 2017, at 12:42 AM, Alan Bateman wrote: > > On 03/04/2017 19:41, Mandy Chung wrote: > >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> > I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. > It?s already aligned. I updated webrev.00 in place yesterday. Maybe you need to reload it if you happened opening the old version. > In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osName).orElse(null) would be cleaner. > OK. > I'm sure Volker or someone maintaining the AIX port will ask for jdk.tools.jlink.internal.Platform to be extended to handle that platform. I was wondering if Volker would ask that. Anyway, I have added Platform::AIX constant. Will send out a new webrev. Mandy From naoto.sato at oracle.com Tue Apr 4 21:27:50 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 4 Apr 2017 14:27:50 -0700 Subject: Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class In-Reply-To: References: Message-ID: <6e180fbc-8569-b554-e275-c4baf89e4974@oracle.com> Looks good to me. Naoto On 4/4/17 1:28 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ > > This is a simple fix. ResourceBundle::getBundle should handle LinkageError that may be thrown by Class.forName when finding a class. > > Mandy > From mark.reinhold at oracle.com Tue Apr 4 22:33:50 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 15:33:50 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <22850907-b1e8-0605-288b-baa534cb4381@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> <22850907-b1e8-0605-288b-baa534cb4381@redhat.com> Message-ID: <20170404153350.741097261@eggemoggin.niobe.net> 2017/4/4 3:45:02 -0700, Andrew Dinn : > Thanks again for another thoughtful and well-reasoned response. Thank you for the continued dialogue. > On 03/04/17 23:36, mark.reinhold at oracle.com wrote: >> 2017/4/3 9:44:43 -0700, Andrew Dinn : >>> ... >>> >>> I'm very happy to consider all sorts of half-way houses or even -- in >>> time -- the full change recommended in the original JIRA. For example, >>> rejecting instrumentation in some specific set of bootstrap/JDK module >>> classes (like, say, java.base) from an agent which has been dynamically >>> loaded might well be a workable compromise -- that at least allows users >>> to employ an agent to tweak any code that is in the classpath through >>> their choice. >> >> That's an interesting option, and worth exploring further. It could, >> though, be troublesome for legitimate late-binding agents that instrument >> JDK internals. Is Byteman typically used in that way? > > Well, if it helps to provide the guarantees that the JDK runtime or core > runtime wants in order to enable performance improvements then I'd > certainly be /interested/ in a restriction that merely put certain > classes out of reach of dynamic agents (assuming it also comes with an > option to remove that restriction). > > Of course,-- to answer your question -- that would still present a > problem for Byteman; it is often used to inject into core (java.base) > classes. > > There are quite a few unit/integration testing scenarios where the > ability to tweak the operation of core JDK runtime code is really > useful. For example, injecting a THROW rule into class File to simulate > an IOException is probably the poster-child for Byteman fault injection. > > The same also applies when using Byteman for runtime diagnosis. A very > good example of that was when one of our customers kept finding that the > first connection obtained from a connection pool would always fail with > a connection error. Trace code injected into Thread.isInterrupted > revealed the reason for the failure -- the application thread's > interrupt state was already set before the open attempt. A stack > backtrace call injected into Thread.setInterrupted showed that a 3rd > party library was invalidly setting (and then not clearing) the > interrupted state as part of application thread initialization. Very interesting use cases! > So, in summary: > > I'm interested in the option for a default setting to provide limited > access to runtime and/or application classes from dynamically loaded > agents -- it's an improvement on no access at all. Got it. > However, on Byteman's account, I'd still really prefer the ability to > support full access in the JDK9 time frame with a move to whatever more > limited access is determined appropriate in JDK10 (for the reasons > already mentioned). Okay, I think I'm starting to see how to revise the proposal. I'll try to write something up and post it tomorrow. - Mark From mark.reinhold at oracle.com Tue Apr 4 22:49:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 15:49:29 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> <20170403155950.542443262@eggemoggin.niobe.net> Message-ID: <20170404154929.569570142@eggemoggin.niobe.net> 2017/4/4 6:02:28 -0700, alasdair.nottingham at gmail.com: >> On Apr 3, 2017, at 6:59 PM, mark.reinhold at oracle.com wrote: >> 2017/4/3 10:52:02 -0700, alasdair.nottingham at gmail.com: >>> ... However there is one case >>> where we do a dynamic attach of this agent. There is an industry trend >>> towards running the application server as an uber-jar using java -jar >>> . To support this in Liberty (in common with other >>> application servers) our main method extracts the app server to disk >>> at startup before bootstrapping the server from extracted jar >>> files. One of the jar files extracted in this way is our Java agent, >>> so we use the attach API to attach it so we get monitoring and debug >>> logging. I had been thinking of expanding this to use the attach api >>> in preference to -javaagent because that gets rid of this spurious >>> error message from the mac JVM: >>> >>> objc[56755]: Class JavaLaunchHelper is implemented in both >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java >>> (0x10f4464c0) and >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib >>> (0x110dbb4e0). One of the two will be used. Which one is undefined. >> >> Is getting rid of this spurious message (which, as Alan observed, has >> been removed) your only motivation to load the agent dynamically? > > No, as I described the motivation for our first use of attach to add a Java agent was to > address our uber-jar deployment. I wanted to use a single JVM, but I wanted the Java > agent to be in the uber-jar and I did not want to have to require the end user to specify > -javaagent as well as -jar. The user experience I wanted to enable was java -jar uber.jar, > but still have the agent. While I was making this change I noticed that when I dynamically > attached the agent I didn?t get the error message I included. As I didn?t know that the JDK > bug had been finally fixed I was thinking of doing a dynamic attach simply to remove the > error message. I?m assuming that if I thought this way it is likely someone else did also. Okay, thanks for the clarification. It wasn't obvious (to me, at least) from your first message. I think there may be an easy way to support this idiom; let me give it a bit more thought. >>> ... >>> >>> Mark did ask for alternative proposals, so other than the defer to a >>> future release option, what about allowing a developer to put >>> something in the manifest.mf to enable dynamic attachment from the >>> same JVM? If there is a concern over all or nothing being too broad >>> the manifest entry could list a hash of the agent jar so the developer >>> has to know about the agent a-priori. >> >> I don't see how this would address the scenario of a dynamically-loaded >> agent (for, say, performance monitoring) that's unknown to the original >> library or application developer. This seems to be an important use >> case. > > It doesn?t, and I didn?t intend to suggest it would. Essentially I was assuming that > a remote attach and enable of a Java Agent would work, thus allowing performance > monitoring to work, but it would close the aperture for a self-attach, that is agents > that a developer has specifically blessed at the point the jar was built. This would > ensure that if an app developer used a library that did something nefarious with an agent > that the agent wouldn?t work without an app developer specifically acknowledging it. Okay, got it. > One of the problems Java has today is that it is very easy to end up depending on internals > because the JVM has no modularity. It is one thing to end up using a Java API that is > visible, but not intended to be used by an application, and another to explicitly break > the modularity constraints in order to call API?s that are not intended to be accessible. If > someone does write an agent, to break out of the modularity constraints, I do not think anyone > can validly complain if a change breaks what they are doing. The creation of the agent is > essentially an acceptance they have done something that could be broken at any time. > Essentially I?m leaning back on I don?t think this is a likely vector for someone attempting > to subvert the modularity system for the long term. Perhaps I?m just being too optimistic, but > in my work on non-modular app servers, and modular app servers it is clear that if you put in > place protection designed to stop accidental use (but not determined malicious use), then it > causes people to think twice about breaking out of the constraints. As I wrote in my reply to Andrew, my own experience makes me less optimistic than either of you two seem to be. Either way, the performance work that we'd like to pursue in the long term needs more than optimism and honorable behavior -- it needs hard and fast guarantees. - Mark From mark.reinhold at oracle.com Tue Apr 4 22:53:50 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 15:53:50 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <734b38ef-d971-b59a-f2b7-8a41c269fae6@redhat.com> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <734b38ef-d971-b59a-f2b7-8a41c269fae6@redhat.com> Message-ID: <20170404155350.527616881@eggemoggin.niobe.net> 2017/4/4 2:36:38 -0700, Andrew Dinn : > ... > > More generally, it certainly doesn't help anyone when constructive > comments made by OpenJDK developers garner inattentive criticisms that > fail to allow for honest intentions and/or acknowledge different and, > potentially, competing needs. It's especially unfair to apply such > criticism to Alan who for months has been extraordinarily diligent in > investigating, considering and responding to those many competing needs. Indeed! This project would be nowhere without Alan. > The same praise is due to many others in Oracle's OpenJDK team -- > consider, for example, the highly valuable, longstanding efforts of the > EA program team to identify and fix problems before JDK9 gets released. > Oracle have been working very hard to ensure JDK9 is a success and to > suggest otherwise is as misguided as it is unhelpful. This project would > be in a dire state without the contributions of Oracle staff and I for > one appreciate their contribution enormously. Thank you for the kinds words, Andrew. They are very much appreciated. - Mark From mark.reinhold at oracle.com Tue Apr 4 23:17:16 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 16:17:16 -0700 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: References: <20170403093500.721331054@eggemoggin.niobe.net> Message-ID: <20170404161716.672368397@eggemoggin.niobe.net> 2017/4/4 2:38:37 -0700, Brian Fox : > Mark I think some of the assertions on the prevalence of the pom.properties > is wrong. We pulled our own top 20 list based on download popularity and > you can see it lines up well with your cited article: > > count | group_name | artifact_name > ---------+----------------------------+--------------------- > 9620458 | junit | junit > 7660971 | org.slf4j | slf4j-api > 5608458 | log4j | log4j > 5542626 | commons-codec | commons-codec > 5389851 | com.google.guava | guava > 5357355 | commons-io | commons-io > 5177092 | commons-logging | commons-logging > 4936300 | org.apache.httpcomponents | httpclient > 4874902 | org.apache.httpcomponents | httpcore > 4756847 | commons-cli | commons-cli > 4577052 | org.apache.commons | commons-lang3 > 4508856 | commons-lang | commons-lang > 4430776 | com.fasterxml.jackson.core | jackson-core > 4280673 | com.fasterxml.jackson.core | jackson-databind > 4270501 | com.google.code.findbugs | jsr305 > 4140850 | com.fasterxml.jackson.core | jackson-annotations > 3860911 | org.slf4j | jcl-over-slf4j > 3410877 | org.springframework | spring-core > 3062759 | org.springframework | spring-beans > 2989047 | classworlds | classworlds > > However, only junit and the 2 spring modules are missing a pom.properties. > The assertion that less than half the popular components don't have it > seems provably incorrect. It's correct for the 140 projects that I examined, which is all that I claimed. Check them for yourself. The number of projects that constitutes a reasonable sample of the "popular" projects (by whatever ranking) is a bit of a judgement call, but twenty seems very small to me. Every project in my list of 140 is well known, so I think it's a more representative sample. What do you see if you examine the top 140 projects according to whatever ranking you use for Central? > All the popular stuff is in Maven Central and > again, 94% is a huge number, saying it doesn't cover much is just > inaccurate. Nearly everything in Central is not popular. That 94% of all projects have a given property does not imply that 94% of the popular projects have that property. - Mark From mandy.chung at oracle.com Wed Apr 5 05:10:38 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 05 Apr 2017 05:10:38 +0000 Subject: hg: jigsaw/jake/hotspot: Update jtreg required version to 4.2 b07 Message-ID: <201704050510.v355Adh5011830@aojmv0008.oracle.com> Changeset: b0076c96fadc Author: mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0076c96fadc Update jtreg required version to 4.2 b07 ! test/TEST.ROOT From mandy.chung at oracle.com Wed Apr 5 05:10:47 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 05 Apr 2017 05:10:47 +0000 Subject: hg: jigsaw/jake/jaxp: Update jtreg required version to 4.2 b07 Message-ID: <201704050510.v355Al6q011896@aojmv0008.oracle.com> Changeset: d44354fed774 Author: mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d44354fed774 Update jtreg required version to 4.2 b07 ! test/TEST.ROOT From mandy.chung at oracle.com Wed Apr 5 05:10:55 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 05 Apr 2017 05:10:55 +0000 Subject: hg: jigsaw/jake/jdk: Update jtreg required version to 4.2 b07 Message-ID: <201704050510.v355At1b012002@aojmv0008.oracle.com> Changeset: 3f059be20ccb Author: mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f059be20ccb Update jtreg required version to 4.2 b07 ! test/TEST.ROOT From mandy.chung at oracle.com Wed Apr 5 05:11:02 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 05 Apr 2017 05:11:02 +0000 Subject: hg: jigsaw/jake/langtools: Update jtreg required version to 4.2 b07 Message-ID: <201704050511.v355B2UT012092@aojmv0008.oracle.com> Changeset: a564c0126103 Author: mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a564c0126103 Update jtreg required version to 4.2 b07 ! test/TEST.ROOT From mandy.chung at oracle.com Wed Apr 5 05:11:06 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 05 Apr 2017 05:11:06 +0000 Subject: hg: jigsaw/jake/nashorn: Update jtreg required version to 4.2 b07 Message-ID: <201704050511.v355B6LD012149@aojmv0008.oracle.com> Changeset: f1d6cca3853b Author: mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f1d6cca3853b Update jtreg required version to 4.2 b07 ! test/TEST.ROOT From john.r.rose at oracle.com Wed Apr 5 05:19:35 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Apr 2017 22:19:35 -0700 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <20170403223631.349F5A1A68@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> Message-ID: On Apr 3, 2017, at 3:36 PM, mark.reinhold at oracle.com wrote: > > If developers and deployers have to to opt-in to breaking encapsulation > on the command line then that at least makes it clear to someone trying > to diagnose a failing system that something fishy might be going on. It seems to me that some of the legitimate use cases use injected code to perform similar diagnoses. Having been many times on the wrong side of a failing system, I am sympathetic with any diagnostic tool, no matter how invasive. And, yes, I give extra credit to tools that can be applied online with no prearrangement. This seems to lead back to allowing ad hoc code injection out of the box. Would it help if, although there was not an opt-in on the command line, there was some restriction about the nature of the injected code? I'm thinking what we did with JVMCI: Opened up a deep hole into the JVM, and then protected it by sealing it into a module. Can we get the module system to help us out here also? Maybe, out of the box, your code must be inside some particular module in order to do monkey-patching. Is there a way to do post facto loading, during an emergency, into the privileged module, of diagnostic code? (Probably not; modules are static.) Anyway, I imagine there are ways for instrumentation code to be loaded that are far more controlled and explicit than the current state of affairs, and still won't require prearrangement. Possibly all such ways will end up being too abusable. But surely it is better to have a library that says "Hey, I'm using/defining the monkey patching module", than a random JAR that sneaks in and fires up a self-attach. A couple of other thoughts: 1. The "execute from JAR" use case seems to want a hook for command line options. It's very ugly, but maybe that would relieve pressure on users who cannot access command lines. (But I'd much rather see problems solved by injecting a module info file into a JAR, rather than some new command-line knobs.) 2. I think it is inevitable that we will be using the static structure of modules, in future releases, to guide global optimizations. Some of the hot-patching techniques people rely on today will come into conflict with those optimizations. The JVM is amazing at dealing with dynamically changing configurations, but we also need to keep the option for static optimizations open, in the long term. Sometimes the cost of switching from optimized code to debug-mode must be so great that it won't be a viable option, especially for online problem solving. HTH ? John From chris at hazelcast.com Wed Apr 5 05:59:30 2017 From: chris at hazelcast.com (Christoph Engelbert) Date: Wed, 5 Apr 2017 07:59:30 +0200 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <20170403223631.349F5A1A68@eggemoggin.niobe.net> Message-ID: <866BC767-C6B4-450C-BDF8-F03808AF0125@hazelcast.com> Comments inlined Chris > On 5. Apr 2017, at 07:19, John Rose wrote: > > On Apr 3, 2017, at 3:36 PM, mark.reinhold at oracle.com wrote: >> >> If developers and deployers have to to opt-in to breaking encapsulation >> on the command line then that at least makes it clear to someone trying >> to diagnose a failing system that something fishy might be going on. > > It seems to me that some of the legitimate use cases use injected > code to perform similar diagnoses. Having been many times on the > wrong side of a failing system, I am sympathetic with any diagnostic > tool, no matter how invasive. And, yes, I give extra credit to tools > that can be applied online with no prearrangement. Not the only tools, as we have this ?uber-jar? use case but I think that might have a better solution than the more general one we?re looking for to support those diagnostic tools :) > > This seems to lead back to allowing ad hoc code injection out > of the box. Would it help if, although there was not an opt-in > on the command line, there was some restriction about the > nature of the injected code? I'm thinking what we did with > JVMCI: Opened up a deep hole into the JVM, and then > protected it by sealing it into a module. Can we get the > module system to help us out here also? Maybe, out of > the box, your code must be inside some particular module > in order to do monkey-patching. Is there a way to do post > facto loading, during an emergency, into the privileged > module, of diagnostic code? (Probably not; modules are > static.) I already proposed, more as a side note, something like the Ubuntu / Debian alike repository private-public key signatures. If I want to have ?privileged? modules (for example agents being attached at runtime) I have to trust the signature key. Anyhow I?m not looking for a certification process from Oracle side but a user can trust / mistrust key-pairs on their own by something like ?jtrust add https://repository.company.com/key.asc ? which would be easy to explain to customers, adds a general ?trust process? to all modules (for example to be reused in SecurityManager) and maybe other use cases. Still just a fix idea but maybe something to look into in the long term. > > Anyway, I imagine there are ways for instrumentation code > to be loaded that are far more controlled and explicit than the > current state of affairs, and still won't require prearrangement. > > Possibly all such ways will end up being too abusable. > But surely it is better to have a library that says "Hey, > I'm using/defining the monkey patching module", than > a random JAR that sneaks in and fires up a self-attach. It could be solved with layers (or different class loaders) and only modules on the same layer as the main JAR are ok to directly attach (in this specific use case)? > > A couple of other thoughts: > > 1. The "execute from JAR" use case seems to want a hook > for command line options. It's very ugly, but maybe that would > relieve pressure on users who cannot access command lines. > (But I'd much rather see problems solved by injecting a module > info file into a JAR, rather than some new command-line knobs.) > > 2. I think it is inevitable that we will be using the static structure > of modules, in future releases, to guide global optimizations. > Some of the hot-patching techniques people rely on today > will come into conflict with those optimizations. The JVM is > amazing at dealing with dynamically changing configurations, > but we also need to keep the option for static optimizations open, > in the long term. Sometimes the cost of switching from optimized > code to debug-mode must be so great that it won't be a viable > option, especially for online problem solving. > > HTH > ? John > > From serguei.spitsyn at oracle.com Wed Apr 5 06:42:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Apr 2017 23:42:56 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: The hotspot part looks good to me. Some copyright comments need update: http://cr.openjdk.java.net/~alanb/8177530/1/hotspot/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java.frames.html http://cr.openjdk.java.net/~alanb/8177530/1/hotspot/src/share/vm/oops/klass.cpp.frames.html http://cr.openjdk.java.net/~alanb/8177530/1/hotspot/src/share/vm/prims/jvmtiEnv.cpp.frames.html One question: http://cr.openjdk.java.net/~alanb/8177530/1/hotspot/src/share/vm/prims/jvmtiEnv.cpp.udiff.html +// module - pre-checked for NULL +// is_modifiable_class_ptr - pre-checked for NULL +jvmtiError +JvmtiEnv::IsModifiableModule(jobject module, jboolean* is_modifiable_module_ptr) { + JavaThread* THREAD = JavaThread::current(); + + // check module + Handle h_module(THREAD, JNIHandles::resolve(module)); + if (!java_lang_Module::is_instance(h_module())) { + return JVMTI_ERROR_INVALID_MODULE; + } + + *is_modifiable_module_ptr = JNI_TRUE; + return JVMTI_ERROR_NONE; +} /* end IsModifiableModule */ + It seems, all the modules are modifiable at this point. Is it right? Thanks, Serguei On 4/4/17 09:28, Alan Bateman wrote: > As I mentioned on jigsaw-dev yesterday, we have accumulated a number > of changes in the jake forest and would like to bring the changes into > jdk9/dev for jdk-9+165. > > Most of the changes in this update are the move of Module and friends > from java.lang.reflect to java.lang. This is mostly a mechanical update. > > We also have the update to the derivation of automatic modules to no > longer ignore trailing digits in modules names, this is to align JDK 9 > with the updated proposal for issue #VersionsInModuleNames [1]. > > There are a number of smaller changes, summarized in JDK-8177530 [2]. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > > The changes are currently based on jdk-9+163 and will be rebased > before pushing to jdk9/dev. > > The corresponding update to jtreg is already in the code-tools/jtreg > repo and will be tagged (I assume as jtreg4.2-b07) before this > integration. Once it is tagged then we'll rev'ing the requiredVersion > in each TEST.ROOT. > > -Alan > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames > [2] https://bugs.openjdk.java.net/browse/JDK-8177530 > > > From Alan.Bateman at oracle.com Wed Apr 5 06:52:51 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Apr 2017 07:52:51 +0100 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: On 05/04/2017 07:42, serguei.spitsyn at oracle.com wrote: > The hotspot part looks good to me. > > + It seems, all the modules are modifiable at this point. Is it right? That's right. On the copyright dates then Lana will be doing a bulk update soon. I expect it will update hundreds of files. I don't mind manually updating files that we've missed here of course. -Alan From serguei.spitsyn at oracle.com Wed Apr 5 06:54:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Apr 2017 23:54:45 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: <3c9de575-8a01-6477-d736-1efdb00fc717@oracle.com> Ok. Thanks, Alan Serguei On 4/4/17 23:52, Alan Bateman wrote: > On 05/04/2017 07:42, serguei.spitsyn at oracle.com wrote: > >> The hotspot part looks good to me. >> >> + It seems, all the modules are modifiable at this point. Is it right? > That's right. > > On the copyright dates then Lana will be doing a bulk update soon. I > expect it will update hundreds of files. I don't mind manually > updating files that we've missed here of course. > > -Alan From Alan.Bateman at oracle.com Wed Apr 5 07:01:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Apr 2017 08:01:46 +0100 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <628bc23b-4a23-385b-ab4c-1cdf24886194@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> <628bc23b-4a23-385b-ab4c-1cdf24886194@oracle.com> Message-ID: <6c23c313-5890-9966-5f19-989624e3b835@oracle.com> On 04/04/2017 20:03, Lois Foltan wrote: > Hi Alan, > > Hotspot changes look good. One minor comment, can you move the > definition of java/lang/Module at line #93 in > hotspot/src/share/vm/classfile/vmSymbols.hpp up to a new line after > #58 which is java/lang/Package? I wouldn't need to see another webrev > for this. > Thanks, I'll get that sorted out. -Alan From greggwon at cox.net Wed Apr 5 15:26:44 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Wed, 5 Apr 2017 10:26:44 -0500 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <4FlA1v0230dAWJx01FlB7S> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <4FlA1v0230dAWJx01FlB7S> Message-ID: > On Apr 4, 2017, at 10:45 AM, Andrew Dinn wrote: > > On 04/04/17 15:58, Gregg Wonderly wrote: >> Alan said: >> >>> The issue here is nothing to do with the security manager, assume >>> no security manager in the picture. >> >> But, I always have a security manager in the picture. It?s how I >> always grant access to various pieces of the JDK features to my >> application. It?s how I limit/grant access to the details that I >> care about my users being exposed to by using my software. So, >> saying that a SecurityManager doesn?t matter, when this is clearly a >> JVM security issue, just doesn?t fly for me. As I?ve already said, >> a command line argument can feel like a permission, but it is like >> AllPermission. It doesn?t help me manage what I am opening my users >> to. If I have to use the AllPermission for my users to deploy, and >> they are on a network, I?ve now opened them up to network penetration >> by other agents! That?s absolutely not acceptable to me. > > That may be so but, as Alan said, there are many other Java users who > have never had a security manager in the picture. You seem to be > assuming that we can rely on users to correct that omission as an > element of how we address this problem. I'd suggest that is just as > questionable -- indeed, probably more so -- as assuming that we can > rely on users to remember to reset the current proposed default to > enable dynamic agents. Let me put together my whole argument again. 1) People can edit jar files and completely obliterate any security settings expressed in those files. 2) People can add JNI modules and have complete access to all details of the JVM environment. 3) People can recompile the openJDK JVM to turn off anything that they want about this development. 4) People are going to have to use command line switches to control this behavior in environments where their current applications are broken by Jigsaw changes. So, in the end, integrity, modularity and ultimately the goals of this project can only be maintained by active participation from the community of developers which we hope will all be capable, and able to participate because their use of the JVM (for other JVM languages besides Java) can deal with these changes. This whole effort relies on developers to make it possible for users of java to succeed at using JDK-9. If developers don?t do that, or can?t do that because of limitations of JigSaw, this will be like windows-7 users. There will be a lot of old cruft setting around giving Java a bad name because it won?t be current and the new version of Java broke it. I am not trying to be a arse about this. I am being forthright and direct with my comments and recommendations because I believe that?s the best way to not beat around the bush. > Please try to assume that Alan might be arguing for a more nuanced > position than the one you assumed when his argument appears to be making > no sense to you. He is neither stupid nor ignorant of what a security > manager can and cannot do. If anything he says leads you to question > dconfirming such an opinion before posting it. I am not one to assume anything. That?s a big fault of failing discussions. Everything needs to be on the table here. What?s important to me, is important to me. What?s important to another group of developers, is important to them. What is not helping me be comfortable with this, is the simple fact that nothing done here, guarantees anything without developers participating ?nicely?. At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and should instead be immutable. But, because ?assume no security manager in the picture? is the state of ?the world?, the details have not been fixed, officially. In the Jini community, Peter Firmstone (most of the recent work), and I, have spent quite a bit of time on understand and fixing these issues. He has tried to push the knowledge of what needs to be done into various places, which I don?t recall at the moment. In the end because JDK-9 breaks everything (well not quite, but nearly, since spring and other similar libraries are broken), requiring command line arguments, why not just finally fix Java by instituting a default SecurityManager, instead of the command line flags, which enforces all of these things. Why not just require the added command line argument to be the permissions file to use? It seems just insane, to me, for all of this infrastructure to exist, which does exactly what all of these command line arguments are going to essentially do (turn the permission to do something on/off) and then to just summarily go around it and completely ignore it. I don?t know how else to say anything here more constructively without continuously pointing at the fact that I think this just completely BOTCHES the JVM with nonsense changes trying to recreate SecurityManager features, which already exist. That?s where my ?Do you know what the SecurityManager does?? argument comes from. I just cannot look past this work and say, oh, yeah, lets put in some other form of ?key? to the kingdom so that developers and users of Java have yet another way to do exactly the same ?mechanisms? that we already have. It make absolutely no sense to me. And I am being harsh and direct to invite comments and explanations and arguments about the pros of what is being done, not to try and shut people up because they think I just want to whine and fuss about this. Gregg > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From alan.bateman at oracle.com Wed Apr 5 15:37:05 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 05 Apr 2017 15:37:05 +0000 Subject: hg: jigsaw/jake: Switch back to jtreg promoted build Message-ID: <201704051537.v35Fb5Dr005136@aojmv0008.oracle.com> Changeset: 133ccdf271c4 Author: alanb Date: 2017-04-05 16:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/133ccdf271c4 Switch back to jtreg promoted build ! common/conf/jib-profiles.js From mark.reinhold at oracle.com Wed Apr 5 16:15:20 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 5 Apr 2017 09:15:20 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default (revised) References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> Message-ID: <20170405161520.81729A2BC4@eggemoggin.niobe.net> Thanks to everyone for the quick feedback on this topic, and especially to Andrew for the constructive dialogue. Here's a revised proposal: - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's on by default in JDK 9 but off by default in JDK 10. This will allow launch scripts that use this option on JDK 10 to work on JDK 9 without change, and will allow early testing of the JDK 10 behavior on JDK 9. - Revise the `com.sun.tools.attach` API to forbid attachment to the current process or to an ancestor of the current process, and define a read-only system property that allows such attachment to be enabled via the command line. This will discourage the inadvertent use of libraries that, for better or for worse, intentionally violate strong encapsulation. - Enhance the `-jar` launcher option so that if the JAR file being launched contains a `Premain-Class` attribute then it's launched as both an application and as an agent for that application. This will allow `java -jar foo.jar` to be used in place of the more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. Taken together, these changes are intended to enable the continued use of legitimate dynamically-loaded agents without change on JDK 9 and with a small change on JDK 10. That later change will align the treatment of such agents with the other means of breaking encapsulation (`--add-opens`, etc.) in order to ensure integrity by default for all code. This proposal does not attempt to lock down platform classes as distinct from user classes. Many agents have legitimate reasons to transform platform classes, so an additional mechanism to protect those classes does not appear to be worthwhile. Comments? - Mark [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012000.html From sean.coffey at oracle.com Wed Apr 5 16:25:24 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 5 Apr 2017 17:25:24 +0100 Subject: Disallowing the dynamic loading of agents by default In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170330153845.72C9B96BD9@eggemoggin.niobe.net> <9443936e-a923-cb3b-feaa-35b745c74031@redhat.com> <4ee7fedf-8422-4bde-995b-74fa985e953d@default> <2BEF4AB9-1AF4-4A5B-8B30-CE4B58278587@hazelcast.com> <7b52be1b-0bb0-f940-714c-1b8e87c1cc85@oracle.com> <6ab10c3c-60de-a44b-d09a-cb72f6d2e79a@redhat.com> <8a273e19-2ace-f0f7-038c-363fceae5758@oracle.com> <4c768d5a-13f7-2011-339c-8ff843a7a424@redhat.com> <3A3E7D33-50DD-49A8-AE3E-CDE572BC7A1B@gmail.com> <73a374c3-9515-5d09-cdd2-5f56a46f739c@oracle.com> Message-ID: <6126b749-8ed5-9679-156d-8b4d2f2d07fc@oracle.com> Oracle has early access builds of jdk8u released at : https://jdk8.java.net/download.html JDK-8022291 is fixed in this ea release. Regards, Sean. On 03/04/17 20:11, Alasdair Nottingham wrote: > Yes that is really good. I was really happy to see that. I can?t wait for a Java 8 release that contains the fix (u121 on the mac does not). The reason I brought it up is because that long standing weird error message is resolved using the attach api to add the agent. I?m sure I?m not the only person to have realized this. > > Alasdair > >> On Apr 3, 2017, at 2:41 PM, Alan Bateman wrote: >> >> On 03/04/2017 18:52, Alasdair Nottingham wrote: >> >>> Hi, >>> >>> I?m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this proposal will affect us. Our Java Agent is used to update the bytecode of our classes to add in instrumentation for debug logging and performance monitoring. In general it is attached via -javaagent, which wont be affected by this proposal. However there is one case where we do a dynamic attach of this agent. There is an industry trend towards running the application server as an uber-jar using java -jar . To support this in Liberty (in common with other application servers) our main method extracts the app server to disk at startup before bootstrapping the server from extracted jar files. One of the jar files extracted in this way is our Java agent, so we use the attach API to attach it so we get monitoring and debug logging. I had been thinking of expanding this to use the attach api in preference to -javaagent because that gets rid of this spurious error message from the mac JVM: >>> >>> objc[56755]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x10f4464c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x110dbb4e0). One of the two will be used. Which one is undefined. >> Thanks for the mail on your usage. On the spurious message then this was this was JDK-8022291 and has been fixed since jdk-9+127. The change has also been back-ported to jdk8u-dev. >> >> -Alan From david.lloyd at redhat.com Wed Apr 5 16:55:08 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 5 Apr 2017 11:55:08 -0500 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: On 04/05/2017 11:15 AM, mark.reinhold at oracle.com wrote: > Thanks to everyone for the quick feedback on this topic, and especially > to Andrew for the constructive dialogue. > > Here's a revised proposal: > > - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's > on by default in JDK 9 but off by default in JDK 10. > > This will allow launch scripts that use this option on JDK 10 to > work on JDK 9 without change, and will allow early testing of the > JDK 10 behavior on JDK 9. > > - Revise the `com.sun.tools.attach` API to forbid attachment to the > current process or to an ancestor of the current process, and > define a read-only system property that allows such attachment to > be enabled via the command line. This is just plain weird from a security perspective, to say that unrelated processes have more privilege to control the current process than processes that are closely related. Anyway this is yet another case where arbitrary artificial hurdles are put in place for the purpose of human behavior modification. Such hurdles can always be bypassed, generally resulting in even uglier situations that the one you're trying to avoid. In this case I can just fire a child process and then attach to it from the parent. Or fire off two sibling processes and have one attach to the other. Nothing is being saved here. > This will discourage the inadvertent use of libraries that, for > better or for worse, intentionally violate strong encapsulation. > > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. > > Taken together, these changes are intended to enable the continued use > of legitimate dynamically-loaded agents without change on JDK 9 and with > a small change on JDK 10. That later change will align the treatment of > such agents with the other means of breaking encapsulation (`--add-opens`, > etc.) in order to ensure integrity by default for all code. > > This proposal does not attempt to lock down platform classes as distinct > from user classes. Many agents have legitimate reasons to transform > platform classes, so an additional mechanism to protect those classes > does not appear to be worthwhile. > > Comments? > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012000.html > -- - DML From michael.rasmussen at zeroturnaround.com Wed Apr 5 17:00:13 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Wed, 5 Apr 2017 20:00:13 +0300 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: On 5 April 2017 at 19:15, wrote: > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. I would propose the presence of an addition option in the manifest to enable/control this behavior. In the case of standalone agents, running them as -jar are sometimes used for a different purpose than running them as agents. For instance, in the case of JRebel, java -jar jrebel.jar is used for license activation/control, and should not activate the agent part. Kind regards Michael Rasmussen JRebel, Product Manager ZeroTurnaround From Alan.Bateman at oracle.com Wed Apr 5 17:53:41 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Apr 2017 18:53:41 +0100 Subject: SecurityManager environments In-Reply-To: References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <4FlA1v0230dAWJx01FlB7S> Message-ID: <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> On 05/04/2017 16:26, Gregg Wonderly wrote: > : > At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and should instead be immutable. But, because ?assume no security manager in the picture? is the state of ?the world?, the details have not been fixed, officially. In the Jini community, Peter Firmstone (most of the recent work), and I, have spent quite a bit of time on understand and fixing these issues. He has tried to push the knowledge of what needs to be done into various places, which I don?t recall at the moment. You are right that the performance overhead when running with a security manager can be a problem. Walking the stack to get the intersection of the permissions has historically been a big part of this. If there are proposals and patches to improve the performance then security-dev is the place to bring those for discussion, maybe hotspot-dev if it gets into the stack walking in the VM. > In the end because JDK-9 breaks everything (well not quite, but nearly, since spring and other similar libraries are broken), requiring command line arguments, why not just finally fix Java by instituting a default SecurityManager, instead of the command line flags, which enforces all of these things. Why not just require the added command line argument to be the permissions file to use? I assume the breakage you see is just a consequence of strong encapsulation. There is a lot of existing code that relies on being able to break into non-public members or access protected members from the wrong context. These are issues that should be reported to the owners of these libraries. We know it will be difficult in the interim before the maintainers release new versions that work with JDK 9. You mention Spring. There are some very smart people working on it and tracking JDK 9 closely from what I can tell. Existing versions SpringBoot fail today for a couple of reasons - one is that it is helping itself to a non-public constructor for MethodHandles.Lookup. Another is that it wants to invoke the protected ClassLoader.defineClass from the wrong context. I'm confident that they will fix this code in time as there new APIs to address these use cases. In the mean-time then there are command line options to keep existing versions working. Yes, command line options are pain but for executable JAR cases like this then there are JAR file attributes that come some relief from CLI options. As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days. I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager very often. If the overhead was zero and it was easier to identify the permissions needed by each component then maybe it would have got more popular. Another reason is that the access checks that you see in the discussions here are the access checks that the JLS and JVMS specifies. They are access checks that have to be done when you are not running with a security manager. They are also at a completely different level, meaning can bytecode in C1.m can access a member of C2. This is very different to the stack based permission checks that a security manager does. -Alan From reto.merz at abacus.ch Wed Apr 5 19:53:09 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Wed, 5 Apr 2017 21:53:09 +0200 Subject: SecurityManager environments In-Reply-To: <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> Message-ID: <1067438972-25207@kerio.abacus.ch> >> To be honest, we don't see a lot of security manager >> usage on the server side these days. I'm really surprised about that. How can a app server or servlet container like JBoss Tomcat etc guarantee that System.exit does not shut down the JVM? >> I look at a lot of bug reports and >> error logs that include the command line and I don't see >> -Djava.security.manager very often. Our app server (closed-source) set it via System.setSecurityManager while bootstrapping. We have started using a SecurityManager over 11 years ago, basically to disallow invocation of ??? System.setSecurityManager, System.setProperties ??? System.exit, System.setIn, System.setOut ??? Authenticator.setDefault, ProxySelector.setDefault ??? HttpsURLConnection.setDefaultSSLSocketFactory ??? HttpsURLConnection.setDefaultHostnameVerifier ??? etc We also disallow System.setProperty with these keys ??? ssl.* ??? javax.net.ssl.* ??? java.security.* ??? http.proxyHost, http.proxyPort ??? sun.util.spi.XmlPropertiesProvider and all keys which are set at the time when we register our security manager (eg: "user.dir" etc). At this moment we also set a custom java.util.Properties implementation via System.setProperties so that access via System.getProperties() is restricted too, eg: ??? System.getProperties().clear() // removes mutable entries only ??? System.getProperties().put("http.proxyPort", "unlucky") // will cause a security exception Of course there are still holes but in our case we just want to find erroneous code from new programmer colleague which is still a little green. Regards Reto Von: Alan Bateman An: Gregg Wonderly Kopie: Gesendet: 05.04.2017 19:53 Betreff: Re: SecurityManager environments On 05/04/2017 16:26, Gregg Wonderly wrote: > : > At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and should instead be immutable. ?But, because ?assume no security manager in the picture? is the state of ?the world?, the details have not been fixed, officially. ?In the Jini community, Peter Firmstone (most of the recent work), and I, have spent quite a bit of time on understand and fixing these issues. ?He has tried to push the knowledge of what needs to be done into various places, which I don?t recall at the moment. You are right that the performance overhead when running with a security manager can be a problem. Walking the stack to get the intersection of the permissions has historically been a big part of this. If there are proposals and patches to improve the performance then security-dev is the place to bring those for discussion, maybe hotspot-dev if it gets into the stack walking in the VM. > In the end because JDK-9 breaks everything (well not quite, but nearly, since spring and other similar libraries are broken), requiring command line arguments, why not just finally fix Java by instituting a default SecurityManager, instead of the command line flags, which enforces all of these things. ?Why not just require the added command line argument to be the permissions file to use? I assume the breakage you see is just a consequence of strong encapsulation. There is a lot of existing code that relies on being able to break into non-public members or access protected members from the wrong context. These are issues that should be reported to the owners of these libraries. ?We know it will be difficult in the interim before the maintainers release new versions that work with JDK 9. You mention Spring. There are some very smart people working on it and tracking JDK 9 closely from what I can tell. Existing versions SpringBoot ?fail today for a couple of reasons - one is that it is helping itself to a non-public constructor for MethodHandles.Lookup. Another is that it wants to invoke the protected ClassLoader.defineClass from the wrong context. I'm confident that they will fix this code in time as there new APIs to address these use cases. ?In the mean-time then there are command line options to keep existing versions working. Yes, command line options are pain but for executable JAR cases like this then there are JAR file attributes that come some relief from CLI options. As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days. I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager very often. If the overhead was zero and it was easier to identify the permissions needed by each component then maybe it would have got more popular. Another reason is that the access checks that you see in the discussions here are the access checks that the JLS and JVMS specifies. They are access checks that have to be done when you are not running with a security manager. They are also at a completely different level, meaning can bytecode in C1.m can access a member of C2. This is very different to the stack based permission checks that a security manager does. -Alan From greggwon at cox.net Wed Apr 5 20:23:57 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Wed, 5 Apr 2017 15:23:57 -0500 Subject: SecurityManager environments In-Reply-To: <4htl1v0251VxnVH01htm4G> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <4FlA1v0230dAWJx01FlB7S> <4htl1v0251VxnVH01htm4G> Message-ID: <260AE93E-F59D-4D13-AE4B-5F6F2D7D42D8@cox.net> > On Apr 5, 2017, at 12:53 PM, Alan Bateman wrote: > > On 05/04/2017 16:26, Gregg Wonderly wrote: >> : >> At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and should instead be immutable. But, because ?assume no security manager in the picture? is the state of ?the world?, the details have not been fixed, officially. In the Jini community, Peter Firmstone (most of the recent work), and I, have spent quite a bit of time on understand and fixing these issues. He has tried to push the knowledge of what needs to be done into various places, which I don?t recall at the moment. > You are right that the performance overhead when running with a security manager can be a problem. Walking the stack to get the intersection of the permissions has historically been a big part of this. If there are proposals and patches to improve the performance then security-dev is the place to bring those for discussion, maybe hotspot-dev if it gets into the stack walking in the VM. I believe that these are places where Peter has taken some of his findings. >> In the end because JDK-9 breaks everything (well not quite, but nearly, since spring and other similar libraries are broken), requiring command line arguments, why not just finally fix Java by instituting a default SecurityManager, instead of the command line flags, which enforces all of these things. Why not just require the added command line argument to be the permissions file to use? > I assume the breakage you see is just a consequence of strong encapsulation. There is a lot of existing code that relies on being able to break into non-public members or access protected members from the wrong context. These are issues that should be reported to the owners of these libraries. We know it will be difficult in the interim before the maintainers release new versions that work with JDK 9. > > You mention Spring. There are some very smart people working on it and tracking JDK 9 closely from what I can tell. Existing versions SpringBoot fail today for a couple of reasons - one is that it is helping itself to a non-public constructor for MethodHandles.Lookup. Another is that it wants to invoke the protected ClassLoader.defineClass from the wrong context. I'm confident that they will fix this code in time as there new APIs to address these use cases. In the mean-time then there are command line options to keep existing versions working. Yes, command line options are pain but for executable JAR cases like this then there are JAR file attributes that come some relief from CLI options. I believe that the focus is still on just the server class of applications. Desktop applications started from a double clicked jar file, have no explicit access to the command line. It just doesn?t exist for that application. It only exists for ?all? applications (launched for mime-type mapped application mappings) in most cases (linux/unix shortcuts can be constructed to specify arguments more readily, but still require expertise to do that). > As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days. This is one of my standing issues. The focus is all around server applications. Those are the applications where there is engineering and development around deployment. Desktop is completely different the JRE/JDK is update asynchronously from the actual application. There are all kinds of places where Java gets used besides a ?engineered? deployment. It?s those environments where corporate standards for security are going to require updates to occur in corporate environments, or whatever update policy is decided on by Oracle for the desktop JRE environment to recommend to the user that they update there JDK/JRE release to the most recent. If they just have a clickable jar which has been carefully crafted and packaged to hold some of the broken code from other libraries, who is going to help those users recover to a working application? Who?s going to pay for all of the support people who have to hold peoples hands to get stuff fixed? Yes, there might be an organization inside of a corporation who is going to analyze things and figure out what?s broken. They are going to then need to find the fixes, test them, engineer a deployment scheme and spend real time and money to take care of the details. What timeline constraints are going to impact them? Some new applications will be deployed with new command line arguments that old JDKs don?t support. Some old applications are going to break because they have old versions of Spring in them. How will a user with a single default version of Java installed, be able to manage the fact that they have apps that need JDK-9 command line support and others that can?t use JDK-9 because of the new requirements for command line arguments to work around the broken software they have been using? People have multiple Java applications in use, and probably a sizable number of those are not going to be broken. But, the Spring libraries seem to have become quite prevalent in lots of places and that, for me, is going to be the stick in the mud that just keeps on getting stuck. > I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager very often. If the overhead was zero and it was easier to identify the permissions needed by each component then maybe it would have got more popular. Another reason is that the access checks that you see in the discussions here are the access checks that the JLS and JVMS specifies. They are access checks that have to be done when you are not running with a security manager. They are also at a completely different level, meaning can bytecode in C1.m can access a member of C2. This is very different to the stack based permission checks that a security manager does. Yes, all of these JVM level access checks are where they need to be. There are a lot of details of the actual implementation which I am sure I do no understand. However, I?ve been around Java for a long time. I create a broker for Java before there was JMS or JXTA and lots of other things that happened 20 years ago. It?s still a vital platform for me, because I still hope we can get something to keep from creating yet another procedural language that just keeps on denying the opportunity for large scale integration of software systems which should be in the same process. Gregg From brianf at infinity.nu Wed Apr 5 21:36:49 2017 From: brianf at infinity.nu (Brian Fox) Date: Wed, 5 Apr 2017 23:36:49 +0200 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: <20170404161716.672368397@eggemoggin.niobe.net> References: <20170403093500.721331054@eggemoggin.niobe.net> <20170404161716.672368397@eggemoggin.niobe.net> Message-ID: What I meant to saw but didn't clearly articulate is that I found it unlikely that half of the most popular stuff was somehow in that 6%. I pulled the top 200 based on consumption and 136 had easily verifiable pom.properties. I don't think the facts really matter though,. I don't understand the motivations and will avoid the trap of projecting them. However, it's been clear that the team has been looking for reasons not to change the status quo, vs having an open mind. I thought that the Module-Name was a reasonable middle ground that would allow developers to provide a smooth migration path between now and when this hits critical mass. Now that it's out the window, we're right back where we started from. On Wed, Apr 5, 2017 at 1:17 AM, wrote: > 2017/4/4 2:38:37 -0700, Brian Fox : > > Mark I think some of the assertions on the prevalence of the > pom.properties > > is wrong. We pulled our own top 20 list based on download popularity and > > you can see it lines up well with your cited article: > > > > count | group_name | artifact_name > > ---------+----------------------------+--------------------- > > 9620458 | junit | junit > > 7660971 | org.slf4j | slf4j-api > > 5608458 | log4j | log4j > > 5542626 | commons-codec | commons-codec > > 5389851 | com.google.guava | guava > > 5357355 | commons-io | commons-io > > 5177092 | commons-logging | commons-logging > > 4936300 | org.apache.httpcomponents | httpclient > > 4874902 | org.apache.httpcomponents | httpcore > > 4756847 | commons-cli | commons-cli > > 4577052 | org.apache.commons | commons-lang3 > > 4508856 | commons-lang | commons-lang > > 4430776 | com.fasterxml.jackson.core | jackson-core > > 4280673 | com.fasterxml.jackson.core | jackson-databind > > 4270501 | com.google.code.findbugs | jsr305 > > 4140850 | com.fasterxml.jackson.core | jackson-annotations > > 3860911 | org.slf4j | jcl-over-slf4j > > 3410877 | org.springframework | spring-core > > 3062759 | org.springframework | spring-beans > > 2989047 | classworlds | classworlds > > > > However, only junit and the 2 spring modules are missing a > pom.properties. > > The assertion that less than half the popular components don't have it > > seems provably incorrect. > > It's correct for the 140 projects that I examined, which is all that > I claimed. Check them for yourself. > > The number of projects that constitutes a reasonable sample of the > "popular" projects (by whatever ranking) is a bit of a judgement call, > but twenty seems very small to me. Every project in my list of 140 is > well known, so I think it's a more representative sample. > > What do you see if you examine the top 140 projects according to > whatever ranking you use for Central? > > > All the popular stuff is in Maven Central and > > again, 94% is a huge number, saying it doesn't cover much is just > > inaccurate. > > Nearly everything in Central is not popular. That 94% of all projects > have a given property does not imply that 94% of the popular projects > have that property. > > - Mark > From mandy.chung at oracle.com Wed Apr 5 22:43:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Apr 2017 15:43:10 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: > > On Apr 4, 2017, at 9:28 AM, Alan Bateman wrote: > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > I reviewed all changes. Looks good in general with a few minor comments: Resolver.java 221 String prefix; 222 if (mref.descriptor().isAutomatic()) { 223 prefix = "Automatic module"; 224 } else { 225 prefix = "Module"; 226 } It may be nice for this tracing output to follow similar format as to ?-list-module output (e.g ?automatic? following the name/location) java/util/ServiceLoader.java 216 *

Service loaders created to locate providers in a {@linkplain module layer} LauncherHelper.java 996 .ifPresent(any -> ostream.print(" automatic")); It might be useful to indicate if the required module is not observable. InstrumentationImpl.java I think redefineModule should check isModifiableModule even the current implementation returns true for all modules. Mandy From mark.reinhold at oracle.com Wed Apr 5 23:34:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 05 Apr 2017 16:34:21 -0700 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <20170405163421.448261819@eggemoggin.niobe.net> 2017/4/5 10:00:13 -0700, michael.rasmussen at zeroturnaround.com: > On 5 April 2017 at 19:15, wrote: >> ... >> >> - Enhance the `-jar` launcher option so that if the JAR file being >> launched contains a `Premain-Class` attribute then it's launched >> as both an application and as an agent for that application. >> >> This will allow `java -jar foo.jar` to be used in place of the >> more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. > > I would propose the presence of an addition option in the manifest to > enable/control this behavior. > > In the case of standalone agents, running them as -jar are sometimes > used for a different purpose than running them as agents. > For instance, in the case of JRebel, java -jar jrebel.jar is used for > license activation/control, and should not activate the agent part. Interesting. Perhaps we need a `Self-Premain-Class` attribute, or some such. Out of curiosity, would it do any harm in your `java -jar` case if the agent is activated? - Mark From amy.lu at oracle.com Thu Apr 6 02:35:48 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 6 Apr 2017 10:35:48 +0800 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: Hi, Alan I noticed test tools/launcher/FXLauncherTest.java fails with jigsaw-nightly-h6277-20170404 (on Windows platform). Is that because related OpenJFX changes are not yet in the mentioned build? Thanks, Amy On 4/5/17 12:28 AM, Alan Bateman wrote: > As I mentioned on jigsaw-dev yesterday, we have accumulated a number > of changes in the jake forest and would like to bring the changes into > jdk9/dev for jdk-9+165. > > Most of the changes in this update are the move of Module and friends > from java.lang.reflect to java.lang. This is mostly a mechanical update. > > We also have the update to the derivation of automatic modules to no > longer ignore trailing digits in modules names, this is to align JDK 9 > with the updated proposal for issue #VersionsInModuleNames [1]. > > There are a number of smaller changes, summarized in JDK-8177530 [2]. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > > The changes are currently based on jdk-9+163 and will be rebased > before pushing to jdk9/dev. > > The corresponding update to jtreg is already in the code-tools/jtreg > repo and will be tagged (I assume as jtreg4.2-b07) before this > integration. Once it is tagged then we'll rev'ing the requiredVersion > in each TEST.ROOT. > > -Alan > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames > [2] https://bugs.openjdk.java.net/browse/JDK-8177530 > > > From jason at tedor.me Thu Apr 6 03:10:40 2017 From: jason at tedor.me (Jason Tedor) Date: Thu, 06 Apr 2017 03:10:40 +0000 Subject: SecurityManager environments In-Reply-To: <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> References: <883259944-21059@kerio.abacus.ch> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> Message-ID: > As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days. I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager very often. This is not to negate your point. We use the security manager in Elasticsearch (a server application). It is not enabled via the java.security.manager system property, instead we enable it at runtime [1]. SecureSM is our own security manager, too. [1]: https://github.com/elastic/elasticsearch/blob/471af48170218fbbb32399aabb3056f2f8a99c17/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L119 On Wed, Apr 5, 2017 at 4:14 PM Alan Bateman wrote: > On 05/04/2017 16:26, Gregg Wonderly wrote: > > : > > At the forefront of the failure of the SecurityManager to be an avidly > used element of Java applications, is the simple fact that the whole > infrastructure is horribly inefficient and full of locks and mutable data > which should not be locked and should instead be immutable. But, because > ?assume no security manager in the picture? is the state of ?the world?, > the details have not been fixed, officially. In the Jini community, Peter > Firmstone (most of the recent work), and I, have spent quite a bit of time > on understand and fixing these issues. He has tried to push the knowledge > of what needs to be done into various places, which I don?t recall at the > moment. > You are right that the performance overhead when running with a security > manager can be a problem. Walking the stack to get the intersection of > the permissions has historically been a big part of this. If there are > proposals and patches to improve the performance then security-dev is > the place to bring those for discussion, maybe hotspot-dev if it gets > into the stack walking in the VM. > > > In the end because JDK-9 breaks everything (well not quite, but nearly, > since spring and other similar libraries are broken), requiring command > line arguments, why not just finally fix Java by instituting a default > SecurityManager, instead of the command line flags, which enforces all of > these things. Why not just require the added command line argument to be > the permissions file to use? > I assume the breakage you see is just a consequence of strong > encapsulation. There is a lot of existing code that relies on being able > to break into non-public members or access protected members from the > wrong context. These are issues that should be reported to the owners of > these libraries. We know it will be difficult in the interim before the > maintainers release new versions that work with JDK 9. > > You mention Spring. There are some very smart people working on it and > tracking JDK 9 closely from what I can tell. Existing versions > SpringBoot fail today for a couple of reasons - one is that it is > helping itself to a non-public constructor for MethodHandles.Lookup. > Another is that it wants to invoke the protected ClassLoader.defineClass > from the wrong context. I'm confident that they will fix this code in > time as there new APIs to address these use cases. In the mean-time > then there are command line options to keep existing versions working. > Yes, command line options are pain but for executable JAR cases like > this then there are JAR file attributes that come some relief from CLI > options. > > As regards the security manager then it's hard to see how it fits into > the discussion. To be honest, we don't see a lot of security manager > usage on the server side these days. I look at a lot of bug reports and > error logs that include the command line and I don't see > -Djava.security.manager very often. If the overhead was zero and it was > easier to identify the permissions needed by each component then maybe > it would have got more popular. Another reason is that the access checks > that you see in the discussions here are the access checks that the JLS > and JVMS specifies. They are access checks that have to be done when you > are not running with a security manager. They are also at a completely > different level, meaning can bytecode in C1.m can access a member of C2. > This is very different to the stack based permission checks that a > security manager does. > > -Alan > From mandy.chung at oracle.com Thu Apr 6 04:38:21 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Apr 2017 21:38:21 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> FXLauncherTest.java should fail until FX change [1] is integrated and promoted (target for jdk-9+164). I suggest to rerun the test after jdk-9+164 is promoted and sync down to jdk9/dev and jake. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8177751 > On Apr 5, 2017, at 7:35 PM, Amy Lu wrote: > > Hi, Alan > > I noticed test tools/launcher/FXLauncherTest.java fails with jigsaw-nightly-h6277-20170404 (on Windows platform). Is that because related OpenJFX changes are not yet in the mentioned build? > > Thanks, > Amy > > On 4/5/17 12:28 AM, Alan Bateman wrote: >> As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. >> >> Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. >> >> We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. >> >> There are a number of smaller changes, summarized in JDK-8177530 [2]. >> >> The webrev with the changes is here: >> http://cr.openjdk.java.net/~alanb/8177530/1 >> >> The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. >> >> The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. >> >> -Alan >> >> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames >> [2] https://bugs.openjdk.java.net/browse/JDK-8177530 >> >> >> > From amy.lu at oracle.com Thu Apr 6 04:48:41 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 6 Apr 2017 12:48:41 +0800 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> Message-ID: Got it. Thank you Mandy! /Amy On 4/6/17 12:38 PM, Mandy Chung wrote: > FXLauncherTest.java should fail until FX change [1] is integrated and promoted (target for jdk-9+164). I suggest to rerun the test after jdk-9+164 is promoted and sync down to jdk9/dev and jake. > > Mandy > [1]https://bugs.openjdk.java.net/browse/JDK-8177751 > > >> On Apr 5, 2017, at 7:35 PM, Amy Lu wrote: >> >> Hi, Alan >> >> I noticed test tools/launcher/FXLauncherTest.java fails with jigsaw-nightly-h6277-20170404 (on Windows platform). Is that because related OpenJFX changes are not yet in the mentioned build? >> >> Thanks, >> Amy From Alan.Bateman at oracle.com Thu Apr 6 07:07:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 08:07:53 +0100 Subject: SecurityManager environments In-Reply-To: <1067438972-25207@kerio.abacus.ch> References: <1067438972-25207@kerio.abacus.ch> Message-ID: <3bd20f5c-f773-7f14-ced6-9a3a987260fd@oracle.com> On 05/04/2017 20:53, Reto Merz wrote: > >> To be honest, we don't see a lot of security manager > >> usage on the server side these days. > > I'm really surprised about that. How can a app server or servlet container > like JBoss Tomcat etc guarantee that System.exit does not shut down > the JVM? AFAIK the app servers have to provide a way to run with a security manager but I don't know how many app server run it by default. The System.exit example is a good example that has come up a few times. There is at least one IDE that used to run with a SM so that it could block plugins from calling System.exit. That use case is one that probably needs a specific API. -Alan From Alan.Bateman at oracle.com Thu Apr 6 07:50:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 08:50:11 +0100 Subject: SecurityManager environments In-Reply-To: <260AE93E-F59D-4D13-AE4B-5F6F2D7D42D8@cox.net> References: <883259944-21059@kerio.abacus.ch> <3sYq1v03X4x5MXx01sYrGp> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <49d41v01M4x5MXx019d6wk> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <4FlA1v0230dAWJx01FlB7S> <4htl1v0251VxnVH01htm4G> <260AE93E-F59D-4D13-AE4B-5F6F2D7D42D8@cox.net> Message-ID: On 05/04/2017 21:23, Gregg Wonderly wrote: > Desktop applications started from a double clicked jar file, have no explicit access to the command line. It just doesn?t exist for that application. It only exists for ?all? applications (launched for mime-type mapped application mappings) in most cases (linux/unix shortcuts can be constructed to specify arguments more readily, but still require expertise to do that). The Add-Exports and Add-Opens attributes are the executable JAR equivalent of the --add-exports and --add-opens command line options. So if an application is hacking into say sun.awt then the maintainer of the application can shield the users of the application until those issues are fixed. These JAR file attributes are ignored when running on JDK 8. There are equivalents for JNLP applications that have been discussed on other threads here. So more support keeping bad code working until the owners of that code fix the issues. I think part of your mail is concerned with the scenario of users using the JRE and getting automatic updates. If they are updated to JRE 9 but are using a much older version of an application with bad code then they will have problems. The responsibility has to lie with the maintainers of the application (and whoever else is in the middle) to make sure that the users get a new version of the application in advance. This is no different to an upgrade from JRE 7 to JRE 8. That is, if there is code hacking into sun.awt (and I'm just using that as an example as there weren't any specific example in your mail) then it's going to be fragile anyway. Maybe the AWT code has been refactored so the private field that is being hacked no longer exists or has been renamed. FWIW, I see that users using Oracle's JRE with auto update enabled had the option to upgrade to JRE 8 from Jan 2015. JDK 8 shipped in March 2014 so there was a 9 month lag. I have no knowledge on when JRE 9 might be offered to end users using auto update. > : > People have multiple Java applications in use, and probably a sizable number of those are not going to be broken. But, the Spring libraries seem to have become quite prevalent in lots of places and that, for me, is going to be the stick in the mud that just keeps on getting stuck. > The Spring maintainers come across as smart cookies, I'm sure they will release versions in a timely manner that address the technical debt and work on JDK 9 without needing command line options. -Alan From Alan.Bateman at oracle.com Thu Apr 6 07:56:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 08:56:34 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: On 05/04/2017 17:55, David M. Lloyd wrote: > > This is just plain weird from a security perspective, to say that > unrelated processes have more privilege to control the current process > than processes that are closely related. > > Anyway this is yet another case where arbitrary artificial hurdles are > put in place for the purpose of human behavior modification. Such > hurdles can always be bypassed, generally resulting in even uglier > situations that the one you're trying to avoid. In this case I can > just fire a child process and then attach to it from the parent. Or > fire off two sibling processes and have one attach to the other. > Nothing is being saved here. This thread/proposal is concerned with libraries using APIs intended for tools to do brain surgery in the current VM. Launching VMs and attaching to those VMs isn't a concern, no issue with sibling VMs attaching to each other either either. -Alan. From magnus.ihse.bursie at oracle.com Thu Apr 6 08:09:20 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Apr 2017 10:09:20 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> Message-ID: <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> On 2017-04-04 10:04, Magnus Ihse Bursie wrote: > > On 2017-04-03 23:50, Mandy Chung wrote: >>> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >>> >>> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>>> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>>>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>>>> >>>>>> ... >>>>>> >>>>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>>>> in the `release` file: >>>>>> >>>>>> JDK 8 JDK 9 >>>>>> ----- ----- >>>>>> OS_NAME Linux linux >>>>>> SunOS solaris >>>>>> Darwin osx >>>>>> Windows windows >>>>>> >>>>>> OS_ARCH i386,x86 x86 >>>>>> i586,amd64,x86_64 x64 >>>>>> sparcv9 sparcv9 >>>>>> arm arm32 >>>>>> aarch64 arm64 >>>> I am not sure why we would change to osx for Mac when the Mac >>>> developers >>>> have recently dropped the Mac OS X terminology and changed it to >>>> macOS. >>> Agreed -- we should change OS_NAME from "Darwin" to "macos?. >> OK. Should the bundle names be updated to reflect this change? >> In any case, it is a separate issue. >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 Having though this over real hard, I'd realized I need to make a plea for sanity and consistency. I thought I should lay low in this discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86 platform is really, really unfortunate and a step backwards in our effort to standardize the name of this platform. We have continuously worked on trying to get "x64" the all-around standard name for this platform. Since we dropped the path "lib/amd64", I believe more or less the only place left that still has "amd64" is os.arch, which is not easy to change due to legacy reasons (although I'd really like to see that changed too, considering that it already is different on different operating systems...) I'd really hate for us to suddenly start introducing changes that once again divert us away. :-( It's hard enough as it is with all this converting of names. Let us not add yet another odd place! /Magnus > If we are making changes to the original proposal from JDK-8175819, > then I just want to add my few cents: > > Why change from the well-established "aarch64" to the virtually unused > "arm64"? As far as I know, using the name "arm64" for the aarch64 > platform is something that has only been done in the (recently opened) > closed Oracle port. This change, however, proposes to change the value > in the release file even for the open aarch64 port, which has always > been known by that name. > > /Magnus > >> >> Mandy >> > From forax at univ-mlv.fr Thu Apr 6 08:18:54 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 6 Apr 2017 10:18:54 +0200 (CEST) Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <1747429017.1656728.1491466734088.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "mark reinhold" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 5 Avril 2017 18:15:20 > Objet: Disallowing the dynamic loading of agents by default (revised) > Thanks to everyone for the quick feedback on this topic, and especially > to Andrew for the constructive dialogue. > > Here's a revised proposal: > > - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's > on by default in JDK 9 but off by default in JDK 10. > > This will allow launch scripts that use this option on JDK 10 to > work on JDK 9 without change, and will allow early testing of the > JDK 10 behavior on JDK 9. yes > > - Revise the `com.sun.tools.attach` API to forbid attachment to the > current process or to an ancestor of the current process, and > define a read-only system property that allows such attachment to > be enabled via the command line. > > This will discourage the inadvertent use of libraries that, for > better or for worse, intentionally violate strong encapsulation. don't get this one, as David said, if you span a new VM with an exec, you have more right ?? > > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. Can be very useful indeed. (with another name that "Premain-Class" for backward compatibility). > > Taken together, these changes are intended to enable the continued use > of legitimate dynamically-loaded agents without change on JDK 9 and with > a small change on JDK 10. That later change will align the treatment of > such agents with the other means of breaking encapsulation (`--add-opens`, > etc.) in order to ensure integrity by default for all code. > > This proposal does not attempt to lock down platform classes as distinct > from user classes. Many agents have legitimate reasons to transform > platform classes, so an additional mechanism to protect those classes > does not appear to be worthwhile. > > Comments? > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012000.html R?mi From michael.rasmussen at zeroturnaround.com Thu Apr 6 09:07:27 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 6 Apr 2017 12:07:27 +0300 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405163421.448261819@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <20170405163421.448261819@eggemoggin.niobe.net> Message-ID: On 6 April 2017 at 02:34, wrote: > Interesting. Perhaps we need a `Self-Premain-Class` attribute, or some > such. > > Out of curiosity, would it do any harm in your `java -jar` case if the > agent is activated? As it is right now, yes, that would cause the execution to potentially fail. Should a Self-Premain-Class (or like) not be implements, we would have to check in the beginning of premain if we are running in java -jar mode, and if such, make premain a no-op. /Michael From adinn at redhat.com Thu Apr 6 10:09:49 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 6 Apr 2017 11:09:49 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <1fd45a87-5e0e-8f4f-3746-31ad9b64518e@redhat.com> On 05/04/17 17:15, mark.reinhold at oracle.com wrote: > Thanks to everyone for the quick feedback on this topic, and especially > to Andrew for the constructive dialogue. > > Here's a revised proposal: > > - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's > on by default in JDK 9 but off by default in JDK 10. > > This will allow launch scripts that use this option on JDK 10 to > work on JDK 9 without change, and will allow early testing of the > JDK 10 behavior on JDK 9. This at the least is very welcome. It will give Red Hat and others the time needed to prepare their users for for this change. > - Revise the `com.sun.tools.attach` API to forbid attachment to the > current process or to an ancestor of the current process, and > define a read-only system property that allows such attachment to > be enabled via the command line. > > This will discourage the inadvertent use of libraries that, for > better or for worse, intentionally violate strong encapsulation. I guess I'm agnostic to this. I'm certainly not against it. Is this change being proposed for JDK9 or JDK10? I'd prefer the latter as that would give me more time to educate those using the Byteman BMUnit package about the need to configure the requisite system property. However, it's less of an issue than the -XX:+EnableDynamicAgentLoading flag since, once configured, the system property does no harm when switching from JDK9 back to JDK8. > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. I have no comments to offer on this as it is not a scenario I have had to deal with. > Taken together, these changes are intended to enable the continued use > of legitimate dynamically-loaded agents without change on JDK 9 and with > a small change on JDK 10. That later change will align the treatment of > such agents with the other means of breaking encapsulation (`--add-opens`, > etc.) in order to ensure integrity by default for all code. That's a compromise position I can live with. Much as I want to retain the ability to load my agent dynamically I also acknowledge that this is one side of a trade-off. In particular, this proposal incorporates the need for the JVM /eventually/ to have -- as a default -- a guarantee that some portion of the code base cannot be subject to change and hence is available for optimization without the need for ever more complex apparatus to ensure later de-optimization. That's something I understand the significance of and regard as very important for the future of the JVM and JVM-based languages (not just Java). This probably means that at some point (maybe JDK10 time, maybe later, depending upon when this might start to deliver performance improvements) Red Hat will decide to advise most of their Java customers to run without the option to load dynamic agents. That may lose our support team some opportunities to diagnose certain types of problems but may also enable those customers to gain from performance improvements. > This proposal does not attempt to lock down platform classes as distinct > from user classes. Many agents have legitimate reasons to transform > platform classes, so an additional mechanism to protect those classes > does not appear to be worthwhile. I'm happy with this although it might be worth reviewing it later. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From alan.bateman at oracle.com Thu Apr 6 10:47:38 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 10:47:38 +0000 Subject: hg: jigsaw/jake/hotspot: Address review comments Message-ID: <201704061047.v36AlcDe013414@aojmv0008.oracle.com> Changeset: b4b842a1dbe6 Author: alanb Date: 2017-04-06 11:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b4b842a1dbe6 Address review comments ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvmtiEnv.cpp From alan.bateman at oracle.com Thu Apr 6 12:22:38 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 12:22:38 +0000 Subject: hg: jigsaw/jake/jdk: Address review comments Message-ID: <201704061222.v36CMcBu017308@aojmv0008.oracle.com> Changeset: 2182c183a9ad Author: alanb Date: 2017-04-06 13:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2182c183a9ad Address review comments ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! test/tools/launcher/modules/listmods/ListModsTest.java From david.lloyd at redhat.com Thu Apr 6 12:56:33 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 6 Apr 2017 07:56:33 -0500 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <19e9cc68-895d-c1ae-0a7e-334e6e469f25@redhat.com> On 04/06/2017 02:56 AM, Alan Bateman wrote: > On 05/04/2017 17:55, David M. Lloyd wrote: > >> >> This is just plain weird from a security perspective, to say that >> unrelated processes have more privilege to control the current process >> than processes that are closely related. >> >> Anyway this is yet another case where arbitrary artificial hurdles are >> put in place for the purpose of human behavior modification. Such >> hurdles can always be bypassed, generally resulting in even uglier >> situations that the one you're trying to avoid. In this case I can >> just fire a child process and then attach to it from the parent. Or >> fire off two sibling processes and have one attach to the other. >> Nothing is being saved here. > This thread/proposal is concerned with libraries using APIs intended for > tools to do brain surgery in the current VM. I know, I'm giving examples of how such a library could circumvent this restriction. Another example is to start a child process and a grandchild process, and then have the child process exit. Adding technical hurdles to send a social message is frankly pretty lousy engineering. It never fails to backfire. -- - DML From adinn at redhat.com Thu Apr 6 13:05:01 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 6 Apr 2017 14:05:01 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <19e9cc68-895d-c1ae-0a7e-334e6e469f25@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <19e9cc68-895d-c1ae-0a7e-334e6e469f25@redhat.com> Message-ID: On 06/04/17 13:56, David M. Lloyd wrote: > On 04/06/2017 02:56 AM, Alan Bateman wrote: >> On 05/04/2017 17:55, David M. Lloyd wrote: >> >>> >>> This is just plain weird from a security perspective, to say that >>> unrelated processes have more privilege to control the current process >>> than processes that are closely related. >>> >>> Anyway this is yet another case where arbitrary artificial hurdles are >>> put in place for the purpose of human behavior modification. Such >>> hurdles can always be bypassed, generally resulting in even uglier >>> situations that the one you're trying to avoid. In this case I can >>> just fire a child process and then attach to it from the parent. Or >>> fire off two sibling processes and have one attach to the other. >>> Nothing is being saved here. >> This thread/proposal is concerned with libraries using APIs intended for >> tools to do brain surgery in the current VM. > > I know, I'm giving examples of how such a library could circumvent this > restriction. Another example is to start a child process and a > grandchild process, and then have the child process exit. > > Adding technical hurdles to send a social message is frankly pretty > lousy engineering. It never fails to backfire. This proposal comes with an even simpler way to 'circumvent this restriction' i.e. set the requisite property on the command line. I think the point is not really to stop rogue code from hoisting an agent by such indirect means (Mark Reinhold agreed that if such rogue code is in the runtime you have already handed over the keys to the castle). It is to make normal code explicitly acknowledge what it is doing (more precisely, to make those deploying the code be more explicit about their intention to do so). That's not such a terrible thing to transition to in the longer term, assuming we are given time to manage the transition. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From greggwon at cox.net Thu Apr 6 13:24:50 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 6 Apr 2017 08:24:50 -0500 Subject: SecurityManager environments In-Reply-To: <4v8c1v00Y4x5MXx01v8e6c> References: <1067438972-25207@kerio.abacus.ch> <4v8c1v00Y4x5MXx01v8e6c> Message-ID: <19E11FA1-B36B-489E-8802-1B2959670708@cox.net> > > On Apr 6, 2017, at 2:07 AM, Alan Bateman wrote: > > On 05/04/2017 20:53, Reto Merz wrote: > >>>> To be honest, we don't see a lot of security manager >>>> usage on the server side these days. >> >> I'm really surprised about that. How can a app server or servlet container >> like JBoss Tomcat etc guarantee that System.exit does not shut down the JVM? > AFAIK the app servers have to provide a way to run with a security manager but I don't know how many app server run it by default. > > The System.exit example is a good example that has come up a few times. There is at least one IDE that used to run with a SM so that it could block plugins from calling System.exit. That use case is one that probably needs a specific API. > > -Alan SecurityManager provides exactly the API because you can just not give that permission to the jar. SecurityManager needs to be used more, and that means that it needs to be fixed. Even the low level JVM operations can be driven by SecurityManager operations that are just as efficient (complexity) as these command line options. Gregg From dalibor.topic at oracle.com Thu Apr 6 13:52:15 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 6 Apr 2017 15:52:15 +0200 Subject: SecurityManager environments In-Reply-To: <19E11FA1-B36B-489E-8802-1B2959670708@cox.net> References: <1067438972-25207@kerio.abacus.ch> <4v8c1v00Y4x5MXx01v8e6c> <19E11FA1-B36B-489E-8802-1B2959670708@cox.net> Message-ID: On 06.04.2017 15:24, Gregg Wonderly wrote: > SecurityManager needs to be used more Potentially relevant academic research: http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf "We observed evidence that many developers struggle to understand and use the security manager for any purpose. This is perhaps why there were only 36 applications in our sample." cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Thu Apr 6 14:04:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 15:04:36 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <19e9cc68-895d-c1ae-0a7e-334e6e469f25@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <19e9cc68-895d-c1ae-0a7e-334e6e469f25@redhat.com> Message-ID: <4b65e3a8-79b7-d86f-1f82-e8e8ebe05161@oracle.com> On 06/04/2017 13:56, David M. Lloyd wrote: > > I know, I'm giving examples of how such a library could circumvent > this restriction. Another example is to start a child process and a > grandchild process, and then have the child process exit. The examples in your first mail aren't a problem. Yes, the example in this mail of an intermediate process terminating and being re-parented to the init process will workaround any check that uses the process tree but I don't think we should be overly distracted by wild-ass code doing that. The purpose is simply to make it inconvenient for general purpose libraries to get at these APIs for the purposes of doing brain surgery in the current VM. -Alan From uschindler at apache.org Thu Apr 6 14:25:53 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 6 Apr 2017 16:25:53 +0200 Subject: SecurityManager environments In-Reply-To: <3bd20f5c-f773-7f14-ced6-9a3a987260fd@oracle.com> References: <1067438972-25207@kerio.abacus.ch> <3bd20f5c-f773-7f14-ced6-9a3a987260fd@oracle.com> Message-ID: <06ac01d2aee1$b5abde60$21039b20$@apache.org> Hi, > > >> To be honest, we don't see a lot of security manager > > >> usage on the server side these days. > > > > I'm really surprised about that. How can a app server or servlet container > > like JBoss Tomcat etc guarantee that System.exit does not shut down > > the JVM? > AFAIK the app servers have to provide a way to run with a security > manager but I don't know how many app server run it by default. > > The System.exit example is a good example that has come up a few times. > There is at least one IDE that used to run with a SM so that it could > block plugins from calling System.exit. That use case is one that > probably needs a specific API. Elasticsearch Server also blocks System.exit, so plugins or scripts running inside the query cannot shut down the server (it also blocks many other stuff for sandboxing everything). The main problem with implementing the exitVM permission is to make it work that you can still exit on your own ?? If you forbid exiting the VM, you cannot do it on your own. (cannot be done in a policy file, because the exit permission is given by default). This is by the way a good use case for the new StackWalker API!: The Elasticsearch (and Apache Lucene's Test Runner) SecurityManager do Thread.currentThread().getStackTrace() and then walk down the stack and only allow exiting if the right class/package is on the stack trace right before the System/Runtime.exit() call. E.g., I agree some improvements to SecurityManager around that would be good. It is really hard to implement that (only allow existing from a specific class/method), as you need to inspect stack, otherwise you cannot exit on your own... The code here is still known as "Uwe Schindler" algorithm in the community, originating from Apache Lucene and was just forked in Elasticsearch. They made a Maven package out of it (SecureSM is taking a list of packages that are allowed to exit the VM): Uwe From chris at hazelcast.com Thu Apr 6 14:29:16 2017 From: chris at hazelcast.com (Christoph Engelbert) Date: Thu, 6 Apr 2017 16:29:16 +0200 Subject: SecurityManager environments In-Reply-To: References: <1067438972-25207@kerio.abacus.ch> <4v8c1v00Y4x5MXx01v8e6c> <19E11FA1-B36B-489E-8802-1B2959670708@cox.net> Message-ID: <33726FEF-AA0B-434D-8105-9B89EF7FD0E7@hazelcast.com> I would agree with the paper that you shared, Dalibor. The SecurityManager system is not self-explanatory and I would also agree that, at least in the systems I worked with, there normally is no SecurityManager set, or even worse, the software fails with a SecurityManager set because some library doesn?t play nice. On the other side, I think the solution to make more use of the SecurityManager is not wrong but the API should be revised and a better / faster way is necessary, maybe incorporating the new StackWalker API for access checks. Christoph Engelbert Manager Developer Relations > On 6. Apr 2017, at 15:52, dalibor topic wrote: > > On 06.04.2017 15:24, Gregg Wonderly wrote: >> SecurityManager needs to be used more > > Potentially relevant academic research: http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf > > "We observed evidence that many developers struggle to > understand and use the security manager for any purpose. > This is perhaps why there were only 36 applications in our > sample." > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From kevin.rushforth at oracle.com Thu Apr 6 14:30:36 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Apr 2017 07:30:36 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> Message-ID: <58E6510C.4060002@oracle.com> FX build for jdk9+164 already was promoted last Friday. The changeset to use that build was pushed to jdk9/dev on Saturday (as per usual), but probably wasn't synced down to jdk9/jake. -- Kevin Mandy Chung wrote: > FXLauncherTest.java should fail until FX change [1] is integrated and promoted (target for jdk-9+164). I suggest to rerun the test after jdk-9+164 is promoted and sync down to jdk9/dev and jake. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8177751 > > > >> On Apr 5, 2017, at 7:35 PM, Amy Lu wrote: >> >> Hi, Alan >> >> I noticed test tools/launcher/FXLauncherTest.java fails with jigsaw-nightly-h6277-20170404 (on Windows platform). Is that because related OpenJFX changes are not yet in the mentioned build? >> >> Thanks, >> Amy >> >> On 4/5/17 12:28 AM, Alan Bateman wrote: >> >>> As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. >>> >>> Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. >>> >>> We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. >>> >>> There are a number of smaller changes, summarized in JDK-8177530 [2]. >>> >>> The webrev with the changes is here: >>> http://cr.openjdk.java.net/~alanb/8177530/1 >>> >>> The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. >>> >>> The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. >>> >>> -Alan >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames >>> [2] https://bugs.openjdk.java.net/browse/JDK-8177530 >>> >>> >>> >>> > > From Alan.Bateman at oracle.com Thu Apr 6 14:33:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 15:33:32 +0100 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <58E6510C.4060002@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> <78D5A319-FA55-4286-9989-D5623EA0F15D@oracle.com> <58E6510C.4060002@oracle.com> Message-ID: <2fae89f5-c452-0a50-1354-3b2c3673c3fc@oracle.com> On 06/04/2017 15:30, Kevin Rushforth wrote: > FX build for jdk9+164 already was promoted last Friday. The changeset > to use that build was pushed to jdk9/dev on Saturday (as per usual), > but probably wasn't synced down to jdk9/jake. Thanks. I will sync up jake once the jdk-9+164 tags have been pushed to master. -Alan From reto.merz at abacus.ch Thu Apr 6 16:52:35 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Thu, 6 Apr 2017 18:52:35 +0200 Subject: SecurityManager environments In-Reply-To: <06ac01d2aee1$b5abde60$21039b20$@apache.org> Message-ID: <1143145437-22252@kerio.abacus.ch> We use the same approach like Elasticsearch (walk through stack trace and check caller). Note that this does not work in any case. For example this will bypass checkExit, sure, in Java 9 this would also need --add-opens to make reflection work: ??? Method halt0 = Class.forName("java.lang.Shutdown").getDeclaredMethod("halt0", int.class); ??? halt0.setAccessible(true); ??? halt0.invoke(halt0, 0); But we can life with that because in our case we just want to find erroneous code. It is impossible to protect a JVM from malicious code (which is executed within the JVM) anyway. Regards Reto Von: Uwe Schindler An: 'Alan Bateman' , 'Reto Merz' Kopie: Gesendet: 06.04.2017 16:25 Betreff: RE: SecurityManager environments Hi, > > >> To be honest, we don't see a lot of security manager > > >> usage on the server side these days. > > > > I'm really surprised about that. How can a app server or servlet container > > like JBoss Tomcat etc guarantee that System.exit does not shut down > > the JVM? > AFAIK the app servers have to provide a way to run with a security > manager but I don't know how many app server run it by default. > > The System.exit example is a good example that has come up a few times. > There is at least one IDE that used to run with a SM so that it could > block plugins from calling System.exit. That use case is one that > probably needs a specific API. Elasticsearch Server also blocks System.exit, so plugins or scripts running inside the query cannot shut down the server (it also blocks many other stuff for sandboxing everything). The main problem with implementing the exitVM permission is to make it work that you can still exit on your own ?? If you forbid exiting the VM, you cannot do it on your own. (cannot be done in a policy file, because the exit permission is given by default). This is by the way a good use case for the new StackWalker API!: The Elasticsearch (and Apache Lucene's Test Runner) SecurityManager do Thread.currentThread().getStackTrace() and then walk down the stack and only allow exiting if the right class/package is on the stack trace right before the ?System/Runtime.exit() call. E.g., I agree some improvements to SecurityManager around that would be good. It is really hard to implement that (only allow existing from a specific class/method), as you need to inspect stack, otherwise you cannot exit on your own... The code here is still known as "Uwe Schindler" algorithm in the community, originating from Apache Lucene and was just forked in Elasticsearch. They made a Maven package out of it (SecureSM is taking a list of packages that are allowed to exit the VM): Uwe From uschindler at apache.org Thu Apr 6 17:01:26 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 6 Apr 2017 19:01:26 +0200 Subject: SecurityManager environments In-Reply-To: <1143145437-22252@kerio.abacus.ch> References: <06ac01d2aee1$b5abde60$21039b20$@apache.org> <1143145437-22252@kerio.abacus.ch> Message-ID: <06db01d2aef7$70554fc0$50ffef40$@apache.org> Hi, Elasticsearch does not allow setAccessible() anywhere in its code (by security policy), except some places in trusted libraries like Apache Lucene for mmap unmapping support (but those must use doPrivileged for that), but plugins and Elasticsearch?s core cannot call setAccessible. See also Dalibor Topic?s post with the paper about SecurityManager usage, if you allow ?suppressAccessChecks? permission to code you?re f*ked up. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From: Reto Merz [mailto:reto.merz at abacus.ch] Sent: Thursday, April 6, 2017 6:53 PM To: Uwe Schindler ; 'Alan Bateman' Cc: jigsaw-dev at openjdk.java.net Subject: Re: SecurityManager environments We use the same approach like Elasticsearch (walk through stack trace and check caller). Note that this does not work in any case. For example this will bypass checkExit, sure, in Java 9 this would also need --add-opens to make reflection work: Method halt0 = Class.forName("java.lang.Shutdown").getDeclaredMethod("halt0", int.class); halt0.setAccessible(true); halt0.invoke(halt0, 0); But we can life with that because in our case we just want to find erroneous code. It is impossible to protect a JVM from malicious code (which is executed within the JVM) anyway. Regards Reto Von: Uwe Schindler > An: 'Alan Bateman' >, 'Reto Merz' > Kopie: > Gesendet: 06.04.2017 16:25 Betreff: RE: SecurityManager environments Hi, > > >> To be honest, we don't see a lot of security manager > > >> usage on the server side these days. > > > > I'm really surprised about that. How can a app server or servlet container > > like JBoss Tomcat etc guarantee that System.exit does not shut down > > the JVM? > AFAIK the app servers have to provide a way to run with a security > manager but I don't know how many app server run it by default. > > The System.exit example is a good example that has come up a few times. > There is at least one IDE that used to run with a SM so that it could > block plugins from calling System.exit. That use case is one that > probably needs a specific API. Elasticsearch Server also blocks System.exit, so plugins or scripts running inside the query cannot shut down the server (it also blocks many other stuff for sandboxing everything). The main problem with implementing the exitVM permission is to make it work that you can still exit on your own ?? If you forbid exiting the VM, you cannot do it on your own. (cannot be done in a policy file, because the exit permission is given by default). This is by the way a good use case for the new StackWalker API!: The Elasticsearch (and Apache Lucene's Test Runner) SecurityManager do Thread.currentThread().getStackTrace() and then walk down the stack and only allow exiting if the right class/package is on the stack trace right before the System/Runtime.exit() call. E.g., I agree some improvements to SecurityManager around that would be good. It is really hard to implement that (only allow existing from a specific class/method), as you need to inspect stack, otherwise you cannot exit on your own... The code here is still known as "Uwe Schindler" algorithm in the community, originating from Apache Lucene and was just forked in Elasticsearch. They made a Maven package out of it (SecureSM is taking a list of packages that are allowed to exit the VM): Uwe From alasdair.nottingham at gmail.com Thu Apr 6 17:48:12 2017 From: alasdair.nottingham at gmail.com (Alasdair Nottingham) Date: Thu, 6 Apr 2017 13:48:12 -0400 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: Mark, I much prefer this proposal and it covers my use case which is fantastic Some comments below: > On Apr 5, 2017, at 12:15 PM, mark.reinhold at oracle.com wrote: > > Thanks to everyone for the quick feedback on this topic, and especially > to Andrew for the constructive dialogue. > > Here's a revised proposal: > > - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's > on by default in JDK 9 but off by default in JDK 10. > > This will allow launch scripts that use this option on JDK 10 to > work on JDK 9 without change, and will allow early testing of the > JDK 10 behavior on JDK 9. I think giving more time to react to the change is good, but I think this just provides more notice that dynamic attach will go away, it doesn?t ultimately provide a solution for the problems that are currently solved using dynamic attach of agents. > > - Revise the `com.sun.tools.attach` API to forbid attachment to the > current process or to an ancestor of the current process, and > define a read-only system property that allows such attachment to > be enabled via the command line. > > This will discourage the inadvertent use of libraries that, for > better or for worse, intentionally violate strong encapsulation. I think just preventing self-attach would be enough. I don?t think you need to worry about the hierarchy. If you are going to the lengths of launching new JVM?s to attach the agent I?m pretty sure that you have found out that you cannot self attach, and are therefore already in the camp of knowing you are doing something bad. > > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. > I like this idea, it solves my problem in a much simpler way than having to self attach. I don?t mind what the header is called, so if Self-Premain-Class is used I can cope with that. I?m assuming this will continue to work in Java SE 10 and only dynamic attach will be disabled in Java SE 10. > Taken together, these changes are intended to enable the continued use > of legitimate dynamically-loaded agents without change on JDK 9 and with > a small change on JDK 10. That later change will align the treatment of > such agents with the other means of breaking encapsulation (`--add-opens`, > etc.) in order to ensure integrity by default for all code. > > This proposal does not attempt to lock down platform classes as distinct > from user classes. Many agents have legitimate reasons to transform > platform classes, so an additional mechanism to protect those classes > does not appear to be worthwhile. > > Comments? > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012000.html From alan.bateman at oracle.com Thu Apr 6 18:21:35 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:35 +0000 Subject: hg: jigsaw/jake/corba: 4 new changesets Message-ID: <201704061821.v36ILZ4w016640@aojmv0008.oracle.com> Changeset: 8e9b64d90b69 Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/8e9b64d90b69 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.corba/share/classes/module-info.java Changeset: 965bbae30727 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/965bbae30727 Merge Changeset: a510b2201154 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a510b2201154 Added tag jdk-9+164 for changeset 965bbae30727 ! .hgtags Changeset: 9bc5ee131c5b Author: alanb Date: 2017-04-06 18:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9bc5ee131c5b Merge ! .hgtags ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Thu Apr 6 18:21:35 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:35 +0000 Subject: hg: jigsaw/jake: 6 new changesets Message-ID: <201704061821.v36ILZci016639@aojmv0008.oracle.com> Changeset: 66df71217ba3 Author: mchung Date: 2017-03-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/66df71217ba3 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! make/Javadoc.gmk ! make/Main.gmk Changeset: 04d60d5ae6fd Author: ihse Date: 2017-03-30 08:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/04d60d5ae6fd 8177634: Fix for 8175307 may cause linker errors on OS X 10.9 Reviewed-by: dholmes, erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 148642751a9f Author: erikj Date: 2017-03-30 10:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/148642751a9f 8177135: OpenJDK 9 freetype needs msvcr100.dll Reviewed-by: ihse, prr ! common/conf/jib-profiles.js Changeset: 7810f75d016a Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7810f75d016a Merge Changeset: 6fe9f8461672 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6fe9f8461672 Added tag jdk-9+164 for changeset 7810f75d016a ! .hgtags Changeset: 177315847c94 Author: alanb Date: 2017-04-06 18:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/177315847c94 Merge ! .hgtags ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/conf/jib-profiles.js ! make/Javadoc.gmk ! make/Main.gmk From alan.bateman at oracle.com Thu Apr 6 18:21:36 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:36 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201704061821.v36ILaMK016728@aojmv0008.oracle.com> Changeset: ee1849f16695 Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ee1849f16695 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 1a52de2da827 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1a52de2da827 Merge Changeset: b92bbd3a5613 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b92bbd3a5613 Added tag jdk-9+164 for changeset 1a52de2da827 ! .hgtags Changeset: 29a79547b48f Author: alanb Date: 2017-04-06 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/29a79547b48f Merge ! .hgtags ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java From alan.bateman at oracle.com Thu Apr 6 18:21:39 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:39 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201704061821.v36ILd2C016771@aojmv0008.oracle.com> Changeset: 8c8c38891345 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8c8c38891345 Added tag jdk-9+164 for changeset b473fab09baa ! .hgtags Changeset: 8ce75a7ba115 Author: alanb Date: 2017-04-06 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8ce75a7ba115 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 6 18:21:37 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:37 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201704061821.v36ILbXD016756@aojmv0008.oracle.com> Changeset: 086b6a500c6c Author: mchung Date: 2017-03-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/086b6a500c6c 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java Changeset: 6dc790a4e831 Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6dc790a4e831 Merge Changeset: 8ecce2375af1 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8ecce2375af1 Added tag jdk-9+164 for changeset 6dc790a4e831 ! .hgtags Changeset: 442ad4e004b9 Author: alanb Date: 2017-04-06 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/442ad4e004b9 Merge ! .hgtags ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java From alan.bateman at oracle.com Thu Apr 6 18:21:39 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:39 +0000 Subject: hg: jigsaw/jake/langtools: 14 new changesets Message-ID: <201704061821.v36ILd1A016768@aojmv0008.oracle.com> Changeset: bef1cba2d0d9 Author: ksrini Date: 2017-03-27 17:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bef1cba2d0d9 8175277: javadoc AssertionError when specified with release 8 Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/tool/modules/ReleaseOptions.java Changeset: cc3c67b12ef1 Author: jlahoda Date: 2017-03-29 10:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cc3c67b12ef1 8177311: Denied access when named module accesses unreferences package from the unnamed module Summary: Ensure access to the unnamed module is allowed if the given module reads the unnamed module. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/modules/EdgeCases.java Changeset: bb0649dbe925 Author: mchung Date: 2017-03-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bb0649dbe925 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea Contributed-by: jonathan.gibbons at oracle.com, mandy.chung at oracle.com ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java Changeset: 3b47c6cb966e Author: lancea Date: 2017-03-29 16:31 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3b47c6cb966e 8175013: Add Generated annotation Reviewed-by: darcy, alanb + src/java.compiler/share/classes/javax/annotation/processing/Generated.java Changeset: 573dfe4c63d4 Author: rfield Date: 2017-03-29 16:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/573dfe4c63d4 8177079: jshell tool: usability of /help for commands and sub-commands Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 132f24d279d1 Author: lana Date: 2017-03-30 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/132f24d279d1 Merge Changeset: 4c4738ddfbc0 Author: rfield Date: 2017-03-30 13:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4c4738ddfbc0 8177078: jshell tool: fix documentation of /help shortcuts 8177735: jshell tool: /help /help -- typo "comand" 8177308: jshell tool: documentation: multiple start-up files and predefines not documented Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties Changeset: 0f4a3fa6bac0 Author: jjg Date: 2017-03-30 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0f4a3fa6bac0 8177484: The old standard doclet should be deprecated for removal. Reviewed-by: ksrini ! make/CompileInterim.gmk ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 5df3b79e6526 Author: redestad Date: 2017-03-31 08:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5df3b79e6526 8175116: jtreg agentvms uses more virtual address space in langtool/test :tier1 runs Summary: Avoiding creation of an unnecessary read edge from jdk.compiler to a newly created unnamed module. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java Changeset: 33c818a75ec9 Author: jlahoda Date: 2017-03-31 10:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/33c818a75ec9 8177076: jshell tool: usability of completion Summary: Merging completion and documentation completion, assigning Shift-tab shortcut to fix actions. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/jdk/jshell/MergedTabShiftTabTest.java Changeset: 04d69a5db5e1 Author: ksrini Date: 2017-03-31 07:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/04d69a5db5e1 8177567: cache VisibleMemberMap Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java Changeset: c7f3df19667b Author: mcimadamore Date: 2017-04-03 12:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c7f3df19667b 8177667: Langtools ant build has issues with Windows file separators Summary: Replace complex, non-portable regex logic for generating --patch-module option with a script mapper Reviewed-by: jjg, ksrini ! make/build.properties ! make/build.xml ! make/intellij/runConfigurations/javadoc.xml ! make/intellij/runConfigurations/jshell.xml Changeset: 77a4b2e2e5be Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/77a4b2e2e5be Added tag jdk-9+164 for changeset c7f3df19667b ! .hgtags Changeset: 166097231ebe Author: alanb Date: 2017-04-06 18:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/166097231ebe Merge ! .hgtags ! make/CompileInterim.gmk ! make/build.properties ! make/build.xml ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/module-info.java ! test/jdk/jshell/CommandCompletionTest.java ! test/tools/javac/modules/EdgeCases.java From alan.bateman at oracle.com Thu Apr 6 18:21:43 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:43 +0000 Subject: hg: jigsaw/jake/hotspot: 11 new changesets Message-ID: <201704061821.v36ILigR016785@aojmv0008.oracle.com> Changeset: fa10bec35262 Author: mdoerr Date: 2017-03-20 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fa10bec35262 8176518: C2: Invalid ImplicitNullChecks with non-protected heap base Summary: Avoid generating implicit null checks if heap base is not protected Reviewed-by: zmajo ! src/share/vm/opto/lcm.cpp + test/compiler/c2/TestNPEHeapBased.java Changeset: 40ad6af5e434 Author: jwilhelm Date: 2017-03-20 23:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/40ad6af5e434 Merge Changeset: 8afdef5de101 Author: rehn Date: 2017-03-21 16:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8afdef5de101 8177092: [TESTBUG] JMX test on MinimalVM fails after fix for 8176533 Reviewed-by: dholmes, mlarsson ! test/runtime/MinimalVM/JMX.java Changeset: b163435e40b3 Author: mgerdin Date: 2017-03-22 15:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b163435e40b3 8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles Reviewed-by: kbarrett, coleenp, tschatzl ! make/test/JtregNative.gmk ! src/cpu/aarch64/vm/jniFastGetField_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp ! src/cpu/arm/vm/interp_masm_arm.cpp ! src/cpu/arm/vm/interp_masm_arm.hpp ! src/cpu/arm/vm/jniFastGetField_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.hpp ! src/cpu/arm/vm/sharedRuntime_arm.cpp ! src/cpu/arm/vm/templateInterpreterGenerator_arm.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp ! src/cpu/s390/vm/macroAssembler_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.hpp ! src/cpu/s390/vm/sharedRuntime_s390.cpp ! src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp + test/runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java + test/runtime/jni/CallWithJNIWeak/libCallWithJNIWeak.c + test/runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java + test/runtime/jni/ReturnJNIWeak/libReturnJNIWeak.c Changeset: 838393a7baa6 Author: jwilhelm Date: 2017-03-23 15:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/838393a7baa6 Merge Changeset: dabd810a9825 Author: dholmes Date: 2017-03-23 17:15 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dabd810a9825 8165358: vmassert_status is not debug-only Reviewed-by: dsamersoff, stuefe, zgu ! src/share/vm/utilities/debug.hpp Changeset: c68024d52834 Author: jwilhelm Date: 2017-03-25 00:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c68024d52834 Merge Changeset: b70c17184fdb Author: jwilhelm Date: 2017-03-30 19:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b70c17184fdb Merge Changeset: 0af429be8bba Author: neugens Date: 2017-03-29 15:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0af429be8bba 8177390: java -version does not differentiate between which port of AArch64 is used Reviewed-by: aph, dholmes ! make/lib/CompileJvm.gmk ! test/test_env.sh Changeset: e2a24f3510e9 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2a24f3510e9 Added tag jdk-9+164 for changeset 0af429be8bba ! .hgtags Changeset: 97e482e0594d Author: alanb Date: 2017-04-06 18:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/97e482e0594d Merge ! .hgtags ! make/test/JtregNative.gmk ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp From alan.bateman at oracle.com Thu Apr 6 18:21:46 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 06 Apr 2017 18:21:46 +0000 Subject: hg: jigsaw/jake/jdk: 23 new changesets Message-ID: <201704061821.v36ILmin016805@aojmv0008.oracle.com> Changeset: 6efd46c87aff Author: bpb Date: 2017-03-28 09:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6efd46c87aff 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 Summary: Enable test for macOS 10.10.5 and newer and remove from problem list Reviewed-by: alanb, amlu ! test/ProblemList.txt ! test/java/nio/channels/Selector/OutOfBand.java Changeset: c1207d6ce231 Author: darcy Date: 2017-03-28 17:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1207d6ce231 8177722: Improve grouping of jdk/internal/math tests Reviewed-by: smarks ! test/TEST.groups Changeset: 8903214706a2 Author: dfuchs Date: 2017-03-29 13:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8903214706a2 8177136: Caller sensitive method System::getLogger should specify what happens if there is no caller on the stack. Summary: IllegalCallerException (instead of undocumented NPE) is thrown if there is no caller on the stack. The specification is clarified in this respect. Reviewed-by: alanb, mchung, dholmes, bchristi ! src/java.base/share/classes/java/lang/System.java Changeset: 171e10061798 Author: mchung Date: 2017-03-29 09:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/171e10061798 8173303: Add module-subgraph images to main platform documentation Reviewed-by: alanb, chegar, erikj, ihse, lancea Contributed-by: jonathan.gibbons at oracle.com, mandy.chung at oracle.com ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java + make/src/classes/build/tools/jigsaw/javadoc-graphs.properties + make/src/classes/build/tools/taglet/ModuleGraph.java ! src/java.base/share/classes/module-info.java ! src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.instrument/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.management.agent/share/classes/module-info.java ! src/jdk.management/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.net/share/classes/module-info.java ! src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: 10e27f8fa3a1 Author: ksrini Date: 2017-03-29 10:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/10e27f8fa3a1 8174148: Typo in java.util.jar.Pack200.Unpacker.properties() method documentation 8173871: Typos in Jar Packer/Unpacker PROGRESS field documentation Reviewed-by: bpb, darcy ! src/java.base/share/classes/java/util/jar/Pack200.java Changeset: b79469412aa0 Author: weijun Date: 2017-03-30 07:29 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b79469412aa0 8177569: keytool should not warn if signature algorithm used in cacerts is weak Reviewed-by: mullan ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! test/sun/security/tools/keytool/WeakAlg.java Changeset: 5734c4a761cf Author: lana Date: 2017-03-30 17:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5734c4a761cf Merge Changeset: a1d25a8fdc98 Author: smarks Date: 2017-03-30 11:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a1d25a8fdc98 8155052: add notes and links to j.u.Observer/Observable deprecation comments Reviewed-by: chegar ! src/java.base/share/classes/java/util/Observable.java Changeset: 762c970fed4d Author: rehn Date: 2017-03-16 07:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/762c970fed4d 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool Reviewed-by: sspitsyn, dsamersoff ! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java Changeset: 13c06d444258 Author: iignatyev Date: 2017-03-15 22:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13c06d444258 8176176: fix @modules in jdk_svc tests Reviewed-by: shurailine, sspitsyn ! test/com/sun/jdi/AcceptTimeout.java ! test/com/sun/jdi/AccessSpecifierTest.java ! test/com/sun/jdi/AfterThreadDeathTest.java ! test/com/sun/jdi/AllLineLocations.java ! test/com/sun/jdi/ArrayRangeTest.java ! test/com/sun/jdi/BacktraceFieldTest.java ! test/com/sun/jdi/ClassLoaderClassesTest.java ! test/com/sun/jdi/ClassesByName.java ! test/com/sun/jdi/ClassesByName2Test.java ! test/com/sun/jdi/CompatibleConnectors.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/ConstantPoolInfo.java ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/com/sun/jdi/CountEvent.java ! test/com/sun/jdi/CountFilterTest.java ! test/com/sun/jdi/DebuggerThreadTest.java ! test/com/sun/jdi/DeleteAllBkptsTest.java ! test/com/sun/jdi/DeleteEventRequestsTest.java ! test/com/sun/jdi/EarlyReturnNegativeTest.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/EnumTest.java ! test/com/sun/jdi/EventQueueDisconnectTest.java ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/ExpiredRequestDeletionTest.java ! test/com/sun/jdi/FieldWatchpoints.java ! test/com/sun/jdi/FilterMatch.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/FinalLocalsTest.java ! test/com/sun/jdi/FinalizerTest.java ! test/com/sun/jdi/FramesTest.java ! test/com/sun/jdi/GenericsTest.java ! test/com/sun/jdi/GetLocalVariables2Test.java ! test/com/sun/jdi/GetUninitializedStringValue.java ! test/com/sun/jdi/HomeTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/InstanceFilter.java ! test/com/sun/jdi/InstancesTest.java ! test/com/sun/jdi/InterfaceMethodsTest.java ! test/com/sun/jdi/InterruptHangTest.java ! test/com/sun/jdi/InvokeHangTest.java ! test/com/sun/jdi/InvokeTest.java ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/Java_gTest.java ! test/com/sun/jdi/LambdaStepTest.java ! test/com/sun/jdi/LaunchCommandLine.java ! test/com/sun/jdi/LineNumberInfo.java ! test/com/sun/jdi/ListenAddress.java ! test/com/sun/jdi/LocalVariableEqual.java ! test/com/sun/jdi/LocationTest.java ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/MixedSuspendTest.sh ! test/com/sun/jdi/ModificationWatchpoints.java ! test/com/sun/jdi/ModulesTest.java ! test/com/sun/jdi/MonitorEventTest.java ! test/com/sun/jdi/MonitorFrameInfo.java ! test/com/sun/jdi/MultiBreakpointsTest.java ! test/com/sun/jdi/NativeInstanceFilter.java ! test/com/sun/jdi/NewInstanceTest.java ! test/com/sun/jdi/NoLaunchOptionTest.java ! test/com/sun/jdi/NoLocInfoTest.java ! test/com/sun/jdi/NullThreadGroupNameTest.java ! test/com/sun/jdi/OnThrowTest.java ! test/com/sun/jdi/OptionTest.java ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/jdi/PopAsynchronousTest.java ! test/com/sun/jdi/PopSynchronousTest.java ! test/com/sun/jdi/RedefineCrossEvent.java ! test/com/sun/jdi/RedefineCrossStart.java ! test/com/sun/jdi/ReferrersTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/RequestReflectionTest.java ! test/com/sun/jdi/ResumeOneThreadTest.java ! test/com/sun/jdi/SDENullTest.java ! test/com/sun/jdi/SimulResumerTest.java ! test/com/sun/jdi/SourceNameFilterTest.java ! test/com/sun/jdi/StepTest.java ! test/com/sun/jdi/SuspendThreadTest.java + test/com/sun/jdi/TEST.properties ! test/com/sun/jdi/TemplateTest.java ! test/com/sun/jdi/ThreadGroupTest.java ! test/com/sun/jdi/TwoThreadsTest.java ! test/com/sun/jdi/UTF8Test.java ! test/com/sun/jdi/UnpreparedByName.java ! test/com/sun/jdi/UnpreparedClasses.java ! test/com/sun/jdi/VMDeathLastTest.java ! test/com/sun/jdi/VMDeathRequestTest.java ! test/com/sun/jdi/VarargsTest.java ! test/com/sun/jdi/Vars.java ! test/com/sun/jdi/VisibleMethods.java ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java ! test/com/sun/jdi/redefine/RedefineTest.java ! test/com/sun/jdi/redefineMethod/RedefineTest.java ! test/com/sun/jdi/sde/FilterMangleTest.java ! test/com/sun/jdi/sde/MangleStepTest.java ! test/com/sun/jdi/sde/MangleTest.java ! test/com/sun/jdi/sde/SourceDebugExtensionTest.java ! test/com/sun/jdi/sde/TemperatureTableTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java ! test/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetAllVMOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java ! test/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreePhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreeSwapSpaceSize.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java ! test/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetTotalPhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/MemoryStatusOverflow.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.java + test/com/sun/management/TEST.properties ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java ! test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/management/VMOptionOpenDataTest.java ! test/com/sun/tools/attach/PermissionTest.java ! test/com/sun/tools/attach/ProviderTest.java ! test/com/sun/tools/attach/StartManagementAgent.java ! test/com/sun/tools/attach/TempDirTest.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/instrument/TestAgentWithLimitMods.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/management/CompositeData/MemoryUsageCompositeData.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/GetObjectName.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/GetPlatformManagementInterfaces.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/MXBeanException.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/ManagementFactory/PlatformMBeanServerTest.java ! test/java/lang/management/ManagementFactory/ProxyExceptions.java ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java + test/java/lang/management/ManagementFactory/TEST.properties ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh ! test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh ! test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh + test/java/lang/management/PlatformLoggingMXBean/TEST.properties ! test/java/lang/management/RuntimeMXBean/GetSystemProperties.java ! test/java/lang/management/RuntimeMXBean/PropertiesTest.java ! test/java/lang/management/RuntimeMXBean/TestInputArgument.sh ! test/java/lang/management/RuntimeMXBean/UpTime.java + test/java/lang/management/TEST.properties ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/InvalidThreadID.java ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java ! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java ! test/java/lang/management/ThreadMXBean/ThreadCounts.java ! test/java/lang/management/ThreadMXBean/ThreadCpuTime.java ! test/java/lang/management/ThreadMXBean/ThreadDaemonTest.java ! test/java/lang/management/ThreadMXBean/ThreadLists.java ! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java ! test/java/lang/management/ThreadMXBean/ThreadUserTime.java ! test/javax/management/ImplementationVersion/ImplVersionTest.java ! test/javax/management/Introspector/AnnotationSecurityTest.java ! test/javax/management/Introspector/AnnotationTest.java ! test/javax/management/Introspector/ChangingNotifsTest.java ! test/javax/management/Introspector/ClassLeakTest.java ! test/javax/management/Introspector/DuplicateGetterTest.java ! test/javax/management/Introspector/FeatureOrderTest.java ! test/javax/management/Introspector/GetMBeanInfoExceptionTest.java ! test/javax/management/Introspector/IdenticalMBeanInfoTest.java ! test/javax/management/Introspector/ImmutableNotificationInfoTest.java ! test/javax/management/Introspector/InvokeGettersTest.java ! test/javax/management/Introspector/IsMethodTest.java ! test/javax/management/Introspector/LegacyConstructorPropertiesTest.java ! test/javax/management/Introspector/NotAnMBeanTest.java ! test/javax/management/Introspector/NotCompliantCauseTest.java ! test/javax/management/Introspector/SetWrongTypeAttributeTest.java ! test/javax/management/Introspector/UnregisterMBeanExceptionTest.java ! test/javax/management/MBeanInfo/EqualExceptionTest.java ! test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java ! test/javax/management/MBeanInfo/MBeanInfoEqualsTest.java ! test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java ! test/javax/management/MBeanInfo/NullInfoArraysTest.java ! test/javax/management/MBeanInfo/SerializationTest.java ! test/javax/management/MBeanInfo/SerializationTest1.java ! test/javax/management/MBeanInfo/TooManyFooTest.java ! test/javax/management/MBeanServer/AttributeListTypeSafeTest.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java ! test/javax/management/MBeanServer/MBeanFallbackTest.java ! test/javax/management/MBeanServer/MBeanServerInvocationHandlerExceptionTest.java ! test/javax/management/MBeanServer/MBeanTest.java ! test/javax/management/MBeanServer/NewMBeanListenerTest.java ! test/javax/management/MBeanServer/NotifDeadlockTest.java ! test/javax/management/MBeanServer/PostExceptionTest.java ! test/javax/management/MBeanServer/PostRegisterDeadlockTest.java ! test/javax/management/MBeanServer/PostRegisterDeadlockTest2.java ! test/javax/management/MBeanServer/PreDeregisterDeadlockTest.java ! test/javax/management/MBeanServer/PreRegisterTest.java ! test/javax/management/MBeanServerFactory/ReleaseMBeanServerTest.java ! test/javax/management/MustBeValidMBeanInfo/MustBeValidCommand.java ! test/javax/management/ObjectInstance/MBeanInfoFailTest.java ! test/javax/management/ObjectInstance/ObjectInstanceNullTest.java ! test/javax/management/ObjectInstance/ToStringMethodTest.java ! test/javax/management/ObjectName/ApplyWildcardTest.java ! test/javax/management/ObjectName/ComparatorTest.java ! test/javax/management/ObjectName/DelegateNameWildcardNameTest.java ! test/javax/management/ObjectName/NullEmptyKeyValueTest.java ! test/javax/management/ObjectName/ObjectNameGetInstanceTest.java ! test/javax/management/ObjectName/RepositoryWildcardTest.java ! test/javax/management/ObjectName/SerialCompatTest.java ! test/javax/management/ObjectName/ValueWildcardTest.java + test/javax/management/TEST.properties ! test/javax/management/descriptor/DefaultDescriptorTest.java ! test/javax/management/descriptor/DescriptorTest.java ! test/javax/management/descriptor/EqualsHashCodeTest.java ! test/javax/management/descriptor/ImmutableArrayFieldTest.java ! test/javax/management/descriptor/ImmutableDescriptorSerialTest.java ! test/javax/management/descriptor/ImmutableDescriptorSetFieldsTest.java ! test/javax/management/descriptor/MBeanInfoInteropTest.java ! test/javax/management/descriptor/UnionTest.java ! test/javax/management/generified/GenericTest.java ! test/javax/management/generified/ListTypeCheckTest.java ! test/javax/management/loading/ArrayClassTest.java ! test/javax/management/loading/DocumentRootTest.java ! test/javax/management/loading/GetMBeansFromURLTest.java ! test/javax/management/loading/LibraryLoader/LibraryLoaderTest.java ! test/javax/management/loading/MLetCLR/MLetCommand.java ! test/javax/management/loading/MLetContentTest.java ! test/javax/management/loading/MletParserLocaleTest.java ! test/javax/management/loading/ParserInfiniteLoopTest.java ! test/javax/management/loading/SystemClassLoaderTest.java ! test/javax/management/modelmbean/AddAttributeChangeNotificationListenerTest.java ! test/javax/management/modelmbean/DescriptorSupportSerialTest.java ! test/javax/management/modelmbean/DescriptorSupportTest.java ! test/javax/management/modelmbean/DescriptorSupportXMLLocaleTest.java ! test/javax/management/modelmbean/DescriptorSupportXMLTest.java ! test/javax/management/modelmbean/ExoticTargetTypeTest.java ! test/javax/management/modelmbean/InfoSupportTest.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/modelmbean/ModelMBeanInfoSupport/GetAllDescriptorsTest.java ! test/javax/management/modelmbean/OnUnregisterTest.java ! test/javax/management/modelmbean/RequiredModelMBeanGetAttributeTest.java ! test/javax/management/modelmbean/RequiredModelMBeanMethodTest.java ! test/javax/management/modelmbean/RequiredModelMBeanSetAttributeTest.java ! test/javax/management/modelmbean/SimpleModelMBean/SimpleModelMBeanCommand.java ! test/javax/management/monitor/CounterMonitorDeadlockTest.java ! test/javax/management/monitor/CounterMonitorInitThresholdTest.java ! test/javax/management/monitor/CounterMonitorTest.java ! test/javax/management/monitor/CounterMonitorThresholdTest.java ! test/javax/management/monitor/DerivedGaugeMonitorTest.java ! test/javax/management/monitor/GaugeMonitorDeadlockTest.java ! test/javax/management/monitor/MultiMonitorTest.java ! test/javax/management/monitor/NonComparableAttributeValueTest.java ! test/javax/management/monitor/NullAttributeValueTest.java ! test/javax/management/monitor/ReflectionExceptionTest.java ! test/javax/management/monitor/RuntimeExceptionTest.java ! test/javax/management/monitor/StartStopTest.java ! test/javax/management/monitor/StringMonitorDeadlockTest.java ! test/javax/management/monitor/ThreadPoolAccTest.java ! test/javax/management/monitor/ThreadPoolTest.java ! test/javax/management/mxbean/AmbiguousConstructorTest.java ! test/javax/management/mxbean/ComparatorExceptionTest.java ! test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/GenericTypeTest.java ! test/javax/management/mxbean/InvalidMXBeanRegistrationTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MBeanOperationInfoTest.java ! test/javax/management/mxbean/MXBeanAnnotationTest.java ! test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanFlagTest.java ! test/javax/management/mxbean/MXBeanLoadingTest1.java ! test/javax/management/mxbean/MXBeanPreRegisterTest.java ! test/javax/management/mxbean/MXBeanRefTest.java ! test/javax/management/mxbean/MiscTest.java ! test/javax/management/mxbean/OperationImpactTest.java ! test/javax/management/mxbean/OverloadTest.java ! test/javax/management/mxbean/PreRegisterNameTest.java ! test/javax/management/mxbean/PropertyNamesTest.java ! test/javax/management/mxbean/SameObjectTwoNamesTest.java ! test/javax/management/mxbean/StandardMBeanOverrideTest.java ! test/javax/management/mxbean/ThreadMXBeanTest.java ! test/javax/management/mxbean/TypeNameTest.java ! test/javax/management/notification/BroadcasterSupportDeadlockTest.java ! test/javax/management/notification/FilterExceptionTest.java ! test/javax/management/notification/NotifExecutorTest.java ! test/javax/management/notification/NotifInfoTest.java ! test/javax/management/openmbean/ArrayTypeTest.java ! test/javax/management/openmbean/BadConstraintTest.java ! test/javax/management/openmbean/CompositeDataStringTest.java ! test/javax/management/openmbean/ConstraintTest.java ! test/javax/management/openmbean/EqualsTest.java ! test/javax/management/openmbean/IsValueTest.java ! test/javax/management/openmbean/NullConstructorParamsTest.java ! test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java ! test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java ! test/javax/management/openmbean/OpenTypeDescriptorTest.java ! test/javax/management/proxy/JMXProxyFallbackTest.java ! test/javax/management/proxy/JMXProxyTest.java ! test/javax/management/proxy/NotificationEmitterProxy.java ! test/javax/management/proxy/ProxyObjectMethodsTest.java ! test/javax/management/query/CustomQueryTest.java ! test/javax/management/query/InstanceOfExpTest.java ! test/javax/management/query/QueryExpStringTest.java ! test/javax/management/query/QueryMatchTest.java ! test/javax/management/query/QuerySubstringTest.java ! test/javax/management/relation/NonArrayListTest.java ! test/javax/management/relation/RelationNotificationSeqNoTest.java ! test/javax/management/relation/RelationNotificationSourceTest.java ! test/javax/management/relation/RelationTypeTest.java + test/javax/management/remote/mandatory/TEST.properties ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java ! test/javax/management/remote/mandatory/connection/CloseFailedClientTest.java ! test/javax/management/remote/mandatory/connection/CloseServerTest.java ! test/javax/management/remote/mandatory/connection/CloseUnconnectedTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java ! test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java ! test/javax/management/remote/mandatory/connection/DeadLockTest.java ! test/javax/management/remote/mandatory/connection/FailedConnectionTest.java ! test/javax/management/remote/mandatory/connection/GetConnectionTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/JMXServiceURLLocaleTest.java ! test/javax/management/remote/mandatory/connection/MultiOpenCloseTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorLogAttributesTest.java ! test/javax/management/remote/mandatory/connection/RMIExitTest.java ! test/javax/management/remote/mandatory/connection/RMISerializeTest.java ! test/javax/management/remote/mandatory/connection/ReconnectTest.java ! test/javax/management/remote/mandatory/connectorServer/ConnectorStopDeadlockTest.java ! test/javax/management/remote/mandatory/connectorServer/JNDIFailureTest.java ! test/javax/management/remote/mandatory/connectorServer/MBSFPreStartPostStartTest.java ! test/javax/management/remote/mandatory/loading/DefaultProviderTest.java ! test/javax/management/remote/mandatory/loading/DeserializeEncodedURLTest.java ! test/javax/management/remote/mandatory/loading/MethodResultTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/loading/RMIDownloadTest.java ! test/javax/management/remote/mandatory/loading/TargetMBeanTest.java ! test/javax/management/remote/mandatory/loading/UserClassLoaderTest.java ! test/javax/management/remote/mandatory/notif/AddRemoveTest.java ! test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java ! test/javax/management/remote/mandatory/notif/DiffHBTest.java ! test/javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java ! test/javax/management/remote/mandatory/notif/NotifBufferSizePropertyNameTest.java ! test/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferCreationTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/javax/management/remote/mandatory/notif/RMINotifTest.java ! test/javax/management/remote/mandatory/notif/ServerNotifs.java ! test/javax/management/remote/mandatory/notif/UnexpectedNotifTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java ! test/javax/management/remote/mandatory/threads/ExecutorShutdownTest.java ! test/javax/management/remote/mandatory/threads/ExecutorTest.java ! test/javax/management/remote/mandatory/threads/NoServerTimeoutTest.java ! test/javax/management/remote/mandatory/version/ImplVersionTest.java ! test/javax/management/security/AvoidGetMBeanInfoCallsTest.java ! test/javax/management/security/MBeanPermissionTest.java ! test/javax/management/standardmbean/DeadlockTest.java ! test/javax/management/timer/MissingNotificationTest.java ! test/javax/management/timer/StartTest.java + test/sun/jvmstat/TEST.properties ! test/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/jvmstat/monitor/VmIdentifier/VmIdentifierCreateResolve.java ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java ! test/sun/management/LazyCompositeDataTest.java ! test/sun/management/LoggingTest/LoggingWithJULTest.java ! test/sun/management/LoggingTest/LoggingWithLoggerFinderTest.java ! test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java + test/sun/management/TEST.properties ! test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpJmxRemoteDynamicPortTest.java ! test/sun/management/jdp/JdpOffTest.java ! test/sun/management/jdp/JdpSpecificAddressTest.java + test/sun/management/jdp/TEST.properties ! test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java + test/sun/management/jmxremote/TEST.properties ! test/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/management/jmxremote/startstop/JMXStatusTest.java + test/sun/tools/jcmd/TEST.properties ! test/sun/tools/jcmd/TestJcmdDefaults.java ! test/sun/tools/jcmd/TestJcmdSanity.java ! test/sun/tools/jconsole/ResourceCheckTest.java + test/sun/tools/jhsdb/TEST.properties ! test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java ! test/sun/tools/jinfo/JInfoTest.java + test/sun/tools/jinfo/TEST.properties + test/sun/tools/jmap/TEST.properties + test/sun/tools/jstack/TEST.properties + test/sun/tools/jstat/TEST.properties + test/sun/tools/jstatd/TEST.properties ! test/sun/tools/jstatd/TestJstatdDefaults.java ! test/sun/tools/jstatd/TestJstatdExternalRegistry.java ! test/sun/tools/jstatd/TestJstatdPort.java ! test/sun/tools/jstatd/TestJstatdPortAndServer.java ! test/sun/tools/jstatd/TestJstatdServer.java Changeset: 63545defbee3 Author: jwilhelm Date: 2017-03-20 23:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63545defbee3 Merge Changeset: 2d00e12c474d Author: iignatyev Date: 2017-03-22 17:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2d00e12c474d 8177374: fix module dependency declaration in jdk_svc tests Reviewed-by: mchung, sspitsyn ! test/com/sun/tools/attach/BasicTests.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java Changeset: e42aa54d7ed7 Author: jwilhelm Date: 2017-03-23 15:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e42aa54d7ed7 Merge Changeset: b45f8cb93c6f Author: jwilhelm Date: 2017-03-25 00:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b45f8cb93c6f Merge Changeset: eeffca2a1db2 Author: jwilhelm Date: 2017-03-30 19:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeffca2a1db2 Merge Changeset: b23f0d9ff042 Author: jwilhelm Date: 2017-03-30 21:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b23f0d9ff042 Merge Changeset: 184445e67dc7 Author: sherman Date: 2017-03-31 11:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/184445e67dc7 8177910: Update zlib copyright note in idk/src/java.base/share/legal/zlib.md Reviewed-by: mchung, rriggs ! src/java.base/share/legal/zlib.md Changeset: 7c72114a5558 Author: smarks Date: 2017-03-31 14:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c72114a5558 8177653: clarify restrictions on Iterator.forEachRemaining Reviewed-by: martin ! src/java.base/share/classes/java/util/Iterator.java Changeset: f2612af45b7a Author: amlu Date: 2017-04-01 10:19 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f2612af45b7a 8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.groups Reviewed-by: sspitsyn, weijun ! test/ProblemList.txt ! test/TEST.groups Changeset: 6dea581453d7 Author: dfuchs Date: 2017-04-03 12:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6dea581453d7 8177835: System.LoggerFinder#getLogger or getLocalizedLogger does not throw NPE Reviewed-by: rriggs, mchung ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java + test/java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java Changeset: 645c0d3e3977 Author: lana Date: 2017-04-06 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/645c0d3e3977 Added tag jdk-9+164 for changeset 6dea581453d7 ! .hgtags Changeset: a72a9977f1b1 Author: alanb Date: 2017-04-06 18:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a72a9977f1b1 Merge ! .hgtags ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/jar/Pack200.java ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java ! src/java.base/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.instrument/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java ! test/ProblemList.txt ! test/TEST.groups ! test/com/sun/jdi/ConstantPoolInfoGC.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/InstanceFilter.java ! test/com/sun/jdi/InterruptHangTest.java ! test/com/sun/jdi/ModulesTest.java ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java ! test/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetAllVMOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java ! test/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreePhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/GetFreeSwapSpaceSize.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java ! test/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java ! test/com/sun/management/OperatingSystemMXBean/GetTotalPhysicalMemorySize.java ! test/com/sun/management/OperatingSystemMXBean/MemoryStatusOverflow.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.java ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java ! test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java ! test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/tools/attach/BasicTests.java ! test/com/sun/tools/attach/PermissionTest.java ! test/com/sun/tools/attach/ProviderTest.java ! test/com/sun/tools/attach/StartManagementAgent.java ! test/com/sun/tools/attach/TempDirTest.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ProxyExceptions.java ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java ! test/javax/management/ImplementationVersion/ImplVersionTest.java ! test/javax/management/Introspector/ClassLeakTest.java ! test/javax/management/loading/ArrayClassTest.java ! test/javax/management/monitor/MultiMonitorTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/ThreadMXBeanTest.java ! test/javax/management/remote/mandatory/loading/MethodResultTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java ! test/javax/management/remote/mandatory/version/ImplVersionTest.java ! test/javax/management/timer/MissingNotificationTest.java ! test/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/jvmstat/monitor/VmIdentifier/VmIdentifierCreateResolve.java ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java ! test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpOffTest.java ! test/sun/management/jdp/JdpSpecificAddressTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jstatd/TestJstatdExternalRegistry.java Changeset: 9c108a0f7bed Author: alanb Date: 2017-04-06 19:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c108a0f7bed java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java failing ! test/java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java From brianf at infinity.nu Thu Apr 6 20:07:06 2017 From: brianf at infinity.nu (Brian Fox) Date: Thu, 6 Apr 2017 22:07:06 +0200 Subject: Build tools can help, if you let us Message-ID: I replied on the expert list but it bounced off the moderation. Since this is a topic that affects everyone, I'm republishing my thoughts (only) here: ----- Our users are your users and therefore our interests should be absolutely aligned. Our users won't tolerate the build tool doing something completely stupid. The ability for build tools to adequately support the jigsaw efforts will be key to driving adoption, so lets take a step back and analyze the situation. It's hopefully not controversial and we should be able to agree that in an ideal world, filename is not the best default module name...however for a legacy jar without any other mechanism, you feel there's there's no other choice. In other words, there's no metadata that can be convincingly used to indicate the author's intended module name. We disagree on the priority of a "beautiful" name vs a properly name spaced and unique one. You prefer the former, I prefer the later (although generally I am a neat-nick on naming, it's just a case of priority for me in this case). Fine, set that aside for now. The guidance in your last proposal was to block publishing of libraries that depend upon automodules. This is largely impractical in the real world, but lets just assume there's a way to dis-incent library creators from depending upon an automodule. The problem with this is that no library creator can ever fully modularize until ALL OF his/her dependencies have also done so. With an ecosystem that has transitive dependencies sometimes dozens to hundreds of layers deep and with some of those very deep dependencies quite stable and infrequently updated, this will take an eternity before the ecosystem can get over this hump. *The build tools can help this migration from the old world to the new one, but you must let us help.* The vision that I had behind the Module Name was simply that we could make it easy for module authors starting nearly immediately to choose their module name. (There is disagreement within Maven committers over defaulting this, so I seem to be in the minority of this and I think you don't have to be afraid because of that.) We can make choosing and declaring a name easy, maybe even required very soon for library authors. That means that we can start to build up the very metadata that is missing and forcing you to lean only on filename as the default. We can do so starting now, and by the time jigsaw starts to hit critical mass, there will hopefully be very few important libraries that aren't already properly named _by their authors_ as you intend. The bar to picking a good name is clearly much lower than fully modularizing...especially if you are barred or shamed into doing so before all your dependencies have. If you both require that someone is fully ready to modularize their own library (and their users are equally ready and willing to upgrade to Java9) and after their dependencies have gone first before you let someone declare their chosen name in a stable way... well you're going to be waiting a long time. Maybe forever. On the contrary, if people start declaring their Module-Name now, and the rule against automodule dependencies is redefined such that it's ok to lean on something with a Module-Name, it becomes very easy and very quick for the ecosystem to get to a sane building point for full modularization. Without the Module-Name metadata or some equivalent, you are effectively barring all the build systems from helping with the conversion to achieve the very goal of this entire process. --Brian Fox From jason at tedor.me Thu Apr 6 20:26:20 2017 From: jason at tedor.me (Jason Tedor) Date: Thu, 06 Apr 2017 20:26:20 +0000 Subject: SecurityManager environments In-Reply-To: <06db01d2aef7$70554fc0$50ffef40$@apache.org> References: <06ac01d2aee1$b5abde60$21039b20$@apache.org> <1143145437-22252@kerio.abacus.ch> <06db01d2aef7$70554fc0$50ffef40$@apache.org> Message-ID: This is correct, thank you for pointing it Uwe, but actually Reto's example will fail before the setAccessible call because we do not even allow accessDeclaredMembers (again, except for Lucene, for the RAM usage estimator). :) On Thu, Apr 6, 2017 at 2:32 PM Uwe Schindler wrote: Hi, Elasticsearch does not allow setAccessible() anywhere in its code (by security policy), except some places in trusted libraries like Apache Lucene for mmap unmapping support (but those must use doPrivileged for that), but plugins and Elasticsearch?s core cannot call setAccessible. See also Dalibor Topic?s post with the paper about SecurityManager usage, if you allow ?suppressAccessChecks? permission to code you?re f*ked up. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From: Reto Merz [mailto:reto.merz at abacus.ch] Sent: Thursday, April 6, 2017 6:53 PM To: Uwe Schindler ; 'Alan Bateman' < Alan.Bateman at oracle.com> Cc: jigsaw-dev at openjdk.java.net Subject: Re: SecurityManager environments We use the same approach like Elasticsearch (walk through stack trace and check caller). Note that this does not work in any case. For example this will bypass checkExit, sure, in Java 9 this would also need --add-opens to make reflection work: Method halt0 = Class.forName("java.lang.Shutdown").getDeclaredMethod("halt0", int.class); halt0.setAccessible(true); halt0.invoke(halt0, 0); But we can life with that because in our case we just want to find erroneous code. It is impossible to protect a JVM from malicious code (which is executed within the JVM) anyway. Regards Reto Von: Uwe Schindler > An: 'Alan Bateman' >, 'Reto Merz' > Kopie: > Gesendet: 06.04.2017 16:25 Betreff: RE: SecurityManager environments Hi, > > >> To be honest, we don't see a lot of security manager > > >> usage on the server side these days. > > > > I'm really surprised about that. How can a app server or servlet container > > like JBoss Tomcat etc guarantee that System.exit does not shut down > > the JVM? > AFAIK the app servers have to provide a way to run with a security > manager but I don't know how many app server run it by default. > > The System.exit example is a good example that has come up a few times. > There is at least one IDE that used to run with a SM so that it could > block plugins from calling System.exit. That use case is one that > probably needs a specific API. Elasticsearch Server also blocks System.exit, so plugins or scripts running inside the query cannot shut down the server (it also blocks many other stuff for sandboxing everything). The main problem with implementing the exitVM permission is to make it work that you can still exit on your own ?? If you forbid exiting the VM, you cannot do it on your own. (cannot be done in a policy file, because the exit permission is given by default). This is by the way a good use case for the new StackWalker API!: The Elasticsearch (and Apache Lucene's Test Runner) SecurityManager do Thread.currentThread().getStackTrace() and then walk down the stack and only allow exiting if the right class/package is on the stack trace right before the System/Runtime.exit() call. E.g., < https://github.com/elastic/securesm/blob/master/src/main/java/org/elasticsearch/SecureSM.java#L199-L249 > < https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/bootstrap/Security.java#L119 > I agree some improvements to SecurityManager around that would be good. It is really hard to implement that (only allow existing from a specific class/method), as you need to inspect stack, otherwise you cannot exit on your own... The code here is still known as "Uwe Schindler" algorithm in the community, originating from Apache Lucene and was just forked in Elasticsearch. They made a Maven package out of it (SecureSM is taking a list of packages that are allowed to exit the VM): < http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.elasticsearch%22%20AND%20a%3A%22securesm%22 > Uwe From blackdrag at gmx.org Thu Apr 6 23:09:57 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 7 Apr 2017 01:09:57 +0200 Subject: feedback on --permit-illegal-access Message-ID: <58E6CAC5.2060001@gmx.org> Hi, so today I found finally _JAVA_OPTIONS to get our gradle build running and of course I used --permit-illegal-access and I thought I give some feedback here. Running a clean test on our build will result in 44531 warning messages. Of which 6394 are unique. of course some of those warnings are actually from gradle and some are from xstream, but that makes maybe 21 less. Why do we have such a huge amount of warnings? That is because of the way we are building our meta classes, which we still have to change and use JDK9 special code (something we tried to avoid) bye Jochen From stephen.felts at oracle.com Thu Apr 6 23:34:09 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 6 Apr 2017 16:34:09 -0700 (PDT) Subject: feedback on --permit-illegal-access In-Reply-To: <58E6CAC5.2060001@gmx.org> References: <58E6CAC5.2060001@gmx.org> Message-ID: <3a743951-990e-457b-91fe-6612aac8dcb5@default> I have been using _JAVA_OPTIONS to get gradle working for over a year. I recently ran a build with --permit-illegal-access turned on (and --add-options taken out) and filed/updated bugs for several third-party jar files. There are problems with ant, xstream, simplestub, javassist, jmockit, jboss classfile, weld, mockit is fixed in 2.x, apache felix, eclipselink. I updated https://github.com/gradle/gradle/issues/1461#issuecomment-292343220 with more information about my use of a gradle wrapper to do this. -----Original Message----- From: Jochen Theodorou [mailto:blackdrag at gmx.org] Sent: Thursday, April 6, 2017 7:10 PM To: jigsaw-dev at openjdk.java.net Subject: feedback on --permit-illegal-access Hi, so today I found finally _JAVA_OPTIONS to get our gradle build running and of course I used --permit-illegal-access and I thought I give some feedback here. Running a clean test on our build will result in 44531 warning messages. Of which 6394 are unique. of course some of those warnings are actually from gradle and some are from xstream, but that makes maybe 21 less. Why do we have such a huge amount of warnings? That is because of the way we are building our meta classes, which we still have to change and use JDK9 special code (something we tried to avoid) bye Jochen From mandy.chung at oracle.com Fri Apr 7 00:28:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 6 Apr 2017 17:28:10 -0700 Subject: Review Request: JDK-8178286 Missing @moduleGraph in javadoc Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8178286/webrev.00/index.html This adds @moduleGraph in a few more modules that will be included in unified docs bundle. Mandy From stuart.monteith at linaro.org Wed Apr 5 08:37:32 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 5 Apr 2017 09:37:32 +0100 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <921dba93-4497-55b4-3ac4-dd3c6c559deb@redhat.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> <20170404093557.376393610@eggemoggin.niobe.net> <921dba93-4497-55b4-3ac4-dd3c6c559deb@redhat.com> Message-ID: It is historical revisionism. AArch32 was introduced with ARMv8, before there was no need to distinguish between 32-bit and 64-bit execution states. If people are selecting, say, JNI libraries, based on os.arch, then there is every reason to be consistent. On 4 April 2017 at 17:39, Andrew Haley wrote: > On 04/04/17 17:35, mark.reinhold at oracle.com wrote: >> This does raise another question, though: Should we use "aarch32" >> instead of "arm32" for the 32-bit ARM architecture? > > Probably not. I believe that "aarch32" is historical revisionism > coming from ARM: it didn't exist as a name before AArch64 came out. > AFAICR... > > Andrew. From igor.veresov at oracle.com Thu Apr 6 22:40:27 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 6 Apr 2017 15:40:27 -0700 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: <1B8A9416-513D-4038-9F2F-EACE52B6A803@oracle.com> Hi Alan, The changes to jdk.internal.vm.compiler will need to go to https://github.com/graalvm/graal-core as well. For jdk10 we?re not doing two-way merges when we pull a fresh version of graal. For jdk9 it?s ok because we?re not going to refresh Graal there. Please coordinate with the Labs. CCing Doug Simon. igor > On Apr 4, 2017, at 9:28 AM, Alan Bateman wrote: > > As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. > > Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. > > We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. > > There are a number of smaller changes, summarized in JDK-8177530 [2]. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > > The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. > > The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. > > -Alan > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames > [2] https://bugs.openjdk.java.net/browse/JDK-8177530 > > > From lance.andersen at oracle.com Fri Apr 7 00:53:40 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 6 Apr 2017 20:53:40 -0400 Subject: Review Request: JDK-8178286 Missing @moduleGraph in javadoc In-Reply-To: References: Message-ID: <8AA54F63-BADE-447E-9473-86E521548DCC@oracle.com> +1 > On Apr 6, 2017, at 8:28 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8178286/webrev.00/index.html > > This adds @moduleGraph in a few more modules that will be included > in unified docs bundle. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From rcmuir at gmail.com Fri Apr 7 02:54:08 2017 From: rcmuir at gmail.com (Robert Muir) Date: Thu, 6 Apr 2017 22:54:08 -0400 Subject: SecurityManager environments In-Reply-To: <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> References: <883259944-21059@kerio.abacus.ch> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> Message-ID: > > As regards the security manager then it's hard to see how it fits into the > discussion. To be honest, we don't see a lot of security manager usage on > the server side these days. I look at a lot of bug reports and error logs > that include the command line and I don't see -Djava.security.manager very > often. Not to be negative nancy, but that's because SecurityManager is totally unfriendly for server-side usage, as others have pointed out in this thread. To me, it always seemed geared at a desktop/applet use-case. On the other hand for a server (e.g. long-lived daemon-process), its basically useless to set -Djava.security.manager, you get almost zero protection, because of the nature of the beast. I think its generally accepted that such use-cases require a lot of privileges up-front initially (e.g. bind to network ports and so on), then they drop them. This is pretty common in other programming languages, java just screws it up, its really hard to do such a thing with securitymanager out of box without writing tons of custom code. I won't even mention the low level nuances such as the the fact the default security policy shipped with java allows tons of bogus crap like binding to network ports, Thread.stop, etc :) The second problem is that so many common java libraries don't care about this stuff and just call internal apis and do all kinds of bogus crap (e.g. setAccessible) without any care to the world. They are doing this cowboy-style so of course such usages are generally not contained/well-protected, they probably dont even know how doPrivileged() works at all. Because of these problems, if you are a server-side app, even if you understand this stuff and want to do the right thing, its really hard to avoid simply granting all kinds of horrible permissions globally to all code. In my experience the worst problems are the internal api usage issues, so it would be nice to "give jigsaw a chance" to see if it makes the situation better. SecurityManager is really great if you want to prevent common security issues such as directory traversal, but its too hard for a server side app right now. From Alan.Bateman at oracle.com Fri Apr 7 07:11:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Apr 2017 08:11:11 +0100 Subject: feedback on --permit-illegal-access In-Reply-To: <58E6CAC5.2060001@gmx.org> References: <58E6CAC5.2060001@gmx.org> Message-ID: <2702ecca-dbae-41fd-fe2e-80751944c432@oracle.com> On 07/04/2017 00:09, Jochen Theodorou wrote: > Hi, > > so today I found finally _JAVA_OPTIONS to get our gradle build running > and of course I used --permit-illegal-access and I thought I give some > feedback here. > > Running a clean test on our build will result in 44531 warning > messages. Of which 6394 are unique. of course some of those warnings > are actually from gradle and some are from xstream, but that makes > maybe 21 less. > > Why do we have such a huge amount of warnings? That is because of the > way we are building our meta classes, which we still have to change > and use JDK9 special code (something we tried to avoid) The implementation makes a best effort to avoid emitting duplicate warnings. Are these 44531 warnings coming from one run of the VM or is this the total from many `java` commands run in the build? Another possibility is code generation. The filtering of duplicates is based on the perpetrator's call stack and the victim. If Groovy is generating a lot of classes and the code is say using a shared utility class to hack in then these usages would not be unique. Running with -Dsun.reflect.debugModuleAccessChecks=access will give you a full stack trace at each warning and should help debug this. -Alan From doug.simon at oracle.com Fri Apr 7 08:06:06 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 7 Apr 2017 10:06:06 +0200 Subject: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <1B8A9416-513D-4038-9F2F-EACE52B6A803@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> <1B8A9416-513D-4038-9F2F-EACE52B6A803@oracle.com> Message-ID: <5D747D04-9D67-42BB-97CB-3D34F2370C49@oracle.com> In light of https://bugs.openjdk.java.net/browse/JDK-8177845, I think it's fine to apply this webrev as is (wrt JVMCI/Graal changes anyway). I'll then adopt the changes into Graal and will rebase my 8177845 on them. -Doug > On 7 Apr 2017, at 00:40, Igor Veresov wrote: > > Hi Alan, > > The changes to jdk.internal.vm.compiler will need to go to https://github.com/graalvm/graal-core as well. For jdk10 we?re not doing two-way merges when we pull a fresh version of graal. For jdk9 it?s ok because we?re not going to refresh Graal there. Please coordinate with the Labs. > > CCing Doug Simon. > > igor > > >> On Apr 4, 2017, at 9:28 AM, Alan Bateman wrote: >> >> As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. >> >> Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. >> >> We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. >> >> There are a number of smaller changes, summarized in JDK-8177530 [2]. >> >> The webrev with the changes is here: >> http://cr.openjdk.java.net/~alanb/8177530/1 >> >> The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. >> >> The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. >> >> -Alan >> >> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames >> [2] https://bugs.openjdk.java.net/browse/JDK-8177530 >> >> >> > From adinn at redhat.com Fri Apr 7 09:47:40 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Apr 2017 10:47:40 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: On 06/04/17 18:48, Alasdair Nottingham wrote: > I think giving more time to react to the change is good, but I think this just > provides more notice that dynamic attach will go away, it doesn?t ultimately > provide a solution for the problems that are currently solved using dynamic > attach of agents. I agree that it provides no such solution. However, I also agree with John Rose's observation (which may have sailed by you unawares in the wide ocean this thread has come to occupy) that in the long term there probably is no such solution. Eventually, we (yes, Red Hat hope to be involved in this work as much as Oracle and, no doubt, the other OpenJDK contributors) -- we hope to make the JVM smart enough to profit from certain guarantees of invariance in the code base and Jigsaw is one move towards that goal. At some point that is going inevitably going to mean choosing between the flexibility offered by transformations effected by dynamically loaded agents or the performance benefits offered by hard restrictions on such a flexible runtime. Java -- specifically the JVM -- does an amazing job of coping with dynamic changes to the code base (not just agents but also lazy loading and other dynamic reconfigurations to accommodate dynamic code usage) and that is a great part of its magic. However, Arthur C Clarke got it right -- to those in the know the magic is actually just a very advanced technology. Advancing it further is bound to require trade-offs and compromises where you can't have one without losing the other (whatever Frank Sinatra says). > I think just preventing self-attach would be enough. I don?t think you need > to worry about the hierarchy. If you are going to the lengths of launching new > JVM?s to attach the agent I?m pretty sure that you have found out that you > cannot self attach, and are therefore already in the camp of knowing you are > doing something bad. This is a fair point. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From blackdrag at gmx.org Fri Apr 7 10:15:06 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 7 Apr 2017 12:15:06 +0200 Subject: feedback on --permit-illegal-access In-Reply-To: <2702ecca-dbae-41fd-fe2e-80751944c432@oracle.com> References: <58E6CAC5.2060001@gmx.org> <2702ecca-dbae-41fd-fe2e-80751944c432@oracle.com> Message-ID: On 07.04.2017 09:11, Alan Bateman wrote: > On 07/04/2017 00:09, Jochen Theodorou wrote: > >> Hi, >> >> so today I found finally _JAVA_OPTIONS to get our gradle build running >> and of course I used --permit-illegal-access and I thought I give some >> feedback here. >> >> Running a clean test on our build will result in 44531 warning >> messages. Of which 6394 are unique. of course some of those warnings >> are actually from gradle and some are from xstream, but that makes >> maybe 21 less. >> >> Why do we have such a huge amount of warnings? That is because of the >> way we are building our meta classes, which we still have to change >> and use JDK9 special code (something we tried to avoid) > > The implementation makes a best effort to avoid emitting duplicate > warnings. Are these 44531 warnings coming from one run of the VM or is > this the total from many `java` commands run in the build? Another > possibility is code generation. The filtering of duplicates is based on > the perpetrator's call stack and the victim. If Groovy is generating a > lot of classes and the code is say using a shared utility class to hack > in then these usages would not be unique. both I guess. Many of our tests are in script form, which means they are runtime compiled and executed. The tests are executed in parallel, I guess on my computer it was around 8 parallel running JVMs. Most messages are reported for the same class though, because that is kind of our base class for the meta class initialization process. > Running with -Dsun.reflect.debugModuleAccessChecks=access will give you > a full stack trace at each warning and should help debug this. yes, will check that soon bye Jochen From alan.bateman at oracle.com Fri Apr 7 10:28:37 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:37 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201704071028.v37ASbGR021598@aojmv0008.oracle.com> Changeset: 554196039897 Author: alanb Date: 2017-04-07 08:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/554196039897 8177530: Module system implementation refresh (4/2017) Reviewed-by: mchung ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! test/TEST.ROOT ! test/javax/xml/jaxp/module/ServiceProviderTest/DefaultFactoryWrapperTest.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/unnamed/Main.java Changeset: ed538fa31edb Author: alanb Date: 2017-04-07 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ed538fa31edb Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java From alan.bateman at oracle.com Fri Apr 7 10:28:36 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:36 +0000 Subject: hg: jigsaw/jake: 5 new changesets Message-ID: <201704071028.v37ASaJF021579@aojmv0008.oracle.com> Changeset: 6fafcd0896fc Author: ihse Date: 2017-04-04 10:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6fafcd0896fc 8177955: Add testing documentation Reviewed-by: erikj + common/doc/testing.html + common/doc/testing.md ! make/RunTests.gmk ! make/UpdateBuildDocs.gmk Changeset: cfc382b84971 Author: lana Date: 2017-04-06 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cfc382b84971 Merge Changeset: 02653e27987c Author: alanb Date: 2017-04-07 08:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/02653e27987c 8177530: Module system implementation refresh (4/2017) Reviewed-by: mchung ! common/conf/jib-profiles.js Changeset: aff4f339acd4 Author: alanb Date: 2017-04-07 09:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/aff4f339acd4 Merge Changeset: 4749335f788f Author: alanb Date: 2017-04-07 11:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4749335f788f Merge ! common/conf/jib-profiles.js From alan.bateman at oracle.com Fri Apr 7 10:28:38 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:38 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201704071028.v37AScgM021674@aojmv0008.oracle.com> Changeset: e4cd98db3249 Author: alanb Date: 2017-04-07 08:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e4cd98db3249 8177530: Module system implementation refresh (4/2017) Reviewed-by: mchung ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/addressing/EPRSDDocumentFilter.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java Changeset: af75b2041f87 Author: alanb Date: 2017-04-07 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/af75b2041f87 Merge From alan.bateman at oracle.com Fri Apr 7 10:28:41 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:41 +0000 Subject: hg: jigsaw/jake/nashorn: 4 new changesets Message-ID: <201704071028.v37ASfEj021742@aojmv0008.oracle.com> Changeset: 8bf1dab35084 Author: mchung Date: 2017-04-06 18:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8bf1dab35084 8178286: Missing @moduleGraph in javadoc Reviewed-by: lancea ! src/jdk.dynalink/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: 48d8835e3aaa Author: alanb Date: 2017-04-07 08:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/48d8835e3aaa 8177530: Module system implementation refresh (4/2017) Reviewed-by: mchung ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/scripts/ModuleGraphManipulator.java ! test/TEST.ROOT ! test/src/jdk/nashorn/test/models/Reflector.java Changeset: e36e62d3ea53 Author: alanb Date: 2017-04-07 09:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e36e62d3ea53 Merge Changeset: b3ea15f8d67d Author: alanb Date: 2017-04-07 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b3ea15f8d67d Merge ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/scripts/ModuleGraphManipulator.java ! src/jdk.scripting.nashorn/share/classes/module-info.java From alan.bateman at oracle.com Fri Apr 7 10:28:41 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:41 +0000 Subject: hg: jigsaw/jake/langtools: 13 new changesets Message-ID: <201704071028.v37ASf8l021739@aojmv0008.oracle.com> Changeset: f08f6a2f834c Author: ksrini Date: 2017-04-04 11:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f08f6a2f834c 8176901: Internal error running javadoc over jdk internal classes Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/JavaScriptScanner.java + test/jdk/javadoc/doclet/testBadHtml/TestBadHtml.java + test/jdk/javadoc/doclet/testBadHtml/pkg1/A.java Changeset: 17bb6279f8cb Author: jjg Date: 2017-04-04 14:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17bb6279f8cb 8177562: Small updates to module summary page Reviewed-by: bpatel, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/jdk/javadoc/doclet/testModules/TestModules.java Changeset: 2e47daa5c52b Author: bpatel Date: 2017-04-04 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2e47daa5c52b 8177417: Constructor Summary readability problems in jdk9 javadoc Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/jdk/javadoc/doclet/testMemberSummary/pkg/PrivateParent.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java Changeset: 838ccb5763e1 Author: vromero Date: 2017-04-04 15:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/838ccb5763e1 8177332: The presence of a file with a Japanese ShiftJIS name can cause javac to fail Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java Changeset: 0e63023ff978 Author: bpatel Date: 2017-04-04 23:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0e63023ff978 8175218: The fix for JDK-8141492 broke formatting of some javadoc documentation. 8178078: jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java failed due to some subtests failed 8178079: jdk/javadoc/doclet/testModules/TestModules.java failed due to some subtests failed Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java Changeset: 3a05346a30cd Author: sadayapalam Date: 2017-04-05 14:34 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3a05346a30cd 8176572: Javac does not enforce module name restrictions Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/modules/PoorChoiceForModuleNameTest.java Changeset: 64080a53e65c Author: jlahoda Date: 2017-04-06 11:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/64080a53e65c 8178013: Finetuning of merged tab and shift tab completion Summary: Fixing mistakes in localization bundle, fixing completion after /help set. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/CommandCompletionTest.java Changeset: bd530c55e62c Author: jlahoda Date: 2017-04-06 16:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bd530c55e62c 8178077: jshell tool: crash on ctrl-up or ctrl-down Summary: Adding a test for EditingHistory. Reviewed-by: rfield + test/jdk/jshell/HistoryUITest.java ! test/jdk/jshell/MergedTabShiftTabTest.java + test/jdk/jshell/UITesting.java Changeset: b873436b362b Author: mcimadamore Date: 2017-04-06 17:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b873436b362b 8177933: Stackoverflow during compilation, starting jdk-9+163 Summary: Avoid extra method call in Attr.attribTree Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/speculative/T8177933.java Changeset: 82097900b7be Author: lana Date: 2017-04-06 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/82097900b7be Merge Changeset: 4012b3f11f0d Author: alanb Date: 2017-04-07 08:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4012b3f11f0d 8177530: Module system implementation refresh (4/2017) Reviewed-by: jjg Contributed-by: alan.bateman at oracle.com, jan.lahoda at oracle.com ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java ! test/TEST.ROOT ! test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/jdk/javadoc/tool/CheckResourceKeys.java ! test/jdk/jshell/KullaTesting.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/T6406771.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples/NoJavaLang.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/IncubatingTest.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/warnings/VerifyLintDescriptions.java ! test/tools/javadoc/CheckResourceKeys.java Changeset: a3a30789ab61 Author: alanb Date: 2017-04-07 10:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a3a30789ab61 Merge Changeset: ff80ebf4ace6 Author: alanb Date: 2017-04-07 11:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ff80ebf4ace6 Merge ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/TEST.ROOT ! test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/javadoc/tool/CheckResourceKeys.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/KullaTesting.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/T6406771.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/warnings/VerifyLintDescriptions.java ! test/tools/javadoc/CheckResourceKeys.java From alan.bateman at oracle.com Fri Apr 7 10:28:43 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:43 +0000 Subject: hg: jigsaw/jake/hotspot: 7 new changesets Message-ID: <201704071028.v37AShj4021748@aojmv0008.oracle.com> Changeset: 7587882381ad Author: iveresov Date: 2017-04-03 12:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7587882381ad 8177856: [AOT] EliminateRedundantInitializationPhase is not working Summary: Looks for constants of a correct type Reviewed-by: kvn ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/aot/EliminateRedundantInitializationPhase.java Changeset: 2eef1000e07f Author: dnsimon Date: 2017-04-03 14:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2eef1000e07f 8177673: [JVMCI] missing checks in HotSpotMemoryAccessProviderImpl can cause VM assertions to fail Reviewed-by: never, iveresov ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderData.java ! test/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java Changeset: 28e7bb59323e Author: thartmann Date: 2017-04-06 08:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/28e7bb59323e 8178033: C1 crashes with -XX:UseAVX = 3: "not a mov [reg+offs], reg instruction" Summary: Skip the EVEX prefix such that the instruction address points to the prefixed opcode. Reviewed-by: kvn, mcberg ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp Changeset: 83f1f2fad2a5 Author: lana Date: 2017-04-06 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83f1f2fad2a5 Merge Changeset: afedee84773e Author: alanb Date: 2017-04-07 08:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/afedee84773e 8177530: Module system implementation refresh (4/2017) Reviewed-by: lfoltan, sspitsyn Contributed-by: alan.bateman at oracle.com, harold.seigel at oracle.com, mandy.chung at oracle.com ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/ModuleAPI.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLRModule.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! test/TEST.ROOT ! test/compiler/jvmci/common/CTVMUtilities.java ! test/runtime/classFileParserBug/fakeMethodAccessor.jasm ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/modules/AccModuleTest.java ! test/runtime/modules/AccessCheck/AccessExportTwice.java ! test/runtime/modules/AccessCheck/AccessReadTwice.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/p1/c1ReadEdge.java ! test/runtime/modules/AccessCheck/p1/c1ReadEdgeDiffLoader.java ! test/runtime/modules/AccessCheck/p3/c3ReadEdge.jcod ! test/runtime/modules/AccessCheck/p3/c3ReadEdgeDiffLoader.jcod ! test/runtime/modules/AccessCheck/p4/c4.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckJavaBase.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/CCE_module_msg.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExports.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/JVMGetModuleByPkgName.java ! test/runtime/modules/LoadUnloadModuleStress.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/Main.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java ! test/runtime/modules/getModuleJNI/GetModule.java + test/runtime/modules/java.base/java/lang/ModuleHelper.java - test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java ! test/serviceability/jdwp/AllModulesCommandTestDebuggee.java ! test/serviceability/jvmti/AddModuleExportsAndOpens/MyPackage/AddModuleExportsAndOpensTest.java ! test/serviceability/jvmti/AddModuleExportsAndOpens/libAddModuleExportsAndOpensTest.c ! test/serviceability/jvmti/AddModuleReads/MyPackage/AddModuleReadsTest.java ! test/serviceability/jvmti/AddModuleReads/libAddModuleReadsTest.c ! test/serviceability/jvmti/AddModuleUsesAndProvides/MyPackage/AddModuleUsesAndProvidesTest.java ! test/serviceability/jvmti/AddModuleUsesAndProvides/libAddModuleUsesAndProvidesTest.c ! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java ! test/serviceability/jvmti/GetModulesInfo/libJvmtiGetAllModulesTest.c ! test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c Changeset: 71330a0c7294 Author: alanb Date: 2017-04-07 10:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/71330a0c7294 Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLRModule.java - test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java Changeset: 3ef5cda929ab Author: alanb Date: 2017-04-07 11:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3ef5cda929ab Merge ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! test/TEST.ROOT ! test/compiler/jvmci/common/CTVMUtilities.java ! test/runtime/classFileParserBug/fakeMethodAccessor.jasm ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/modules/AccModuleTest.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExports.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/LoadUnloadModuleStress.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/Main.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java ! test/runtime/modules/getModuleJNI/GetModule.java ! test/runtime/modules/java.base/java/lang/ModuleHelper.java ! test/serviceability/jdwp/AllModulesCommandTestDebuggee.java ! test/serviceability/jvmti/AddModuleExportsAndOpens/MyPackage/AddModuleExportsAndOpensTest.java ! test/serviceability/jvmti/AddModuleExportsAndOpens/libAddModuleExportsAndOpensTest.c ! test/serviceability/jvmti/AddModuleReads/MyPackage/AddModuleReadsTest.java ! test/serviceability/jvmti/AddModuleReads/libAddModuleReadsTest.c ! test/serviceability/jvmti/AddModuleUsesAndProvides/MyPackage/AddModuleUsesAndProvidesTest.java ! test/serviceability/jvmti/AddModuleUsesAndProvides/libAddModuleUsesAndProvidesTest.c ! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java ! test/serviceability/jvmti/GetModulesInfo/libJvmtiGetAllModulesTest.c ! test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c From alan.bateman at oracle.com Fri Apr 7 10:28:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Apr 2017 10:28:48 +0000 Subject: hg: jigsaw/jake/jdk: 21 new changesets Message-ID: <201704071028.v37ASoVE021790@aojmv0008.oracle.com> Changeset: e9325773dd96 Author: bpb Date: 2017-04-03 16:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e9325773dd96 8177526: BufferedReader readLine() javadoc does not match the implementation regarding EOF Summary: Improve the verbiage of the method and return value descriptions Reviewed-by: lancea, smarks ! src/java.base/share/classes/java/io/BufferedReader.java Changeset: eadd7f013eb9 Author: iignatyev Date: 2017-04-03 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eadd7f013eb9 8177507: line number sensitive tests for jdi should be unified Reviewed-by: dholmes, mseledtsov, sspitsyn ! test/com/sun/jdi/ArgumentValuesTest.java ! test/com/sun/jdi/BreakpointTest.java ! test/com/sun/jdi/FetchLocals.java ! test/com/sun/jdi/GetLocalVariables.java ! test/com/sun/jdi/GetSetLocalTest.java ! test/com/sun/jdi/LambdaBreakpointTest.java ! test/com/sun/jdi/LineNumberOnBraceTest.java ! test/com/sun/jdi/PopAndStepTest.java Changeset: d584006ddd5d Author: rpatil Date: 2017-04-04 19:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d584006ddd5d 8177449: (tz) Support tzdata2017b Reviewed-by: martin, naoto ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/iso3166.tab ! make/data/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/northamerica Changeset: 1a8997b4292d Author: bpb Date: 2017-04-04 08:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a8997b4292d 8177984: (ch) java/nio/channels/SocketChannel/VectorIO.java should use RandomFactory Summary: Obtain Random from RandomFactory instead of directly. Reviewed-by: clanger ! test/java/nio/channels/SocketChannel/VectorIO.java Changeset: f940fd4232d8 Author: darcy Date: 2017-04-04 11:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f940fd4232d8 8177949: @link tag arguments need correction for ElementType documentation Reviewed-by: lancea ! src/java.base/share/classes/java/lang/annotation/ElementType.java Changeset: a49fb788ac68 Author: mli Date: 2017-04-04 19:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a49fb788ac68 8165367: Additional tests for JEP 288: Disable SHA-1 Certificates Summary: The new tests just focus on the usage constraints TLSSever and TLSClient with TLS communication Reviewed-by: ascarpino Contributed-by: John Jiang + test/sun/security/ssl/CertPathRestrictions/JSSEClient.java + test/sun/security/ssl/CertPathRestrictions/JSSEServer.java + test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA1-INTER_CA_SHA256-ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA1-INTER_CA_SHA256-ROOT_CA_SHA256.cer + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA1-ROOT_CA_SHA1-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA1-ROOT_CA_SHA1.cer + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA1-ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA1-ROOT_CA_SHA256.cer + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA256-ROOT_CA_SHA1-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA256-ROOT_CA_SHA1.cer + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA256-ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/END_ENTITY_SHA256-INTER_CA_SHA256-ROOT_CA_SHA256.cer + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA1-ROOT_CA_SHA1-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA1-ROOT_CA_SHA1.cer + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA1-ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA1-ROOT_CA_SHA256.cer + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA256-ROOT_CA_SHA1-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA256-ROOT_CA_SHA1.cer + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA256-ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/INTER_CA_SHA256-ROOT_CA_SHA256.cer + test/sun/security/ssl/CertPathRestrictions/certs/ROOT_CA_SHA1-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/ROOT_CA_SHA1.cer + test/sun/security/ssl/CertPathRestrictions/certs/ROOT_CA_SHA256-PRIV.key + test/sun/security/ssl/CertPathRestrictions/certs/ROOT_CA_SHA256.cer Changeset: 9289f04ddb54 Author: rriggs Date: 2017-04-05 09:57 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9289f04ddb54 8165641: Deprecate Object.finalize Reviewed-by: mchung, smarks ! src/java.base/share/classes/com/sun/crypto/provider/DESKey.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKey.java ! src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java ! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java ! src/java.base/share/classes/java/net/SocketInputStream.java ! src/java.base/share/classes/java/net/SocketOutputStream.java ! src/java.base/share/classes/java/util/Timer.java ! src/java.base/share/classes/java/util/concurrent/Executors.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/sun/net/www/MeteredStream.java ! src/java.base/share/classes/sun/net/www/protocol/https/DelegateHttpsURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/security/provider/KeyProtector.java ! src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java ! src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/java.desktop/macosx/classes/sun/font/CFont.java ! src/java.desktop/macosx/classes/sun/font/CStrike.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SubImageInputStream.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFBaseJPEGCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFJPEGDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFOldJPEGDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/stream/StreamFinalizer.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/java.desktop/share/classes/java/awt/Graphics.java ! src/java.desktop/share/classes/java/awt/PrintJob.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/FileImageInputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/FileImageOutputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/java.desktop/share/classes/javax/imageio/stream/MemoryCacheImageInputStream.java ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/classes/sun/java2d/pipe/RegionClipSpanIterator.java ! src/java.desktop/share/classes/sun/print/PeekGraphics.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/ProxyGraphics.java ! src/java.desktop/share/classes/sun/print/ProxyGraphics2D.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethod.java ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java ! src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java ! src/java.rmi/share/classes/sun/rmi/log/LogInputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Base.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/PlainClient.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/CardImpl.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/Key.java ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Changeset: cda91600a4bd Author: mchung Date: 2017-04-05 10:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cda91600a4bd 8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/util/ResourceBundle.java + test/java/util/ResourceBundle/modules/casesensitive/CaseInsensitiveNameClash.java + test/java/util/ResourceBundle/modules/casesensitive/src/resbundle/jdk/test/Main.java + test/java/util/ResourceBundle/modules/casesensitive/src/resbundle/jdk/test/main.properties + test/java/util/ResourceBundle/modules/casesensitive/src/resbundle/module-info.java Changeset: 383a04a71b36 Author: amlu Date: 2017-04-06 09:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/383a04a71b36 8177640: jdk/internal/util/jar/TestVersionedStream.java fails on Windows Reviewed-by: psandoz ! test/ProblemList.txt ! test/jdk/internal/util/jar/TestVersionedStream.java Changeset: fff71e4478c3 Author: chegar Date: 2017-04-06 09:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fff71e4478c3 8178101: Migrate the thread deprecation technote to javadoc doc-files Reviewed-by: dholmes ! src/java.base/share/classes/java/lang/Thread.java + src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html Changeset: c89044066843 Author: dfuchs Date: 2017-04-06 14:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c89044066843 8178139: Minor typo in API documentation of java.util.logging.Logger Reviewed-by: lancea ! src/java.logging/share/classes/java/util/logging/Logger.java Changeset: 0cbd3417cc9d Author: jlahoda Date: 2017-04-06 16:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0cbd3417cc9d 8178077: jshell tool: crash on ctrl-up or ctrl-down Summary: When looking up a private method, using the ConsoleReader.class, instead of getClass(), which may return a subclass. Reviewed-by: rfield ! src/jdk.internal.le/share/classes/jdk/internal/jline/extra/EditingHistory.java Changeset: 98dd9af9e290 Author: rriggs Date: 2017-04-06 10:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/98dd9af9e290 8178154: Typo in Object.finalize deprecation javadoc Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Object.java Changeset: 0526526e7302 Author: ksrini Date: 2017-04-05 14:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0526526e7302 8065825: Make the java -help consistent with the man page Reviewed-by: alanb ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 00605c87c016 Author: lana Date: 2017-04-06 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00605c87c016 Merge Changeset: 1c34a0665f18 Author: mchung Date: 2017-04-06 18:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c34a0665f18 8178286: Missing @moduleGraph in javadoc Reviewed-by: lancea ! src/jdk.accessibility/share/classes/module-info.java ! src/jdk.editpad/share/classes/module-info.java ! src/jdk.incubator.httpclient/share/classes/module-info.java Changeset: af69c0289a77 Author: chegar Date: 2017-04-07 10:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/af69c0289a77 8178161: Default multicast interface on Mac Reviewed-by: michaelm, bpb ! src/java.base/macosx/classes/java/net/DefaultInterface.java Changeset: fa3c4a60a616 Author: alanb Date: 2017-04-07 08:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa3c4a60a616 8177530: Module system implementation refresh (4/2017) Reviewed-by: mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java + src/java.base/share/classes/java/lang/LayerInstantiationException.java + src/java.base/share/classes/java/lang/Module.java + src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/NamedPackage.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/System.java + src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/package-info.java - src/java.base/share/classes/java/lang/reflect/Layer.java - src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java - src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java - src/java.base/share/classes/java/lang/reflect/WeakPairMap.java ! src/java.base/share/classes/java/lang/reflect/package-info.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/javax/crypto/JceSecurityManager.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java ! src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java - src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/native/libjava/Module.c ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/swing/text/PlainView.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java + src/java.instrument/share/classes/java/lang/instrument/UnmodifiableModuleException.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.instrument/share/classes/sun/instrument/TransformerManager.java ! src/java.instrument/share/native/libinstrument/JPLISAgent.h ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java ! src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! test/TEST.ROOT ! test/java/awt/TrayIcon/SystemTrayIconHelper.java ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/awt/regtesthelpers/Util.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/TestMain.java ! test/java/lang/Class/forName/modules/src/m2/p2/test/Main.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoGetClassLoaderAccess.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/ClassLoader/getResource/automaticmodules/Main.java ! test/java/lang/ClassLoader/getResource/modules/Main.java + test/java/lang/ModuleLayer/BasicLayerTest.java + test/java/lang/ModuleLayer/LayerAndLoadersTest.java + test/java/lang/ModuleLayer/LayerControllerTest.java + test/java/lang/ModuleLayer/layertest/Test.java + test/java/lang/ModuleLayer/src/m1/module-info.java + test/java/lang/ModuleLayer/src/m1/p/Main.java + test/java/lang/ModuleLayer/src/m1/p/Service.java + test/java/lang/ModuleLayer/src/m2/module-info.java + test/java/lang/ModuleLayer/src/m2/q/Hello.java + test/java/lang/ModuleLayer/src/m3/module-info.java + test/java/lang/ModuleLayer/src/m3/w/Hello.java + test/java/lang/ModuleLayer/src/m4/impl/ServiceImpl.java + test/java/lang/ModuleLayer/src/m4/module-info.java + test/java/lang/ModuleTests/AddExportsTest.java + test/java/lang/ModuleTests/AnnotationsTest.java + test/java/lang/ModuleTests/BasicModuleTest.java + test/java/lang/ModuleTests/WithSecurityManager.java + test/java/lang/ModuleTests/access/AccessTest.java + test/java/lang/ModuleTests/access/src/target/module-info.java + test/java/lang/ModuleTests/access/src/target/p1/Helper.java + test/java/lang/ModuleTests/access/src/target/p1/Public.java + test/java/lang/ModuleTests/access/src/target/p2/NonPublic.java + test/java/lang/ModuleTests/access/src/target/q1/Public.java + test/java/lang/ModuleTests/access/src/target/q2/NonPublic.java + test/java/lang/ModuleTests/access/src/test/module-info.java + test/java/lang/ModuleTests/access/src/test/test/Main.java + test/java/lang/ModuleTests/addXXX/Driver.java + test/java/lang/ModuleTests/addXXX/m1/module-info.java + test/java/lang/ModuleTests/addXXX/m1/p1/C.java + test/java/lang/ModuleTests/addXXX/m2/module-info.java + test/java/lang/ModuleTests/addXXX/m2/p2/C.java + test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java + test/java/lang/ModuleTests/addXXX/m3/module-info.java + test/java/lang/ModuleTests/addXXX/m3/p3/C.java + test/java/lang/ModuleTests/addXXX/m4/module-info.java + test/java/lang/ModuleTests/addXXX/m4/p4/C.java + test/java/lang/ModuleTests/addXXX/test/module-info.java + test/java/lang/ModuleTests/addXXX/test/test/C.java + test/java/lang/ModuleTests/addXXX/test/test/Main.java + test/java/lang/ModuleTests/addXXX/test/test/Service.java + test/java/lang/ModuleTests/allow.policy + test/java/lang/ModuleTests/annotation/Basic.java + test/java/lang/ModuleTests/annotation/src/m/module-info.java + test/java/lang/ModuleTests/annotation/src/m/p/annotation/Bar.java + test/java/lang/ModuleTests/annotation/src/m/p/annotation/Baz.java + test/java/lang/ModuleTests/annotation/src/m/p/annotation/Foo.java ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/SecurityManager/CheckSecurityProvider.java ! test/java/lang/SecurityManager/modules/Test.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackTraceElement/lib/m1/com/app/Utils.java ! test/java/lang/System/Logger/custom/CustomLoggerTest.java ! test/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinder.java ! test/java/lang/System/LoggerFinder/BaseLoggerFinderTest/TestLoggerFinder.java ! test/java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java ! test/java/lang/System/LoggerFinder/internal/BaseDefaultLoggerFinderTest/BaseDefaultLoggerFinderTest.java ! test/java/lang/System/LoggerFinder/internal/BaseLoggerBridgeTest/BaseLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/BasePlatformLoggerTest/BasePlatformLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java ! test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/SystemLoggerInPlatformLoader/SystemLoggerInPlatformLoader.java ! test/java/lang/System/LoggerFinder/internal/backend/LoggerFinderBackendTest.java ! test/java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java + test/java/lang/WeakPairMap/Driver.java + test/java/lang/WeakPairMap/java.base/java/lang/WeakPairMapTest.java ! test/java/lang/instrument/ATransformerManagementTestCase.java ! test/java/lang/instrument/BootstrapClassPathAgent.java ! test/java/lang/instrument/BootstrapClassPathTest.java ! test/java/lang/instrument/RedefineClassWithNativeMethodAgent.java ! test/java/lang/instrument/RedefineModuleAgent.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/instrument/SimpleIdentityTransformer.java ! test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java ! test/java/lang/invoke/modules/m1/p1/Main.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java - test/java/lang/reflect/Layer/BasicLayerTest.java - test/java/lang/reflect/Layer/LayerAndLoadersTest.java - test/java/lang/reflect/Layer/LayerControllerTest.java - test/java/lang/reflect/Layer/layertest/Test.java - test/java/lang/reflect/Layer/src/m1/module-info.java - test/java/lang/reflect/Layer/src/m1/p/Main.java - test/java/lang/reflect/Layer/src/m1/p/Service.java - test/java/lang/reflect/Layer/src/m2/module-info.java - test/java/lang/reflect/Layer/src/m2/q/Hello.java - test/java/lang/reflect/Layer/src/m3/module-info.java - test/java/lang/reflect/Layer/src/m3/w/Hello.java - test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java - test/java/lang/reflect/Layer/src/m4/module-info.java - test/java/lang/reflect/Module/AddExportsTest.java - test/java/lang/reflect/Module/AnnotationsTest.java - test/java/lang/reflect/Module/BasicModuleTest.java - test/java/lang/reflect/Module/WithSecurityManager.java - test/java/lang/reflect/Module/access/AccessTest.java - test/java/lang/reflect/Module/access/src/target/module-info.java - test/java/lang/reflect/Module/access/src/target/p1/Helper.java - test/java/lang/reflect/Module/access/src/target/p1/Public.java - test/java/lang/reflect/Module/access/src/target/p2/NonPublic.java - test/java/lang/reflect/Module/access/src/target/q1/Public.java - test/java/lang/reflect/Module/access/src/target/q2/NonPublic.java - test/java/lang/reflect/Module/access/src/test/module-info.java - test/java/lang/reflect/Module/access/src/test/test/Main.java - test/java/lang/reflect/Module/addXXX/Driver.java - test/java/lang/reflect/Module/addXXX/m1/module-info.java - test/java/lang/reflect/Module/addXXX/m1/p1/C.java - test/java/lang/reflect/Module/addXXX/m2/module-info.java - test/java/lang/reflect/Module/addXXX/m2/p2/C.java - test/java/lang/reflect/Module/addXXX/m2/p2/internal/C.java - test/java/lang/reflect/Module/addXXX/m3/module-info.java - test/java/lang/reflect/Module/addXXX/m3/p3/C.java - test/java/lang/reflect/Module/addXXX/m4/module-info.java - test/java/lang/reflect/Module/addXXX/m4/p4/C.java - test/java/lang/reflect/Module/addXXX/test/module-info.java - test/java/lang/reflect/Module/addXXX/test/test/C.java - test/java/lang/reflect/Module/addXXX/test/test/Main.java - test/java/lang/reflect/Module/addXXX/test/test/Service.java - test/java/lang/reflect/Module/allow.policy - test/java/lang/reflect/Module/annotation/Basic.java - test/java/lang/reflect/Module/annotation/src/m/module-info.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Bar.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Baz.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Foo.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyForMethodHandle.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/lang/reflect/Proxy/ProxyModuleMapping.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java - test/java/lang/reflect/WeakPairMap/Driver.java - test/java/lang/reflect/WeakPairMap/java.base/java/lang/reflect/WeakPairMapTest.java ! test/java/security/Provider/DefaultProviderList.java ! test/java/util/ResourceBundle/modules/cache/src/test/jdk/test/Main.java ! test/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java ! test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java ! test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java ! test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java ! test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java ! test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java ! test/java/util/ServiceLoader/modules/BadProvidersTest.java ! test/java/util/ServiceLoader/modules/Basic.java ! test/java/util/logging/LocalizedLevelName.java ! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java ! test/java/util/spi/ResourceBundleControlProvider/test/jdk/test/ResourceBundleDelegate.java ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/jdk/internal/jimage/JImageOpenTest.java ! test/jdk/modules/etc/JdkQualifiedExportTest.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/incubator/DefaultImage.java ! test/jdk/modules/incubator/ImageModules.java ! test/jdk/modules/incubator/src/cp/listmods/ListModules.java ! test/jdk/modules/incubator/src/cp/test/ConvertToLowerCase.java ! test/jdk/modules/incubator/src/cp/test/WriteUpperCase.java ! test/jdk/modules/open/Basic.java ! test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java ! test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java ! test/sun/management/LoggingTest/test.loggerfinder/test/loggerfinder/TestLoggerFinder.java ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/basic/src/test/jdk/test/Test.java ! test/tools/jlink/plugins/PluginsNegativeTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m3/p3/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m5/p5/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/test/jdk/test/Main.java ! test/tools/launcher/modules/dryrun/DryRunTest.java ! test/tools/launcher/modules/listmods/ListModsTest.java ! test/tools/launcher/modules/patch/basic/src/test/jdk/test/Main.java ! test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java Changeset: 4253030c44ba Author: alanb Date: 2017-04-07 10:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4253030c44ba Merge ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java - src/java.base/share/classes/java/lang/reflect/Layer.java - src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java - src/java.base/share/classes/java/lang/reflect/Module.java - src/java.base/share/classes/java/lang/reflect/WeakPairMap.java ! src/java.base/share/classes/java/util/ResourceBundle.java - src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java - test/java/lang/reflect/Layer/BasicLayerTest.java - test/java/lang/reflect/Layer/LayerAndLoadersTest.java - test/java/lang/reflect/Layer/LayerControllerTest.java - test/java/lang/reflect/Layer/layertest/Test.java - test/java/lang/reflect/Layer/src/m1/module-info.java - test/java/lang/reflect/Layer/src/m1/p/Main.java - test/java/lang/reflect/Layer/src/m1/p/Service.java - test/java/lang/reflect/Layer/src/m2/module-info.java - test/java/lang/reflect/Layer/src/m2/q/Hello.java - test/java/lang/reflect/Layer/src/m3/module-info.java - test/java/lang/reflect/Layer/src/m3/w/Hello.java - test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java - test/java/lang/reflect/Layer/src/m4/module-info.java - test/java/lang/reflect/Module/AddExportsTest.java - test/java/lang/reflect/Module/AnnotationsTest.java - test/java/lang/reflect/Module/BasicModuleTest.java - test/java/lang/reflect/Module/WithSecurityManager.java - test/java/lang/reflect/Module/access/AccessTest.java - test/java/lang/reflect/Module/access/src/target/module-info.java - test/java/lang/reflect/Module/access/src/target/p1/Helper.java - test/java/lang/reflect/Module/access/src/target/p1/Public.java - test/java/lang/reflect/Module/access/src/target/p2/NonPublic.java - test/java/lang/reflect/Module/access/src/target/q1/Public.java - test/java/lang/reflect/Module/access/src/target/q2/NonPublic.java - test/java/lang/reflect/Module/access/src/test/module-info.java - test/java/lang/reflect/Module/access/src/test/test/Main.java - test/java/lang/reflect/Module/addXXX/Driver.java - test/java/lang/reflect/Module/addXXX/m1/module-info.java - test/java/lang/reflect/Module/addXXX/m1/p1/C.java - test/java/lang/reflect/Module/addXXX/m2/module-info.java - test/java/lang/reflect/Module/addXXX/m2/p2/C.java - test/java/lang/reflect/Module/addXXX/m2/p2/internal/C.java - test/java/lang/reflect/Module/addXXX/m3/module-info.java - test/java/lang/reflect/Module/addXXX/m3/p3/C.java - test/java/lang/reflect/Module/addXXX/m4/module-info.java - test/java/lang/reflect/Module/addXXX/m4/p4/C.java - test/java/lang/reflect/Module/addXXX/test/module-info.java - test/java/lang/reflect/Module/addXXX/test/test/C.java - test/java/lang/reflect/Module/addXXX/test/test/Main.java - test/java/lang/reflect/Module/addXXX/test/test/Service.java - test/java/lang/reflect/Module/allow.policy - test/java/lang/reflect/Module/annotation/Basic.java - test/java/lang/reflect/Module/annotation/src/m/module-info.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Bar.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Baz.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Foo.java - test/java/lang/reflect/WeakPairMap/Driver.java - test/java/lang/reflect/WeakPairMap/java.base/java/lang/reflect/WeakPairMapTest.java Changeset: 182207b208dc Author: alanb Date: 2017-04-07 10:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/182207b208dc Merge Changeset: b02c74361520 Author: alanb Date: 2017-04-07 11:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b02c74361520 Merge ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/NamedPackage.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/native/libjava/Module.c ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/jdk.accessibility/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/jdi/BreakpointTest.java ! test/com/sun/jdi/LambdaBreakpointTest.java ! test/com/sun/jdi/PopAndStepTest.java ! test/java/awt/TrayIcon/SystemTrayIconHelper.java ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/ClassLoader/getResource/modules/Main.java ! test/java/lang/ModuleLayer/BasicLayerTest.java ! test/java/lang/ModuleLayer/LayerAndLoadersTest.java ! test/java/lang/ModuleLayer/LayerControllerTest.java ! test/java/lang/ModuleLayer/layertest/Test.java ! test/java/lang/ModuleLayer/src/m1/module-info.java ! test/java/lang/ModuleLayer/src/m1/p/Main.java ! test/java/lang/ModuleLayer/src/m1/p/Service.java ! test/java/lang/ModuleLayer/src/m2/module-info.java ! test/java/lang/ModuleLayer/src/m2/q/Hello.java ! test/java/lang/ModuleLayer/src/m3/module-info.java ! test/java/lang/ModuleLayer/src/m3/w/Hello.java ! test/java/lang/ModuleLayer/src/m4/impl/ServiceImpl.java ! test/java/lang/ModuleLayer/src/m4/module-info.java ! test/java/lang/ModuleTests/AddExportsTest.java ! test/java/lang/ModuleTests/AnnotationsTest.java ! test/java/lang/ModuleTests/BasicModuleTest.java ! test/java/lang/ModuleTests/WithSecurityManager.java ! test/java/lang/ModuleTests/access/AccessTest.java ! test/java/lang/ModuleTests/access/src/target/module-info.java ! test/java/lang/ModuleTests/access/src/target/p1/Helper.java ! test/java/lang/ModuleTests/access/src/target/p1/Public.java ! test/java/lang/ModuleTests/access/src/target/p2/NonPublic.java ! test/java/lang/ModuleTests/access/src/target/q1/Public.java ! test/java/lang/ModuleTests/access/src/target/q2/NonPublic.java ! test/java/lang/ModuleTests/access/src/test/module-info.java ! test/java/lang/ModuleTests/access/src/test/test/Main.java ! test/java/lang/ModuleTests/addXXX/Driver.java ! test/java/lang/ModuleTests/addXXX/m1/module-info.java ! test/java/lang/ModuleTests/addXXX/m1/p1/C.java ! test/java/lang/ModuleTests/addXXX/m2/module-info.java ! test/java/lang/ModuleTests/addXXX/m2/p2/C.java ! test/java/lang/ModuleTests/addXXX/m2/p2/internal/C.java ! test/java/lang/ModuleTests/addXXX/m3/module-info.java ! test/java/lang/ModuleTests/addXXX/m3/p3/C.java ! test/java/lang/ModuleTests/addXXX/m4/module-info.java ! test/java/lang/ModuleTests/addXXX/m4/p4/C.java ! test/java/lang/ModuleTests/addXXX/test/module-info.java ! test/java/lang/ModuleTests/addXXX/test/test/C.java ! test/java/lang/ModuleTests/addXXX/test/test/Main.java ! test/java/lang/ModuleTests/addXXX/test/test/Service.java ! test/java/lang/ModuleTests/allow.policy ! test/java/lang/ModuleTests/annotation/Basic.java ! test/java/lang/ModuleTests/annotation/src/m/module-info.java ! test/java/lang/ModuleTests/annotation/src/m/p/annotation/Bar.java ! test/java/lang/ModuleTests/annotation/src/m/p/annotation/Baz.java ! test/java/lang/ModuleTests/annotation/src/m/p/annotation/Foo.java ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/SecurityManager/CheckSecurityProvider.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackTraceElement/lib/m1/com/app/Utils.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/backend/LoggerFinderBackendTest.java ! test/java/lang/WeakPairMap/Driver.java ! test/java/lang/WeakPairMap/java.base/java/lang/WeakPairMapTest.java ! test/java/lang/instrument/RedefineClassWithNativeMethodAgent.java ! test/java/lang/instrument/RedefineModuleAgent.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java ! test/java/lang/invoke/modules/m1/p1/Main.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyForMethodHandle.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/lang/reflect/Proxy/ProxyModuleMapping.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java ! test/java/util/ServiceLoader/modules/BadProvidersTest.java ! test/java/util/ServiceLoader/modules/Basic.java ! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/incubator/DefaultImage.java ! test/jdk/modules/incubator/ImageModules.java ! test/jdk/modules/incubator/src/cp/listmods/ListModules.java ! test/jdk/modules/incubator/src/cp/test/ConvertToLowerCase.java ! test/jdk/modules/incubator/src/cp/test/WriteUpperCase.java ! test/jdk/modules/open/Basic.java ! test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java ! test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/basic/src/test/jdk/test/Test.java ! test/tools/jlink/plugins/PluginsNegativeTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m3/p3/Main.java ! test/tools/launcher/modules/dryrun/DryRunTest.java ! test/tools/launcher/modules/listmods/ListModsTest.java ! test/tools/launcher/modules/patch/basic/src/test/jdk/test/Main.java ! test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java From Alan.Bateman at oracle.com Fri Apr 7 10:59:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Apr 2017 11:59:37 +0100 Subject: SecurityManager environments In-Reply-To: References: <883259944-21059@kerio.abacus.ch> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> Message-ID: <83d9e03b-834a-0b5c-0e13-b5513475c0cf@oracle.com> On 07/04/2017 03:54, Robert Muir wrote: > : > > Because of these problems, if you are a server-side app, even if you > understand this stuff and want to do the right thing, its really hard > to avoid simply granting all kinds of horrible permissions globally to > all code. In my experience the worst problems are the internal api > usage issues, so it would be nice to "give jigsaw a chance" to see if > it makes the situation better. SecurityManager is really great if you > want to prevent common security issues such as directory traversal, > but its too hard for a server side app right now. I agree with most of what you said in this mail. On "common java libraries don't care about this stuff" then I think part of it is that the security manager is not enabled by default so it's a completely different mode of execution and so rarely tested by many library maintainers. Also to get the permissions right requires understanding each of the privileged operations that the library might need to do and putting that code in a privileged block so that the library can be granted the permission rather than to everyone. On your gripes with default policy, the "bogus crap" as you termed it :-). It grants read access to a number of system properties and allows applications to bind to ephemeral ports, that's it. It used to grant "stopThread" (for compatibility reasons detailed in the comments) but this is no longer the case in JDK 9. It may be that this thread should move to security-dev as that is the right place to discuss usability and other issues with the security manager. -Alan. From stephen.felts at oracle.com Fri Apr 7 12:53:25 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 7 Apr 2017 05:53:25 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <<20170405161520.81729A2BC4@eggemoggin.niobe.net>> References: <> <<4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com>> <<85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr>> <<5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com>> <<3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com>> <> <<843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com>> <<20170405161520.81729A2BC4@eggemoggin.niobe.net>> Message-ID: <79bb680f-0fb6-40af-82d6-15f90ce3495a@default> I have a problem with the second point. Oracle's application server has "FAST SWAP" functionality similar to JRebel built-in so that a developer can speed up the "edit -> build -> deploy -> test" cycle. It uses an internal agent that attaches to the server so customers don't need to see it, configure it, or even know the name of it. It only works on application classes in an exploded ear or war file. This proposal will make it so the JRebel agent will work but our own agent won't. Ironically, this feature only works in development mode and developers are the ones most likely to run without any scripts having the CLASSPATH set up and just run java weblogic.Server. So as I've said many times I don't want any JDK9 command line options. In trying to protect against the guilty, you are killing the innocent. It seems to me that it's late in Phase 2 of ramp-down of JDK 9 and this feature is not baked or well received. IMO no changes should be done in this area for JDK 9. -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com Sent: Wednesday, April 5, 2017 12:15 PM To: jigsaw-dev at openjdk.java.net Subject: Disallowing the dynamic loading of agents by default (revised) Thanks to everyone for the quick feedback on this topic, and especially to Andrew for the constructive dialogue. Here's a revised proposal: - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's on by default in JDK 9 but off by default in JDK 10. This will allow launch scripts that use this option on JDK 10 to work on JDK 9 without change, and will allow early testing of the JDK 10 behavior on JDK 9. - Revise the `com.sun.tools.attach` API to forbid attachment to the current process or to an ancestor of the current process, and define a read-only system property that allows such attachment to be enabled via the command line. This will discourage the inadvertent use of libraries that, for better or for worse, intentionally violate strong encapsulation. - Enhance the `-jar` launcher option so that if the JAR file being launched contains a `Premain-Class` attribute then it's launched as both an application and as an agent for that application. This will allow `java -jar foo.jar` to be used in place of the more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. Taken together, these changes are intended to enable the continued use of legitimate dynamically-loaded agents without change on JDK 9 and with a small change on JDK 10. That later change will align the treatment of such agents with the other means of breaking encapsulation (`--add-opens`, etc.) in order to ensure integrity by default for all code. This proposal does not attempt to lock down platform classes as distinct from user classes. Many agents have legitimate reasons to transform platform classes, so an additional mechanism to protect those classes does not appear to be worthwhile. Comments? - Mark [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012000.html From martijnverburg at gmail.com Fri Apr 7 13:20:04 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 7 Apr 2017 14:20:04 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <79bb680f-0fb6-40af-82d6-15f90ce3495a@default> References: <79bb680f-0fb6-40af-82d6-15f90ce3495a@default> Message-ID: Hi all, I've come back into this thread late, but for us (jClarity) we're OK with the revised proposal, it will give us the time with slow moving enterprise customers to move to an explicit Java agent approach. Cheers, Martijn On 7 April 2017 at 13:53, Stephen Felts wrote: > I have a problem with the second point. > > Oracle's application server has "FAST SWAP" functionality similar to > JRebel built-in so that a developer can speed up the "edit -> build -> > deploy -> test" cycle. > It uses an internal agent that attaches to the server so customers don't > need to see it, configure it, or even know the name of it. > It only works on application classes in an exploded ear or war file. > This proposal will make it so the JRebel agent will work but our own agent > won't. > > Ironically, this feature only works in development mode and developers are > the ones most likely to run without any scripts having the CLASSPATH set up > and just run java weblogic.Server. > So as I've said many times I don't want any JDK9 command line options. > > In trying to protect against the guilty, you are killing the innocent. > > It seems to me that it's late in Phase 2 of ramp-down of JDK 9 and this > feature is not baked or well received. IMO no changes should be done in > this area for JDK 9. > > > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of mark.reinhold at oracle.com > Sent: Wednesday, April 5, 2017 12:15 PM > To: jigsaw-dev at openjdk.java.net > Subject: Disallowing the dynamic loading of agents by default (revised) > > Thanks to everyone for the quick feedback on this topic, and especially to > Andrew for the constructive dialogue. > > Here's a revised proposal: > > - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's > on by default in JDK 9 but off by default in JDK 10. > > This will allow launch scripts that use this option on JDK 10 to > work on JDK 9 without change, and will allow early testing of the > JDK 10 behavior on JDK 9. > > - Revise the `com.sun.tools.attach` API to forbid attachment to the > current process or to an ancestor of the current process, and > define a read-only system property that allows such attachment to > be enabled via the command line. > > This will discourage the inadvertent use of libraries that, for > better or for worse, intentionally violate strong encapsulation. > > - Enhance the `-jar` launcher option so that if the JAR file being > launched contains a `Premain-Class` attribute then it's launched > as both an application and as an agent for that application. > > This will allow `java -jar foo.jar` to be used in place of the > more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. > > Taken together, these changes are intended to enable the continued use of > legitimate dynamically-loaded agents without change on JDK 9 and with a > small change on JDK 10. That later change will align the treatment of such > agents with the other means of breaking encapsulation (`--add-opens`, > etc.) in order to ensure integrity by default for all code. > > This proposal does not attempt to lock down platform classes as distinct > from user classes. Many agents have legitimate reasons to transform > platform classes, so an additional mechanism to protect those classes does > not appear to be worthwhile. > > Comments? > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- > April/012000.html > From andrey.x.nazarov at oracle.com Fri Apr 7 15:40:53 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 7 Apr 2017 18:40:53 +0300 Subject: RFR 8178323: Add negative tests for bind services Jlink feature Message-ID: Hi, Please review 3 negative tests for Jlink which tests new bind-services/suggest-providers feature. JBS: https://bugs.openjdk.java.net/browse/JDK-8178323 webrev: http://cr.openjdk.java.net/~anazarov/8178323/webrev.00/webrev/ ?Andrey From mandy.chung at oracle.com Fri Apr 7 20:04:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 13:04:40 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> Message-ID: <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> > On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie wrote: > > > Having though this over real hard, I'd realized I need to make a plea for sanity and consistency. I thought I should lay low in this discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86 platform is really, really unfortunate and a step backwards in our effort to standardize the name of this platform. > I think it may be useful to see the value of `os.arch` system property on all platforms at a glance. 32-bit 64-bit linux i386 amd64 arm aarch64 solaris amd64 sparcv9 windows x86 amd64 macos x86_64 It's late in JDK 9. The best is to revisit OS and architecture names in JDK 10 on the consistency and simplicity issue. In the context of JDK-8175819, these are names to pass to jmod ?-os-name ?-os-arch options. The values are used at resolution time to avoid linking modules for different target platforms into the same image. As Mark suggests, we use the value of `os.arch` system property for JMOD file in JDK 9 and we can change the value in JDK 10. No change to system property and bundle names, as we said previously. We should revisit OS and architecture names in JDK 10. I have updated JDK-8178016 to reflect that. Are you okay with that? Below shows the old and new values in the `release` file and the new values are used in JMOD files. JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin macos Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 amd64 sparcv9 sparcv9 arm arm aarch64 aarch64 Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html Mandy From mandy.chung at oracle.com Sat Apr 8 00:18:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 17:18:52 -0700 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: References: Message-ID: > On Apr 7, 2017, at 8:40 AM, Andrey Nazarov wrote: > > Hi, > > Please review 3 negative tests for Jlink which tests new bind-services/suggest-providers feature. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178323 > > webrev: http://cr.openjdk.java.net/~anazarov/8178323/webrev.00/webrev/ Thanks for adding these tests. BindServices.java 155 Path dir = Paths.get("verboseNoop?); I suggest to rename ?verboseNoop? to ?verboseNoBind? line 159-161: formatting nit: can you add spaces to align with the first argument in line 158. Same comment to SuggestProviders.java line 180-182 an 198-200. SuggestProviders.java It may be better to rename ?suggestNotProvider" to ?noSuggestedProvider". In the noOneUsesProvider test case, is m4 not observable? I think jlink should fail with m4 not found. When ?-suggest-providers is specified with a service type, it?s a bug in the implementation that does not report it. This should be renamed to ?nonObservableModule? instead. We should file a bug and include this test case in the JBS report. Mandy From mandy.chung at oracle.com Sat Apr 8 05:50:50 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 22:50:50 -0700 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module Message-ID: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/ This fixes -?patch-module to do hash checking on the module being patched so that it will ensure that a non-upgradeable module remains not upgradeable. As Graal has been using ?-patch-module option to disable the hash checking to load a different version of jdk.internal.vm.compiler, it needs a mechanism to load Graal, as tracked by JDK-8177845. Mandy From Alan.Bateman at oracle.com Sat Apr 8 07:21:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 8 Apr 2017 08:21:58 +0100 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module In-Reply-To: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> References: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> Message-ID: <44c6bac8-b4d4-b745-98ae-1d1d82ed3fca@oracle.com> On 08/04/2017 06:50, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/ > > This fixes -?patch-module to do hash checking on the module being patched > so that it will ensure that a non-upgradeable module remains not upgradeable. > > The comment at L523 needs updating too, otherwise looks good. Given that this can't be pushed to jdk9/dev until the issue deploying Graal is fixed then I think we should just push this fix to jake and move on. It will go into jdk9/dev with the next update (which I hope will be the last update). -Alan From nipa at codefx.org Sat Apr 8 11:30:22 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sat, 8 Apr 2017 13:30:22 +0200 Subject: The case for dependencies on automatic modules Message-ID: <5dbdc93a-f7a7-f053-1a70-bb73a6ee3108@codefx.org> Hi! Automatic modules are a great feature because they allow decentralized and uncoordinated modularization. In an ecosystem as gigantic and diverse as Java's that is _the only_ tractable approach! Compared to that ability and in the big scheme of things, how an automatic module's name is chosen is a small detail. That it might end up preventing decentralized modularization[1] is, frankly, ludicrous and would reflect badly on the entire modularity endeavor. As such I am convinced that everything must be done to keep that possible, maybe including making decisions that would otherwise not be the way to go. so long ... Nicolai [1] by not publishing modules that depend on automatic modules -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From nipa at codefx.org Sat Apr 8 11:35:00 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sat, 8 Apr 2017 13:35:00 +0200 Subject: Naming unmodularized modules Message-ID: <51f48846-b59b-d2bd-e22f-5a1304b1fc31@codefx.org> Hi again, one underlying problem of automatic modules is that maintainers have no way to express their desired module name without fully modularizing their artifacts. This will make "proper names" appear rather late in the migration. Brian's and Robert's idea to read Maven meta information addressed this. While giving developers the ability to pick a name this way is commendable I agree with the criticism that this creates a dependency "up the stack". What if the module system offered a similar, low entry-barrier to picking a module's name? As an alternative to the full module declaration, the module system could allow module-info.java to contain the following: not-yet-a module foo; Such a declaration would determine a module's name but would otherwise work as an automatic module (everything open and exported) while clearly communicating that it is in transition. There might be a better keyword than `not-yet-a`, though. ;) Unlike Maven meta information this could not be inferred for existing artifacts but it at least gives maintainers an easy way to start naming their modules. so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From nipa at codefx.org Sat Apr 8 11:35:19 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sat, 8 Apr 2017 13:35:19 +0200 Subject: Aliasing (automatic) modules Message-ID: <9c478a29-4d62-f25e-9ab8-6873622226c2@codefx.org> Hi again, so far most (all?) proposals for handling automatic module names tackled the "what is the module's real name" aspect of this question but I have seen none that would push the likelihood of the same dependency being referenced by different names reasonably close to zero. As argued elsewhere[1], I think this needs to be addressed without preventing the publication of artifacts with such references. I want to propose a feature allowing aliasing (automatic) modules again because it gives consumers of the conflict a straight-forward way to handle the problem. And because I am convinced that these problems will eventually arise, I think the JDK should really give developers a way to fix them locally. A command line option, let's say `--alias-modules A=X`, maps module name A to module name X. Every dependency on either A or X will be resolved to X, implying that there must a module X in the universe of observable modules. There can be several aliases for the same module (`--alias-modules A=X,B=X`; X needs to be observable) and they can be chained (`--alias-modules A=X,X=Y`; Y needs to be observable). Aliasing would of course have to be applied to qualified exports, opens, and similar mechanisms as well. It might be worth adding the rule that no observable module must have an aliased name. So for `--alias-modules A=X` there must be no observable module A. This prevents ambiguity and would effectively prevent aliasing platform modules. That might be a good thing because it looks like aliasing and upgrading modules has quite some overlap (or is even identical?) Unfortunately I could not come up with a way to limit aliasing to automatic module names (in case that were desirable) without somehow marking dependencies on automatic modules, likely in the module declaration. If changing module declaration syntax is still on the table, it could be changed so that dependencies on automatic modules must be phrased as something like `requires automatic`. The obvious semantics would be that only such requires clauses can be fulfilled with automatic modules and that only such dependencies could be aliased (this might make it prudent to phrase the aliasing option accordingly, e.g. `--alias-automatic-modules`). This could also be used to help developers in keeping their module declarations clean: The compiler could emit a warning if a `requires automatic` clause is fulfilled by a regular module. so long ... Nicolai [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012111.html -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From forax at univ-mlv.fr Sat Apr 8 14:22:45 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 08 Apr 2017 14:22:45 +0000 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module In-Reply-To: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> References: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> Message-ID: <97E6A7B9-D6B0-4833-BE6C-DAB0E2528817@univ-mlv.fr> Hi Mandy, how can I test a change in java.lang after that patch ? R?mi On April 8, 2017 7:50:50 AM GMT+02:00, Mandy Chung wrote: >http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/ > >This fixes -?patch-module to do hash checking on the module being >patched >so that it will ensure that a non-upgradeable module remains not >upgradeable. > >As Graal has been using ?-patch-module option to disable the hash >checking >to load a different version of jdk.internal.vm.compiler, it needs a >mechanism to load Graal, as tracked by JDK-8177845. > >Mandy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From mandy.chung at oracle.com Sat Apr 8 14:49:13 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 8 Apr 2017 07:49:13 -0700 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module In-Reply-To: <97E6A7B9-D6B0-4833-BE6C-DAB0E2528817@univ-mlv.fr> References: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> <97E6A7B9-D6B0-4833-BE6C-DAB0E2528817@univ-mlv.fr> Message-ID: No change in that regards. The updated test [1] in the webrev shows it patches java.base/jdk.internal.modules.SystemModules Before this fix, you can do ?patch-module jdk.internal.vm.compiler=.jar ?upgrade-module-path graal.jar. The reason is that ?patch-module disables the hash checking that makes non-upgradeable module upgradeable. After this fix, it fails if you attempt upgrade a patched non-upgradeable module. [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java.frames.html > On Apr 8, 2017, at 7:22 AM, Remi Forax wrote: > > Hi Mandy, > how can I test a change in java.lang after that patch ? > > R?mi > > > On April 8, 2017 7:50:50 AM GMT+02:00, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01 / > > This fixes -?patch-module to do hash checking on the module being patched > so that it will ensure that a non-upgradeable module remains not upgradeable. > > As Graal has been using ?-patch-module option to disable the hash checking > to load a different version of jdk.internal.vm.compiler, it needs a > mechanism to load Graal, as tracked by JDK-8177845. > > Mandy > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From mandy.chung at oracle.com Sat Apr 8 14:52:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 8 Apr 2017 07:52:28 -0700 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module In-Reply-To: <44c6bac8-b4d4-b745-98ae-1d1d82ed3fca@oracle.com> References: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> <44c6bac8-b4d4-b745-98ae-1d1d82ed3fca@oracle.com> Message-ID: <35C56B88-A516-4C84-B295-526F765D42E5@oracle.com> > On Apr 8, 2017, at 12:21 AM, Alan Bateman wrote: > > On 08/04/2017 06:50, Mandy Chung wrote: > >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/ >> >> This fixes -?patch-module to do hash checking on the module being patched >> so that it will ensure that a non-upgradeable module remains not upgradeable. >> >> > The comment at L523 needs updating too, otherwise looks good. > will take that out. > Given that this can't be pushed to jdk9/dev until the issue deploying Graal is fixed then I think we should just push this fix to jake and move on. It will go into jdk9/dev with the next update (which I hope will be the last update). I was thinking to push this to jdk-9+166 but pushing it to jake will probably be a better option for Doug. Mandy From forax at univ-mlv.fr Sat Apr 8 15:29:22 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 08 Apr 2017 15:29:22 +0000 Subject: Review Request JDK-8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module In-Reply-To: References: <3A17E47D-B9ED-4D0D-9258-DDADAE3403CC@oracle.com> <97E6A7B9-D6B0-4833-BE6C-DAB0E2528817@univ-mlv.fr> Message-ID: Ok, thanks. R?mi On April 8, 2017 4:49:13 PM GMT+02:00, Mandy Chung wrote: >No change in that regards. The updated test [1] in the webrev shows it >patches java.base/jdk.internal.modules.SystemModules > >Before this fix, you can do ?patch-module jdk.internal.vm.compiler=.jar >?upgrade-module-path graal.jar. The reason is that ?patch-module >disables the hash checking that makes non-upgradeable module >upgradeable. After this fix, it fails if you attempt upgrade a patched >non-upgradeable module. > >[1] >http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01/test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java.frames.html > >> On Apr 8, 2017, at 7:22 AM, Remi Forax wrote: >> >> Hi Mandy, >> how can I test a change in java.lang after that patch ? >> >> R?mi >> >> >> On April 8, 2017 7:50:50 AM GMT+02:00, Mandy Chung > wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177844/webrev.01 >/ >> >> This fixes -?patch-module to do hash checking on the module being >patched >> so that it will ensure that a non-upgradeable module remains not >upgradeable. >> >> As Graal has been using ?-patch-module option to disable the hash >checking >> to load a different version of jdk.internal.vm.compiler, it needs a >> mechanism to load Graal, as tracked by JDK-8177845. >> >> Mandy >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From mandy.chung at oracle.com Sat Apr 8 17:22:44 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 08 Apr 2017 17:22:44 +0000 Subject: hg: jigsaw/jake/jdk: 8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module Message-ID: <201704081722.v38HMiIQ028422@aojmv0008.oracle.com> Changeset: b2160414fe8c Author: mchung Date: 2017-04-08 10:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2160414fe8c 8177844: Ensure non-upgradeable modules cannot be upgraded even with --patch-module Reviewed-by: alanb ! src/java.base/share/classes/java/lang/module/Resolver.java ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java From Alan.Bateman at oracle.com Sun Apr 9 16:19:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 9 Apr 2017 17:19:50 +0100 Subject: Aliasing (automatic) modules In-Reply-To: <9c478a29-4d62-f25e-9ab8-6873622226c2@codefx.org> References: <9c478a29-4d62-f25e-9ab8-6873622226c2@codefx.org> Message-ID: <99b66257-2633-b0fd-f575-b6e58cacfc75@oracle.com> On 08/04/2017 12:35, Nicolai Parlog wrote: > Hi again, > > so far most (all?) proposals for handling automatic module names tackled > the "what is the module's real name" aspect of this question but I have > seen none that would push the likelihood of the same dependency being > referenced by different names reasonably close to zero. The original exploratory phase of Project Jigsaw did explore (and had basic implementation support for) aliases. It went away, along with many other features, when the design was radically simplified. So there is some understanding here of using aliases at either declaration-site or use-site (the CLI option suggested in your mail is one approach to use-site). As regards trying to introduce something now then it's matter for JSR 376. However, I don't see it happening as it's too late in JDK 9 to be introducing new concepts. Also in this case then it would be a change that has subtle interactions in several areas and there just isn't enough time to shake out that tail of issues. -Alan From mark.reinhold at oracle.com Sun Apr 9 20:58:58 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:58:58 +0000 Subject: hg: jigsaw/jake: Added tag jpms-pr2 for changeset 4749335f788f Message-ID: <201704092058.v39KwxS6014835@aojmv0008.oracle.com> Changeset: a787dca95191 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a787dca95191 Added tag jpms-pr2 for changeset 4749335f788f ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:03 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:03 +0000 Subject: hg: jigsaw/jake/corba: Added tag jpms-pr2 for changeset 9bc5ee131c5b Message-ID: <201704092059.v39Kx39C014911@aojmv0008.oracle.com> Changeset: f79c55d85600 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f79c55d85600 Added tag jpms-pr2 for changeset 9bc5ee131c5b ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:08 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:08 +0000 Subject: hg: jigsaw/jake/hotspot: Added tag jpms-pr2 for changeset 3ef5cda929ab Message-ID: <201704092059.v39Kx8R4015002@aojmv0008.oracle.com> Changeset: 4129a3cc9339 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4129a3cc9339 Added tag jpms-pr2 for changeset 3ef5cda929ab ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:12 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:12 +0000 Subject: hg: jigsaw/jake/jaxp: Added tag jpms-pr2 for changeset ed538fa31edb Message-ID: <201704092059.v39KxCA4015076@aojmv0008.oracle.com> Changeset: 471fb51e88f3 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/471fb51e88f3 Added tag jpms-pr2 for changeset ed538fa31edb ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:16 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:16 +0000 Subject: hg: jigsaw/jake/jaxws: Added tag jpms-pr2 for changeset af75b2041f87 Message-ID: <201704092059.v39KxGl1015153@aojmv0008.oracle.com> Changeset: 62cdc22fb741 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/62cdc22fb741 Added tag jpms-pr2 for changeset af75b2041f87 ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:21 +0000 Subject: hg: jigsaw/jake/jdk: Added tag jpms-pr2 for changeset b2160414fe8c Message-ID: <201704092059.v39KxL6T015235@aojmv0008.oracle.com> Changeset: 89da9f6d9b30 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89da9f6d9b30 Added tag jpms-pr2 for changeset b2160414fe8c ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:26 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:26 +0000 Subject: hg: jigsaw/jake/langtools: Added tag jpms-pr2 for changeset ff80ebf4ace6 Message-ID: <201704092059.v39KxQWi015311@aojmv0008.oracle.com> Changeset: 37f6bf474928 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/37f6bf474928 Added tag jpms-pr2 for changeset ff80ebf4ace6 ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 20:59:30 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 20:59:30 +0000 Subject: hg: jigsaw/jake/nashorn: Added tag jpms-pr2 for changeset b3ea15f8d67d Message-ID: <201704092059.v39KxUVq015387@aojmv0008.oracle.com> Changeset: ee4c180e7758 Author: mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ee4c180e7758 Added tag jpms-pr2 for changeset b3ea15f8d67d ! .hgtags From mark.reinhold at oracle.com Sun Apr 9 21:04:27 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 14:04:27 -0700 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <20170405163421.448261819@eggemoggin.niobe.net> Message-ID: <20170409140427.450814236@eggemoggin.niobe.net> 2017/4/6 2:07:27 -0700, michael.rasmussen at zeroturnaround.com: > On 6 April 2017 at 02:34, wrote: >> Interesting. Perhaps we need a `Self-Premain-Class` attribute, or some >> such. >> >> Out of curiosity, would it do any harm in your `java -jar` case if the >> agent is activated? > > As it is right now, yes, that would cause the execution to potentially fail. > Should a Self-Premain-Class (or like) not be implements, we would have > to check in the beginning of premain if we are running in java -jar > mode, and if such, make premain a no-op. Okay, so how about this revised proposal: - Define a new JAR-file manifest attribute, `Launcher-Agent-Class`. If this attribute is present in the manifest of an executable JAR file then the `agentmain` method of the specified class will be invoked prior to invoking the `main` method of the application. The JAR file will, effectively, be loaded also as a dynamic agent. This will allow `java -jar foo.jar` to be used in place of the more verbose `java -javaagent:foo.jar -jar foo.jar`. - Mark From mark.reinhold at oracle.com Sun Apr 9 21:12:02 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 14:12:02 -0700 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <1fd45a87-5e0e-8f4f-3746-31ad9b64518e@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <1fd45a87-5e0e-8f4f-3746-31ad9b64518e@redhat.com> Message-ID: <20170409141202.471363312@eggemoggin.niobe.net> 2017/4/6 3:09:49 -0700, Andrew Dinn : > On 05/04/17 17:15, mark.reinhold at oracle.com wrote: >> Thanks to everyone for the quick feedback on this topic, and especially >> to Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's >> on by default in JDK 9 but off by default in JDK 10. >> >> This will allow launch scripts that use this option on JDK 10 to >> work on JDK 9 without change, and will allow early testing of the >> JDK 10 behavior on JDK 9. > > This at the least is very welcome. It will give Red Hat and others the > time needed to prepare their users for for this change. > >> - Revise the `com.sun.tools.attach` API to forbid attachment to the >> current process or to an ancestor of the current process, and >> define a read-only system property that allows such attachment to >> be enabled via the command line. >> >> This will discourage the inadvertent use of libraries that, for >> better or for worse, intentionally violate strong encapsulation. > > I guess I'm agnostic to this. I'm certainly not against it. > > Is this change being proposed for JDK9 or JDK10? JDK 9. With `-XX:+EnableDynamicAgentLoading` off by default in JDK 9, this is one of the few ways we have left to discourage the use of encapsulation-busting libraries. >> ... >> >> Taken together, these changes are intended to enable the continued use >> of legitimate dynamically-loaded agents without change on JDK 9 and with >> a small change on JDK 10. That later change will align the treatment of >> such agents with the other means of breaking encapsulation (`--add-opens`, >> etc.) in order to ensure integrity by default for all code. > > That's a compromise position I can live with. Much as I want to retain > the ability to load my agent dynamically I also acknowledge that this is > one side of a trade-off. In particular, this proposal incorporates the > need for the JVM /eventually/ to have -- as a default -- a guarantee > that some portion of the code base cannot be subject to change and hence > is available for optimization without the need for ever more complex > apparatus to ensure later de-optimization. That's something I understand > the significance of and regard as very important for the future of the > JVM and JVM-based languages (not just Java). Indeed! That's a good summary of the tradeoff. > ... > >> This proposal does not attempt to lock down platform classes as distinct >> from user classes. Many agents have legitimate reasons to transform >> platform classes, so an additional mechanism to protect those classes >> does not appear to be worthwhile. > > I'm happy with this although it might be worth reviewing it later. Yes -- it wouldn't surprise me if we come back to this as we start to leverage integrity invariants for optimization. - Mark From mark.reinhold at oracle.com Sun Apr 9 21:22:09 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 09 Apr 2017 14:22:09 -0700 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <20170409142209.333143522@eggemoggin.niobe.net> 2017/4/6 10:48:12 -0700, alasdair.nottingham at gmail.com: > On Apr 5, 2017, at 12:15 PM, mark.reinhold at oracle.com wrote: >> >> Thanks to everyone for the quick feedback on this topic, and especially >> to Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's >> on by default in JDK 9 but off by default in JDK 10. >> >> This will allow launch scripts that use this option on JDK 10 to >> work on JDK 9 without change, and will allow early testing of the >> JDK 10 behavior on JDK 9. > > I think giving more time to react to the change is good, but I think this just > provides more notice that dynamic attach will go away, it doesn?t ultimately > provide a solution for the problems that are currently solved using dynamic > attach of agents. As Andrew Dinn writes nearby there really isn't a solution here, per se, there's just a tradeoff between flexibility and performance. >> - Revise the `com.sun.tools.attach` API to forbid attachment to the >> current process or to an ancestor of the current process, and >> define a read-only system property that allows such attachment to >> be enabled via the command line. >> >> This will discourage the inadvertent use of libraries that, for >> better or for worse, intentionally violate strong encapsulation. > > I think just preventing self-attach would be enough. I don?t think you need > to worry about the hierarchy. If you are going to the lengths of launching new > JVM?s to attach the agent I?m pretty sure that you have found out that you > cannot self attach, and are therefore already in the camp of knowing you are > doing something bad. Yes, I suspect you're right. We'll just forbid self-attachment for now. >> - Enhance the `-jar` launcher option so that if the JAR file being >> launched contains a `Premain-Class` attribute then it's launched >> as both an application and as an agent for that application. >> >> This will allow `java -jar foo.jar` to be used in place of the >> more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. >> > > I like this idea, it solves my problem in a much simpler way than having to > self attach. I don?t mind what the header is called, so if Self-Premain-Class is > used I can cope with that. Please see my nearby reply to Michael Rasumussen -- the new attribute will be named `Launcher-Agent-Class`. > I?m assuming this will continue to work in Java SE 10 > and only dynamic attach will be disabled in Java SE 10. `Launcher-Agent-Class` is a form of dynamic agent loading but it's well-scoped and not so easy to use inadvertently, so I suspect it will do no harm to leave it enabled even when dynamic loading via attachment is disabled by default. - Mark From rcmuir at gmail.com Sun Apr 9 22:15:44 2017 From: rcmuir at gmail.com (Robert Muir) Date: Sun, 9 Apr 2017 18:15:44 -0400 Subject: SecurityManager environments In-Reply-To: <83d9e03b-834a-0b5c-0e13-b5513475c0cf@oracle.com> References: <883259944-21059@kerio.abacus.ch> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> <83d9e03b-834a-0b5c-0e13-b5513475c0cf@oracle.com> Message-ID: I dont agree with the use of the word ephemeral here, thats misleading. Those permissions are *not* needed for outgoing connections. The default security policy of java absolutely allows for backdoors in server applications. It does not matter if port number is 80 or 8000 the effect is the same. On Apr 7, 2017 6:59 AM, "Alan Bateman" wrote: > On 07/04/2017 03:54, Robert Muir wrote: > > : >> >> Because of these problems, if you are a server-side app, even if you >> understand this stuff and want to do the right thing, its really hard >> to avoid simply granting all kinds of horrible permissions globally to >> all code. In my experience the worst problems are the internal api >> usage issues, so it would be nice to "give jigsaw a chance" to see if >> it makes the situation better. SecurityManager is really great if you >> want to prevent common security issues such as directory traversal, >> but its too hard for a server side app right now. >> > I agree with most of what you said in this mail. On "common java libraries > don't care about this stuff" then I think part of it is that the security > manager is not enabled by default so it's a completely different mode of > execution and so rarely tested by many library maintainers. Also to get the > permissions right requires understanding each of the privileged operations > that the library might need to do and putting that code in a privileged > block so that the library can be granted the permission rather than to > everyone. > > On your gripes with default policy, the "bogus crap" as you termed it :-). > It grants read access to a number of system properties and allows > applications to bind to ephemeral ports, that's it. It used to grant > "stopThread" (for compatibility reasons detailed in the comments) but this > is no longer the case in JDK 9. > > It may be that this thread should move to security-dev as that is the > right place to discuss usability and other issues with the security manager. > > -Alan. > From Alan.Bateman at oracle.com Mon Apr 10 06:07:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Apr 2017 07:07:36 +0100 Subject: SecurityManager environments In-Reply-To: References: <883259944-21059@kerio.abacus.ch> <3F129623-05F3-4FED-9DEA-640EED72FDC6@cox.net> <9B950308-EB7D-4D2C-8018-4E6D0C2CB909@oracle.com> <983A5981-BED1-4F07-ADBC-281DE3623640@cox.net> <068f4eaf-a509-6d30-41b8-421188f05461@oracle.com> <83d9e03b-834a-0b5c-0e13-b5513475c0cf@oracle.com> Message-ID: On 09/04/2017 23:15, Robert Muir wrote: > I dont agree with the use of the word ephemeral here, thats > misleading. Those permissions are *not* needed for outgoing connections. > > The default security policy of java absolutely allows for backdoors in > server applications. It does not matter if port number is 80 or 8000 > the effect is the same. > I think I said "bind" rather than "outgoing connection". If I'm granted `SocketPermission "localhost:0", "listen"` then I would expect `bind(null)` or `bind(new InetSocketAddress(0))` should succeed but I wouldn't expect to be able to bind to a specific port. In any case, the default permissions seem like a fine topic to bring to security-dev. AFAIK the only change to the defaults for JDK 9 is that `RuntimePermission "stopThread"` is dropped. -Alan. From michael.rasmussen at zeroturnaround.com Mon Apr 10 09:48:23 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Mon, 10 Apr 2017 12:48:23 +0300 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170409140427.450814236@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <20170405163421.448261819@eggemoggin.niobe.net> <20170409140427.450814236@eggemoggin.niobe.net> Message-ID: On 10 April 2017 at 00:04, wrote: > Okay, so how about this revised proposal: > > - Define a new JAR-file manifest attribute, `Launcher-Agent-Class`. > If this attribute is present in the manifest of an executable JAR > file then the `agentmain` method of the specified class will be > invoked prior to invoking the `main` method of the application. > The JAR file will, effectively, be loaded also as a dynamic agent. > > This will allow `java -jar foo.jar` to be used in place of the more > verbose `java -javaagent:foo.jar -jar foo.jar`. > > - Mark I think that is a better solution, also more backwards compatible, as it won't cause agents to unexpectedly start from existing jar files (as others also have pointed out in this thread). /Michael From alan.bateman at oracle.com Mon Apr 10 11:06:45 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Apr 2017 11:06:45 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704101106.v3AB6jKU015728@aojmv0008.oracle.com> Changeset: 4776864b2d10 Author: alanb Date: 2017-04-10 11:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4776864b2d10 Split --list-modules into --list-modules and --describe-module ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! test/tools/launcher/modules/listmods/ListModsTest.java - test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java ! test/tools/launcher/modules/listmods/src/java.transaction/module-info.java Changeset: e997ce8c88f5 Author: alanb Date: 2017-04-10 12:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e997ce8c88f5 Launch agents in executable JARs Disable attaching to self ! make/mapfiles/libinstrument/mapfile-vers ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.instrument/share/classes/module-info.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.instrument/share/native/libinstrument/InstrumentationImplNativeMethods.c ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java + test/com/sun/tools/attach/AttachSelf.java ! test/com/sun/tools/attach/java.policy.allow + test/java/lang/instrument/executableJAR/Agent.java + test/java/lang/instrument/executableJAR/AgentHelper.java + test/java/lang/instrument/executableJAR/ExecJarWithAgent.java + test/java/lang/instrument/executableJAR/Main.java ! test/java/util/logging/TestLoggerWeakRefLeak.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java From alan.bateman at oracle.com Mon Apr 10 11:30:24 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Apr 2017 11:30:24 +0000 Subject: hg: jigsaw/jake/jdk: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failing with exploded build Message-ID: <201704101130.v3ABUP36021236@aojmv0008.oracle.com> Changeset: 17abfe0ab91a Author: alanb Date: 2017-04-10 12:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/17abfe0ab91a tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failing with exploded build ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java From reto.merz at abacus.ch Mon Apr 10 12:13:31 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Mon, 10 Apr 2017 14:13:31 +0200 Subject: --add-opens and --add-modules in MANIFEST.MF Message-ID: Hi, There is a proposal to support --add-exports in MANIFEST.MF [1]. Are there any plans to support --add-opens and --add-modules also? The current spec does not list such new attributes [2]. I have seen that webstart uses --add-modules ALL-SYSTEM [3]. Wouldn't it make sense to change the default for "java -jar" to ALL-SYSTEM also? Otherwise there are apps which will no longer start with a simple double click [4]. One more question: Is there are way to list the default modules? It seems that "java --list-modules" prints all modules and "java --list-modules ALL-DEFAULT" does not work. Regards Reto [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest [2] http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html#JAR_Manifest [3] https://bugs.openjdk.java.net/browse/JDK-8152839 [4] http://forum.languagetool.org/t/lt-and-java-9/1588 From alan.bateman at oracle.com Mon Apr 10 12:16:02 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Apr 2017 12:16:02 +0000 Subject: hg: jigsaw/jake/jdk: --describe-module can't use -d as short form Message-ID: <201704101216.v3ACG2wS009706@aojmv0008.oracle.com> Changeset: eb5c6f46cde4 Author: alanb Date: 2017-04-10 13:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb5c6f46cde4 --describe-module can't use -d as short form ! src/java.base/share/native/libjli/java.c From Alan.Bateman at oracle.com Mon Apr 10 12:31:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Apr 2017 13:31:19 +0100 Subject: --add-opens and --add-modules in MANIFEST.MF In-Reply-To: References: Message-ID: On 10/04/2017 13:13, Reto Merz wrote: > Hi, > > There is a proposal to support --add-exports in MANIFEST.MF [1]. > Are there any plans to support --add-opens and --add-modules also? > The current spec does not list such new attributes [2]. The builds have supported Add-Opens (in addition to Add-Exports) for some time. The proposal is that they be JDK-specific attributes, this just means they won't be in the JAR file spec. There is no equivalent to `--add-modules` in executable JARs at this time. One reason is that this option is intended to be used in conjunction with `--add-module`. Another is subtle complications in startup as the VM doesn't know anything about executable JAR files. > : > > One more question: Is there are way to list the default modules? > It seems that "java --list-modules" prints all modules > and "java --list-modules ALL-DEFAULT" does not work. `--list-modules` lists the observable module. There is support in the jake forest for listing just the resolved modules but it doesn't have an agree option name yet (it's currently `--list-resolved-modules`). I expect this will be sorted out soon. In the mean-time, use -Xdiag:resolver as it prints the list of resolved modules at the end of the trace output. -Alan From Alan.Bateman at oracle.com Mon Apr 10 12:37:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Apr 2017 13:37:37 +0100 Subject: --add-opens and --add-modules in MANIFEST.MF In-Reply-To: References: Message-ID: On 10/04/2017 13:31, Alan Bateman wrote: > One reason is that this option is intended to be used in conjunction > with `--add-module`. A typo in my mail. I meant `--module-path` of course. From greggwon at cox.net Mon Apr 10 13:04:29 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Mon, 10 Apr 2017 08:04:29 -0500 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <5RM41v03g1VUyRY01RM6s1> References: <79bb680f-0fb6-40af-82d6-15f90ce3495a@default> <5RM41v03g1VUyRY01RM6s1> Message-ID: I really believe that we can't really flip off working applications with a JDK upgrade. It's developer and deployed cooperation no matter which way the switch are by default. Starting with unknowing developers, deployed and users having to suffer through discovery of what will it take to make their software work again just seems like an exercise in anarchy rather than helping the community gain better opportunities out of a more flexible JRE/JDK platform. This really is something that will negatively impact a much large body of ignorant users, who are not engaged here, than we can imagine. Gregg Sent from my iPhone > On Apr 7, 2017, at 8:20 AM, Martijn Verburg wrote: > > Hi all, > > I've come back into this thread late, but for us (jClarity) we're OK with > the revised proposal, it will give us the time with slow moving enterprise > customers to move to an explicit Java agent approach. > > Cheers, > Martijn > >> On 7 April 2017 at 13:53, Stephen Felts wrote: >> >> I have a problem with the second point. >> >> Oracle's application server has "FAST SWAP" functionality similar to >> JRebel built-in so that a developer can speed up the "edit -> build -> >> deploy -> test" cycle. >> It uses an internal agent that attaches to the server so customers don't >> need to see it, configure it, or even know the name of it. >> It only works on application classes in an exploded ear or war file. >> This proposal will make it so the JRebel agent will work but our own agent >> won't. >> >> Ironically, this feature only works in development mode and developers are >> the ones most likely to run without any scripts having the CLASSPATH set up >> and just run java weblogic.Server. >> So as I've said many times I don't want any JDK9 command line options. >> >> In trying to protect against the guilty, you are killing the innocent. >> >> It seems to me that it's late in Phase 2 of ramp-down of JDK 9 and this >> feature is not baked or well received. IMO no changes should be done in >> this area for JDK 9. >> >> >> -----Original Message----- >> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf >> Of mark.reinhold at oracle.com >> Sent: Wednesday, April 5, 2017 12:15 PM >> To: jigsaw-dev at openjdk.java.net >> Subject: Disallowing the dynamic loading of agents by default (revised) >> >> Thanks to everyone for the quick feedback on this topic, and especially to >> Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's >> on by default in JDK 9 but off by default in JDK 10. >> >> This will allow launch scripts that use this option on JDK 10 to >> work on JDK 9 without change, and will allow early testing of the >> JDK 10 behavior on JDK 9. >> >> - Revise the `com.sun.tools.attach` API to forbid attachment to the >> current process or to an ancestor of the current process, and >> define a read-only system property that allows such attachment to >> be enabled via the command line. >> >> This will discourage the inadvertent use of libraries that, for >> better or for worse, intentionally violate strong encapsulation. >> >> - Enhance the `-jar` launcher option so that if the JAR file being >> launched contains a `Premain-Class` attribute then it's launched >> as both an application and as an agent for that application. >> >> This will allow `java -jar foo.jar` to be used in place of the >> more verbose `java -javaagent:foo.jar -jar foo.jar` [1]. >> >> Taken together, these changes are intended to enable the continued use of >> legitimate dynamically-loaded agents without change on JDK 9 and with a >> small change on JDK 10. That later change will align the treatment of such >> agents with the other means of breaking encapsulation (`--add-opens`, >> etc.) in order to ensure integrity by default for all code. >> >> This proposal does not attempt to lock down platform classes as distinct >> from user classes. Many agents have legitimate reasons to transform >> platform classes, so an additional mechanism to protect those classes does >> not appear to be worthwhile. >> >> Comments? >> >> - Mark >> >> >> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- >> April/012000.html >> From Alan.Bateman at oracle.com Mon Apr 10 18:38:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Apr 2017 19:38:37 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <20170405161520.81729A2BC4@eggemoggin.niobe.net> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: The Jigsaw EA builds [1] have been refreshed to include some of the pieces in this proposal, specifically: - If an executable JAR contains a java agent then it will be started by `java -jar` when the main manifest has the `Launcher-Agent-Class` attribute. The entry point that is invoked is the `agentmain` method. In the HotSpot implementation then all Can-XXX attributes can be used. The Boot-Class-Path attribute can be used too, say for cases where the executable JAR brings a helper JAR with classes that need to be visible to the boot loader (when instrumenting classes in modules defined to the boot loader for example). The `Launcher-Agent-Class` attribute will be ignored when on small run-time image that doesn't include the `java.instrument` module. One other point to mention is that the proposal (and implementation) does not include any built-in support for providing options to the agent. If configuration is needed then one simple approach is to include a resource file in the JAR file with the options and have the agent read that with Class.getResourceXXX. - The attach API disallows attaching to the current process. For now, the "jdk.attach.allowAttachSelf" system property can be used for cases where the tool and target VM are the same process. The system property is set on the command line with `-Djdk.attach.allowAttachSelf` or `-Djdk.attach.allowAttachSelf=true`. It will be ignored on JDK 8 and older. The builds don't have the Serguei Spitsyn's patch for EnableDynamicAgentLoading yet. We're re-align that with the revised proposal so that there are builds available to try out in the coming days. -Alan [1] https://jdk9.java.net/jigsaw/ From andrey.x.nazarov at oracle.com Mon Apr 10 19:30:12 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 10 Apr 2017 22:30:12 +0300 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: References: Message-ID: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> Mandy, thanks for review. I?ve updated patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ See my comments inline > On 8 Apr 2017, at 03:18, Mandy Chung wrote: > > >> On Apr 7, 2017, at 8:40 AM, Andrey Nazarov wrote: >> >> Hi, >> >> Please review 3 negative tests for Jlink which tests new bind-services/suggest-providers feature. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178323 >> >> webrev: http://cr.openjdk.java.net/~anazarov/8178323/webrev.00/webrev/ > > Thanks for adding these tests. > > BindServices.java > > 155 Path dir = Paths.get("verboseNoop?); > > I suggest to rename ?verboseNoop? to ?verboseNoBind? fixed > > line 159-161: formatting nit: can you add spaces to align with the first > argument in line 158. Same comment to SuggestProviders.java line 180-182 > an 198-200. Fixed > > SuggestProviders.java > It may be better to rename ?suggestNotProvider" to ?noSuggestedProvider?. We already have test with name noSuggestProvider. Idea here was to specify real existing type which is not provider according to module-info.java. I?ve renamed to ?suggestTypeNotRealProvider?. > > In the noOneUsesProvider test case, is m4 not observable? I think > jlink should fail with m4 not found. When ?-suggest-providers is > specified with a service type, it?s a bug in the implementation that > does not report it. This should be renamed to ?nonObservableModule? > instead. We should file a bug and include this test case in the JBS report. Actually there are two issues here: https://bugs.openjdk.java.net/browse/JDK-8178404 https://bugs.openjdk.java.net/browse/JDK-8178405 > > Mandy From rahman.usta.88 at gmail.com Mon Apr 10 19:35:20 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Mon, 10 Apr 2017 22:35:20 +0300 Subject: jlink output re-create parameter Message-ID: When using the jlink command if there is a created directory, jlink gives "Error: directory already exists: " output. I remember it was overwriting the files in earlier releases. I think there could be a -f parameter to force overwriting or recreating the output. Thanks -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From Alan.Bateman at oracle.com Mon Apr 10 20:31:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Apr 2017 21:31:11 +0100 Subject: jlink output re-create parameter In-Reply-To: References: Message-ID: <8310e3ac-fa47-d593-fd07-6f6c328e8462@oracle.com> On 10/04/2017 20:35, Rahman USTA wrote: > When using the jlink command if there is a created directory, jlink gives > "Error: directory already exists: " output. I remember it was > overwriting the files in earlier releases. I think there could be a -f > parameter to force overwriting or recreating the output. > I don't recall it every overriding as that would be problematic if the existing run-time image is in use. If jlink were to blow away the existing image then it might cause existing VMs to SIGBUS. On Windows then it won't be able to remove all files. Moving the directory to a .bak directory has also been looked at but it has issues too. -Alan From rahman.usta.88 at gmail.com Mon Apr 10 20:35:28 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Mon, 10 Apr 2017 23:35:28 +0300 Subject: jlink output re-create parameter In-Reply-To: <8310e3ac-fa47-d593-fd07-6f6c328e8462@oracle.com> References: <8310e3ac-fa47-d593-fd07-6f6c328e8462@oracle.com> Message-ID: I got it, thank you for the explanation. 2017-04-10 23:31 GMT+03:00 Alan Bateman : > On 10/04/2017 20:35, Rahman USTA wrote: > > When using the jlink command if there is a created directory, jlink gives >> "Error: directory already exists: " output. I remember it was >> overwriting the files in earlier releases. I think there could be a -f >> parameter to force overwriting or recreating the output. >> >> I don't recall it every overriding as that would be problematic if the > existing run-time image is in use. If jlink were to blow away the existing > image then it might cause existing VMs to SIGBUS. On Windows then it won't > be able to remove all files. Moving the directory to a .bak directory has > also been looked at but it has issues too. > > -Alan > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From mandy.chung at oracle.com Mon Apr 10 20:50:33 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Apr 2017 13:50:33 -0700 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> References: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> Message-ID: <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> > On Apr 10, 2017, at 12:30 PM, Andrey Nazarov wrote: > > Mandy, thanks for review. I?ve updated patch > http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ > I suggest to add m4/p4.S to make it clear it?s a service type and m4 provides p4.S with p4.Impl. noOneUsesProvider will call ?suggest-providers p4.S instead. 239 static JLink run(boolean expectSuccess, String... options) { Instead of adding a new parameter, what about adding a new runWithNonZeroExitCode method? > See my comments inline >> >> >> line 159-161: formatting nit: can you add spaces to align with the first >> argument in line 158. Same comment to SuggestProviders.java line 180-182 >> an 198-200. > Fixed line 216-219. > Actually there are two issues here: > https://bugs.openjdk.java.net/browse/JDK-8178404 > https://bugs.openjdk.java.net/browse/JDK-8178405 Not really a bug but it?d be helpful to show that the provider exists but the service is not used in this case. Mandy From rahman.usta.88 at gmail.com Mon Apr 10 21:49:25 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 11 Apr 2017 00:49:25 +0300 Subject: jna-platform,xalan, batik-script InvalidModuleDescriptorException Message-ID: I try to adopt my application to Java 9. It use several 3rd party dependency from Maven. I get the following exceptions Because I'm not the author of this libraries, how can I adopt this libraries to my Jigsaw project ? Thanks. 1) Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for \.m2\repository\net\java\dev\jna\jna-platform\4.4.0\jna-platform-4.4.0.jar Caused by: java.lang.module.InvalidModuleDescriptorException: Main-Class com.sun.jna.Native not in module 2) Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for \.m2\repository\org\apache\xmlgraphics\batik-script\1.8\batik-script-1.8.jar Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.batik.bridge.RhinoInterpreterFactory not in module 3) Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for \.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.bsf.BSFManager not in module Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From rahman.usta.88 at gmail.com Mon Apr 10 21:57:11 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 11 Apr 2017 00:57:11 +0300 Subject: jna-platform, xalan, batik-script InvalidModuleDescriptorException In-Reply-To: References: Message-ID: adopt -> adapt, sorry. 2017-04-11 0:49 GMT+03:00 Rahman USTA : > I try to adopt my application to Java 9. It use several 3rd party > dependency from Maven. I get the following exceptions Because I'm not the > author of this libraries, how can I adopt this libraries to my Jigsaw > project ? > > Thanks. > > 1) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\net\java\dev\jna\jna-platform\4.4.0\jna-platform-4.4.0.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Main-Class > com.sun.jna.Native not in module > > 2) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\org\apache\xmlgraphics\batik-script\1.8\ > batik-script-1.8.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.batik.bridge.RhinoInterpreterFactory not in module > > 3) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.bsf.BSFManager not in module > > Thanks. > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From kevin.rushforth at oracle.com Mon Apr 10 22:56:25 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Apr 2017 15:56:25 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> Message-ID: <58EC0D99.1070700@oracle.com> Sorry for the delay in responding. I added a simple test program to the JBS bug that shows the same behavior as the application and also an evaluation of the bug. The short version is that JavaFX beans is (mostly) working as expected, except for the misleading exception message. In JDK 9 it is required that any object that is reflected on by JavaFX beans, specifically the items passed to TableView, which are accessed via a PropertyValueFactory, will need to be in a package that is exported unconditionally. In JDK 10 we can look into relaxing this requirement such that the package only needs to be exported to javafx.beans. I do think we need to make the exception message less confusing in JDK 9 and also document the requirement in the appropriate places (at least in TableView and probably in a couple of javafx.beans.property.adapter classes). Comments? -- Kevin Mandy Chung wrote: > Hi Trisha, > > Thanks for the report and stack trace. I created > https://bugs.openjdk.java.net/browse/JDK-8177566 for further > investigation. > > Mandy > > > >> On Mar 24, 2017, at 2:34 PM, Trisha Gee wrote: >> >> Hi, >> >> I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a >> project to using Java 9 modules (specifically, this project: >> https://github.com/trishagee/sense-nine) and mentioned some surprising >> behaviour in a module that uses JavaFX. I've been asked to send the >> details so people can take a look at it. >> >> My module-info.java is here: >> https://github.com/trishagee/sense-nine/blob/master/src/com.mechanitis.demo.sense.client/module-info.java >> Note that I have to export two additional packages (mood and user), and I >> did not expect (or really want) to. This is because I was getting this >> error if I did not: >> >> java.lang.reflect.InvocationTargetException >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:482) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:381) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >> at >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:912) >> Caused by: java.lang.RuntimeException: Exception in Application start method >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:982) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:200) >> at java.base/java.lang.Thread.run(Thread.java:844) >> Caused by: java.lang.RuntimeException: *java.lang.IllegalAccessException: >> class sun.reflect.misc.Trampoline cannot access class >> com.mechanitis.demo.sense.client.user.TwitterUser (in module >> com.mechanitis.demo.sense.client) because module >> com.mechanitis.demo.sense.client does not export >> com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6* >> at >> javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:200) >> at >> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.getCellDataReflectively(PropertyValueFactory.java:145) >> at >> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:119) >> at >> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:98) >> at >> javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:579) >> at >> javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:564) >> at >> javafx.controls/javafx.scene.control.TableCell.updateItem(TableCell.java:645) >> at >> javafx.controls/javafx.scene.control.TableCell.indexChanged(TableCell.java:468) >> at >> javafx.controls/javafx.scene.control.IndexedCell.updateIndex(IndexedCell.java:116) >> at >> javafx.controls/javafx.scene.control.skin.TableRowSkinBase.updateCells(TableRowSkinBase.java:534) >> at >> javafx.controls/javafx.scene.control.skin.TableRowSkinBase.(TableRowSkinBase.java:159) >> at >> javafx.controls/javafx.scene.control.skin.TableRowSkin.(TableRowSkin.java:89) >> at >> javafx.controls/javafx.scene.control.TableRow.createDefaultSkin(TableRow.java:212) >> at >> javafx.controls/javafx.scene.control.Control.doProcessCSS(Control.java:895) >> at javafx.controls/javafx.scene.control.Control.access$000(Control.java:83) >> at >> javafx.controls/javafx.scene.control.Control$1.doProcessCSS(Control.java:89) >> at >> javafx.controls/com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67) >> at >> javafx.graphics/com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:147) >> at javafx.graphics/javafx.scene.Node.processCSS(Node.java:9356) >> at javafx.graphics/javafx.scene.Node.applyCss(Node.java:9443) >> at >> javafx.controls/javafx.scene.control.skin.VirtualFlow.setCellIndex(VirtualFlow.java:1697) >> at >> javafx.controls/javafx.scene.control.skin.VirtualFlow.getCell(VirtualFlow.java:1674) >> at >> javafx.controls/javafx.scene.control.skin.VirtualFlow.getCellLength(VirtualFlow.java:1781) >> at >> javafx.controls/javafx.scene.control.skin.VirtualFlow.computeViewportOffset(VirtualFlow.java:2618) >> at >> javafx.controls/javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1242) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1226) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >> at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:585) >> at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1767) >> at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:389) >> at >> javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66) >> at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1092) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >> at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1180) >> at javafx.graphics/javafx.stage.Window.show(Window.java:1195) >> at javafx.graphics/javafx.stage.Stage.show(Stage.java:267) >> at >> com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard.start(Dashboard.java:45) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:928) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$11(PlatformImpl.java:449) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$9(PlatformImpl.java:418) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:417) >> at >> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native >> Method) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:189) >> ... 1 more >> Caused by: java.lang.IllegalAccessException: class >> sun.reflect.misc.Trampoline cannot access class >> com.mechanitis.demo.sense.client.user.TwitterUser (in module >> com.mechanitis.demo.sense.client) because module >> com.mechanitis.demo.sense.client does not export >> com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6 >> at >> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:423) >> at >> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:414) >> at >> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112) >> at >> java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:632) >> at >> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:624) >> at java.base/java.lang.reflect.Method.invoke(Method.java:539) >> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) >> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >> at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:261) >> at >> javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:198) >> ... 48 more >> >> When I discovered this I was a bit stumped about what was in the unnamed >> module, given this appears to be JavaFX code causing this. >> >> I'm running this from inside IntelliJ IDEA, this is the command it's >> calling: "C:\Program Files\Java\jdk-9\bin\java" >> -Djava.util.logging.config.file=logging.properties >> -javaagent:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\lib\idea_rt.jar=54310:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\bin >> -Dfile.encoding=UTF-8 -p >> C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.client;C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.service;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\javax-websocket-server-impl\9.4.1.v20170120\javax-websocket-server-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-annotations\9.4.1.v20170120\jetty-annotations-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-plus\9.4.1.v20170120\jetty-plus-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-webapp\9.4.1.v20170120\jetty-webapp-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-xml\9.4.1.v20170120\jetty-xml-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-util\9.4.1.v20170120\jetty-util-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-servlet\9.4.1.v20170120\jetty-servlet-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-security\9.4.1.v20170120\jetty-security-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-server\9.4.1.v20170120\jetty-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\servlet\javax.servlet-api\3.1.0\javax.servlet-api-3.1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-http\9.4.1.v20170120\jetty-http-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-io\9.4.1.v20170120\jetty-io-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-jndi\9.4.1.v20170120\jetty-jndi-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\annotation\javax.annotation-api\1.2\javax.annotation-api-1.2.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm\5.1\asm-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-commons\5.1\asm-commons-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-tree\5.1\asm-tree-5.1.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\javax-websocket-client-impl\9.4.1.v20170120\javax-websocket-client-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-client\9.4.1.v20170120\websocket-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-client\9.4.1.v20170120\jetty-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-common\9.4.1.v20170120\websocket-common-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-api\9.4.1.v20170120\websocket-api-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\websocket\javax.websocket-api\1.0\javax.websocket-api-1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-server\9.4.1.v20170120\websocket-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-servlet\9.4.1.v20170120\websocket-servlet-9.4.1.v20170120.jar >> -m >> com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard >> >> Thanks, >> Trisha >> > > From mandy.chung at oracle.com Mon Apr 10 23:54:07 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Apr 2017 16:54:07 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58EC0D99.1070700@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> Message-ID: <88E5A395-1274-4D7E-89AC-88069195603B@oracle.com> It may be useful to point to the javadoc where it specifies to require the module to export the packages unconditionally. It would be a good RFE to relax the exports to at least javafx.beans. Mandy > On Apr 10, 2017, at 3:56 PM, Kevin Rushforth wrote: > > Sorry for the delay in responding. > > I added a simple test program to the JBS bug that shows the same behavior as the application and also an evaluation of the bug. > > The short version is that JavaFX beans is (mostly) working as expected, except for the misleading exception message. In JDK 9 it is required that any object that is reflected on by JavaFX beans, specifically the items passed to TableView, which are accessed via a PropertyValueFactory, will need to be in a package that is exported unconditionally. In JDK 10 we can look into relaxing this requirement such that the package only needs to be exported to javafx.beans. > > I do think we need to make the exception message less confusing in JDK 9 and also document the requirement in the appropriate places (at least in TableView and probably in a couple of javafx.beans.property.adapter classes). > > Comments? > > -- Kevin > > > Mandy Chung wrote: >> >> Hi Trisha, >> >> Thanks for the report and stack trace. I created >> https://bugs.openjdk.java.net/browse/JDK-8177566 for further >> investigation. >> >> Mandy >> >> >> >>> On Mar 24, 2017, at 2:34 PM, Trisha Gee wrote: >>> >>> Hi, >>> >>> I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a >>> project to using Java 9 modules (specifically, this project: >>> https://github.com/trishagee/sense-nine ) and mentioned some surprising >>> behaviour in a module that uses JavaFX. I've been asked to send the >>> details so people can take a look at it. >>> >>> My module-info.java is here: >>> https://github.com/trishagee/sense-nine/blob/master/src/com.mechanitis.demo.sense.client/module-info.java >>> Note that I have to export two additional packages (mood and user), and I >>> did not expect (or really want) to. This is because I was getting this >>> error if I did not: >>> >>> java.lang.reflect.InvocationTargetException >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >>> at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:482) >>> at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:381) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >>> at >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:912) >>> Caused by: java.lang.RuntimeException: Exception in Application start method >>> at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:982) >>> at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:200) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> Caused by: java.lang.RuntimeException: *java.lang.IllegalAccessException: >>> class sun.reflect.misc.Trampoline cannot access class >>> com.mechanitis.demo.sense.client.user.TwitterUser (in module >>> com.mechanitis.demo.sense.client) because module >>> com.mechanitis.demo.sense.client does not export >>> com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6* >>> at >>> javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:200) >>> at >>> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.getCellDataReflectively(PropertyValueFactory.java:145) >>> at >>> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:119) >>> at >>> javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:98) >>> at >>> javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:579) >>> at >>> javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:564) >>> at >>> javafx.controls/javafx.scene.control.TableCell.updateItem(TableCell.java:645) >>> at >>> javafx.controls/javafx.scene.control.TableCell.indexChanged(TableCell.java:468) >>> at >>> javafx.controls/javafx.scene.control.IndexedCell.updateIndex(IndexedCell.java:116) >>> at >>> javafx.controls/javafx.scene.control.skin.TableRowSkinBase.updateCells(TableRowSkinBase.java:534) >>> at >>> javafx.controls/javafx.scene.control.skin.TableRowSkinBase.(TableRowSkinBase.java:159) >>> at >>> javafx.controls/javafx.scene.control.skin.TableRowSkin.(TableRowSkin.java:89) >>> at >>> javafx.controls/javafx.scene.control.TableRow.createDefaultSkin(TableRow.java:212) >>> at >>> javafx.controls/javafx.scene.control.Control.doProcessCSS(Control.java:895) >>> at javafx.controls/javafx.scene.control.Control.access$000(Control.java:83) >>> at >>> javafx.controls/javafx.scene.control.Control$1.doProcessCSS(Control.java:89) >>> at >>> javafx.controls/com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67) >>> at >>> javafx.graphics/com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:147) >>> at javafx.graphics/javafx.scene.Node.processCSS(Node.java:9356) >>> at javafx.graphics/javafx.scene.Node.applyCss(Node.java:9443) >>> at >>> javafx.controls/javafx.scene.control.skin.VirtualFlow.setCellIndex(VirtualFlow.java:1697) >>> at >>> javafx.controls/javafx.scene.control.skin.VirtualFlow.getCell(VirtualFlow.java:1674) >>> at >>> javafx.controls/javafx.scene.control.skin.VirtualFlow.getCellLength(VirtualFlow.java:1781) >>> at >>> javafx.controls/javafx.scene.control.skin.VirtualFlow.computeViewportOffset(VirtualFlow.java:2618) >>> at >>> javafx.controls/javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1242) >>> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1226) >>> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >>> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >>> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) >>> at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:585) >>> at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1767) >>> at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:389) >>> at >>> javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66) >>> at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1092) >>> at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>> at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1180) >>> at javafx.graphics/javafx.stage.Window.show(Window.java:1195) >>> at javafx.graphics/javafx.stage.Stage.show(Stage.java:267) >>> at >>> com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard.start(Dashboard.java:45) >>> at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:928) >>> at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$11(PlatformImpl.java:449) >>> at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$9(PlatformImpl.java:418) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:417) >>> at >>> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>> at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native >>> Method) >>> at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:189) >>> ... 1 more >>> Caused by: java.lang.IllegalAccessException: class >>> sun.reflect.misc.Trampoline cannot access class >>> com.mechanitis.demo.sense.client.user.TwitterUser (in module >>> com.mechanitis.demo.sense.client) because module >>> com.mechanitis.demo.sense.client does not export >>> com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6 >>> at >>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:423) >>> at >>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:414) >>> at >>> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112) >>> at >>> java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:632) >>> at >>> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:624) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:539) >>> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) >>> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) >>> at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:547) >>> at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:261) >>> at >>> javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:198) >>> ... 48 more >>> >>> When I discovered this I was a bit stumped about what was in the unnamed >>> module, given this appears to be JavaFX code causing this. >>> >>> I'm running this from inside IntelliJ IDEA, this is the command it's >>> calling: "C:\Program Files\Java\jdk-9\bin\java" >>> -Djava.util.logging.config.file=logging.properties >>> -javaagent:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\lib\idea_rt.jar=54310:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\bin >>> -Dfile.encoding=UTF-8 -p >>> C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.client;C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.service;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\javax-websocket-server-impl\9.4.1.v20170120\javax-websocket-server-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-annotations\9.4.1.v20170120\jetty-annotations-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-plus\9.4.1.v20170120\jetty-plus-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-webapp\9.4.1.v20170120\jetty-webapp-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-xml\9.4.1.v20170120\jetty-xml-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-util\9.4.1.v20170120\jetty-util-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-servlet\9.4.1.v20170120\jetty-servlet-9.4.1 >>> .v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-security\9.4.1.v20170120\jetty-security-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-server\9.4.1.v20170120\jetty-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\servlet\javax.servlet-api\3.1.0\javax.servlet-api-3.1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-http\9.4.1.v20170120\jetty-http-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-io\9.4.1.v20170120\jetty-io-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-jndi\9.4.1.v20170120\jetty-jndi-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\annotation\javax.annotation-api\1.2\javax.annotation-api-1.2.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm\5.1\asm-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-commons\5.1\asm-commons-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-tree\5.1\asm-tree-5.1.jar;C:\Users\Trisha\.m >>> 2\repository\org\eclipse\jetty\websocket\javax-websocket-client-impl\9.4.1.v20170120\javax-websocket-client-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-client\9.4.1.v20170120\websocket-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-client\9.4.1.v20170120\jetty-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-common\9.4.1.v20170120\websocket-common-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-api\9.4.1.v20170120\websocket-api-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\websocket\javax.websocket-api\1.0\javax.websocket-api-1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-server\9.4.1.v20170120\websocket-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-servlet\9.4.1.v20170120\websocket-servlet-9.4.1.v20170120.jar >>> -m >>> com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard >>> >>> Thanks, >>> Trisha >>> >> >> From mandy.chung at oracle.com Tue Apr 11 00:09:34 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Apr 2017 17:09:34 -0700 Subject: jna-platform, xalan, batik-script InvalidModuleDescriptorException In-Reply-To: References: Message-ID: <68FA417F-886D-4DA5-849D-1FC93CCADEBF@oracle.com> > On Apr 10, 2017, at 2:49 PM, Rahman USTA wrote: > > I try to adopt my application to Java 9. It use several 3rd party > dependency from Maven. I get the following exceptions Because I'm not the > author of this libraries, how can I adopt this libraries to my Jigsaw > project ? > I suggest you contact the maintainer of this library to publish a version that can be run as a module. These libraries fail to be loaded as automatic modules because they reference classes that are not in the local module. > Thanks. > > 1) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\net\java\dev\jna\jna-platform\4.4.0\jna-platform-4.4.0.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Main-Class > com.sun.jna.Native not in module > com.sun.jna.Native is in a different artifact net.java.dev.jna:jna:4.4.0. When you place it in the module path as an automatic module, the main class is expected to be local in the same module. Since it?s in a different module, it fails to load jna-platform-4.4.0.jar as automatic module. jdeps -jdkinternals shows that it depends on an internal API. jna-platform-4.4.0.jar -> java.desktop com.sun.jna.platform.WindowUtils$MacWindowUtils$1 -> java.awt.peer.ComponentPeer JDK internal API (java.desktop) Similarly, the other InvalidModuleDescriptorException you got indicates that it fails to load the JAR file as automatic module and reconstitute the module descriptor. > 2) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\org\apache\xmlgraphics\batik-script\1.8\batik-script-1.8.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.batik.bridge.RhinoInterpreterFactory not in module > There exists META-INF/services/org.apache.batik.script.InterpreterFactory config file with a provider class that is not in this module. > 3) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.bsf.BSFManager not in module > Similar to batik-script case. Mandy > Thanks. > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From stephen.felts at oracle.com Tue Apr 11 04:31:10 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 10 Apr 2017 21:31:10 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> Message-ID: <66a366d2-f56e-4883-a287-5b9bcb3e5d7c@default> The description below leaves out the " ancestor of the current process". Which way is it - do we need to start two processes or one to work around this? -----Original Message----- From: Alan Bateman Sent: Monday, April 10, 2017 2:39 PM To: jigsaw-dev at openjdk.java.net Subject: Re: Disallowing the dynamic loading of agents by default (revised) The Jigsaw EA builds [1] have been refreshed to include some of the pieces in this proposal, specifically: - If an executable JAR contains a java agent then it will be started by `java -jar` when the main manifest has the `Launcher-Agent-Class` attribute. The entry point that is invoked is the `agentmain` method. In the HotSpot implementation then all Can-XXX attributes can be used. The Boot-Class-Path attribute can be used too, say for cases where the executable JAR brings a helper JAR with classes that need to be visible to the boot loader (when instrumenting classes in modules defined to the boot loader for example). The `Launcher-Agent-Class` attribute will be ignored when on small run-time image that doesn't include the `java.instrument` module. One other point to mention is that the proposal (and implementation) does not include any built-in support for providing options to the agent. If configuration is needed then one simple approach is to include a resource file in the JAR file with the options and have the agent read that with Class.getResourceXXX. - The attach API disallows attaching to the current process. For now, the "jdk.attach.allowAttachSelf" system property can be used for cases where the tool and target VM are the same process. The system property is set on the command line with `-Djdk.attach.allowAttachSelf` or `-Djdk.attach.allowAttachSelf=true`. It will be ignored on JDK 8 and older. The builds don't have the Serguei Spitsyn's patch for EnableDynamicAgentLoading yet. We're re-align that with the revised proposal so that there are builds available to try out in the coming days. -Alan [1] https://jdk9.java.net/jigsaw/ From Alan.Bateman at oracle.com Tue Apr 11 06:58:51 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Apr 2017 07:58:51 +0100 Subject: jna-platform, xalan, batik-script InvalidModuleDescriptorException In-Reply-To: References: Message-ID: On 10/04/2017 22:49, Rahman USTA wrote: > : > > 1) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\net\java\dev\jna\jna-platform\4.4.0\jna-platform-4.4.0.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Main-Class > com.sun.jna.Native not in module I don't know why this JAR file has a Main-Class attribute but I assume that `java -jar jna-platform-4.4.0.jar` doesn't work or only works when the JAR file containing the entry point is brought into the environment. I see Mandy's note about this JAR file seems to have code that using the AWT peer API so I assume this library is going to need work anyway. > > 2) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\org\apache\xmlgraphics\batik-script\1.8\batik-script-1.8.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.batik.bridge.RhinoInterpreterFactory not in module > > 3) Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for > \.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider > class org.apache.bsf.BSFManager not in module The class path is leaky in that a JAR file can name a class in its META-INF/services configuration file and the class is loaded from another JAR file. It would be interesting to see if that is the case with these two projects. I assume if deployed in isolation on the class path that ServiceConfigurationError is throw when the providers cannot be loaded. As regards moving forward then do you have direct dependences on these libraries? If the dependences not direct then you could leave these JAR files on the class path (assuming they actually work there). When migrating to modules then it's okay to do this, esp. with legacy libraries with issues that prevent them being used as modules. -Alan From Alan.Bateman at oracle.com Tue Apr 11 07:00:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Apr 2017 08:00:53 +0100 Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <66a366d2-f56e-4883-a287-5b9bcb3e5d7c@default> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <66a366d2-f56e-4883-a287-5b9bcb3e5d7c@default> Message-ID: <73b39aa4-0375-acbd-680f-7285943c3ed0@oracle.com> On 11/04/2017 05:31, Stephen Felts wrote: > The description below leaves out the " ancestor of the current process". > Which way is it - do we need to start two processes or one to work around this? > The thread moved one from the original proposal. The only requirement now is that the tool and target VMs are different. -Alan From magnus.ihse.bursie at oracle.com Tue Apr 11 07:40:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 09:40:07 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> Message-ID: On 2017-04-07 22:04, Mandy Chung wrote: > >> On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie >> > > wrote: >> >> >> Having though this over real hard, I'd realized I need to make a plea >> for sanity and consistency. I thought I should lay low in this >> discussion, but I can't. Choosing "amd64" as the name for the 64-bit >> x86 platform is really, really unfortunate and a step backwards in >> our effort to standardize the name of this platform. >> > > I think it may be useful to see the value of `os.arch` system property > on all platforms > at a glance. > > 32-bit64-bit > > linux i386amd64 > arm aarch64 > solaris amd64 > sparcv9 > windows x86 amd64 > macos x86_64 > > It's late in JDK 9. The best is to revisit OS and architecture names > in JDK 10 on the > consistency and simplicity issue. In the context of JDK-8175819, > these are names to > pass tojmod ?-os-name ?-os-arch options. The values are used at > resolution time > to avoid linking modules for different target platforms into the same > image. > > As Mark suggests, we use the value of `os.arch` system property for > JMOD file in > JDK 9 and we can change the value in JDK 10. No change to system > property and > bundle names, as we said previously. I agree. It's late in JDK 9. I'm OK with the proposal of using os.arch for JDK 9, as long as when we're revisiting the issue in JDK 10, we do not use the fact that it was used in JDK 9 as an argument for not changing it... /Magnus > > We should revisit OS and architecture names in JDK 10. I have updated > JDK-8178016 to reflect that. Are you okay with that? > > Below shows the old and new values in the `release` file and the new > values > are used in JMOD files. > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm > aarch64 aarch64 > > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html > > > Mandy From trisha.gee at gmail.com Tue Apr 11 08:36:23 2017 From: trisha.gee at gmail.com (Trisha Gee) Date: Tue, 11 Apr 2017 08:36:23 +0000 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <88E5A395-1274-4D7E-89AC-88069195603B@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <88E5A395-1274-4D7E-89AC-88069195603B@oracle.com> Message-ID: >From a user/developer point of view, a more descriptive error message would be a big help. I was completely at a loss to understand why I needed to unconditionally export my packages, I figured there was a requirement from the JavaFX-side of things but it wasn't clear what it was or why. A helpful error plus updated documentation would reduce confusion. On Tue, 11 Apr 2017 at 01:54 Mandy Chung wrote: > It may be useful to point to the javadoc where it specifies to require the > module to export the packages unconditionally. > > It would be a good RFE to relax the exports to at least javafx.beans. > > Mandy > > On Apr 10, 2017, at 3:56 PM, Kevin Rushforth > wrote: > > Sorry for the delay in responding. > > I added a simple test program to the JBS bug that shows the same behavior > as the application and also an evaluation of the bug. > > The short version is that JavaFX beans is (mostly) working as expected, > except for the misleading exception message. In JDK 9 it is required that > any object that is reflected on by JavaFX beans, specifically the items > passed to TableView, which are accessed via a PropertyValueFactory, will > need to be in a package that is exported unconditionally. In JDK 10 we can > look into relaxing this requirement such that the package only needs to be > exported to javafx.beans. > > I do think we need to make the exception message less confusing in JDK 9 > and also document the requirement in the appropriate places (at least in > TableView and probably in a couple of javafx.beans.property.adapter > classes). > > Comments? > > -- Kevin > > > Mandy Chung wrote: > > Hi Trisha, > > Thanks for the report and stack trace. I createdhttps://bugs.openjdk.java.net/browse/JDK-8177566 for further > investigation. > > Mandy > > > > > On Mar 24, 2017, at 2:34 PM, Trisha Gee wrote: > > Hi, > > I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a > project to using Java 9 modules (specifically, this project:https://github.com/trishagee/sense-nine) and mentioned some surprising > behaviour in a module that uses JavaFX. I've been asked to send the > details so people can take a look at it. > > My module-info.java is here:https://github.com/trishagee/sense-nine/blob/master/src/com.mechanitis.demo.sense.client/module-info.java > Note that I have to export two additional packages (mood and user), and I > did not expect (or really want) to. This is because I was getting this > error if I did not: > > java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:482) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:381) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:912) > Caused by: java.lang.RuntimeException: Exception in Application start method > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:982) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:200) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.RuntimeException: *java.lang.IllegalAccessException: > class sun.reflect.misc.Trampoline cannot access class > com.mechanitis.demo.sense.client.user.TwitterUser (in module > com.mechanitis.demo.sense.client) because module > com.mechanitis.demo.sense.client does not export > com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6* > at > javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:200) > at > javafx.controls/javafx.scene.control.cell.PropertyValueFactory.getCellDataReflectively(PropertyValueFactory.java:145) > at > javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:119) > at > javafx.controls/javafx.scene.control.cell.PropertyValueFactory.call(PropertyValueFactory.java:98) > at > javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:579) > at > javafx.controls/javafx.scene.control.TableColumn.getCellObservableValue(TableColumn.java:564) > at > javafx.controls/javafx.scene.control.TableCell.updateItem(TableCell.java:645) > at > javafx.controls/javafx.scene.control.TableCell.indexChanged(TableCell.java:468) > at > javafx.controls/javafx.scene.control.IndexedCell.updateIndex(IndexedCell.java:116) > at > javafx.controls/javafx.scene.control.skin.TableRowSkinBase.updateCells(TableRowSkinBase.java:534) > at > javafx.controls/javafx.scene.control.skin.TableRowSkinBase.(TableRowSkinBase.java:159) > at > javafx.controls/javafx.scene.control.skin.TableRowSkin.(TableRowSkin.java:89) > at > javafx.controls/javafx.scene.control.TableRow.createDefaultSkin(TableRow.java:212) > at > javafx.controls/javafx.scene.control.Control.doProcessCSS(Control.java:895) > at javafx.controls/javafx.scene.control.Control.access$000(Control.java:83) > at > javafx.controls/javafx.scene.control.Control$1.doProcessCSS(Control.java:89) > at > javafx.controls/com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:147) > at javafx.graphics/javafx.scene.Node.processCSS(Node.java:9356) > at javafx.graphics/javafx.scene.Node.applyCss(Node.java:9443) > at > javafx.controls/javafx.scene.control.skin.VirtualFlow.setCellIndex(VirtualFlow.java:1697) > at > javafx.controls/javafx.scene.control.skin.VirtualFlow.getCell(VirtualFlow.java:1674) > at > javafx.controls/javafx.scene.control.skin.VirtualFlow.getCellLength(VirtualFlow.java:1781) > at > javafx.controls/javafx.scene.control.skin.VirtualFlow.computeViewportOffset(VirtualFlow.java:2618) > at > javafx.controls/javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1242) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1226) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1233) > at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:585) > at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1767) > at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:389) > at > javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66) > at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1092) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1180) > at javafx.graphics/javafx.stage.Window.show(Window.java:1195) > at javafx.graphics/javafx.stage.Stage.show(Stage.java:267) > at > com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard.start(Dashboard.java:45) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:928) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$11(PlatformImpl.java:449) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$9(PlatformImpl.java:418) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:417) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:189) > ... 1 more > Caused by: java.lang.IllegalAccessException: class > sun.reflect.misc.Trampoline cannot access class > com.mechanitis.demo.sense.client.user.TwitterUser (in module > com.mechanitis.demo.sense.client) because module > com.mechanitis.demo.sense.client does not export > com.mechanitis.demo.sense.client.user to unnamed module @779d6cc6 > at > java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:423) > at > java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:414) > at > java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112) > at > java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:632) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:624) > at java.base/java.lang.reflect.Method.invoke(Method.java:539) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) > at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:547) > at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:261) > at > javafx.base/com.sun.javafx.property.PropertyReference.getProperty(PropertyReference.java:198) > ... 48 more > > When I discovered this I was a bit stumped about what was in the unnamed > module, given this appears to be JavaFX code causing this. > > I'm running this from inside IntelliJ IDEA, this is the command it's > calling: "C:\Program Files\Java\jdk-9\bin\java" > -Djava.util.logging.config.file=logging.properties > -javaagent:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\lib\idea_rt.jar=54310:C:\Users\Trisha\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\171.3780.107\bin > -Dfile.encoding=UTF-8 -p > C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.client;C:\Users\Trisha\Projects\trishagee\sense-nine\out\production\com.mechanitis.demo.sense.service;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\javax-websocket-server-impl\9.4.1.v20170120\javax-websocket-server-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-annotations\9.4.1.v20170120\jetty-annotations-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-plus\9.4.1.v20170120\jetty-plus-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-webapp\9.4.1.v20170120\jetty-webapp-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-xml\9.4.1.v20170120\jetty-xml-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-util\9.4.1.v20170120\jetty-util-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-servlet\9.4.1.v20170120\jetty-servlet-9.4.1 > .v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-security\9.4.1.v20170120\jetty-security-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-server\9.4.1.v20170120\jetty-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\servlet\javax.servlet-api\3.1.0\javax.servlet-api-3.1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-http\9.4.1.v20170120\jetty-http-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-io\9.4.1.v20170120\jetty-io-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-jndi\9.4.1.v20170120\jetty-jndi-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\annotation\javax.annotation-api\1.2\javax.annotation-api-1.2.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm\5.1\asm-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-commons\5.1\asm-commons-5.1.jar;C:\Users\Trisha\.m2\repository\org\ow2\asm\asm-tree\5.1\asm-tree-5.1.jar;C:\Users\Trisha\.m > 2\repository\org\eclipse\jetty\websocket\javax-websocket-client-impl\9.4.1.v20170120\javax-websocket-client-impl-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-client\9.4.1.v20170120\websocket-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\jetty-client\9.4.1.v20170120\jetty-client-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-common\9.4.1.v20170120\websocket-common-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-api\9.4.1.v20170120\websocket-api-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\javax\websocket\javax.websocket-api\1.0\javax.websocket-api-1.0.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-server\9.4.1.v20170120\websocket-server-9.4.1.v20170120.jar;C:\Users\Trisha\.m2\repository\org\eclipse\jetty\websocket\websocket-servlet\9.4.1.v20170120\websocket-servlet-9.4.1.v20170120.jar > -m > com.mechanitis.demo.sense.client/com.mechanitis.demo.sense.client.Dashboard > > Thanks, > Trisha > > > > > From erik.joelsson at oracle.com Tue Apr 11 10:05:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Apr 2017 12:05:56 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> Message-ID: On 2017-04-11 09:40, Magnus Ihse Bursie wrote: > > > On 2017-04-07 22:04, Mandy Chung wrote: >> >>> On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie >>> >> > wrote: >>> >>> >>> Having though this over real hard, I'd realized I need to make a >>> plea for sanity and consistency. I thought I should lay low in this >>> discussion, but I can't. Choosing "amd64" as the name for the 64-bit >>> x86 platform is really, really unfortunate and a step backwards in >>> our effort to standardize the name of this platform. >>> >> >> I think it may be useful to see the value of `os.arch` system >> property on all platforms >> at a glance. >> >> 32-bit64-bit >> >> linux i386amd64 >> arm aarch64 >> solaris amd64 >> sparcv9 >> windows x86 amd64 >> macos x86_64 >> >> It's late in JDK 9. The best is to revisit OS and architecture names >> in JDK 10 on the >> consistency and simplicity issue. In the context of JDK-8175819, >> these are names to >> pass tojmod ?-os-name ?-os-arch options. The values are used at >> resolution time >> to avoid linking modules for different target platforms into the same >> image. >> >> As Mark suggests, we use the value of `os.arch` system property for >> JMOD file in >> JDK 9 and we can change the value in JDK 10. No change to system >> property and >> bundle names, as we said previously. > > I agree. It's late in JDK 9. > > I'm OK with the proposal of using os.arch for JDK 9, as long as when > we're revisiting the issue in JDK 10, we do not use the fact that it > was used in JDK 9 as an argument for not changing it... > +1 /Erik > /Magnus > >> >> We should revisit OS and architecture names in JDK 10. I have updated >> JDK-8178016 to reflect that. Are you okay with that? >> >> Below shows the old and new values in the `release` file and the new >> values >> are used in JMOD files. >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm >> aarch64 aarch64 >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html >> >> >> >> Mandy > From alan.bateman at oracle.com Tue Apr 11 11:39:35 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 11 Apr 2017 11:39:35 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201704111139.v3BBdZZD017753@aojmv0008.oracle.com> Changeset: 842097f877f2 Author: alanb Date: 2017-04-11 12:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/842097f877f2 Add EnableDynamicAgentLoading option Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: af8942b1e722 Author: alanb Date: 2017-04-11 12:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/af8942b1e722 Update tests that attach to current VM ! test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java ! test/runtime/Metaspace/DefineClass.java From alan.bateman at oracle.com Tue Apr 11 11:39:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 11 Apr 2017 11:39:48 +0000 Subject: hg: jigsaw/jake/jdk: Add EnableDynamicAgentLoading option Message-ID: <201704111139.v3BBdmcE017890@aojmv0008.oracle.com> Changeset: 305afff7c279 Author: alanb Date: 2017-04-11 12:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/305afff7c279 Add EnableDynamicAgentLoading option Contributed-by: serguei.spitsyn at oracle.com, alan.bateman at oracle.com ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java ! test/com/sun/tools/attach/RunnerUtil.java From peter.levart at gmail.com Tue Apr 11 11:45:20 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Apr 2017 13:45:20 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> Hi Mandy, On 04/03/2017 11:50 PM, Mandy Chung wrote: > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!! Regards, Peter > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 From aguibert at us.ibm.com Tue Apr 11 14:36:21 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 11 Apr 2017 09:36:21 -0500 Subject: Intended usage of `java --dry-run`? Message-ID: I'm working with JDK build b162 and I see that the following option is listed: --dry-run create VM but do not execute main method. This --dry-run option may be useful for validating the command-line options such as the module system configuration. This looked like a convenient option for quickly verifying that I'm specifying other command line options correctly, so I decided to try it out. I was surprised to see that --dry-run prints out full usage information regardless of how it was used. This confused me because it lead me to believe that I was using the option incorrectly. Based on the mailing list discussion where --dry-run was introduced [1] it appears it is intended to be a more obvious substitute than using --version for validating command-line options. If that's the case, I find the following use cases to be inconsistent: ------------------------------------- $ java --version java 9-ea Java(TM) SE Runtime Environment (build 9-ea+162) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+162, mixed mode) $ java --dry-run Usage: java [options] class [args...] . . . full usage data ------------------------------------- $ java --add-modules java.se.ee Usage: java [options] class [args...] . . . full usage data $ java --add-modules java.se.ee --dry-run Usage: java [options] class [args...] . . . full usage data ------------------------------------- $ java --help Usage: java [options] class [args...] . . . full usage data $ java --dry-run Usage: java [options] class [args...] . . . full usage data ------------------------------------- Based on these three use cases, either I'm using --dry-run incorrectly (which isn't obvious if I am) or --dry-run is simply a placebo option. My main point of confusion comes from (what I believe to be) correct usage of --dry-run printing out usage info. For many command line utilities, printing out usage info (unless explicitly requested via --help) is a result of command line options being specified incorrectly. Instead of printing usage info on successful invocation of --dry-run, I think it would make more sense to give a short acknowledgement that a dry run of the VM took place, for example: $ java --dry-run Java VM successfully launched for dry run. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008397.html From Alan.Bateman at oracle.com Tue Apr 11 15:00:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Apr 2017 16:00:04 +0100 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: On 11/04/2017 15:36, Andrew Guibert wrote: > : > > Based on these three use cases, either I'm using --dry-run incorrectly > (which isn't obvious if I am) or --dry-run is simply a placebo option. My > main point of confusion comes from (what I believe to be) correct usage of > --dry-run printing out usage info. I assume the reason that your examples print the usage message is because you haven't specified the main class (or `-jar` or `-m`). If you try an example such as `java --dry-run -p

-m ` it will load the main class from the initial module and exit at that point without invoking the main method. -Alan From chris.bensen at oracle.com Tue Apr 11 15:12:15 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 11 Apr 2017 08:12:15 -0700 Subject: jlink output re-create parameter In-Reply-To: References: <8310e3ac-fa47-d593-fd07-6f6c328e8462@oracle.com> Message-ID: <2C7373E2-863F-42AF-90B7-F0D71D536591@oracle.com> Early on jlink when provided a non empty directory jlink would fail. That has since been fixed, at least for hidden files such as .DS_Store files. Chris > On Apr 10, 2017, at 1:35 PM, Rahman USTA wrote: > > I got it, thank you for the explanation. > > 2017-04-10 23:31 GMT+03:00 Alan Bateman : > >> On 10/04/2017 20:35, Rahman USTA wrote: >> >> When using the jlink command if there is a created directory, jlink gives >>> "Error: directory already exists: " output. I remember it was >>> overwriting the files in earlier releases. I think there could be a -f >>> parameter to force overwriting or recreating the output. >>> >>> I don't recall it every overriding as that would be problematic if the >> existing run-time image is in use. If jlink were to blow away the existing >> image then it might cause existing VMs to SIGBUS. On Windows then it won't >> be able to remove all files. Moving the directory to a .bak directory has >> also been looked at but it has issues too. >> >> -Alan >> > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From aguibert at us.ibm.com Tue Apr 11 16:13:53 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Tue, 11 Apr 2017 11:13:53 -0500 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: > From: Alan Bateman > To: Andrew Guibert/Rochester/IBM at IBMUS, jigsaw-dev dev at openjdk.java.net> > Date: 04/11/2017 10:00 AM > Subject: Re: Intended usage of `java --dry-run`? > > On 11/04/2017 15:36, Andrew Guibert wrote: > > > : > > > > Based on these three use cases, either I'm using --dry-run incorrectly > > (which isn't obvious if I am) or --dry-run is simply a placebo option. My > > main point of confusion comes from (what I believe to be) correct usage of > > --dry-run printing out usage info. > I assume the reason that your examples print the usage message is > because you haven't specified the main class (or `-jar` or `-m`). > > If you try an example such as `java --dry-run -p -m ` it > will load the main class from the initial module and exit at that point > without invoking the main method. Thanks for clarifying Alan. I misunderstood the use case of --dry-run to be that it did not require any main class, but instead the point is to *load* but not *execute* the main class. Perhaps this would be worth clarifying in the option description? - Andy From alan.bateman at oracle.com Tue Apr 11 16:39:12 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 11 Apr 2017 16:39:12 +0000 Subject: hg: jigsaw/jake/jdk: Reinstate java -d as short form of --describe-module Message-ID: <201704111639.v3BGdC7J028558@aojmv0008.oracle.com> Changeset: 0a2030572aa9 Author: alanb Date: 2017-04-11 17:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a2030572aa9 Reinstate java -d as short form of --describe-module ! src/java.base/share/native/libjli/java.c + test/tools/launcher/modules/describe/DescribeModuleTest.java From alan.bateman at oracle.com Tue Apr 11 16:39:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 11 Apr 2017 16:39:13 +0000 Subject: hg: jigsaw/jake/hotspot: compiler/profiling/spectrapredefineclass tests failing Message-ID: <201704111639.v3BGdDKF028562@aojmv0008.oracle.com> Changeset: dfc17fec1a0d Author: alanb Date: 2017-04-11 17:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dfc17fec1a0d compiler/profiling/spectrapredefineclass tests failing ! test/compiler/profiling/spectrapredefineclass/Launcher.java ! test/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java From andrey.x.nazarov at oracle.com Tue Apr 11 19:46:51 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 11 Apr 2017 22:46:51 +0300 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> References: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> Message-ID: <70769D9A-C2E0-4ACC-9C7E-CDF62E5434EA@oracle.com> Hi Mandy, Here is updated patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.02/webrev/ ? Thanks, Andrey > On 10 Apr 2017, at 23:50, Mandy Chung wrote: > > >> On Apr 10, 2017, at 12:30 PM, Andrey Nazarov > wrote: >> >> Mandy, thanks for review. I?ve updated patch >> http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ >> > > I suggest to add m4/p4.S to make it clear it?s a service type and m4 provides p4.S with p4.Impl. > noOneUsesProvider will call ?suggest-providers p4.S instead. > > 239 static JLink run(boolean expectSuccess, String... options) { > Instead of adding a new parameter, what about adding a new runWithNonZeroExitCode method? > >> See my comments inline >>> >>> >>> line 159-161: formatting nit: can you add spaces to align with the first >>> argument in line 158. Same comment to SuggestProviders.java line 180-182 >>> an 198-200. >> Fixed > > line 216-219. > >> Actually there are two issues here: >> https://bugs.openjdk.java.net/browse/JDK-8178404 >> https://bugs.openjdk.java.net/browse/JDK-8178405 > Not really a bug but it?d be helpful to show that the provider exists but the service is not used in this case. > Mandy > From andrey.x.nazarov at oracle.com Tue Apr 11 19:49:42 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 11 Apr 2017 22:49:42 +0300 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> References: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> Message-ID: <85071BBD-51DA-4F47-B9C3-26E33B74F50D@oracle.com> Hi Mandy, Here is updated patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.02/webrev/ ? Thanks, Andrey > On 10 Apr 2017, at 23:50, Mandy Chung > wrote: > > >> On Apr 10, 2017, at 12:30 PM, Andrey Nazarov > wrote: >> >> Mandy, thanks for review. I?ve updated patch >> http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ >> > > I suggest to add m4/p4.S to make it clear it?s a service type and m4 provides p4.S with p4.Impl. > noOneUsesProvider will call ?suggest-providers p4.S instead. > > 239 static JLink run(boolean expectSuccess, String... options) { > Instead of adding a new parameter, what about adding a new runWithNonZeroExitCode method? > >> See my comments inline >>> >>> >>> line 159-161: formatting nit: can you add spaces to align with the first >>> argument in line 158. Same comment to SuggestProviders.java line 180-182 >>> an 198-200. >> Fixed > > line 216-219. > >> Actually there are two issues here: >> https://bugs.openjdk.java.net/browse/JDK-8178404 >> https://bugs.openjdk.java.net/browse/JDK-8178405 > Not really a bug but it?d be helpful to show that the provider exists but the service is not used in this case. > Mandy > From mandy.chung at oracle.com Wed Apr 12 00:33:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Apr 2017 19:33:48 -0500 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> Message-ID: <042EE4F5-2120-4707-9660-CBA9546B1837@oracle.com> > On Apr 11, 2017, at 6:45 AM, Peter Levart wrote: > > Hi Mandy, > > On 04/03/2017 11:50 PM, Mandy Chung wrote: >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 > > i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!! Oops? a typo of course (should be removed). ?i586? is only used as bundle name. os.arch does not have ?i586? value. Mandy From chris.hegarty at oracle.com Wed Apr 12 12:40:21 2017 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 12 Apr 2017 12:40:21 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704121240.v3CCeLm9001486@aojmv0008.oracle.com> Changeset: 3277e976d3c4 Author: chegar Date: 2017-04-12 12:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3277e976d3c4 bug fix in jar Validator comparator ! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java + test/tools/jar/multiRelease/whitebox/Driver.java + test/tools/jar/multiRelease/whitebox/jdk.jartool/sun/tools/jar/ValidatorComparatorTest.java Changeset: 3c03f035f74d Author: chegar Date: 2017-04-12 12:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3c03f035f74d jar tool describe module consistency with launcher ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! test/tools/jar/mmrjar/Basic.java ! test/tools/jar/modularJar/Basic.java From chris.hegarty at oracle.com Wed Apr 12 12:53:01 2017 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 12 Apr 2017 12:53:01 +0000 Subject: hg: jigsaw/jake/jdk: jar tool: remove superflous newlines in describe output Message-ID: <201704121253.v3CCr1HA005683@aojmv0008.oracle.com> Changeset: 245e5e5c0c8e Author: chegar Date: 2017-04-12 13:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/245e5e5c0c8e jar tool: remove superflous newlines in describe output ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java From chris.hegarty at oracle.com Wed Apr 12 13:48:11 2017 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 12 Apr 2017 13:48:11 +0000 Subject: hg: jigsaw/jake/jdk: jmod tool describe module consistency with launcher Message-ID: <201704121348.v3CDmCTS021078@aojmv0008.oracle.com> Changeset: 222e1d0b5f91 Author: chegar Date: 2017-04-12 14:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/222e1d0b5f91 jmod tool describe module consistency with launcher ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/tools/jmod/JmodTest.java From Alan.Bateman at oracle.com Wed Apr 12 14:22:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Apr 2017 15:22:44 +0100 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: On 11/04/2017 17:13, Andrew Guibert wrote: > : > > Thanks for clarifying Alan. I misunderstood the use case of --dry-run > to be > that it did not require any main class, but instead the point is to *load* > but not *execute* the main class. Perhaps this would be worth > clarifying in > the option description? > The current usage for this option does include "create VM but do not execute main method". I guess we could adjust this a bit to make it explicit that the main class is loaded but the main method is not executed. -Alan From alan.bateman at oracle.com Wed Apr 12 18:30:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 12 Apr 2017 18:30:16 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704121830.v3CIUGbr013553@aojmv0008.oracle.com> Changeset: 466e5efca25b Author: alanb Date: 2017-04-12 19:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/466e5efca25b JavaLangAccess.findResource can be removed ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java Changeset: 5c7ca298a92a Author: alanb Date: 2017-04-12 19:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c7ca298a92a Improve java --dry-run usage message ! src/java.base/share/classes/sun/launcher/resources/launcher.properties From mandy.chung at oracle.com Wed Apr 12 23:34:43 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Apr 2017 18:34:43 -0500 Subject: Review Request: 8178404: jlink --suggest-providers should list providers from observable modules Message-ID: <7EBC13CA-EEAC-403F-960F-AE0FD110678A@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8178404/webrev.00/index.html --suggest-providers should suggest providers from any observable modules rather than the resolved modules. This patch also improves the output and fixes JDK-8178405 and JDK-8178327. --add-modules has no effect to the suggested providers when ?suggest-providers is specified. Mandy From peter.levart at gmail.com Thu Apr 13 07:20:21 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 13 Apr 2017 09:20:21 +0200 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: On 04/12/2017 04:22 PM, Alan Bateman wrote: > On 11/04/2017 17:13, Andrew Guibert wrote: > >> : >> >> Thanks for clarifying Alan. I misunderstood the use case of >> --dry-run to be >> that it did not require any main class, but instead the point is to >> *load* >> but not *execute* the main class. Perhaps this would be worth >> clarifying in >> the option description? >> > > The current usage for this option does include "create VM but do not > execute main method". I guess we could adjust this a bit to make it > explicit that the main class is loaded but the main method is not > executed. > > -Alan ...and in addition, that the main class is not even initialized - no user code is executed, right? I think this excludes any java agents and/or custom system class loaders and/or custom security managers specified as command-line options. Perhaps this should be specified explicitly. Regards, Peter From peter.levart at gmail.com Thu Apr 13 07:25:21 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 13 Apr 2017 09:25:21 +0200 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: On 04/13/2017 09:20 AM, Peter Levart wrote: > > > On 04/12/2017 04:22 PM, Alan Bateman wrote: >> On 11/04/2017 17:13, Andrew Guibert wrote: >> >>> : >>> >>> Thanks for clarifying Alan. I misunderstood the use case of >>> --dry-run to be >>> that it did not require any main class, but instead the point is to >>> *load* >>> but not *execute* the main class. Perhaps this would be worth >>> clarifying in >>> the option description? >>> >> >> The current usage for this option does include "create VM but do not >> execute main method". I guess we could adjust this a bit to make it >> explicit that the main class is loaded but the main method is not >> executed. >> >> -Alan > > ...and in addition, that the main class is not even initialized - no > user code is executed, right? I think this excludes any java agents > and/or custom system class loaders and/or custom security managers > specified as command-line options. Perhaps this should be specified > explicitly. > > Regards, Peter > A question regarding this: What should happen if --dry-run is specified together with -jar app.jar and app.jar contains manifest entry: Launcher-Agent-Class ? Regards, Peter From Alan.Bateman at oracle.com Thu Apr 13 07:59:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Apr 2017 08:59:20 +0100 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: On 13/04/2017 08:20, Peter Levart wrote: > > ...and in addition, that the main class is not even initialized - no > user code is executed, right? I think this excludes any java agents > and/or custom system class loaders and/or custom security managers > specified as command-line options. Perhaps this should be specified > explicitly. If there is custom class loader and custom security manager then they are loaded/initialized before the main class is loaded. Ditto for tool agents specified on the command line or in the manifest as they are also loaded/initialized before the main class. If the main class has an initializer then it won't normally run. I say "normally" because the custom class loader or an agent could be in cahoots with the main class and cause it to initialize before the launcher invokes the "main" method. My personal view is that this is way too much detail to attempt to capture in the brief description that is the usage message. I think we have to assume that the usage will be read by non-experts. So no issue with adjusting the message to make it clearer but we should limit it to a few lines. Here is the current output: --dry-run create VM and load main class but do not execute main method. This --dry-run option may be useful for validating the command-line options such as the module system configuration. "This --dry-run" should be "The --dry-run" but otherwise it seems a reasonable summary of what this option does. -Alan From blackdrag at gmx.org Thu Apr 13 14:12:08 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 13 Apr 2017 16:12:08 +0200 Subject: Intended usage of `java --dry-run`? In-Reply-To: References: Message-ID: <2d51e252-00bf-f41e-12f2-ac18d9737177@gmx.org> On 13.04.2017 09:59, Alan Bateman wrote: [...] > --dry-run create VM and load main class but do not execute main method. > This --dry-run option may be useful for validating the > command-line options such as the module system configuration. How about: create VM and load main class but do not execute main method. This may still execute code. The --dry-run option may be useful for validating the command-line options such as the module system configuration. or something similar... just a very very brief hint at least bye Jochen From alan.bateman at oracle.com Thu Apr 13 17:00:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:17 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201704131700.v3DH0I2r004236@aojmv0008.oracle.com> Changeset: 5b2e7b2101c0 Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5b2e7b2101c0 Added tag jdk-9+165 for changeset e36e62d3ea53 ! .hgtags Changeset: 907da52bb86c Author: alanb Date: 2017-04-13 17:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/907da52bb86c Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 17:00:19 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:19 +0000 Subject: hg: jigsaw/jake/jaxws: 3 new changesets Message-ID: <201704131700.v3DH0JQW004339@aojmv0008.oracle.com> Changeset: a987401bac0d Author: mchung Date: 2017-04-10 13:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a987401bac0d 8177855: Clean up legal files Reviewed-by: alanb, darcy ! src/jdk.xml.bind/share/legal/relaxngdatatype.md Changeset: b1f30c27367b Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b1f30c27367b Added tag jdk-9+165 for changeset a987401bac0d ! .hgtags Changeset: 6499b9e5b2ec Author: alanb Date: 2017-04-13 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/6499b9e5b2ec Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 17:00:18 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:18 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201704131700.v3DH0Ivj004242@aojmv0008.oracle.com> Changeset: 934c18145915 Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/934c18145915 Added tag jdk-9+165 for changeset a510b2201154 ! .hgtags Changeset: 21db254e0822 Author: alanb Date: 2017-04-13 17:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/21db254e0822 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 17:00:19 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:19 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201704131700.v3DH0JAi004292@aojmv0008.oracle.com> Changeset: 01393a25477b Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/01393a25477b Added tag jdk-9+165 for changeset 554196039897 ! .hgtags Changeset: 129fdefafbc7 Author: alanb Date: 2017-04-13 17:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/129fdefafbc7 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 17:00:22 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:22 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201704131700.v3DH0Mik004400@aojmv0008.oracle.com> Changeset: e817f52d73d0 Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e817f52d73d0 Added tag jdk-9+165 for changeset aff4f339acd4 ! .hgtags Changeset: f9c92d2e06c9 Author: alanb Date: 2017-04-13 17:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f9c92d2e06c9 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 17:00:23 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:23 +0000 Subject: hg: jigsaw/jake/langtools: 4 new changesets Message-ID: <201704131700.v3DH0Nvk004407@aojmv0008.oracle.com> Changeset: d6627b51ab8b Author: mcimadamore Date: 2017-04-07 15:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d6627b51ab8b 8178283: tools/javac/lambda/speculative/T8177933.java fails with assertion error Summary: disable test on solaris Reviewed-by: darcy ! test/tools/javac/lambda/speculative/T8177933.java Changeset: 98108b7d4cb6 Author: jlahoda Date: 2017-04-10 11:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98108b7d4cb6 8178011: Automatic module warnings Summary: Adding lints for automatic modules in requires and requires transitive directives. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/diags/Example.java + test/tools/javac/diags/examples/RequiresAutomatic/module-info.java + test/tools/javac/diags/examples/RequiresAutomatic/modulepath/a/A.java + test/tools/javac/diags/examples/RequiresTransitiveAutomatic/module-info.java + test/tools/javac/diags/examples/RequiresTransitiveAutomatic/modulepath/a/A.java ! test/tools/javac/modules/AutomaticModules.java Changeset: d3aec746a8d2 Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d3aec746a8d2 Added tag jdk-9+165 for changeset 98108b7d4cb6 ! .hgtags Changeset: 7e531a1008f7 Author: alanb Date: 2017-04-13 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7e531a1008f7 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/diags/Example.java ! test/tools/javac/modules/AutomaticModules.java From alan.bateman at oracle.com Thu Apr 13 17:00:24 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:24 +0000 Subject: hg: jigsaw/jake/hotspot: 7 new changesets Message-ID: <201704131700.v3DH0OVm004411@aojmv0008.oracle.com> Changeset: cded24619229 Author: ysr Date: 2017-04-07 10:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cded24619229 8177963: Parallel GC fails fast when per-thread task log overflows Summary: Instead of exiting the VM when per-thread task log overflows, print warnings once and ignore any further log addition attempt. Reviewed-by: ysr, kbarrett, sangheki ! src/share/vm/gc/parallel/gcTaskThread.cpp ! src/share/vm/gc/parallel/gcTaskThread.hpp ! src/share/vm/runtime/globals.hpp ! test/gc/parallel/TestPrintGCDetailsVerbose.java ! test/native/runtime/test_globals.cpp Changeset: d80c43d9a99e Author: tschatzl Date: 2017-04-07 10:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d80c43d9a99e Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLRModule.java - test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java Changeset: f19b6d14a035 Author: aph Date: 2017-04-07 13:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f19b6d14a035 8170812: Metaspace corruption caused by incorrect memory size for MethodCounters Reviewed-by: kbarrett, coleenp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodCounters.hpp Changeset: 73c72daf8e8d Author: iignatyev Date: 2017-04-07 19:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/73c72daf8e8d 8178333: CTW/PathHandler uses == instead of String::equals for string comparison Reviewed-by: kvn ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java Changeset: c92c6416ca03 Author: iignatyev Date: 2017-04-08 02:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c92c6416ca03 Merge Changeset: e6e90d744553 Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e6e90d744553 Added tag jdk-9+165 for changeset c92c6416ca03 ! .hgtags Changeset: f55aefad0862 Author: alanb Date: 2017-04-13 17:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f55aefad0862 Merge ! .hgtags ! src/share/vm/runtime/globals.hpp From alan.bateman at oracle.com Thu Apr 13 17:00:24 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 17:00:24 +0000 Subject: hg: jigsaw/jake/jdk: 7 new changesets Message-ID: <201704131700.v3DH0Oaf004414@aojmv0008.oracle.com> Changeset: 96f06b21a3f3 Author: bpb Date: 2017-04-07 11:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96f06b21a3f3 8178074: (ch) java/nio/channels/etc/AdaptorCloseAndInterrupt.java: add instrumentation Summary: Add some print statements to indicate state at strategic points Reviewed-by: chegar ! test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java Changeset: c2b213b77b2d Author: smarks Date: 2017-04-07 15:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c2b213b77b2d 8173152: Wrong wording in Comparator.compare() method spec Reviewed-by: bpb ! src/java.base/share/classes/java/lang/Comparable.java ! src/java.base/share/classes/java/util/Comparator.java Changeset: baf915932a01 Author: lancea Date: 2017-04-09 14:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/baf915932a01 8178130: Minor update to the Connection javadocs Reviewed-by: bpb ! src/java.sql/share/classes/java/sql/Connection.java Changeset: d263a4cb0621 Author: asapre Date: 2017-04-10 12:15 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d263a4cb0621 8176204: [DOC] ThreadMXBean Fails to Detect ReentrantReadWriteLock Deadlock Summary: Update LockInfo class javadoc for own-able synchronizer examples Reviewed-by: dholmes Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/java/lang/management/LockInfo.java Changeset: a7942c3b1e59 Author: mchung Date: 2017-04-10 13:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a7942c3b1e59 8177855: Clean up legal files Reviewed-by: alanb, darcy ! src/java.desktop/share/legal/jpeg.md ! src/jdk.crypto.ec/share/legal/ecc.md Changeset: 46e1898b6c6e Author: lana Date: 2017-04-13 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46e1898b6c6e Added tag jdk-9+165 for changeset a7942c3b1e59 ! .hgtags Changeset: 6aa95347da12 Author: alanb Date: 2017-04-13 17:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6aa95347da12 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 13 18:43:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 13 Apr 2017 18:43:16 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201704131843.v3DIhGtG009871@aojmv0008.oracle.com> Changeset: 081f60103878 Author: alanb Date: 2017-04-13 18:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/081f60103878 Add usage note to addOpens Random clean-up ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleResolution.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java Changeset: 09476fe742fe Author: alanb Date: 2017-04-13 18:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/09476fe742fe Fix typo in --dry-run usage ! src/java.base/share/classes/sun/launcher/resources/launcher.properties From Alan.Bateman at oracle.com Thu Apr 13 18:55:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Apr 2017 19:55:19 +0100 Subject: Intended usage of `java --dry-run`? In-Reply-To: <2d51e252-00bf-f41e-12f2-ac18d9737177@gmx.org> References: <2d51e252-00bf-f41e-12f2-ac18d9737177@gmx.org> Message-ID: <32f9b494-084d-d4c8-7ad6-672ee86b3d49@oracle.com> On 13/04/2017 15:12, Jochen Theodorou wrote: > : > > How about: > > create VM and load main class but do not execute main method. > This may still execute code. The --dry-run option may be useful for > validating the command-line options such as the module system > configuration. > > or something similar... just a very very brief hint at least It does give a hint but it could confuse too in that the reader will wonder what code may execute. I think I would prefer to keep it simple. -Alan From rahman.usta.88 at gmail.com Fri Apr 14 23:09:27 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Sat, 15 Apr 2017 02:09:27 +0300 Subject: jna-platform, xalan, batik-script InvalidModuleDescriptorException In-Reply-To: References: Message-ID: Hi Alan, Mandy, Thank you for the hint about keeping classical jars in classpath. I use Intellij Idea in development and Maven for building the project. IntelliJ Idea has an early support for Java 9 but it should involve a bit more. For example I didn't see a way to choose which jars will be in classpath and which jars will be in module path. As Maven, I also didn't see a way for classpath/modulepath seperation. >From this experience I can choose Gradle for flexibility. Thanks. 2017-04-11 9:58 GMT+03:00 Alan Bateman : > On 10/04/2017 22:49, Rahman USTA wrote: > > : >> >> 1) Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for >> \.m2\repository\net\java\dev\jna\jna-platform\4.4.0\jna-plat >> form-4.4.0.jar >> Caused by: java.lang.module.InvalidModuleDescriptorException: Main-Class >> com.sun.jna.Native not in module >> > I don't know why this JAR file has a Main-Class attribute but I assume > that `java -jar jna-platform-4.4.0.jar` doesn't work or only works when the > JAR file containing the entry point is brought into the environment. > > I see Mandy's note about this JAR file seems to have code that using the > AWT peer API so I assume this library is going to need work anyway. > > >> 2) Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for >> \.m2\repository\org\apache\xmlgraphics\batik-script\1.8\bati >> k-script-1.8.jar >> Caused by: java.lang.module.InvalidModuleDescriptorException: Provider >> class org.apache.batik.bridge.RhinoInterpreterFactory not in module >> >> 3) Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for >> \.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar >> Caused by: java.lang.module.InvalidModuleDescriptorException: Provider >> class org.apache.bsf.BSFManager not in module >> > The class path is leaky in that a JAR file can name a class in its > META-INF/services configuration file and the class is loaded from another > JAR file. It would be interesting to see if that is the case with these two > projects. I assume if deployed in isolation on the class path that > ServiceConfigurationError is throw when the providers cannot be loaded. > > As regards moving forward then do you have direct dependences on these > libraries? If the dependences not direct then you could leave these JAR > files on the class path (assuming they actually work there). When migrating > to modules then it's okay to do this, esp. with legacy libraries with > issues that prevent them being used as modules. > > -Alan > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From alan.bateman at oracle.com Sun Apr 16 16:23:30 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 16 Apr 2017 16:23:30 +0000 Subject: hg: jigsaw/jake/jdk: Missing @spec JPMS Message-ID: <201704161623.v3GGNUH4011090@aojmv0008.oracle.com> Changeset: 73daea788e74 Author: alanb Date: 2017-04-15 15:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/73daea788e74 Missing @spec JPMS ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java From sha.jiang at oracle.com Mon Apr 17 02:52:58 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 17 Apr 2017 10:52:58 +0800 Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList Message-ID: Hi, Because of JDK-8178776, java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and tools/jimage/VerifyJimage.java should be added to ProblemList. diff -r 9ba6760481a8 test/ProblemList.txt --- a/test/ProblemList.txt Sat Apr 15 16:54:33 2017 -0400 +++ b/test/ProblemList.txt Sun Apr 16 19:30:49 2017 -0700 @@ -124,6 +124,7 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all +java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java 8178776 generic-all jdk/internal/misc/JavaLangAccess/NewUnsafeString.java 8176188 generic-all @@ -255,6 +256,8 @@ tools/jimage/JImageListTest.java 8170120 generic-all tools/jimage/JImageVerifyTest.java 8170120 generic-all +tools/jimage/VerifyJimage.java 8178776 generic-all + ############################################################################ # jdk_jdi Best regards, John Jiang From Alan.Bateman at oracle.com Mon Apr 17 07:07:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Apr 2017 08:07:13 +0100 Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList In-Reply-To: References: Message-ID: On 17/04/2017 03:52, sha.jiang at oracle.com wrote: > Hi, > Because of JDK-8178776, > java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and > tools/jimage/VerifyJimage.java should be added to ProblemList. > Temporarily excluding these tests for a few days is okay. However, we need to get attention on the real issue, we should never create a run-time image containing types that can't link to their super types. -Alan From Alan.Bateman at oracle.com Mon Apr 17 08:42:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Apr 2017 09:42:43 +0100 Subject: jna-platform, xalan, batik-script InvalidModuleDescriptorException In-Reply-To: References: Message-ID: On 15/04/2017 00:09, Rahman USTA wrote: > Hi Alan, Mandy, > > Thank you for the hint about keeping classical jars in classpath. > > I use Intellij Idea in development and Maven for building the project. > IntelliJ Idea has an early support for Java 9 but it should involve a > bit more. For example I didn't see a way to choose which jars will be > in classpath and which jars will be in module path. > > As Maven, I also didn't see a way for classpath/modulepath seperation. > This may be something that Robert Scholte or others working on Maven can comment on. My understanding is that the Maven Compiler Plugin puts the build dependences on the module path when compiling a project that has a module-info.java. This means the dependences that aren't explicit modules (don't contain a module-info.class) are turned into automatic modules. It could instead just add the libraries for the modules that are directly or transitively required and leave any remaining (non-module) libraries on the class path (with `--add-reads =ALL-UNNAMED` to provide the bridge for cases where the automatic modules are exposing types on the class path). A combination of the module path and class path can be very useful during migration, esp. bottom-up. It can also be used when migration top-down but this is more complicated and may not be something that all developers want to get into. That said, the exceptions you included were run-time exceptions. As with compile-time, you can leave libraries on the class path that won't work as automatic modules. That may allow you to make progress until the issues with the libraries you found have been fixed. -Alan From michael.rasmussen at zeroturnaround.com Mon Apr 17 12:48:53 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Mon, 17 Apr 2017 15:48:53 +0300 Subject: Java 9 class file format finalized? Message-ID: Hi Has the class file format, or more specifically the module-info.class file format, been finalized, or should we still expect changes in that area? /Michael From rahman.usta.88 at gmail.com Mon Apr 17 13:04:05 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Mon, 17 Apr 2017 16:04:05 +0300 Subject: Java 9 class file format finalized? In-Reply-To: References: Message-ID: Hi, JSR 376 is available for public review https://jcp.org/aboutJava/communityprocess/pr/jsr376/index.html. You can look at the proposal and give feedback. You can find the chapter 7.7 Module Declarations. 2017-04-17 15:48 GMT+03:00 Michael Rasmussen < michael.rasmussen at zeroturnaround.com>: > Hi > > Has the class file format, or more specifically the module-info.class > file format, been finalized, or should we still expect changes in that > area? > > /Michael > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From Alan.Bateman at oracle.com Mon Apr 17 16:10:55 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Apr 2017 17:10:55 +0100 Subject: Java 9 class file format finalized? In-Reply-To: References: Message-ID: <6598dbc5-2073-7563-1998-04ff22b456b6@oracle.com> On 17/04/2017 13:48, Michael Rasmussen wrote: > Hi > > Has the class file format, or more specifically the module-info.class > file format, been finalized, or should we still expect changes in that > area? > The format and the attributes have been stable for some time. I'm not aware of any proposal to change anything. At the same time, the specs aren't final. Also the JDK-specific attributes aren't documented in JEP 261 yet (but you might not care about that). -Alan From mandy.chung at oracle.com Mon Apr 17 16:11:20 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Apr 2017 09:11:20 -0700 Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList In-Reply-To: References: Message-ID: <8DA24FCF-52CD-4AC0-9D63-2809DAF0AA6F@oracle.com> > On Apr 17, 2017, at 12:07 AM, Alan Bateman wrote: > > On 17/04/2017 03:52, sha.jiang at oracle.com wrote: > >> Hi, >> Because of JDK-8178776, java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and tools/jimage/VerifyJimage.java should be added to ProblemList. >> > Temporarily excluding these tests for a few days is okay. However, we need to get attention on the real issue, we should never create a run-time image containing types that can't link to their super types. Agree. It?s fine to problem list these tests for a few days and resolve this soon. Mandy From alex.buckley at oracle.com Mon Apr 17 18:58:52 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Apr 2017 11:58:52 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58EC0D99.1070700@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> Message-ID: <58F5106C.3020701@oracle.com> On 4/10/2017 3:56 PM, Kevin Rushforth wrote: > The short version is that JavaFX beans is (mostly) working as expected, > except for the misleading exception message. In JDK 9 it is required > that any object that is reflected on by JavaFX beans, specifically the > items passed to TableView, which are accessed via a > PropertyValueFactory, will need to be in a package that is exported > unconditionally. In JDK 10 we can look into relaxing this requirement > such that the package only needs to be exported to javafx.beans. "exported unconditionally" -- sorry to be picky but this guidance needs to be a bit tighter. Can't the user export to a (possibly large) set of javaxfx.* modules, rather than unconditionally? Is it OK to _export_ the package (rather than open it) because beans will access only its public types/members? What if the user opens the package anyway (rather than exports it)? I don't know the relationship between the PropertyValueFactory type and the type of the items passed to TableView, but I think the high-level requirement is: some user type must be accessible to JavaFX code, and that is achieved by exporting or opening the type's package to at least the javafx.* modules. Alex From greggwon at cox.net Mon Apr 17 19:15:44 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Mon, 17 Apr 2017 14:15:44 -0500 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <9WzS1v00P1VUyRY01WzT5c> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <9WzS1v00P1VUyRY01WzT5c> Message-ID: <83D6673B-0117-49EA-AF91-99DC0835E8D7@cox.net> The interesting thing about this issue, is that it points out that even inside of Oracle, reflection against users objects for ?features? of the software system, is useful practice. At some level, this denial of service is really just a ?control the user? front to an attempt to solidify the walls around the implementation of Java to hopefully allow those details to be more readily enhanced in implementation. But, we are still at this point where all of this is so much about ?how Java works today?, that it seems amazingly intrusive to productivity to yank the carpet out from underneath every single user/developer of Java. It seems less intrusive, overall, to just summarily change the implementation of details inside of Java when needed because doing that, and breaking people software, is exactly the same thing that will happen for JDK 9. No-one, it would appear, is going to be able to ?change JVM? implementations to take advantage of any features in JDK-9 without replacing all the software too. What is really going to be accomplished? Is it not possible to create SPIs around what is already going to be broken by enhancing implementations of JVM details, as those enhancements are made, and forcing people using ?just? those details to introduce the use of the SPIs using standard Java ?version inspection? mechanisms through Class.forName(?Some.new.SPI.Implementation?), rather than by summarily breaking everything now, and creating all of this new, essentially pointless churn for developers to have to use the module system? JavaFX in particular means all desktop applications? Again, this is going to be the environment where users JDKs are going to update automatically without replacing and fixing the software they are using, and it will break their applications with probably no information other than an icon that now seems to not respond to double clicks. Gregg > On Apr 17, 2017, at 1:58 PM, Alex Buckley wrote: > > On 4/10/2017 3:56 PM, Kevin Rushforth wrote: >> The short version is that JavaFX beans is (mostly) working as expected, >> except for the misleading exception message. In JDK 9 it is required >> that any object that is reflected on by JavaFX beans, specifically the >> items passed to TableView, which are accessed via a >> PropertyValueFactory, will need to be in a package that is exported >> unconditionally. In JDK 10 we can look into relaxing this requirement >> such that the package only needs to be exported to javafx.beans. > > "exported unconditionally" -- sorry to be picky but this guidance needs to be a bit tighter. Can't the user export to a (possibly large) set of javaxfx.* modules, rather than unconditionally? Is it OK to _export_ the package (rather than open it) because beans will access only its public types/members? What if the user opens the package anyway (rather than exports it)? I don't know the relationship between the PropertyValueFactory type and the type of the items passed to TableView, but I think the high-level requirement is: some user type must be accessible to JavaFX code, and that is achieved by exporting or opening the type's package to at least the javafx.* modules. > > Alex From stephen.felts at oracle.com Mon Apr 17 19:56:46 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 17 Apr 2017 12:56:46 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default (revised) In-Reply-To: <73b39aa4-0375-acbd-680f-7285943c3ed0@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> <20170405161520.81729A2BC4@eggemoggin.niobe.net> <66a366d2-f56e-4883-a287-5b9bcb3e5d7c@default> <73b39aa4-0375-acbd-680f-7285943c3ed0@oracle.com> Message-ID: I ran into another tool that is broken with this proposal (someone can update https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing again). Mockito is now broken again. It's sad because they recently fixed the 2.x version to run cleanly on JDK 9 and I had just upgraded for that reason. The proposed use of java -jar or the command line property don't work because mockito doesn't own either of these. It's buried deep in gradle calls junit calls mockit. This particular set of tests is doing a fork per test. The start a new process per occurrence is ugly if it works at all and we don't really want every tool in my JVM to be doing this for performance and memory reasons. While a huge amount of JDK9 breakage is based on the one line sentence not to use sun.* classes, this breakage doesn't fit. This is a documented feature that was in fact enhanced to add this API in JDK 6. Apparently a lot of products are using it to do self-attach and there is no restriction on that for JDK 6-8. This is admittedly a short term fix since there isn't time to do a correct fix in JDK9 and it should wait until JDK 10 to be done correctly. Caused by: java.io.IOException: Can not attach to current VM at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.(HotSpotVirtualMachine.java:75) at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:56) at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) at mockit.internal.startup.AgentLoader.attachToRunningVM(AgentLoader.java:146) -----Original Message----- From: Alan Bateman Sent: Tuesday, April 11, 2017 3:01 AM To: Stephen Felts; jigsaw-dev at openjdk.java.net Subject: Re: Disallowing the dynamic loading of agents by default (revised) On 11/04/2017 05:31, Stephen Felts wrote: > The description below leaves out the " ancestor of the current process". > Which way is it - do we need to start two processes or one to work around this? > The thread moved one from the original proposal. The only requirement now is that the tool and target VMs are different. -Alan From kevin.rushforth at oracle.com Mon Apr 17 19:56:53 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 12:56:53 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58F5106C.3020701@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <58F5106C.3020701@oracle.com> Message-ID: <58F51E05.3050207@oracle.com> The current implementation effectively requires that the containing package of the type in question be exported unconditionally, since javafx.beans uses the sun.reflect.misc.Trampoline class to reflectively call the module. It happens to work if the user exports or opens the package to ALL-UNNAMED on the command line, but that isn't something we would want to document or recommend. Without changing the implementation (which would be quite risky for JDK 9), it seems best to just require the application's package to be unconditionally exported in JDK 9 and then relax this requirement in JDK 10 to allow it to be exported (or opened) just to javafx.base. -- Kevin Alex Buckley wrote: > On 4/10/2017 3:56 PM, Kevin Rushforth wrote: >> The short version is that JavaFX beans is (mostly) working as expected, >> except for the misleading exception message. In JDK 9 it is required >> that any object that is reflected on by JavaFX beans, specifically the >> items passed to TableView, which are accessed via a >> PropertyValueFactory, will need to be in a package that is exported >> unconditionally. In JDK 10 we can look into relaxing this requirement >> such that the package only needs to be exported to javafx.beans. > > "exported unconditionally" -- sorry to be picky but this guidance > needs to be a bit tighter. Can't the user export to a (possibly large) > set of javaxfx.* modules, rather than unconditionally? Is it OK to > _export_ the package (rather than open it) because beans will access > only its public types/members? What if the user opens the package > anyway (rather than exports it)? I don't know the relationship between > the PropertyValueFactory type and the type of the items passed to > TableView, but I think the high-level requirement is: some user type > must be accessible to JavaFX code, and that is achieved by exporting > or opening the type's package to at least the javafx.* modules. > > Alex From kevin.rushforth at oracle.com Mon Apr 17 19:57:53 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 12:57:53 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <83D6673B-0117-49EA-AF91-99DC0835E8D7@cox.net> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <9WzS1v00P1VUyRY01WzT5c> <83D6673B-0117-49EA-AF91-99DC0835E8D7@cox.net> Message-ID: <58F51E41.70106@oracle.com> I don't follow your logic. All we are saying in this case is that an application that wishes to migrate to using modules will have to provide explicit access to the objects that they want another module (javafx.beans in this case) to access. -- Kevin Gregg Wonderly wrote: > The interesting thing about this issue, is that it points out that even inside of Oracle, reflection against users objects for ?features? of the software system, is useful practice. At some level, this denial of service is really just a ?control the user? front to an attempt to solidify the walls around the implementation of Java to hopefully allow those details to be more readily enhanced in implementation. But, we are still at this point where all of this is so much about ?how Java works today?, that it seems amazingly intrusive to productivity to yank the carpet out from underneath every single user/developer of Java. > > It seems less intrusive, overall, to just summarily change the implementation of details inside of Java when needed because doing that, and breaking people software, is exactly the same thing that will happen for JDK 9. No-one, it would appear, is going to be able to ?change JVM? implementations to take advantage of any features in JDK-9 without replacing all the software too. > > What is really going to be accomplished? Is it not possible to create SPIs around what is already going to be broken by enhancing implementations of JVM details, as those enhancements are made, and forcing people using ?just? those details to introduce the use of the SPIs using standard Java ?version inspection? mechanisms through Class.forName(?Some.new.SPI.Implementation?), rather than by summarily breaking everything now, and creating all of this new, essentially pointless churn for developers to have to use the module system? > > JavaFX in particular means all desktop applications? Again, this is going to be the environment where users JDKs are going to update automatically without replacing and fixing the software they are using, and it will break their applications with probably no information other than an icon that now seems to not respond to double clicks. > > Gregg > > >> On Apr 17, 2017, at 1:58 PM, Alex Buckley wrote: >> >> On 4/10/2017 3:56 PM, Kevin Rushforth wrote: >> >>> The short version is that JavaFX beans is (mostly) working as expected, >>> except for the misleading exception message. In JDK 9 it is required >>> that any object that is reflected on by JavaFX beans, specifically the >>> items passed to TableView, which are accessed via a >>> PropertyValueFactory, will need to be in a package that is exported >>> unconditionally. In JDK 10 we can look into relaxing this requirement >>> such that the package only needs to be exported to javafx.beans. >>> >> "exported unconditionally" -- sorry to be picky but this guidance needs to be a bit tighter. Can't the user export to a (possibly large) set of javaxfx.* modules, rather than unconditionally? Is it OK to _export_ the package (rather than open it) because beans will access only its public types/members? What if the user opens the package anyway (rather than exports it)? I don't know the relationship between the PropertyValueFactory type and the type of the items passed to TableView, but I think the high-level requirement is: some user type must be accessible to JavaFX code, and that is achieved by exporting or opening the type's package to at least the javafx.* modules. >> >> Alex >> > > From alex.buckley at oracle.com Mon Apr 17 20:03:41 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Apr 2017 13:03:41 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58F51E05.3050207@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <58F5106C.3020701@oracle.com> <58F51E05.3050207@oracle.com> Message-ID: <58F51F9D.2020601@oracle.com> On 4/17/2017 12:56 PM, Kevin Rushforth wrote: > The current implementation effectively requires that the containing > package of the type in question be exported unconditionally, since > javafx.beans uses the sun.reflect.misc.Trampoline class to reflectively > call the module. It happens to work if the user exports or opens the > package to ALL-UNNAMED on the command line, but that isn't something we > would want to document or recommend. Without changing the implementation > (which would be quite risky for JDK 9), it seems best to just require > the application's package to be unconditionally exported in JDK 9 and > then relax this requirement in JDK 10 to allow it to be exported (or > opened) just to javafx.base. OK, so for the JDK 9 docs, "unconditionally exported (or unconditionally opened)" would be clear. Alex From kevin.rushforth at oracle.com Mon Apr 17 20:37:00 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 13:37:00 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58F51F9D.2020601@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <58F5106C.3020701@oracle.com> <58F51E05.3050207@oracle.com> <58F51F9D.2020601@oracle.com> Message-ID: <58F5276C.9080601@oracle.com> Alex Buckley wrote: > OK, so for the JDK 9 docs, "unconditionally exported (or > unconditionally opened)" would be clear. I was originally thinking to require unconditional export, but since it will also be fine for an application to open the package unconditionally, I will make this change and document either as being sufficient. Thanks. -- Kevin From alan.bateman at oracle.com Tue Apr 18 11:17:06 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 18 Apr 2017 11:17:06 +0000 Subject: hg: jigsaw/jake/jdk: tools/jlink/JLinkNegativeTest.java failing Message-ID: <201704181117.v3IBH6CC012748@aojmv0008.oracle.com> Changeset: b44379d23925 Author: alanb Date: 2017-04-18 12:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b44379d23925 tools/jlink/JLinkNegativeTest.java failing ! test/tools/jlink/JLinkNegativeTest.java From Alan.Bateman at oracle.com Tue Apr 18 14:35:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Apr 2017 15:35:52 +0100 Subject: Review Request: 8178404: jlink --suggest-providers should list providers from observable modules In-Reply-To: <7EBC13CA-EEAC-403F-960F-AE0FD110678A@oracle.com> References: <7EBC13CA-EEAC-403F-960F-AE0FD110678A@oracle.com> Message-ID: <058fc3ed-56d2-695b-6c46-3ae117639b23@oracle.com> On 13/04/2017 00:34, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8178404/webrev.00/index.html > > --suggest-providers should suggest providers from any observable modules > rather than the resolved modules. This patch also improves the output and > fixes JDK-8178405 and JDK-8178327. --add-modules has no effect to the > suggested providers when ?suggest-providers is specified. > This mostly looks good to me. For the usage message then --suggest-providers might be simpler as "Suggest service providers that implement the given service type from the module path". The mention of `--add-modules` could confuse readers so I'd leave it out. In passing, --bind-services currently prints "Do full service binding" and maybe we should change that to something "Automaticall link in service provider modules and their dependences" or something that is clearer than the current text. Minor nit in JlinkTask.java L381 where the throw is indented too much, might be a tab. -Alan From mandy.chung at oracle.com Tue Apr 18 16:32:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Apr 2017 09:32:17 -0700 Subject: Review Request: 8178404: jlink --suggest-providers should list providers from observable modules In-Reply-To: <058fc3ed-56d2-695b-6c46-3ae117639b23@oracle.com> References: <7EBC13CA-EEAC-403F-960F-AE0FD110678A@oracle.com> <058fc3ed-56d2-695b-6c46-3ae117639b23@oracle.com> Message-ID: <640C71B2-B620-4E29-B297-AB64920CE3C3@oracle.com> > On Apr 18, 2017, at 7:35 AM, Alan Bateman wrote: > > For the usage message then --suggest-providers might be simpler as "Suggest service providers that implement the given service type from the module path". The mention of `--add-modules` could confuse readers so I'd leave it out. > > In passing, --bind-services currently prints "Do full service binding" and maybe we should change that to something "Automaticall link in service provider modules and their dependences" or something that is clearer than the current text. > How about this: diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties @@ -57,12 +57,12 @@ \ if specified main.opt.bind-services=\ -\ --bind-services Do full service binding +\ --bind-services Link in service provider modules and\n\ +\ their dependences main.opt.suggest-providers=\ -\ --suggest-providers [,...] Suggest providers of services used by\n\ -\ the modules that would be linked, or\n\ -\ of the given service types +\ --suggest-providers [,...] Suggest providers that implement the\n\ +\ given service types from the module path main.command.files=\ \ @ Read options from file @@ -138,7 +138,7 @@ warn.signing=WARNING: signed modular JAR {0} is currently not supported warn.invalid.arg=invalid classname or pathname not exist: {0} warn.split.package=package {0} defined in {1} {2} -warn.unused.services=Services specified in --suggest-providers not used: {0} +warn.provider.notfound=No provider found for service specified to --suggest-providers: {0} no.suggested.providers=--bind-services option is specified. No additional providers suggested. suggested.providers.header=Suggested providers providers.header=Providers > Minor nit in JlinkTask.java L381 where the throw is indented too much, might be a tab. Will fix before I push. Mandy From Alan.Bateman at oracle.com Tue Apr 18 16:37:02 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Apr 2017 17:37:02 +0100 Subject: Review Request: 8178404: jlink --suggest-providers should list providers from observable modules In-Reply-To: <640C71B2-B620-4E29-B297-AB64920CE3C3@oracle.com> References: <7EBC13CA-EEAC-403F-960F-AE0FD110678A@oracle.com> <058fc3ed-56d2-695b-6c46-3ae117639b23@oracle.com> <640C71B2-B620-4E29-B297-AB64920CE3C3@oracle.com> Message-ID: On 18/04/2017 17:32, Mandy Chung wrote: > : > How about this: > > diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > @@ -57,12 +57,12 @@ > \ if specified > > main.opt.bind-services=\ > -\ --bind-services Do full service binding > +\ --bind-services Link in service provider modules and\n\ > +\ their dependences > > main.opt.suggest-providers=\ > -\ --suggest-providers [,...] Suggest providers of services used by\n\ > -\ the modules that would be linked, or\n\ > -\ of the given service types > +\ --suggest-providers [,...] Suggest providers that implement the\n\ > +\ given service types from the module path > Looks good. -Alan. From doug.simon at oracle.com Tue Apr 18 22:13:50 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 00:13:50 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal Message-ID: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. The primary requirement for this is to remove all usage of JDK internals from Graal. While this most involves changes in Graal, there remain a few capabilities that must be exposed via JVMCI. Namely: 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize can use system properties that are guaranteed not to have been modified by application code (Graal initialization is lazy and may occur after application code has been run). 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal optimized implementation of the Truffle runtime. These capabilities have been added to jdk.vm.ci.services.Services. A comment has also been added to this class to denote the current methods to be removed in a subsequent bug to update the JDK copy of Graal with the upstream version which no longer uses the methods. The methods destined for removal are: exportJVMCITo(Class requestor) load(Class service) loadSingle(Class service, boolean required) The first one is no longer needed as JVMCI exports itself to Graal service providers it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API is only useful for JVMCI-8 where a hidden JVMCI class loader is used. These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra minor changes were required: 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException on all error paths except one which throws AssertionError. The latter was a mistake and has been fixed to also throw IllegalArgumentException. 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and remove use of JDK internal API from the jdk.aot module. The qualified exports to jdk.vm.internal.compiler and jdk.aot can then be removed. -Doug https://bugs.openjdk.java.net/browse/JDK-8177845 http://cr.openjdk.java.net/~dnsimon/8177845/ [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess From mandy.chung at oracle.com Wed Apr 19 00:02:43 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Apr 2017 17:02:43 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> Message-ID: <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> > On Apr 18, 2017, at 3:13 PM, Doug Simon wrote: > > Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. > : > http://cr.openjdk.java.net/~dnsimon/8177845/ Thanks for making this change. This would simplify the way to replace JDK?s graal with the lab graal. A couple of comments: jdk/internal/misc/VM.java 161 * Note that the saved system properties do not include 162 * the ones set by sun.misc.Version.init(). sun.misc.Version is no longer present in JDK 9. Renamed to java.lang.VersionProps jdk/vm/ci/services/Services.java 67 Class.forName("jdk.vm.ci.runtime.JVMCI?); JVMCI class is local in jdk.internal.vm.ci module. An alternative may be to provide a static initialize method rather than Class::forName. jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java 211 for (HotSpotJVMCIBackendFactory factory : ServiceLoader.load(HotSpotJVMCIBackendFactory.class)) { This uses the thread context class loader to load providers. Services::load uses the system class loader to load providers. I suspect you want this to use the system class loader here too. jdk/vm/ci/services/JVMCIServiceLocator.java 78 for (JVMCIServiceLocator access : ServiceLoader.load(JVMCIServiceLocator.class)) { Same comment as above. I think you want to use system class loader to load providers. Mandy From doug.simon at oracle.com Wed Apr 19 07:06:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 09:06:38 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: <385D6A4A-0C1F-4CCD-8806-5665052A81AA@oracle.com> > On 19 Apr 2017, at 02:02, Mandy Chung wrote: > > >> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote: >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> : >> http://cr.openjdk.java.net/~dnsimon/8177845/ > > Thanks for making this change. This would simplify the way to replace JDK?s graal with the lab graal. A couple of comments: > > jdk/internal/misc/VM.java > > 161 * Note that the saved system properties do not include > 162 * the ones set by sun.misc.Version.init(). > > sun.misc.Version is no longer present in JDK 9. Renamed to java.lang.VersionProps Sorry, the webrev was out of date. I've updated it and also fixed the comment for VM::getSavedProperty. > jdk/vm/ci/services/Services.java > 67 Class.forName("jdk.vm.ci.runtime.JVMCI?); > > JVMCI class is local in jdk.internal.vm.ci module. An alternative may be > to provide a static initialize method rather than Class::forName. JVMCI is broken into fine grained "projects" and the jdk.vm.ci.runtime[1] project depends on the jdk.vm.ci.services project[2] so I cannot make a direct reference without introducing a circular dependency. I don't expect the reflection cost to be significant in practice. > jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java > 211 for (HotSpotJVMCIBackendFactory factory : ServiceLoader.load(HotSpotJVMCIBackendFactory.class)) { > > This uses the thread context class loader to load providers. Services::load uses > the system class loader to load providers. I suspect you want this to use the > system class loader here too. > > jdk/vm/ci/services/JVMCIServiceLocator.java > 78 for (JVMCIServiceLocator access : ServiceLoader.load(JVMCIServiceLocator.class)) { > > Same comment as above. I think you want to use system class loader to load providers. Yes, I think you're right. I've updated the webrev with that change. Thanks for the review. -Doug [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l94 [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l45 From doug.simon at oracle.com Wed Apr 19 07:16:08 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 09:16:08 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal Message-ID: (adding hotspot-compiler-dev) Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. The primary requirement for this is to remove all usage of JDK internals from Graal. While this most involves changes in Graal, there remain a few capabilities that must be exposed via JVMCI. Namely: 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize can use system properties that are guaranteed not to have been modified by application code (Graal initialization is lazy and may occur after application code has been run). 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal optimized implementation of the Truffle runtime. These capabilities have been added to jdk.vm.ci.services.Services. A comment has also been added to this class to denote the current methods to be removed in a subsequent bug to update the JDK copy of Graal with the upstream version which no longer uses the methods. The methods destined for removal are: exportJVMCITo(Class requestor) load(Class service) loadSingle(Class service, boolean required) The first one is no longer needed as JVMCI exports itself to Graal service providers it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API is only useful for JVMCI-8 where a hidden JVMCI class loader is used. These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra minor changes were required: 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException on all error paths except one which throws AssertionError. The latter was a mistake and has been fixed to also throw IllegalArgumentException. 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and remove use of JDK internal API from the jdk.aot module. The qualified exports to jdk.vm.internal.compiler and jdk.aot can then be removed. -Doug https://bugs.openjdk.java.net/browse/JDK-8177845 http://cr.openjdk.java.net/~dnsimon/8177845/ [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess From doug.simon at oracle.com Wed Apr 19 07:18:03 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 09:18:03 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: (adding hotspot-compiler-dev) > On 19 Apr 2017, at 02:02, Mandy Chung wrote: > > >> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote: >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> : >> http://cr.openjdk.java.net/~dnsimon/8177845/ > > Thanks for making this change. This would simplify the way to replace JDK?s graal with the lab graal. A couple of comments: > > jdk/internal/misc/VM.java > > 161 * Note that the saved system properties do not include > 162 * the ones set by sun.misc.Version.init(). > > sun.misc.Version is no longer present in JDK 9. Renamed to java.lang.VersionProps Sorry, the webrev was out of date. I've updated it and also fixed the comment for VM::getSavedProperty. > jdk/vm/ci/services/Services.java > 67 Class.forName("jdk.vm.ci.runtime.JVMCI?); > > JVMCI class is local in jdk.internal.vm.ci module. An alternative may be > to provide a static initialize method rather than Class::forName. JVMCI is broken into fine grained "projects" and the jdk.vm.ci.runtime[1] project depends on the jdk.vm.ci.services project[2] so I cannot make a direct reference without introducing a circular dependency. I don't expect the reflection cost to be significant in practice. > jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java > 211 for (HotSpotJVMCIBackendFactory factory : ServiceLoader.load(HotSpotJVMCIBackendFactory.class)) { > > This uses the thread context class loader to load providers. Services::load uses > the system class loader to load providers. I suspect you want this to use the > system class loader here too. > > jdk/vm/ci/services/JVMCIServiceLocator.java > 78 for (JVMCIServiceLocator access : ServiceLoader.load(JVMCIServiceLocator.class)) { > > Same comment as above. I think you want to use system class loader to load providers. Yes, I think you're right. I've updated the webrev with that change. Thanks for the review. -Doug [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l94 [2] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/560d7aa083a2/.mx.jvmci/suite.py#l45 From peter.levart at gmail.com Wed Apr 19 07:37:38 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 09:37:38 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: Hi Doug, Mandy, Just a minor comment on the VM class changes... Note that Properties class is thread-safe, while HashMap isn't. But I think this should not be a problem here, as during initPhase1(), as far as I know, no threads apart from main thread are started yet (is this true?), so anyone accessing getSavedProperty(ies) will either be the main thread itself or a thread started afterwards, so there is a happens-before relationship. If this is true, then we could wrap the copy of saved properties with an unmodifiable map view before setting the savedProps field so that getSavedProperties() could always return the same instance. Like for example in the following alternative change: http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ What do you think? Regards, Peter On 04/19/2017 02:02 AM, Mandy Chung wrote: >> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote: >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> : >> http://cr.openjdk.java.net/~dnsimon/8177845/ > Thanks for making this change. This would simplify the way to replace JDK?s graal with the lab graal. A couple of comments: > > jdk/internal/misc/VM.java > > 161 * Note that the saved system properties do not include > 162 * the ones set by sun.misc.Version.init(). > > sun.misc.Version is no longer present in JDK 9. Renamed to java.lang.VersionProps > > jdk/vm/ci/services/Services.java > 67 Class.forName("jdk.vm.ci.runtime.JVMCI?); > > JVMCI class is local in jdk.internal.vm.ci module. An alternative may be > to provide a static initialize method rather than Class::forName. > > jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java > 211 for (HotSpotJVMCIBackendFactory factory : ServiceLoader.load(HotSpotJVMCIBackendFactory.class)) { > > This uses the thread context class loader to load providers. Services::load uses > the system class loader to load providers. I suspect you want this to use the > system class loader here too. > > jdk/vm/ci/services/JVMCIServiceLocator.java > 78 for (JVMCIServiceLocator access : ServiceLoader.load(JVMCIServiceLocator.class)) { > > Same comment as above. I think you want to use system class loader to load providers. > > Mandy From peter.levart at gmail.com Wed Apr 19 07:42:27 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 09:42:27 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> On 04/19/2017 09:37 AM, Peter Levart wrote: > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ > Also, while we are at it, the following javadocs in the getSavedProperty() do not apply any more: 138 * It accesses a private copy of the system properties so 139 * that user's locking of the system properties object will not 140 * cause the library to deadlock. In JDK 9, Properties class does not use locking any more on the Properties instance for get()/getProperty() methods... Regards, Peter From peter.levart at gmail.com Wed Apr 19 08:12:59 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 10:12:59 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> Message-ID: On 04/19/2017 09:42 AM, Peter Levart wrote: > > > On 04/19/2017 09:37 AM, Peter Levart wrote: >> >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ >> > > Also, while we are at it, the following javadocs in the > getSavedProperty() do not apply any more: > > 138 * It accesses a private copy of the system properties so > 139 * that user's locking of the system properties object will not > 140 * cause the library to deadlock. > > In JDK 9, Properties class does not use locking any more on the > Properties instance for get()/getProperty() methods... > > Regards, Peter > I also noticed the following comment: // TODO: the Property Management needs to be refactored and // the appropriate prop keys need to be accessible to the // calling classes to avoid duplication of keys. private static Map savedProps; ...which is not entirely true. Neither keys nor values are duplicated (they are just referenced in the new copy of the Properties/Map object). What is duplicated is an excessive amount of internal objects, such as array slots and Map.Entry objects. If this is a concern, then we could use the new immutable Map implementation that is available in JDK 9, so the following lines in my webrev: 181 @SuppressWarnings("unchecked") 182 Map sp = new HashMap<>((Map)props); 183 // only main thread is running at this time, so savedProps and 184 // its content will be correctly published to threads started later 185 savedProps = Collections.unmodifiableMap(sp); Could be changed into: @SuppressWarnings("unchecked") Map sp = Map.ofEntries(props.entrySet().toArray(new Map.Entry[0])); // only main thread is running at this time, so savedProps // will be correctly published to threads started later savedProps = sp; ...to save some excessive space (the implementation is a linear-probe hashtable which keeps keys and values directly in an array without wrapping them with Map.Entry objects). Regards, Peter From doug.simon at oracle.com Wed Apr 19 09:25:54 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 11:25:54 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> Message-ID: Hi Peter, All of your suggestions look good. I've updated http://cr.openjdk.java.net/~dnsimon/8177845/jdk/src/java.base/share/classes/jdk/internal/misc/VM.java.udiff.html to include them (please check I didn't make any copy errors in the process). I was not aware of the new Map.ofEntries method. Nice to see more space efficient map implementations being added to the JDK. Thanks! -Doug > On 19 Apr 2017, at 10:12, Peter Levart wrote: > > > > On 04/19/2017 09:42 AM, Peter Levart wrote: >> >> >> On 04/19/2017 09:37 AM, Peter Levart wrote: >>> >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ >> >> Also, while we are at it, the following javadocs in the getSavedProperty() do not apply any more: >> >> 138 * It accesses a private copy of the system properties so >> 139 * that user's locking of the system properties object will not >> 140 * cause the library to deadlock. >> >> In JDK 9, Properties class does not use locking any more on the Properties instance for get()/getProperty() methods... >> >> Regards, Peter >> > > I also noticed the following comment: > > // TODO: the Property Management needs to be refactored and > // the appropriate prop keys need to be accessible to the > // calling classes to avoid duplication of keys. > private static Map savedProps; > > ...which is not entirely true. Neither keys nor values are duplicated (they are just referenced in the new copy of the Properties/Map object). What is duplicated is an excessive amount of internal objects, such as array slots and Map.Entry objects. If this is a concern, then we could use the new immutable Map implementation that is available in JDK 9, so the following lines in my webrev: > > 181 @SuppressWarnings("unchecked") > 182 Map sp = new HashMap<>((Map)props); > 183 // only main thread is running at this time, so savedProps and > 184 // its content will be correctly published to threads started later > 185 savedProps = Collections.unmodifiableMap(sp); > > Could be changed into: > > @SuppressWarnings("unchecked") > Map sp = > Map.ofEntries(props.entrySet().toArray(new Map.Entry[0])); > // only main thread is running at this time, so savedProps > // will be correctly published to threads started later > savedProps = sp; > > ...to save some excessive space (the implementation is a linear-probe hashtable which keeps keys and values directly in an array without wrapping them with Map.Entry objects). > > Regards, Peter > From peter.levart at gmail.com Wed Apr 19 09:49:08 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 11:49:08 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> Message-ID: Hi Simon, On 04/19/2017 11:25 AM, Doug Simon wrote: > Hi Peter, > > All of your suggestions look good. I've updated http://cr.openjdk.java.net/~dnsimon/8177845/jdk/src/java.base/share/classes/jdk/internal/misc/VM.java.udiff.html to include them (please check I didn't make any copy errors in the process). Looks good. > > I was not aware of the new Map.ofEntries method. Nice to see more space efficient map implementations being added to the JDK. Admittedly, I used this method in a way not envisioned by the author. Maybe there's a reason there is no Map.copyOf(Map) method there, which would make this even simpler. If there was one, it would be too easy to (mis)use it instead of Collections.unmodifiableMap(Map), albeit with a slightly different semantics, and force re-hashing-copying of big maps where there is no need to do that. But it would be a pretty nice replacement for the following idiom: Collections.unmodifiableMap(new HashMap<>(someMap)) Regards, Peter > > Thanks! > > -Doug > >> On 19 Apr 2017, at 10:12, Peter Levart wrote: >> >> >> >> On 04/19/2017 09:42 AM, Peter Levart wrote: >>> >>> On 04/19/2017 09:37 AM, Peter Levart wrote: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ >>> Also, while we are at it, the following javadocs in the getSavedProperty() do not apply any more: >>> >>> 138 * It accesses a private copy of the system properties so >>> 139 * that user's locking of the system properties object will not >>> 140 * cause the library to deadlock. >>> >>> In JDK 9, Properties class does not use locking any more on the Properties instance for get()/getProperty() methods... >>> >>> Regards, Peter >>> >> I also noticed the following comment: >> >> // TODO: the Property Management needs to be refactored and >> // the appropriate prop keys need to be accessible to the >> // calling classes to avoid duplication of keys. >> private static Map savedProps; >> >> ...which is not entirely true. Neither keys nor values are duplicated (they are just referenced in the new copy of the Properties/Map object). What is duplicated is an excessive amount of internal objects, such as array slots and Map.Entry objects. If this is a concern, then we could use the new immutable Map implementation that is available in JDK 9, so the following lines in my webrev: >> >> 181 @SuppressWarnings("unchecked") >> 182 Map sp = new HashMap<>((Map)props); >> 183 // only main thread is running at this time, so savedProps and >> 184 // its content will be correctly published to threads started later >> 185 savedProps = Collections.unmodifiableMap(sp); >> >> Could be changed into: >> >> @SuppressWarnings("unchecked") >> Map sp = >> Map.ofEntries(props.entrySet().toArray(new Map.Entry[0])); >> // only main thread is running at this time, so savedProps >> // will be correctly published to threads started later >> savedProps = sp; >> >> ...to save some excessive space (the implementation is a linear-probe hashtable which keeps keys and values directly in an array without wrapping them with Map.Entry objects). >> >> Regards, Peter >> From peter.levart at gmail.com Wed Apr 19 10:01:51 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 12:01:51 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <49b6a3ac-da15-7635-ab26-07d21de19b40@gmail.com> Message-ID: <8a7d3c56-0190-710a-8f21-0f957ebb95a2@gmail.com> On 04/19/2017 11:49 AM, Peter Levart wrote: >> I was not aware of the new Map.ofEntries method. Nice to see more >> space efficient map implementations being added to the JDK. > > Admittedly, I used this method in a way not envisioned by the author. > Maybe there's a reason there is no Map.copyOf(Map) method there, which > would make this even simpler. If there was one, it would be too easy > to (mis)use it instead of Collections.unmodifiableMap(Map), albeit > with a slightly different semantics, and force re-hashing-copying of > big maps where there is no need to do that. But it would be a pretty > nice replacement for the following idiom: > > Collections.unmodifiableMap(new HashMap<>(someMap)) Sometimes I wish that besides public, protected, "package-private" and private, Java also had an "expert protected" access modifier ;-) Regards, Peter From Alan.Bateman at oracle.com Wed Apr 19 13:41:24 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Apr 2017 14:41:24 +0100 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: On 19/04/2017 08:37, Peter Levart wrote: > : > > Note that Properties class is thread-safe, while HashMap isn't. But I > think this should not be a problem here, as during initPhase1(), as > far as I know, no threads apart from main thread are started yet (is > this true?), so anyone accessing getSavedProperty(ies) will either be > the main thread itself or a thread started afterwards, so there is a > happens-before relationship. The ReferenceHandler and Finalizer threads are started early, before initPhase1. However, both should immediately block and in the case of the Finalizer, await the completion of initPhase1 before polling. -Alan From Alan.Bateman at oracle.com Wed Apr 19 14:04:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Apr 2017 15:04:10 +0100 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> Message-ID: <56bb9632-e8d7-60be-0832-fa86c20a36ef@oracle.com> On 18/04/2017 23:13, Doug Simon wrote: > : > > https://bugs.openjdk.java.net/browse/JDK-8177845 > http://cr.openjdk.java.net/~dnsimon/8177845/ > I'm happy to see jdk.internal.vm.compiler changing to be an upgradable module and the patching foo going away. If I read the changes correctly then I can extend JVMCIServiceLocator and the construction of my sub-class will open up all packages in jdk.internal.vm.ci to me. It is there any to tie this to -XX:+EnableJVMCI? -Alan From doug.simon at oracle.com Wed Apr 19 14:16:44 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 16:16:44 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <56bb9632-e8d7-60be-0832-fa86c20a36ef@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <56bb9632-e8d7-60be-0832-fa86c20a36ef@oracle.com> Message-ID: <28A2A0B1-3898-43DB-BFA1-011B64D2CE69@oracle.com> > On 19 Apr 2017, at 16:04, Alan Bateman wrote: > > On 18/04/2017 23:13, Doug Simon wrote: > >> : >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> > I'm happy to see jdk.internal.vm.compiler changing to be an upgradable module and the patching foo going away. Yes, I'm delighted to see the command line required for using upstream Graal shrinking! > If I read the changes correctly then I can extend JVMCIServiceLocator and the construction of my sub-class will open up all packages in jdk.internal.vm.ci to me. It is there any to tie this to -XX:+EnableJVMCI? We could but I'm not sure what it would buy you. The service lookup only originates from the JVMCI runtime and the initialization of JVMCI already checks EnableJVMCI[1] -Doug [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/file/4368832d1991/src/share/vm/jvmci/jvmciRuntime.cpp#l634 From kevin.rushforth at oracle.com Wed Apr 19 14:20:58 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Apr 2017 07:20:58 -0700 Subject: Issue with JavaFX and Jigsaw In-Reply-To: <58F5276C.9080601@oracle.com> References: <8D46B267-3FE8-4076-A8A0-677A71758833@oracle.com> <58EC0D99.1070700@oracle.com> <58F5106C.3020701@oracle.com> <58F51E05.3050207@oracle.com> <58F51F9D.2020601@oracle.com> <58F5276C.9080601@oracle.com> Message-ID: <58F7724A.50800@oracle.com> Actually, since the API doc for Module#isExported(String) [1] specifies that it also returns true if the package is opened unconditionally, do you think I need to mention it in the JavaFX docs as a parenthetical comment, or it is sufficient to link to Module#isExported(String)? -- Kevin [1] http://download.java.net/java/jdk9/docs/api/java/lang/Module.html#isExported-java.lang.String- Kevin Rushforth wrote: > > > Alex Buckley wrote: >> OK, so for the JDK 9 docs, "unconditionally exported (or >> unconditionally opened)" would be clear. > > I was originally thinking to require unconditional export, but since > it will also be fine for an application to open the package > unconditionally, I will make this change and document either as being > sufficient. > > Thanks. > > -- Kevin > From peter.levart at gmail.com Wed Apr 19 15:03:04 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Apr 2017 17:03:04 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: Hi Alan, On 04/19/2017 03:41 PM, Alan Bateman wrote: > On 19/04/2017 08:37, Peter Levart wrote: > >> : >> >> Note that Properties class is thread-safe, while HashMap isn't. But I >> think this should not be a problem here, as during initPhase1(), as >> far as I know, no threads apart from main thread are started yet (is >> this true?), so anyone accessing getSavedProperty(ies) will either be >> the main thread itself or a thread started afterwards, so there is a >> happens-before relationship. > The ReferenceHandler and Finalizer threads are started early, before > initPhase1. However, both should immediately block and in the case of > the Finalizer, await the completion of initPhase1 before polling. > > -Alan Just out of curiosity, what guarantees are there that no code before VM.saveAndRemoveProperties() ever executes Integer.valueOf(int) method for example? Note that this call is implicitly hidden in autoboxing of int(s)... If this happens, then class initialization of Integer.IntegerCache may fail, because it is using VM.getSavedProperty(): public static String getSavedProperty(String key) { if (savedProps.isEmpty()) throw new IllegalStateException("Should be non-empty if initialized"); return savedProps.getProperty(key); } Hm.... Peter From mandy.chung at oracle.com Wed Apr 19 18:01:33 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 11:01:33 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> Message-ID: <078DD9E5-1A87-4F82-8698-3E19757DEDE4@oracle.com> > On Apr 19, 2017, at 8:03 AM, Peter Levart wrote: > > Hi Alan, > > On 04/19/2017 03:41 PM, Alan Bateman wrote: >> On 19/04/2017 08:37, Peter Levart wrote: >> >>> : >>> >>> Note that Properties class is thread-safe, while HashMap isn't. But I think this should not be a problem here, as during initPhase1(), as far as I know, no threads apart from main thread are started yet (is this true?), so anyone accessing getSavedProperty(ies) will either be the main thread itself or a thread started afterwards, so there is a happens-before relationship. >> The ReferenceHandler and Finalizer threads are started early, before initPhase1. However, both should immediately block and in the case of the Finalizer, await the completion of initPhase1 before polling. >> >> -Alan > > Just out of curiosity, what guarantees are there that no code before VM.saveAndRemoveProperties() ever executes Integer.valueOf(int) method for example? Note that this call is implicitly hidden in autoboxing of int(s)... > > If this happens, then class initialization of Integer.IntegerCache may fail, because it is using VM.getSavedProperty(): > > public static String getSavedProperty(String key) { > if (savedProps.isEmpty()) > throw new IllegalStateException("Should be non-empty if initialized"); > > return savedProps.getProperty(key); > } > > Hm.... We should catch this issue and detect if VM.getSavedProperty is called when init level < 1 during early startup. Mandy From cthalinger at twitter.com Wed Apr 19 18:24:48 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 08:24:48 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: Message-ID: I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? module jdk.internal.vm.ci { - exports jdk.vm.ci.services to jdk.internal.vm.compiler; + exports jdk.vm.ci.services; > On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: > > (adding hotspot-compiler-dev) > > Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. > The primary requirement for this is to remove all usage of JDK internals from Graal. > While this most involves changes in Graal, there remain a few capabilities that must > be exposed via JVMCI. Namely: > > 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize > can use system properties that are guaranteed not to have been modified by application > code (Graal initialization is lazy and may occur after application code has been run). > > 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal > optimized implementation of the Truffle runtime. > > These capabilities have been added to jdk.vm.ci.services.Services. A comment has > also been added to this class to denote the current methods to be removed > in a subsequent bug to update the JDK copy of Graal with the upstream version which > no longer uses the methods. The methods destined for removal are: > > exportJVMCITo(Class requestor) > load(Class service) > loadSingle(Class service, boolean required) > > The first one is no longer needed as JVMCI exports itself to Graal service providers > it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. > The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API > is only useful for JVMCI-8 where a hidden JVMCI class loader is used. > > These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra > minor changes were required: > > 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException > on all error paths except one which throws AssertionError. The latter was a mistake and has been > fixed to also throw IllegalArgumentException. > 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. > Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. > This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. > > As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and > remove use of JDK internal API from the jdk.aot module. The qualified exports to > jdk.vm.internal.compiler and jdk.aot can then be removed. > > -Doug > > https://bugs.openjdk.java.net/browse/JDK-8177845 > http://cr.openjdk.java.net/~dnsimon/8177845/ > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess > > > From mandy.chung at oracle.com Wed Apr 19 18:38:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 11:38:04 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: Message-ID: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. Mandy > On Apr 19, 2017, at 11:24 AM, Christian Thalinger wrote: > > I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? > > module jdk.internal.vm.ci { > - exports jdk.vm.ci.services to jdk.internal.vm.compiler; > + exports jdk.vm.ci.services; > >> On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: >> >> (adding hotspot-compiler-dev) >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> The primary requirement for this is to remove all usage of JDK internals from Graal. >> While this most involves changes in Graal, there remain a few capabilities that must >> be exposed via JVMCI. Namely: >> >> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >> can use system properties that are guaranteed not to have been modified by application >> code (Graal initialization is lazy and may occur after application code has been run). >> >> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >> optimized implementation of the Truffle runtime. >> >> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >> also been added to this class to denote the current methods to be removed >> in a subsequent bug to update the JDK copy of Graal with the upstream version which >> no longer uses the methods. The methods destined for removal are: >> >> exportJVMCITo(Class requestor) >> load(Class service) >> loadSingle(Class service, boolean required) >> >> The first one is no longer needed as JVMCI exports itself to Graal service providers >> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >> >> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >> minor changes were required: >> >> 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >> on all error paths except one which throws AssertionError. The latter was a mistake and has been >> fixed to also throw IllegalArgumentException. >> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >> >> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >> remove use of JDK internal API from the jdk.aot module. The qualified exports to >> jdk.vm.internal.compiler and jdk.aot can then be removed. >> >> -Doug >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> >> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >> >> >> > From cthalinger at twitter.com Wed Apr 19 18:55:29 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 08:55:29 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> Message-ID: <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> > On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: > > Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. > > The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. > > Mandy > >> On Apr 19, 2017, at 11:24 AM, Christian Thalinger wrote: >> >> I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? >> >> module jdk.internal.vm.ci { >> - exports jdk.vm.ci.services to jdk.internal.vm.compiler; >> + exports jdk.vm.ci.services; >> >>> On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: >>> >>> (adding hotspot-compiler-dev) >>> >>> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >>> The primary requirement for this is to remove all usage of JDK internals from Graal. >>> While this most involves changes in Graal, there remain a few capabilities that must >>> be exposed via JVMCI. Namely: >>> >>> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >>> can use system properties that are guaranteed not to have been modified by application >>> code (Graal initialization is lazy and may occur after application code has been run). >>> >>> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >>> optimized implementation of the Truffle runtime. >>> >>> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >>> also been added to this class to denote the current methods to be removed >>> in a subsequent bug to update the JDK copy of Graal with the upstream version which >>> no longer uses the methods. The methods destined for removal are: >>> >>> exportJVMCITo(Class requestor) >>> load(Class service) >>> loadSingle(Class service, boolean required) >>> >>> The first one is no longer needed as JVMCI exports itself to Graal service providers >>> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >>> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >>> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >>> >>> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >>> minor changes were required: >>> >>> 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >>> on all error paths except one which throws AssertionError. The latter was a mistake and has been >>> fixed to also throw IllegalArgumentException. >>> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >>> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >>> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >>> >>> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >>> remove use of JDK internal API from the jdk.aot module. The qualified exports to >>> jdk.vm.internal.compiler and jdk.aot can then be removed. >>> >>> -Doug >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177845 >>> http://cr.openjdk.java.net/~dnsimon/8177845/ >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >>> >>> >>> >> > From mandy.chung at oracle.com Wed Apr 19 19:04:49 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 12:04:49 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: > > >> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >> >> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >> >> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. > > This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? It's unqualified and no restriction in this change. Mandy From doug.simon at oracle.com Wed Apr 19 19:07:06 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 21:07:06 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <078DD9E5-1A87-4F82-8698-3E19757DEDE4@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <078DD9E5-1A87-4F82-8698-3E19757DEDE4@oracle.com> Message-ID: <2FDA9652-F376-439B-AFA6-DF929DB3D403@oracle.com> > On 19 Apr 2017, at 20:01, Mandy Chung wrote: > >> >> On Apr 19, 2017, at 8:03 AM, Peter Levart wrote: >> >> Hi Alan, >> >> On 04/19/2017 03:41 PM, Alan Bateman wrote: >>> On 19/04/2017 08:37, Peter Levart wrote: >>> >>>> : >>>> >>>> Note that Properties class is thread-safe, while HashMap isn't. But I think this should not be a problem here, as during initPhase1(), as far as I know, no threads apart from main thread are started yet (is this true?), so anyone accessing getSavedProperty(ies) will either be the main thread itself or a thread started afterwards, so there is a happens-before relationship. >>> The ReferenceHandler and Finalizer threads are started early, before initPhase1. However, both should immediately block and in the case of the Finalizer, await the completion of initPhase1 before polling. >>> >>> -Alan >> >> Just out of curiosity, what guarantees are there that no code before VM.saveAndRemoveProperties() ever executes Integer.valueOf(int) method for example? Note that this call is implicitly hidden in autoboxing of int(s)... >> >> If this happens, then class initialization of Integer.IntegerCache may fail, because it is using VM.getSavedProperty(): >> >> public static String getSavedProperty(String key) { >> if (savedProps.isEmpty()) >> throw new IllegalStateException("Should be non-empty if initialized"); >> >> return savedProps.getProperty(key); >> } >> >> Hm.... > > We should catch this issue and detect if VM.getSavedProperty is called when init level < 1 during early startup. What are you proposing? Some extra testing of VM startup to see if this is an issue? If so, can you please suggest what testing is to be performed. -Doug From mandy.chung at oracle.com Wed Apr 19 19:20:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 12:20:10 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <2FDA9652-F376-439B-AFA6-DF929DB3D403@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <808007C7-8B14-46BB-A932-9EA9DE2285A9@oracle.com> <078DD9E5-1A87-4F82-8698-3E19757DEDE4@oracle.com> <2FDA9652-F376-439B-AFA6-DF929DB3D403@oracle.com> Message-ID: <08B17CC8-CAA5-44AD-BD85-ED8B72326C73@oracle.com> > On Apr 19, 2017, at 12:07 PM, Doug Simon wrote: > > >> On 19 Apr 2017, at 20:01, Mandy Chung wrote: >> >> We should catch this issue and detect if VM.getSavedProperty is called when init level < 1 during early startup. > > What are you proposing? Some extra testing of VM startup to see if this is an issue? If so, can you please suggest what testing is to be performed. This is an existing issue, not related to your change. I will create JBS issue to track it. What you have is fine. Mandy From doug.simon at oracle.com Wed Apr 19 19:27:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 21:27:38 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On 19 Apr 2017, at 21:04, Mandy Chung wrote: > > >> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >> >> >>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>> >>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>> >>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >> >> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? > > It's unqualified and no restriction in this change. The public methods currently in jdk.vm.ci.services are: 1. JVMCIServiceLocator.getProvider(Class) 2. JVMCIServiceLocator.getProviders(Class) 3. Services.initializeJVMCI() 4. Services.getSavedProperties() 5. Services.exportJVMCITo(Class) 6. Services.load(Class) 7. Services.loadSingle(Class, boolean) 1 should be made protected. I'll update the webrev with this change. 2 should check for JVMCIPermission. I'll update the webrev with this change. 3 is harmless from a security perspective in my opinion. 4 checks for JVMCIPermission. 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). Does this address the security concerns? -Doug From cthalinger at twitter.com Wed Apr 19 19:40:19 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 19 Apr 2017 09:40:19 -1000 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: > On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: > >> >> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >> >> >>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>> >>> >>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>> >>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>> >>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>> >>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >> >> It's unqualified and no restriction in this change. > > The public methods currently in jdk.vm.ci.services are: > > 1. JVMCIServiceLocator.getProvider(Class) > 2. JVMCIServiceLocator.getProviders(Class) > 3. Services.initializeJVMCI() > 4. Services.getSavedProperties() > 5. Services.exportJVMCITo(Class) > 6. Services.load(Class) > 7. Services.loadSingle(Class, boolean) > > 1 should be made protected. I'll update the webrev with this change. Good. > > 2 should check for JVMCIPermission. I'll update the webrev with this change. Good. > > 3 is harmless from a security perspective in my opinion. Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > > 4 checks for JVMCIPermission. Ok. > > 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). About this, will this Graal update happen for JDK 9? It?s awfully late in the cycle... > > Does this address the security concerns? Mostly, yes. Thanks. > > -Doug From vladimir.kozlov at oracle.com Wed Apr 19 19:46:05 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 12:46:05 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> Message-ID: Hi Doug, Can you consider using other name and not JDK9 for new JVMCI class? It will be used in JDK 10 too: jdk.vm.ci.services.internal.JDK9; Thanks, Vladimir On 4/18/17 3:13 PM, Doug Simon wrote: > Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. > The primary requirement for this is to remove all usage of JDK internals from Graal. > While this most involves changes in Graal, there remain a few capabilities that must > be exposed via JVMCI. Namely: > > 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize > can use system properties that are guaranteed not to have been modified by application > code (Graal initialization is lazy and may occur after application code has been run). > > 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal > optimized implementation of the Truffle runtime. > > These capabilities have been added to jdk.vm.ci.services.Services. A comment has > also been added to this class to denote the current methods to be removed > in a subsequent bug to update the JDK copy of Graal with the upstream version which > no longer uses the methods. The methods destined for removal are: > > exportJVMCITo(Class requestor) > load(Class service) > loadSingle(Class service, boolean required) > > The first one is no longer needed as JVMCI exports itself to Graal service providers > it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. > The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API > is only useful for JVMCI-8 where a hidden JVMCI class loader is used. > > These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra > minor changes were required: > > 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException > on all error paths except one which throws AssertionError. The latter was a mistake and has been > fixed to also throw IllegalArgumentException. > 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. > Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. > This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. > > As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and > remove use of JDK internal API from the jdk.aot module. The qualified exports to > jdk.vm.internal.compiler and jdk.aot can then be removed. > > -Doug > > https://bugs.openjdk.java.net/browse/JDK-8177845 > http://cr.openjdk.java.net/~dnsimon/8177845/ > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess > > > From doug.simon at oracle.com Wed Apr 19 20:02:46 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 22:02:46 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> Message-ID: <69BA05B6-C33A-4D97-A323-3E3216515A38@oracle.com> Sure - how about good old Util? ;-) I'm open to other suggestions. Sent from my iPhone > On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov wrote: > > Hi Doug, > > Can you consider using other name and not JDK9 for new JVMCI class? It will be used in JDK 10 too: > > jdk.vm.ci.services.internal.JDK9; > > Thanks, > Vladimir > >> On 4/18/17 3:13 PM, Doug Simon wrote: >> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >> The primary requirement for this is to remove all usage of JDK internals from Graal. >> While this most involves changes in Graal, there remain a few capabilities that must >> be exposed via JVMCI. Namely: >> >> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >> can use system properties that are guaranteed not to have been modified by application >> code (Graal initialization is lazy and may occur after application code has been run). >> >> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >> optimized implementation of the Truffle runtime. >> >> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >> also been added to this class to denote the current methods to be removed >> in a subsequent bug to update the JDK copy of Graal with the upstream version which >> no longer uses the methods. The methods destined for removal are: >> >> exportJVMCITo(Class requestor) >> load(Class service) >> loadSingle(Class service, boolean required) >> >> The first one is no longer needed as JVMCI exports itself to Graal service providers >> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >> >> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >> minor changes were required: >> >> 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >> on all error paths except one which throws AssertionError. The latter was a mistake and has been >> fixed to also throw IllegalArgumentException. >> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >> >> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >> remove use of JDK internal API from the jdk.aot module. The qualified exports to >> jdk.vm.internal.compiler and jdk.aot can then be removed. >> >> -Doug >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> >> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >> >> >> From vladimir.kozlov at oracle.com Wed Apr 19 20:29:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 13:29:24 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <69BA05B6-C33A-4D97-A323-3E3216515A38@oracle.com> References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <69BA05B6-C33A-4D97-A323-3E3216515A38@oracle.com> Message-ID: ReflectionAccessJDK ? Based on your comment in the file. Vladimir On 4/19/17 1:02 PM, Doug Simon wrote: > Sure - how about good old Util? ;-) I'm open to other suggestions. > > Sent from my iPhone > >> On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov wrote: >> >> Hi Doug, >> >> Can you consider using other name and not JDK9 for new JVMCI class? It will be used in JDK 10 too: >> >> jdk.vm.ci.services.internal.JDK9; >> >> Thanks, >> Vladimir >> >>> On 4/18/17 3:13 PM, Doug Simon wrote: >>> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >>> The primary requirement for this is to remove all usage of JDK internals from Graal. >>> While this most involves changes in Graal, there remain a few capabilities that must >>> be exposed via JVMCI. Namely: >>> >>> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >>> can use system properties that are guaranteed not to have been modified by application >>> code (Graal initialization is lazy and may occur after application code has been run). >>> >>> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >>> optimized implementation of the Truffle runtime. >>> >>> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >>> also been added to this class to denote the current methods to be removed >>> in a subsequent bug to update the JDK copy of Graal with the upstream version which >>> no longer uses the methods. The methods destined for removal are: >>> >>> exportJVMCITo(Class requestor) >>> load(Class service) >>> loadSingle(Class service, boolean required) >>> >>> The first one is no longer needed as JVMCI exports itself to Graal service providers >>> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >>> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >>> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >>> >>> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >>> minor changes were required: >>> >>> 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >>> on all error paths except one which throws AssertionError. The latter was a mistake and has been >>> fixed to also throw IllegalArgumentException. >>> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >>> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >>> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >>> >>> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >>> remove use of JDK internal API from the jdk.aot module. The qualified exports to >>> jdk.vm.internal.compiler and jdk.aot can then be removed. >>> >>> -Doug >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177845 >>> http://cr.openjdk.java.net/~dnsimon/8177845/ >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >>> >>> >>> > From doug.simon at oracle.com Wed Apr 19 21:12:22 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 23:12:22 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> Message-ID: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> > On 19 Apr 2017, at 21:40, Christian Thalinger wrote: > >> >> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>> >>> >>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>> >>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>> >>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>> >>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>> >>> It's unqualified and no restriction in this change. >> >> The public methods currently in jdk.vm.ci.services are: >> >> 1. JVMCIServiceLocator.getProvider(Class) >> 2. JVMCIServiceLocator.getProviders(Class) >> 3. Services.initializeJVMCI() >> 4. Services.getSavedProperties() >> 5. Services.exportJVMCITo(Class) >> 6. Services.load(Class) >> 7. Services.loadSingle(Class, boolean) >> >> 1 should be made protected. I'll update the webrev with this change. > > Good. > >> >> 2 should check for JVMCIPermission. I'll update the webrev with this change. > > Good. > >> >> 3 is harmless from a security perspective in my opinion. > > Would be good if one of Oracle?s security engineers could take a quick look just to be sure. Vladimir, can you please bring this to the attention of the relevant engineer. >> >> 4 checks for JVMCIPermission. > > Ok. > >> >> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). > > About this, will this Graal update happen for JDK 9? Yes. > It?s awfully late in the cycle... These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). -Doug From doug.simon at oracle.com Wed Apr 19 21:26:28 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 19 Apr 2017 23:26:28 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: 1. JVMCIServiceLocator.getProvider(Class) is now protected 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK -Doug > On 19 Apr 2017, at 23:12, Doug Simon wrote: > >> >> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >> >>> >>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>> >>>> >>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>> >>>> >>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>> >>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>> >>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>> >>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>> >>>> It's unqualified and no restriction in this change. >>> >>> The public methods currently in jdk.vm.ci.services are: >>> >>> 1. JVMCIServiceLocator.getProvider(Class) >>> 2. JVMCIServiceLocator.getProviders(Class) >>> 3. Services.initializeJVMCI() >>> 4. Services.getSavedProperties() >>> 5. Services.exportJVMCITo(Class) >>> 6. Services.load(Class) >>> 7. Services.loadSingle(Class, boolean) >>> >>> 1 should be made protected. I'll update the webrev with this change. >> >> Good. >> >>> >>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >> >> Good. >> >>> >>> 3 is harmless from a security perspective in my opinion. >> >> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > > Vladimir, can you please bring this to the attention of the relevant engineer. > >>> >>> 4 checks for JVMCIPermission. >> >> Ok. >> >>> >>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >> >> About this, will this Graal update happen for JDK 9? > > Yes. > >> It?s awfully late in the cycle... > > These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). > > -Doug From vladimir.kozlov at oracle.com Wed Apr 19 22:28:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 15:28:09 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> Message-ID: <21999ed5-23aa-939b-f1e5-1eb08b3c03e4@oracle.com> Hotspot changes looks good to me. Thanks, Vladimir On 4/19/17 2:26 PM, Doug Simon wrote: > I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: > > 1. JVMCIServiceLocator.getProvider(Class) is now protected > 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission > 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK > > -Doug > >> On 19 Apr 2017, at 23:12, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>> >>>> >>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>> >>>>> >>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>> >>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>> >>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>> >>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>> >>>>> It's unqualified and no restriction in this change. >>>> >>>> The public methods currently in jdk.vm.ci.services are: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) >>>> 2. JVMCIServiceLocator.getProviders(Class) >>>> 3. Services.initializeJVMCI() >>>> 4. Services.getSavedProperties() >>>> 5. Services.exportJVMCITo(Class) >>>> 6. Services.load(Class) >>>> 7. Services.loadSingle(Class, boolean) >>>> >>>> 1 should be made protected. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 3 is harmless from a security perspective in my opinion. >>> >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> >> Vladimir, can you please bring this to the attention of the relevant engineer. >> >>>> >>>> 4 checks for JVMCIPermission. >>> >>> Ok. >>> >>>> >>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>> >>> About this, will this Graal update happen for JDK 9? >> >> Yes. >> >>> It?s awfully late in the cycle... >> >> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >> >> -Doug > From vladimir.kozlov at oracle.com Wed Apr 19 22:31:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Apr 2017 15:31:25 -0700 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: Doug, Can you point (link) particular code which needs to be reviewed? And what security issues could be? Thanks, Vladimir On 4/19/17 2:12 PM, Doug Simon wrote: >> 3. Services.initializeJVMCI() >>> 3 is harmless from a security perspective in my opinion. >> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. > Vladimir, can you please bring this to the attention of the relevant engineer. > From manovotn at redhat.com Thu Apr 20 06:43:04 2017 From: manovotn at redhat.com (Matej Novotny) Date: Thu, 20 Apr 2017 02:43:04 -0400 (EDT) Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> Message-ID: <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> So I did some hacking and tried to make Weld use MethodHandles.Lookup and here is a bit of a feedback for you. But first of all, thanks for your quick advice on how to approach this. Alright, I should say that I _somehow_ managed to make it work in simple cases (SE container for most part). I haven't tried my dirty solution in anything EE, which is where problems will definitely pop-up (as they always do when you say "EAR"). ATM it is pretty impossible to try Weld 3 (will support jdk 9, still not final, CDI 2.0 impl) with any AS as none support it ATM (will try to port it to Wildfly 11). To sum up how well Lookup worked for me, let me shed some light on how Weld works (simplified ofc) and therefore what I needed to achieve: In short, we scan CP for classes which are to become beans. Such classes are the processed and eventually get a proxy created for them (given they have the right scope). This proxy is a piece of generated bytecode which we need to register via CL, or now via Lookup, using defineClass method. We respect the packages - proxy lands in the same package as the original class (with notable exceptions, see below). All the above has to be done during bootstrap - you cannot dynamically add/remove beans once you got application running. So, how did Lookup work for us? 1) privateLookupIn + drop private mode This was the way to go, as the bean classes can be anywhere (in classes not openly accessible to us, especially if we consider modules). BTW I am not sure about the purpose of the private mode as you always need to drop it to be able to use lookup. 2) Lookup approach carries along the need to pass the reference to the base lookup class at all times. This is kind of weird because in some (not-so-rare) cases, we need to create "artificial packages" in which we place proxy classes. For instance when we create a proxy for Interger, Map, Principal,... Ofc we cannot place in into java.* packages, so we create our own. For this to work with Lookup, we need to have that package created ahead of time and have a reference to some "dummy" useless class inside to be able to do the lookup. Or is there a way to define a whole new (open by default) package where we could place it using Lookup? Having the "dummy" package/class just to use Lookup is lame and very error prone (I can think of several ways to break the proxy creation even now). 3) All in all the changes carried along a lot of complexity compared to plain old ClassLoader.defineClass We need to create A LOT of Lookups (might present performance overhead, haven't tested yet). Extra care needs to be given to the packages for Lookup not to blow up while we in fact don't really care where the proxy lands as long as it is usable. Another nasty thing is that the code of course needs to work with both, JDK 9 and 8. While it isn't impossible, it will add a not-so-nice reflection magic layer to the mix. Regards Matej ----- Original Message ----- > From: "Alan Bateman" > To: "Matej Novotny" , jigsaw-dev at openjdk.java.net > Cc: "Martin Kouba" > Sent: Friday, March 31, 2017 4:28:34 PM > Subject: Re: setAccessible() alternative with Jigsaw > > On 31/03/2017 14:46, Matej Novotny wrote: > > > Hello, > > > > I work on Weld, context dependency injection framework. > > Long story short - we need to generate proxies for classes - bytecode which > > we then "register" with the class loader using > > java.lang.ClassLoader#defineClass. > > > > Obviously, for this you need reflections - to load java.lang.ClassLoader, > > then to load the method itself, and most importantly, to make the method > > accessible cause it's `protected`. > > In JDK 9, this blows up as soon as you try to make the method accessible > > (invocation of setAccessible). > > > > Fair enough, but what is the "legitimate" alternative? > > I know I can --add-opens / --add-opens / --permit-illegal-access > > But all those just bypass the checks and don't really solve it. I am > > looking for an intended way to do such stuff. > > I am pretty sure there are many frameworks which need to do this in one way > > or the other. > > > > So far I have found workarounds which involve using `sun.misc.Unsafe` > > because there (for some reason) you are allowed to invoke setAccessible(). > > Is this the official intended backdoor? Because it sure does not look any > > safer/cleaner solution than the original one... > > > As Claes pointed out, look at Lookup.defineClass. It shouldn't be too > hard to imagine a future update of the CDI spec where there a select > variant that includes a Lookup to the target class with the @Inject > annotation. When using Weld outside of a container then I think there is > main code that obtains the WeldContainer and selects the types, that > might be a suitable place to extend to provide the Lookup to the library. > > MethodHandles.privateLookupIn might also be useful to know about, esp. > starting out when you don't want to make API changes and where the > user's code is on the class path or in open modules. > > -Alan > From doug.simon at oracle.com Thu Apr 20 07:49:10 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 09:49:10 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> Message-ID: > On 20 Apr 2017, at 00:31, Vladimir Kozlov wrote: > > Doug, > > Can you point (link) particular code which needs to be reviewed? And what security issues could be? I believe Chris had possible concerns with Services.initializeJVMCI() (at http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java.udiff.html). As previously stated, I can't see any security issues with this method which is why it doesn't check JVMCIPermission. -Doug > > Thanks, > Vladimir > > On 4/19/17 2:12 PM, Doug Simon wrote: >>> 3. Services.initializeJVMCI() > >>>> 3 is harmless from a security perspective in my opinion. >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> Vladimir, can you please bring this to the attention of the relevant engineer. >> From Alan.Bateman at oracle.com Thu Apr 20 08:52:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 09:52:04 +0100 Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> Message-ID: <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> On 20/04/2017 07:43, Matej Novotny wrote: > So I did some hacking and tried to make Weld use MethodHandles.Lookup and here is a bit of a feedback for you. > But first of all, thanks for your quick advice on how to approach this. Thank you for writing down your experiences. > > > So, how did Lookup work for us? > > 1) privateLookupIn + drop private mode > This was the way to go, as the bean classes can be anywhere (in classes not openly accessible to us, especially if we consider modules). > BTW I am not sure about the purpose of the private mode as you always need to drop it to be able to use lookup. This should work fine for existing bean classes as presumably they are in the class path or at least not in modules that are strongly encapsulated. In the future then if the bean classes are compiled and deployed as modules then the owner of the module will have to open the packages to at least the library that wants to reflect deeply. The reason you have to drop the PRIVATE mode is because it is expected to be used in the future. JDK-8171335 [1] and JEP 181 [2] provide some context as how this could evolve. > > 2) Lookup approach carries along the need to pass the reference to the base lookup class at all times. > This is kind of weird because in some (not-so-rare) cases, we need to create "artificial packages" in which we place proxy classes. For instance when we create a proxy for Interger, Map, Principal,... > Ofc we cannot place in into java.* packages, so we create our own. For this to work with Lookup, we need to have that package created ahead of time and have a reference to some "dummy" useless class inside to be able to do the lookup. > Or is there a way to define a whole new (open by default) package where we could place it using Lookup? Having the "dummy" package/class just to use Lookup is lame and very error prone (I can think of several ways to break the proxy creation even now). What is the defining loader of the proxy class that you spin for types such as java.lang.Integer? If it's your class loader implementation then you can invoke its defineClass method to define the class, your don't need a Lookup to an existing class for that scenario. If you are looking to define a class in a new runtime package and the class loader that is not your implementation then you are out of luck. Lookup is designed for doing computations in the context of an existing class. There is a note in the archives here from John Rose about extending the lookup API for cases like this but it would come with a lot of complexity. Also there isn't any notion of adding a package to a named module at this time. When java.lang.reflect.Proxy spins proxy classes then it doesn't add packages to named modules, it instead spins the proxy classes into its own module (something you could do too, assuming the classes that you are proxying are accessible). > > 3) All in all the changes carried along a lot of complexity compared to plain old ClassLoader.defineClass > We need to create A LOT of Lookups (might present performance overhead, haven't tested yet). > Extra care needs to be given to the packages for Lookup not to blow up while we in fact don't really care where the proxy lands as long as it is usable. Can you expand on the "don't really care" comment? Do you mean that you don't care about either the defining loader or runtime package? > > > Another nasty thing is that the code of course needs to work with both, JDK 9 and 8. > While it isn't impossible, it will add a not-so-nice reflection magic layer to the mix. > Multi-release JARs (JEP 238 [3]) and the ability to compile to older releases (JEP 247 [4]) might be useful here (you might know about these features already). -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8171335 [2] http://openjdk.java.net/jeps/181 [3] http://openjdk.java.net/jeps/238 [4] http://openjdk.java.net/jeps/247 From adinn at redhat.com Thu Apr 20 11:03:35 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Apr 2017 12:03:35 +0100 Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> Message-ID: On 20/04/17 09:52, Alan Bateman wrote: > On 20/04/2017 07:43, Matej Novotny wrote: >> Another nasty thing is that the code of course needs to work with >> both, JDK 9 and 8. >> While it isn't impossible, it will add a not-so-nice reflection magic >> layer to the mix. >> > Multi-release JARs (JEP 238 [3]) and the ability to compile to older > releases (JEP 247 [4]) might be useful here (you might know about these > features already). Alan is right to point to multi-release JARs as a useful way to solve this type of problem. However, I managed to bypass this issue in Byteman simply by hiding the affected code behind a facade (interface) and dynamically loading either a pre-jdk9 or jdk9+ implementation with all code bundled into the same jar. So, only one reflective operation was required (to instantiate the facade class). n.b. I realise that decoupling the rest of the code from the two alternative implementations is not necessarily going to be straightforward and might lead you to prefer the nulti-release jar approach. In my case the factoring this implied was not too difficult but it was actually a very useful exercise to go through. It forced me to clean up a slightly scrappy internal dependency with the *right* abstraction. If you are going to have to maintain jdk8 and jdk9 function for some time then I suspect Alan's route will probably also require you either to i) introduce some such clean abstraction or ii) go mad maintaining two slowly diverging sets of classes. So, you might still want to consider the approach I followed. Your mileage (or madness) may vary. regards, Andrew Dinn ----------- From david.lloyd at redhat.com Thu Apr 20 12:57:46 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 20 Apr 2017 07:57:46 -0500 Subject: How to actually ship JSR-250? Message-ID: Let's say I want to create a module distribution with my own JSR 250 classes. Let's also assume that I or the spec team want the module to be named java.annotations.common. How do I properly upgrade the JDK's java.xml.ws.annotation module such that java.xml.ws can see it, *and* I have my proper java.annotations.common module name? Am I forced to ship my annotations module as java.xml.ws.annotation? Or manually replace java.xml.ws with one that looks for my annotations (and where does that leave the original java.xml.ws.annotation module)? -- - DML From Alan.Bateman at oracle.com Thu Apr 20 13:18:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 14:18:25 +0100 Subject: How to actually ship JSR-250? In-Reply-To: References: Message-ID: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> On 20/04/2017 13:57, David M. Lloyd wrote: > Let's say I want to create a module distribution with my own JSR 250 > classes. Let's also assume that I or the spec team want the module to > be named java.annotations.common. > > How do I properly upgrade the JDK's java.xml.ws.annotation module such > that java.xml.ws can see it, *and* I have my proper > java.annotations.common module name? Am I forced to ship my > annotations module as java.xml.ws.annotation? Or manually replace > java.xml.ws with one that looks for my annotations (and where does > that leave the original java.xml.ws.annotation module)? > java.xml.ws.annotation is upgradable so all you need to do is deploy the compiled form of the following on the upgrade module path: module java.xml.ws.annotation { requires transitive java.annotations.common; } Separately, I don't know what name that JSR-250 will eventually choose. It could be indeed be "java.annotations.common", maybe "java.ee.annotation", maybe something else. -Alan From david.lloyd at redhat.com Thu Apr 20 13:21:27 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 20 Apr 2017 08:21:27 -0500 Subject: How to actually ship JSR-250? In-Reply-To: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> References: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> Message-ID: <25fd4016-c343-6142-b8b1-45d8bc88c7e9@redhat.com> On 04/20/2017 08:18 AM, Alan Bateman wrote: > On 20/04/2017 13:57, David M. Lloyd wrote: > >> Let's say I want to create a module distribution with my own JSR 250 >> classes. Let's also assume that I or the spec team want the module to >> be named java.annotations.common. >> >> How do I properly upgrade the JDK's java.xml.ws.annotation module such >> that java.xml.ws can see it, *and* I have my proper >> java.annotations.common module name? Am I forced to ship my >> annotations module as java.xml.ws.annotation? Or manually replace >> java.xml.ws with one that looks for my annotations (and where does >> that leave the original java.xml.ws.annotation module)? >> > java.xml.ws.annotation is upgradable so all you need to do is deploy the > compiled form of the following on the upgrade module path: > > module java.xml.ws.annotation { > requires transitive java.annotations.common; > } > > Separately, I don't know what name that JSR-250 will eventually choose. > It could be indeed be "java.annotations.common", maybe > "java.ee.annotation", maybe something else. I'm not too worried about that; it has to be decided by the time of Java EE 9 (obviously) but until then I just want to ensure that it is definitely possible to do this, as (unless I missed something) I don't believe that it was adequately covered in prior discussions. -- - DML From alan.bateman at oracle.com Thu Apr 20 15:57:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 15:57:48 +0000 Subject: hg: jigsaw/jake/hotspot: Dynamic loading of JMX or tool agent into modular application Message-ID: <201704201557.v3KFvmGH021587@aojmv0008.oracle.com> Changeset: d2c2e33197d2 Author: alanb Date: 2017-04-20 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d2c2e33197d2 Dynamic loading of JMX or tool agent into modular application ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp From alan.bateman at oracle.com Thu Apr 20 15:58:03 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 15:58:03 +0000 Subject: hg: jigsaw/jake/jdk: Dynamic loading of JMX or tool agent into modular application Message-ID: <201704201558.v3KFw3HL021714@aojmv0008.oracle.com> Changeset: ba4e9b37cd44 Author: alanb Date: 2017-04-20 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba4e9b37cd44 Dynamic loading of JMX or tool agent into modular application ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.instrument/share/classes/java/lang/instrument/package.html + test/com/sun/tools/attach/modules/Agent.java + test/com/sun/tools/attach/modules/Driver.java + test/com/sun/tools/attach/modules/m/module-info.java + test/com/sun/tools/attach/modules/m/p/Main.java From mandy.chung at oracle.com Thu Apr 20 16:01:15 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 20 Apr 2017 16:01:15 +0000 Subject: hg: jigsaw/jake/jdk: Add @spec JPMS to ThreadInfo::from Message-ID: <201704201601.v3KG1Fjn022656@aojmv0008.oracle.com> Changeset: 31ed261df102 Author: mchung Date: 2017-04-20 09:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31ed261df102 Add @spec JPMS to ThreadInfo::from ! src/java.management/share/classes/java/lang/management/ThreadInfo.java From stephen.felts at oracle.com Thu Apr 20 16:45:50 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 20 Apr 2017 09:45:50 -0700 (PDT) Subject: How to actually ship JSR-250? In-Reply-To: <25fd4016-c343-6142-b8b1-45d8bc88c7e9@redhat.com> References: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> <25fd4016-c343-6142-b8b1-45d8bc88c7e9@redhat.com> Message-ID: <35e9b225-3e6a-4cff-b9a5-ebc561a00d0d@default> First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define modules. It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as opposed to adopting the new module system. Since javax.annotation.* classes are now hidden in JDK 9, every project that uses these classes will need to ship a copy of these classes. For a project that is not adopting the module system, these classes will be on the classpath. They can just ship the RI jar file (currently glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 endorsed is no longer supported but no longer needed for these classes (that's the reason for hiding the classes). To provide the jax-ws annotations (they seem to live in glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the classpath, it just works. Both jar files need to be provided by project that uses these annotations and added to the classpath directly or indirectly via a manifest classpath. (As a side note, there are some API's that are not in the endorsed directory that will need to be additionally shipped for projects that use them.) For a project that is adopting the module system, the jar files need to be turned into modules with the correct names and the associated module-info.class in the root. Both modules need to be shipped and both jar files need to be in the module path or upgrade module path? If two projects run in the same JVM, one using the classpath and one using the module path, the module path wins? -----Original Message----- From: David M. Lloyd [mailto:david.lloyd at redhat.com] Sent: Thursday, April 20, 2017 9:21 AM To: Alan Bateman; jigsaw-dev Subject: Re: How to actually ship JSR-250? On 04/20/2017 08:18 AM, Alan Bateman wrote: > On 20/04/2017 13:57, David M. Lloyd wrote: > >> Let's say I want to create a module distribution with my own JSR 250 >> classes. Let's also assume that I or the spec team want the module >> to be named java.annotations.common. >> >> How do I properly upgrade the JDK's java.xml.ws.annotation module >> such that java.xml.ws can see it, *and* I have my proper >> java.annotations.common module name? Am I forced to ship my >> annotations module as java.xml.ws.annotation? Or manually replace >> java.xml.ws with one that looks for my annotations (and where does >> that leave the original java.xml.ws.annotation module)? >> > java.xml.ws.annotation is upgradable so all you need to do is deploy > the compiled form of the following on the upgrade module path: > > module java.xml.ws.annotation { > requires transitive java.annotations.common; } > > Separately, I don't know what name that JSR-250 will eventually choose. > It could be indeed be "java.annotations.common", maybe > "java.ee.annotation", maybe something else. I'm not too worried about that; it has to be decided by the time of Java EE 9 (obviously) but until then I just want to ensure that it is definitely possible to do this, as (unless I missed something) I don't believe that it was adequately covered in prior discussions. -- - DML From doug.simon at oracle.com Thu Apr 20 18:50:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 20:50:16 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: References: <816F9D53-B11D-48F0-B7BE-4A5E32AD92ED@oracle.com> <69BA05B6-C33A-4D97-A323-3E3216515A38@oracle.com> Message-ID: > On 19 Apr 2017, at 22:29, Vladimir Kozlov wrote: > > ReflectionAccessJDK ? Based on your comment in the file. > > Vladimir > > On 4/19/17 1:02 PM, Doug Simon wrote: >> Sure - how about good old Util? ;-) I'm open to other suggestions. >> >> Sent from my iPhone >> >>> On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov wrote: >>> >>> Hi Doug, >>> >>> Can you consider using other name and not JDK9 for new JVMCI class? It will be used in JDK 10 too: >>> >>> jdk.vm.ci.services.internal.JDK9; >>> >>> Thanks, >>> Vladimir >>> >>>> On 4/18/17 3:13 PM, Doug Simon wrote: >>>> Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. >>>> The primary requirement for this is to remove all usage of JDK internals from Graal. >>>> While this most involves changes in Graal, there remain a few capabilities that must >>>> be exposed via JVMCI. Namely: >>>> >>>> 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal initialize >>>> can use system properties that are guaranteed not to have been modified by application >>>> code (Graal initialization is lazy and may occur after application code has been run). >>>> >>>> 2. Truffle needs to be able to trigger JVMCI initialization so that it can select the Graal >>>> optimized implementation of the Truffle runtime. >>>> >>>> These capabilities have been added to jdk.vm.ci.services.Services. A comment has >>>> also been added to this class to denote the current methods to be removed >>>> in a subsequent bug to update the JDK copy of Graal with the upstream version which >>>> no longer uses the methods. The methods destined for removal are: >>>> >>>> exportJVMCITo(Class requestor) >>>> load(Class service) >>>> loadSingle(Class service, boolean required) >>>> >>>> The first one is no longer needed as JVMCI exports itself to Graal service providers >>>> it loads via private API and Graal re-exports[1] JVMCI to any module the extends Graal. >>>> The latter 2 are no longer required as Graal uses the standard ServiceLoader. This API >>>> is only useful for JVMCI-8 where a hidden JVMCI class loader is used. >>>> >>>> These changes have been tested against upstream Graal. To make the Graal tests pass, 2 extra >>>> minor changes were required: >>>> >>>> 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added and throws IllegalArgumentException >>>> on all error paths except one which throws AssertionError. The latter was a mistake and has been >>>> fixed to also throw IllegalArgumentException. >>>> 2. An invalid assertion has been removed from HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. >>>> Up to JDK 8, it was true that all classes in java.* packages were loaded by the boot class loader. >>>> This is no longer true in JDK 9 with classes like java.sql being loaded by platform class loader. >>>> >>>> As hinted above, a subsequent bug will be required to pull in the latest upstream Graal and >>>> remove use of JDK internal API from the jdk.aot module. The qualified exports to >>>> jdk.vm.internal.compiler and jdk.aot can then be removed. >>>> >>>> -Doug >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8177845 >>>> http://cr.openjdk.java.net/~dnsimon/8177845/ >>>> >>>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess >>>> >>>> >>>> >> From doug.simon at oracle.com Thu Apr 20 18:50:56 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Apr 2017 20:50:56 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> Message-ID: <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to the version compatible with the JVMCI API changes. In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these tests better isolates them from parts of the runtime they are not aiming to test. org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) ... 26 more -Doug > On 19 Apr 2017, at 23:26, Doug Simon wrote: > > I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: > > 1. JVMCIServiceLocator.getProvider(Class) is now protected > 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission > 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK > > -Doug > >> On 19 Apr 2017, at 23:12, Doug Simon wrote: >> >>> >>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>> >>>> >>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>> >>>>> >>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>> >>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>> >>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>> >>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>> >>>>> It's unqualified and no restriction in this change. >>>> >>>> The public methods currently in jdk.vm.ci.services are: >>>> >>>> 1. JVMCIServiceLocator.getProvider(Class) >>>> 2. JVMCIServiceLocator.getProviders(Class) >>>> 3. Services.initializeJVMCI() >>>> 4. Services.getSavedProperties() >>>> 5. Services.exportJVMCITo(Class) >>>> 6. Services.load(Class) >>>> 7. Services.loadSingle(Class, boolean) >>>> >>>> 1 should be made protected. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>> >>> Good. >>> >>>> >>>> 3 is harmless from a security perspective in my opinion. >>> >>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >> >> Vladimir, can you please bring this to the attention of the relevant engineer. >> >>>> >>>> 4 checks for JVMCIPermission. >>> >>> Ok. >>> >>>> >>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>> >>> About this, will this Graal update happen for JDK 9? >> >> Yes. >> >>> It?s awfully late in the cycle... >> >> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >> >> -Doug > From alan.bateman at oracle.com Thu Apr 20 19:36:44 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:44 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201704201936.v3KJajiQ014323@aojmv0008.oracle.com> Changeset: eea021f7411c Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/eea021f7411c Added tag jdk-9+166 for changeset b1f30c27367b ! .hgtags Changeset: 32200acaad50 Author: alanb Date: 2017-04-20 20:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/32200acaad50 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 20 19:36:46 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:46 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201704201936.v3KJakK5014447@aojmv0008.oracle.com> Changeset: 43de67f51801 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/43de67f51801 Added tag jdk-9+166 for changeset 934c18145915 ! .hgtags Changeset: d072e5afa03f Author: alanb Date: 2017-04-20 20:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d072e5afa03f Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 20 19:36:45 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:45 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201704201936.v3KJajTj014378@aojmv0008.oracle.com> Changeset: 37cdb2871070 Author: rriggs Date: 2017-04-12 10:53 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/37cdb2871070 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: alanb, bpb ! test/javax/xml/jaxp/libs/jdk/testlibrary/ProcessTools.java Changeset: 8d3febd5c9d8 Author: lana Date: 2017-04-13 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8d3febd5c9d8 Merge Changeset: c98480dd22e7 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c98480dd22e7 Added tag jdk-9+166 for changeset 8d3febd5c9d8 ! .hgtags Changeset: 241f86f89fe8 Author: alanb Date: 2017-04-20 20:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/241f86f89fe8 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 20 19:36:46 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:46 +0000 Subject: hg: jigsaw/jake: 7 new changesets Message-ID: <201704201936.v3KJakOI014432@aojmv0008.oracle.com> Changeset: 7d5d7ae50c72 Author: rriggs Date: 2017-04-11 14:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7d5d7ae50c72 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: alanb, bpb ! test/lib/jdk/test/lib/apps/LingeredApp.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 35fbd9906dfc Author: erikj Date: 2017-04-13 09:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/35fbd9906dfc 8177822: Move closed jib configuration for arm platforms to open Reviewed-by: tbell ! common/conf/jib-profiles.js Changeset: 9e093f2eaabc Author: erikj Date: 2017-04-13 09:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9e093f2eaabc 8176271: Still unable to build JDK 9 on some *7 sparcs Reviewed-by: ihse ! common/conf/jib-profiles.js Changeset: 455bd4cb2482 Author: lana Date: 2017-04-13 16:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/455bd4cb2482 Merge Changeset: ba5b16c9c6d8 Author: darcy Date: 2017-04-13 14:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ba5b16c9c6d8 8177553: Address removal lint warnings in the JDK build Reviewed-by: mchung, erikj ! make/common/SetupJavaCompilers.gmk Changeset: cf6ee4d4c839 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cf6ee4d4c839 Added tag jdk-9+166 for changeset ba5b16c9c6d8 ! .hgtags Changeset: 03d4146b2bd4 Author: alanb Date: 2017-04-20 20:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/03d4146b2bd4 Merge ! .hgtags ! common/conf/jib-profiles.js ! make/common/SetupJavaCompilers.gmk From alan.bateman at oracle.com Thu Apr 20 19:36:49 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:49 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201704201936.v3KJanpv014509@aojmv0008.oracle.com> Changeset: 85bf1d0aeb09 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/85bf1d0aeb09 Added tag jdk-9+166 for changeset 5b2e7b2101c0 ! .hgtags Changeset: e89bf7fa0a32 Author: alanb Date: 2017-04-20 20:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e89bf7fa0a32 Merge ! .hgtags From alan.bateman at oracle.com Thu Apr 20 19:36:49 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:49 +0000 Subject: hg: jigsaw/jake/langtools: 13 new changesets Message-ID: <201704201936.v3KJao3T014514@aojmv0008.oracle.com> Changeset: 151bc67acf92 Author: mcimadamore Date: 2017-04-11 14:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/151bc67acf92 8178414: T8177933.java fails even after fix for JDK-8178283 Summary: add T8177933.java to problem list Reviewed-by: jlahoda ! test/ProblemList.txt Changeset: 256d9fce6c53 Author: rfield Date: 2017-04-11 17:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/256d9fce6c53 8178023: jshell tool: crash with ugly message on attempt to add non-existant module path Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java ! test/jdk/jshell/DyingRemoteAgent.java ! test/jdk/jshell/HangingRemoteAgent.java ! test/jdk/jshell/HistoryTest.java ! test/jdk/jshell/JdiBadOptionLaunchExecutionControlTest.java ! test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java ! test/jdk/jshell/JdiBogusHostListenExecutionControlTest.java ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/ToolProviderTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/jdk/jshell/UITesting.java Changeset: 3e7eab1d1e96 Author: ksrini Date: 2017-04-12 11:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3e7eab1d1e96 8178067: support for @uses/@provides tags is broken Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/jdk/javadoc/doclet/lib/JavadocTester.java + test/jdk/javadoc/doclet/testModules/TestModuleServices.java ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/tools/lib/toolbox/ModuleBuilder.java Changeset: 688279815c27 Author: ksrini Date: 2017-04-12 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/688279815c27 8178686: Fix incorrect bug id in test. Reviewed-by: darcy ! test/jdk/javadoc/doclet/testModules/TestModuleServices.java Changeset: 42705de602d7 Author: lana Date: 2017-04-13 16:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/42705de602d7 Merge Changeset: b51c0ba6fd8f Author: rfield Date: 2017-04-13 14:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b51c0ba6fd8f 8178520: jshell tool: /help /save -- incorrect description of /save -start Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties Changeset: ad2910e96239 Author: jjg Date: 2017-04-14 15:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ad2910e96239 8178426: Extra } is coming in the javadoc of Taglet.toString() API Reviewed-by: ksrini, bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java Changeset: d2f92cb767a6 Author: bpatel Date: 2017-04-14 17:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d2f92cb767a6 8175823: doclet crashes when documenting a single class in a module. Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/jdk/javadoc/doclet/testModules/TestModules.java + test/jdk/javadoc/doclet/testModules/moduleNoExport/module-info.java + test/jdk/javadoc/doclet/testModules/moduleNoExport/testpkgmdlNoExport/TestClassInModuleNoExport.java Changeset: 8b68fb0d8159 Author: jjg Date: 2017-04-17 14:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8b68fb0d8159 8178509: MODULE_SOURCE_PATH: Implement missing methods 8178493: StandardJavaFileManager: Clarify/document the use of IllegalStateException Reviewed-by: jlahoda ! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/lib/toolbox/JavacTask.java Changeset: 229a32ad3b26 Author: jjg Date: 2017-04-17 15:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/229a32ad3b26 8176801: tools/javac/platform/PlatformProviderTest.java sensitive to warnings sent to stderr Reviewed-by: ksrini ! test/ProblemList.txt Changeset: 2a8b403a6233 Author: jjg Date: 2017-04-17 15:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2a8b403a6233 8161295: javac, cleanup use of ModuleTestBase Reviewed-by: ksrini ! test/tools/javac/modules/ModuleTestBase.java Changeset: 2bd173891dcf Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2bd173891dcf Added tag jdk-9+166 for changeset 2a8b403a6233 ! .hgtags Changeset: 94a50bfd5340 Author: alanb Date: 2017-04-20 20:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/94a50bfd5340 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/ProblemList.txt ! test/jdk/javadoc/doclet/testModules/TestModules.java ! test/jdk/jshell/HistoryTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/lib/toolbox/ModuleBuilder.java From alan.bateman at oracle.com Thu Apr 20 19:36:51 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:51 +0000 Subject: hg: jigsaw/jake/hotspot: 9 new changesets Message-ID: <201704201936.v3KJapj2014529@aojmv0008.oracle.com> Changeset: e8699be63872 Author: iveresov Date: 2017-04-11 11:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8699be63872 8176887: AOT: SIGSEGV in AOTCodeHeap::next when using specific configuration Summary: Derive MethodCounters from Metadata Reviewed-by: kvn, coleenp ! src/share/vm/oops/metadata.hpp ! src/share/vm/oops/methodCounters.cpp ! src/share/vm/oops/methodCounters.hpp Changeset: 66ec8add62cd Author: dholmes Date: 2017-04-11 19:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/66ec8add62cd 8135161: Missing commas in copyright notices Reviewed-by: sspitsyn ! src/cpu/s390/vm/c1_Runtime1_s390.cpp ! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp ! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp Changeset: 773e40f3fc21 Author: never Date: 2017-04-06 00:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/773e40f3fc21 8178119: [JVMCI] when rethrowing exceptions at deopt the exception must be fetched after materialization Reviewed-by: kvn ! src/share/vm/runtime/deoptimization.cpp Changeset: 00bf892e5553 Author: rriggs Date: 2017-04-12 11:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/00bf892e5553 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: hseigel ! test/runtime/libadimalloc.solaris.sparc/Testlibadimalloc.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/tmtools/jstack/DaemonThreadTest.java ! test/serviceability/tmtools/jstack/SpreadLockTest.java ! test/serviceability/tmtools/jstack/ThreadNamesTest.java ! test/serviceability/tmtools/jstack/TraveledLockTest.java ! test/serviceability/tmtools/jstack/WaitNotifyThreadTest.java ! test/serviceability/tmtools/jstat/GcCapacityTest.java ! test/serviceability/tmtools/jstat/GcCauseTest01.java ! test/serviceability/tmtools/jstat/GcCauseTest02.java ! test/serviceability/tmtools/jstat/GcCauseTest03.java ! test/serviceability/tmtools/jstat/GcNewTest.java ! test/serviceability/tmtools/jstat/GcTest01.java ! test/serviceability/tmtools/jstat/GcTest02.java Changeset: 4d6df9a75465 Author: dlong Date: 2017-04-12 16:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d6df9a75465 8158168: Missing bounds checks for some String intrinsics Reviewed-by: vlivanov, thartmann, sherman ! src/share/vm/opto/library_call.cpp + test/compiler/intrinsics/string/TestStringUTF16IntrinsicRangeChecks.java ! test/compiler/patches/java.base/java/lang/Helper.java Changeset: bbf855a44562 Author: lana Date: 2017-04-13 16:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bbf855a44562 Merge Changeset: 560d7aa083a2 Author: iignatyev Date: 2017-04-14 18:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/560d7aa083a2 8178731: compiler/ciReplay/SABase.java does not compile Reviewed-by: iignatyev, sspitsyn Contributed-by: ekaterina.pavlova at oracle.com ! test/compiler/ciReplay/SABase.java ! test/serviceability/sa/sadebugd/SADebugDTest.java Changeset: 443a768ec827 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/443a768ec827 Added tag jdk-9+166 for changeset 560d7aa083a2 ! .hgtags Changeset: c150239dda02 Author: alanb Date: 2017-04-20 20:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c150239dda02 Merge ! .hgtags ! src/share/vm/opto/library_call.cpp ! test/serviceability/attach/AttachSetGetFlag.java From alan.bateman at oracle.com Thu Apr 20 19:36:57 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 20 Apr 2017 19:36:57 +0000 Subject: hg: jigsaw/jake/jdk: 42 new changesets Message-ID: <201704201936.v3KJawVX014589@aojmv0008.oracle.com> Changeset: cd268728d178 Author: weijun Date: 2017-04-11 10:12 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd268728d178 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize Reviewed-by: rriggs, mullan ! src/java.base/share/classes/java/io/FilePermission.java ! test/java/io/FilePermission/Correctness.java Changeset: c35ff69c2852 Author: dfuchs Date: 2017-04-11 16:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c35ff69c2852 8178147: Race conditions in timeout handling code in http/2 incubator client Summary: Timeout handling code (in particular cancel(IOException)) is modified to take into account cancellation arising before exchange implementation is established or response completable future is created. TimeoutEvent::compareTo method is modified to be consistent with TimeoutEvent::equals. Reviewed-by: prappo, chegar, michaelm ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Exchange.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http1Exchange.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpClientImpl.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/MultiExchange.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainHttpConnection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Stream.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/TimeoutEvent.java ! test/ProblemList.txt + test/java/net/httpclient/SmallTimeout.java ! test/java/net/httpclient/TimeoutOrdering.java Changeset: 23255bc8606d Author: rriggs Date: 2017-04-11 14:18 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23255bc8606d 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/ProcessHandle.java ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! test/com/sun/jdi/ProcessAttachTest.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/ProcessBuilder/PipelineTest.java ! test/java/lang/ProcessBuilder/Zombies.java ! test/java/lang/ProcessHandle/Basic.java ! test/java/lang/ProcessHandle/JavaChild.java ! test/java/lang/ProcessHandle/OnExitTest.java ! test/java/lang/ProcessHandle/ProcessUtil.java ! test/java/lang/ProcessHandle/TreeTest.java ! test/java/lang/Runtime/exec/SleepyCat.java ! test/java/util/logging/LoggingDeadlock2.java ! test/lib/testlibrary/jdk/testlibrary/ProcessThread.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/tools/jps/LingeredApp.java ! test/sun/tools/jstat/JStatInterval.java Changeset: 0c8f43317c1f Author: ascarpino Date: 2017-04-12 12:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c8f43317c1f 8177784: Use CounterMode intrinsic for AES/GCM Reviewed-by: mullan, psandoz, chegar ! src/java.base/share/classes/com/sun/crypto/provider/CounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Changeset: ede22275fbfa Author: dlong Date: 2017-04-12 16:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ede22275fbfa 8158168: Missing bounds checks for some String intrinsics Reviewed-by: vlivanov, thartmann, sherman ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java Changeset: 2a15003cb4b7 Author: jwilhelm Date: 2017-04-13 15:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a15003cb4b7 8178447: Remove link from JavaDoc to Dev guide Reviewed-by: tschatzl, dholmes ! src/jdk.management/share/classes/com/sun/management/VMOption.java Changeset: 15cb1241abad Author: lana Date: 2017-04-13 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15cb1241abad Merge Changeset: f36e07712a1b Author: serb Date: 2017-03-21 01:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f36e07712a1b 8176544: Compilation error in plaf.metal.MetalBumps.Test6657026 Reviewed-by: prr ! test/javax/swing/plaf/metal/MetalBumps/Test6657026.java Changeset: 1158c3e5bd9c Author: prr Date: 2017-03-21 11:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1158c3e5bd9c Merge Changeset: 0f4994564ae6 Author: serb Date: 2017-03-23 17:50 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f4994564ae6 6574989: TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes Reviewed-by: prr ! test/javax/sound/sampled/Clip/bug5070081.java Changeset: e352eacd7a94 Author: prr Date: 2017-03-24 09:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e352eacd7a94 Merge - src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java Changeset: 908bdcadfab5 Author: stuefe Date: 2017-03-25 18:57 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/908bdcadfab5 8177137: 8175293 breaks Windows build on Vs2010 Reviewed-by: serb, alexsch ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp Changeset: bbf040535813 Author: ddehaven Date: 2017-03-27 12:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bbf040535813 Merge Changeset: b3a70b0fd710 Author: prr Date: 2017-03-28 09:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b3a70b0fd710 8043773: Deprecate JComponent.AccessibleJComponent.AccessibleFocusHandler Reviewed-by: alexsch, azvegint ! src/java.desktop/share/classes/javax/swing/JComponent.java Changeset: 5ca3a286b761 Author: serb Date: 2017-03-29 17:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5ca3a286b761 8177766: [TEST_BUG] JPopupMenu tests fails intermittently Reviewed-by: alexsch, yan ! test/javax/swing/JPopupMenu/4458079/bug4458079.java ! test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cdb6fd420176 Author: dmarkov Date: 2017-03-29 19:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cdb6fd420176 8176490: [macosx] Sometimes NSWindow.isZoomed hangs Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Window/WindowDeadlockTest/WindowDeadlockTest.java Changeset: 87801ca8520c Author: alexsch Date: 2017-03-29 21:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87801ca8520c 8177625: apple.laf.JRSUIConstants.getConstantName(int) checks for THUMB_START twice Reviewed-by: prr, serb, azvegint ! src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java Changeset: 19042d75c724 Author: serb Date: 2017-03-30 16:40 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19042d75c724 8177461: Wrong references are used in the javadoc in the java.desktop module Reviewed-by: alexsch ! src/java.desktop/macosx/classes/com/apple/eawt/Application.java ! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationAdapter.java ! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationListener.java ! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenAdapter.java ! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenListener.java ! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenUtilities.java ! src/java.desktop/macosx/classes/com/apple/eawt/MacQuitResponse.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureAdapter.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/MagnificationListener.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/RotationListener.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/SwipeListener.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java ! src/java.desktop/share/classes/com/sun/awt/AWTUtilities.java ! src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SingleTileRenderedImage.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFBaseJPEGCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriter.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKGraphicsUtils.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifGraphicsUtils.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/AudioSynthesizer.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/Toolkit.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Desktop.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/MenuBar.java ! src/java.desktop/share/classes/java/awt/PaintContext.java ! src/java.desktop/share/classes/java/awt/SystemTray.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/desktop/FilesEvent.java ! src/java.desktop/share/classes/java/awt/font/CharArrayIterator.java ! src/java.desktop/share/classes/java/awt/peer/DesktopPeer.java ! src/java.desktop/share/classes/java/awt/print/PrinterJob.java ! src/java.desktop/share/classes/java/beans/ChangeListenerMap.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/java.desktop/share/classes/javax/swing/Action.java ! src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/LazyActionMap.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/GlyphPainter1.java ! src/java.desktop/share/classes/javax/swing/text/GlyphPainter2.java ! src/java.desktop/share/classes/javax/swing/text/ParagraphView.java ! src/java.desktop/share/classes/javax/swing/text/PlainView.java ! src/java.desktop/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/java.desktop/share/classes/javax/swing/text/Utilities.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/FormView.java ! src/java.desktop/share/classes/javax/swing/text/html/FrameView.java ! src/java.desktop/share/classes/javax/swing/text/html/NoFramesView.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFParser.java ! src/java.desktop/share/classes/sun/awt/image/BytePackedRaster.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java Changeset: 41703cb17ee1 Author: serb Date: 2017-03-31 18:23 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/41703cb17ee1 8177560: @headful key can be removed from the tests for JavaSound Reviewed-by: prr ! test/javax/sound/midi/Devices/InitializationHang.java ! test/javax/sound/midi/Sequencer/SeqRecordDoesNotCopy.java ! test/javax/sound/midi/Sequencer/SeqRecordsRealTimeEvents.java ! test/javax/sound/midi/Sequencer/SeqStartRecording.java ! test/javax/sound/midi/Synthesizer/bug4685396.java ! test/javax/sound/sampled/Clip/ClipCloseLoss.java ! test/javax/sound/sampled/Clip/bug5070081.java ! test/javax/sound/sampled/DataLine/LongFramePosition.java ! test/javax/sound/sampled/DirectAudio/bug6372428.java Changeset: e0f119ab7b1c Author: alitvinov Date: 2017-03-31 19:42 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e0f119ab7b1c 8167102: [macosx] PrintRequestAttributeSet breaks page size set using PageFormat Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PageFormat/WrongPaperPrintingTest.java Changeset: 9ccf8c6e7d7e Author: serb Date: 2017-04-05 20:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ccf8c6e7d7e 8177672: DataFlavor.imageFlavor is null when the java.desktop module is not resolved Reviewed-by: prr, mchung, alanb ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 204b01546b68 Author: rsingh Date: 2017-04-10 16:20 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/204b01546b68 8177386: [TESTBUG] The "Undo" menu item in the context menu is disable Reviewed-by: serb, aghaisas Contributed-by: rahul.d.singh at oracle.com ! test/java/awt/TextField/DisabledUndoTest/DisabledUndoTest.java Changeset: f19cf7eaf0e3 Author: ssadetsky Date: 2017-04-10 08:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f19cf7eaf0e3 8164469: [TEST_BUG] Unity, java/awt/MouseInfo/JContainerMousePositionTest.java Reviewed-by: yan, serb ! test/java/awt/MouseInfo/JContainerMousePositionTest.java Changeset: da335cb02480 Author: prr Date: 2017-04-10 08:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/da335cb02480 Merge - src/java.base/share/classes/java/lang/reflect/Layer.java - src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java - src/java.base/share/classes/java/lang/reflect/Module.java - src/java.base/share/classes/java/lang/reflect/WeakPairMap.java - src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFBaseJPEGCompressor.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/javax/swing/text/PlainView.java - test/java/lang/reflect/Layer/BasicLayerTest.java - test/java/lang/reflect/Layer/LayerAndLoadersTest.java - test/java/lang/reflect/Layer/LayerControllerTest.java - test/java/lang/reflect/Layer/layertest/Test.java - test/java/lang/reflect/Layer/src/m1/module-info.java - test/java/lang/reflect/Layer/src/m1/p/Main.java - test/java/lang/reflect/Layer/src/m1/p/Service.java - test/java/lang/reflect/Layer/src/m2/module-info.java - test/java/lang/reflect/Layer/src/m2/q/Hello.java - test/java/lang/reflect/Layer/src/m3/module-info.java - test/java/lang/reflect/Layer/src/m3/w/Hello.java - test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java - test/java/lang/reflect/Layer/src/m4/module-info.java - test/java/lang/reflect/Module/AddExportsTest.java - test/java/lang/reflect/Module/AnnotationsTest.java - test/java/lang/reflect/Module/BasicModuleTest.java - test/java/lang/reflect/Module/WithSecurityManager.java - test/java/lang/reflect/Module/access/AccessTest.java - test/java/lang/reflect/Module/access/src/target/module-info.java - test/java/lang/reflect/Module/access/src/target/p1/Helper.java - test/java/lang/reflect/Module/access/src/target/p1/Public.java - test/java/lang/reflect/Module/access/src/target/p2/NonPublic.java - test/java/lang/reflect/Module/access/src/target/q1/Public.java - test/java/lang/reflect/Module/access/src/target/q2/NonPublic.java - test/java/lang/reflect/Module/access/src/test/module-info.java - test/java/lang/reflect/Module/access/src/test/test/Main.java - test/java/lang/reflect/Module/addXXX/Driver.java - test/java/lang/reflect/Module/addXXX/m1/module-info.java - test/java/lang/reflect/Module/addXXX/m1/p1/C.java - test/java/lang/reflect/Module/addXXX/m2/module-info.java - test/java/lang/reflect/Module/addXXX/m2/p2/C.java - test/java/lang/reflect/Module/addXXX/m2/p2/internal/C.java - test/java/lang/reflect/Module/addXXX/m3/module-info.java - test/java/lang/reflect/Module/addXXX/m3/p3/C.java - test/java/lang/reflect/Module/addXXX/m4/module-info.java - test/java/lang/reflect/Module/addXXX/m4/p4/C.java - test/java/lang/reflect/Module/addXXX/test/module-info.java - test/java/lang/reflect/Module/addXXX/test/test/C.java - test/java/lang/reflect/Module/addXXX/test/test/Main.java - test/java/lang/reflect/Module/addXXX/test/test/Service.java - test/java/lang/reflect/Module/allow.policy - test/java/lang/reflect/Module/annotation/Basic.java - test/java/lang/reflect/Module/annotation/src/m/module-info.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Bar.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Baz.java - test/java/lang/reflect/Module/annotation/src/m/p/annotation/Foo.java - test/java/lang/reflect/WeakPairMap/Driver.java - test/java/lang/reflect/WeakPairMap/java.base/java/lang/reflect/WeakPairMapTest.java Changeset: c69e8ca0008e Author: prr Date: 2017-04-10 09:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c69e8ca0008e Merge Changeset: 79e099ab284b Author: mcherkas Date: 2017-04-11 00:05 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79e099ab284b 8177450: javax.swing.text.html.parser.Parser parseScript ignores a character after commend end Reviewed-by: prr, alexsch ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/HtmlCommentTagParseTest/HtmlCommentTagParseTest.java + test/javax/swing/text/html/parser/Parser/HtmlCommentTagParseTest/test.html Changeset: b289db56c862 Author: prr Date: 2017-04-13 10:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b289db56c862 Merge Changeset: 413e8af4fc3c Author: darcy Date: 2017-04-13 10:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/413e8af4fc3c 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool Reviewed-by: weijun ! src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisLoginModule.java Changeset: 5bfdd4e83008 Author: darcy Date: 2017-04-13 11:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5bfdd4e83008 8177684: Suppress lint removal warnings in AppletSecurity Reviewed-by: mchung, mullan ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java Changeset: 2c28af3a1e5d Author: darcy Date: 2017-04-13 11:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c28af3a1e5d 8177682: Suppress removal warning for System.runFinalizersOnExit Reviewed-by: mchung, smarks ! src/java.base/share/classes/java/lang/System.java Changeset: 2b4bacfcbe17 Author: darcy Date: 2017-04-13 11:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2b4bacfcbe17 8177723: Suppress lint removal warning in java.se.ee and jdk.unsupported Reviewed-by: lancea, chegar ! src/java.se.ee/share/classes/module-info.java ! src/jdk.unsupported/share/classes/sun/reflect/Reflection.java Changeset: 5f24e5bf62bd Author: amlu Date: 2017-04-14 15:30 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f24e5bf62bd 8169971: JLinkMultiReleaseJarTest.java fails intermittently at the final clean up Reviewed-by: chegar, psandoz ! test/ProblemList.txt ! test/tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java Changeset: fc53a0468c1f Author: tidu Date: 2017-04-14 00:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc53a0468c1f 8178083: Remove intermittent key from java/security/SignedObject/Chain.java Reviewed-by: xuelei Contributed-by: Tim Du ! test/java/security/SignedObject/Chain.java Changeset: 389b078873a0 Author: chegar Date: 2017-04-14 10:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/389b078873a0 8177536: Avoid Apple Peer-to-Peer interfaces in networking tests Reviewed-by: michaelm, rriggs ! test/java/net/Inet6Address/B6206527.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/B6427403.java - test/java/net/MulticastSocket/JoinGroup.java + test/java/net/MulticastSocket/JoinLeave.java - test/java/net/MulticastSocket/Leave.java + test/java/net/NetworkConfigurationProbe.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/SocketPermission/SocketPermissionTest.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/Tests.java + test/lib/testlibrary/jdk/testlibrary/NetworkConfiguration.java ! test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 2a96f24cea2e Author: mli Date: 2017-04-14 04:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a96f24cea2e 8145163: Test Task for Platform Logging API and Service -- for moduralization Reviewed-by: dfuchs + test/java/lang/System/LoggerFinder/modules/Base.java + test/java/lang/System/LoggerFinder/modules/JDKLoggerForImageTest.java + test/java/lang/System/LoggerFinder/modules/JDKLoggerForJDKTest.java + test/java/lang/System/LoggerFinder/modules/LoggerInImageTest.java + test/java/lang/System/LoggerFinder/modules/NamedLoggerForImageTest.java + test/java/lang/System/LoggerFinder/modules/NamedLoggerForJDKTest.java + test/java/lang/System/LoggerFinder/modules/UnnamedLoggerForImageTest.java + test/java/lang/System/LoggerFinder/modules/UnnamedLoggerForJDKTest.java + test/java/lang/System/LoggerFinder/modules/boot_client/BootClient.java + test/java/lang/System/LoggerFinder/modules/boot_usage/BootUsage.java + test/java/lang/System/LoggerFinder/modules/named_client/m.t.a/module-info.java + test/java/lang/System/LoggerFinder/modules/named_client/m.t.a/pkg/a/t/TestA.java + test/java/lang/System/LoggerFinder/modules/named_logger/m.l.a/module-info.java + test/java/lang/System/LoggerFinder/modules/named_logger/m.l.a/pkg/a/l/LoggerA.java + test/java/lang/System/LoggerFinder/modules/named_logger/m.l.a/pkg/a/p/LoggerFinderA.java + test/java/lang/System/LoggerFinder/modules/patched_client/PatchedClient.java + test/java/lang/System/LoggerFinder/modules/patched_usage/java.base/java/lang/PatchedUsage.java + test/java/lang/System/LoggerFinder/modules/unnamed_client/pkg/b/t/TestB.java + test/java/lang/System/LoggerFinder/modules/unnamed_logger/META-INF/services/java.lang.System$LoggerFinder + test/java/lang/System/LoggerFinder/modules/unnamed_logger/pkg/b/l/LoggerB.java + test/java/lang/System/LoggerFinder/modules/unnamed_logger/pkg/b/p/LoggerFinderB.java Changeset: d7add8d9ab22 Author: weijun Date: 2017-04-15 00:58 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7add8d9ab22 8178795: krb5 Basic.java test should be basic Reviewed-by: xuelei ! test/sun/security/krb5/auto/Basic.java + test/sun/security/krb5/auto/ModuleName.java Changeset: d1c491ec39d2 Author: bpb Date: 2017-04-14 14:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1c491ec39d2 8178783: Java_sun_nio_ch_EPoll_close0 definition, but no sun.nio.ch.EPoll.close0 declaration. Summary: Delete unused method. Reviewed-by: rriggs, chegar ! src/java.base/linux/native/libnio/ch/EPoll.c Changeset: 9ba6760481a8 Author: lancea Date: 2017-04-15 16:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ba6760481a8 8164390: Add module javadoc to jdk.internal.jvmstat Reviewed-by: alanb, mchung ! src/jdk.internal.jvmstat/share/classes/module-info.java Changeset: d57893482534 Author: mli Date: 2017-04-17 01:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d57893482534 8178840: Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList Summary: Adds FieldSetAccessibleTest.java and VerifyJimage.java to ProblemList due to JDK-8178776 Reviewed-by: alanb Contributed-by: John Jiang ! test/ProblemList.txt Changeset: 5d2b48f1f0a3 Author: naoto Date: 2017-04-17 14:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d2b48f1f0a3 8177314: java VM fails to start with a Japanese ShiftJIS locale Reviewed-by: sherman, mchung ! make/data/charsetmapping/stdcs-linux Changeset: b4a7d4678a43 Author: lana Date: 2017-04-20 18:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b4a7d4678a43 Added tag jdk-9+166 for changeset 5d2b48f1f0a3 ! .hgtags Changeset: 6ce8dcdabfc9 Author: alanb Date: 2017-04-20 20:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ce8dcdabfc9 Merge ! .hgtags ! src/java.base/share/classes/java/lang/System.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java ! src/java.se.ee/share/classes/module-info.java ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/jdk.internal.jvmstat/share/classes/module-info.java ! src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/ProblemList.txt ! test/com/sun/tools/attach/AttachSelf.java ! test/com/sun/tools/attach/modules/m/p/Main.java ! test/java/io/FilePermission/Correctness.java ! test/java/lang/ProcessBuilder/Basic.java - test/java/net/MulticastSocket/JoinGroup.java - test/java/net/MulticastSocket/Leave.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java From david.lloyd at redhat.com Thu Apr 20 22:48:58 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 20 Apr 2017 17:48:58 -0500 Subject: How to actually ship JSR-250? In-Reply-To: <35e9b225-3e6a-4cff-b9a5-ebc561a00d0d@default> References: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> <25fd4016-c343-6142-b8b1-45d8bc88c7e9@redhat.com> <35e9b225-3e6a-4cff-b9a5-ebc561a00d0d@default> Message-ID: To address the first point only... I think if Java EE 8 required Java SE 9, that would be surprising news for all. For the last few Java EE releases at least, each Java EE release has required the Java SE version of the same number. And there has been plenty of talk over the past couple years that seems to indicate that this will continue to 9. Thus I have no expectation that Java EE 8 will do anything special for Java SE 9. However, we definitely want our implementation to run on Java SE 9. My understanding was that you cannot replace classes in upgradeable modules via the class path, but if that's wrong then I suppose it's time to do another round of experiments. On 04/20/2017 11:45 AM, Stephen Felts wrote: > First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define modules. > It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as opposed to adopting the new module system. > > Since javax.annotation.* classes are now hidden in JDK 9, every project that uses these classes will need to ship a copy of these classes. > > For a project that is not adopting the module system, these classes will be on the classpath. They can just ship the RI jar file (currently glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 endorsed is no longer supported but no longer needed for these classes (that's the reason for hiding the classes). > To provide the jax-ws annotations (they seem to live in glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the classpath, it just works. > Both jar files need to be provided by project that uses these annotations and added to the classpath directly or indirectly via a manifest classpath. > (As a side note, there are some API's that are not in the endorsed directory that will need to be additionally shipped for projects that use them.) > > For a project that is adopting the module system, the jar files need to be turned into modules with the correct names and the associated module-info.class in the root. > Both modules need to be shipped and both jar files need to be in the module path or upgrade module path? > > If two projects run in the same JVM, one using the classpath and one using the module path, the module path wins? > > > > > -----Original Message----- > From: David M. Lloyd [mailto:david.lloyd at redhat.com] > Sent: Thursday, April 20, 2017 9:21 AM > To: Alan Bateman; jigsaw-dev > Subject: Re: How to actually ship JSR-250? > > On 04/20/2017 08:18 AM, Alan Bateman wrote: >> On 20/04/2017 13:57, David M. Lloyd wrote: >> >>> Let's say I want to create a module distribution with my own JSR 250 >>> classes. Let's also assume that I or the spec team want the module >>> to be named java.annotations.common. >>> >>> How do I properly upgrade the JDK's java.xml.ws.annotation module >>> such that java.xml.ws can see it, *and* I have my proper >>> java.annotations.common module name? Am I forced to ship my >>> annotations module as java.xml.ws.annotation? Or manually replace >>> java.xml.ws with one that looks for my annotations (and where does >>> that leave the original java.xml.ws.annotation module)? >>> >> java.xml.ws.annotation is upgradable so all you need to do is deploy >> the compiled form of the following on the upgrade module path: >> >> module java.xml.ws.annotation { >> requires transitive java.annotations.common; } >> >> Separately, I don't know what name that JSR-250 will eventually choose. >> It could be indeed be "java.annotations.common", maybe >> "java.ee.annotation", maybe something else. > > I'm not too worried about that; it has to be decided by the time of Java EE 9 (obviously) but until then I just want to ensure that it is definitely possible to do this, as (unless I missed something) I don't believe that it was adequately covered in prior discussions. > > -- > - DML > -- - DML From andrey.x.nazarov at oracle.com Fri Apr 21 00:12:13 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Thu, 20 Apr 2017 17:12:13 -0700 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: <70769D9A-C2E0-4ACC-9C7E-CDF62E5434EA@oracle.com> References: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> <70769D9A-C2E0-4ACC-9C7E-CDF62E5434EA@oracle.com> Message-ID: <52EAB1D4-1CA2-433C-8FCB-371C21D28E17@oracle.com> HI Mandy, I?ve update patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ I?ve removed some tests since you pushed them with fix for https://bugs.openjdk.java.net/browse/JDK-8178404 ?Andrey > On 11 Apr 2017, at 12:46, Andrey Nazarov wrote: > > Hi Mandy, > > Here is updated patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.02/webrev/ > > ? Thanks, > Andrey >> On 10 Apr 2017, at 23:50, Mandy Chung wrote: >> >> >>> On Apr 10, 2017, at 12:30 PM, Andrey Nazarov > wrote: >>> >>> Mandy, thanks for review. I?ve updated patch >>> http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ >>> >> >> I suggest to add m4/p4.S to make it clear it?s a service type and m4 provides p4.S with p4.Impl. >> noOneUsesProvider will call ?suggest-providers p4.S instead. >> >> 239 static JLink run(boolean expectSuccess, String... options) { >> Instead of adding a new parameter, what about adding a new runWithNonZeroExitCode method? >> >>> See my comments inline >>>> >>>> >>>> line 159-161: formatting nit: can you add spaces to align with the first >>>> argument in line 158. Same comment to SuggestProviders.java line 180-182 >>>> an 198-200. >>> Fixed >> >> line 216-219. >> >>> Actually there are two issues here: >>> https://bugs.openjdk.java.net/browse/JDK-8178404 >>> https://bugs.openjdk.java.net/browse/JDK-8178405 >> Not really a bug but it?d be helpful to show that the provider exists but the service is not used in this case. >> Mandy >> > From mandy.chung at oracle.com Fri Apr 21 00:46:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 17:46:01 -0700 Subject: RFR 8178323: Add negative tests for bind services Jlink feature In-Reply-To: <52EAB1D4-1CA2-433C-8FCB-371C21D28E17@oracle.com> References: <3996389A-5567-4D52-866E-C97637BDFDE8@oracle.com> <237DD867-EF3C-46DC-93E7-789D3CBA7AB1@oracle.com> <70769D9A-C2E0-4ACC-9C7E-CDF62E5434EA@oracle.com> <52EAB1D4-1CA2-433C-8FCB-371C21D28E17@oracle.com> Message-ID: > On Apr 20, 2017, at 5:12 PM, Andrey Nazarov wrote: > > HI Mandy, > > I?ve update patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ Nit: use 4-space indent e.g. BindServices.java. line 159 (the following lines will move along) and SuggestProviders.java line 255-258, 262, 273-276, and 280. Otherwise looks good. You can fix the formatting before push. Thanks Mandy From stephen.felts at oracle.com Fri Apr 21 00:50:57 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 20 Apr 2017 17:50:57 -0700 (PDT) Subject: How to actually ship JSR-250? In-Reply-To: References: <82fa3d5f-ed4b-16dc-59fd-9190f9158025@oracle.com> <25fd4016-c343-6142-b8b1-45d8bc88c7e9@redhat.com> <35e9b225-3e6a-4cff-b9a5-ebc561a00d0d@default> Message-ID: Yes, you are correct that Java EE 8 won't require Java SE 9. This will be the first time that two versions of Java SE ship before the next Java EE. There are a bunch of JDK 9 bugs against the RI but they are generally for internal API's. However, the RI won't be able to run on JDK9 until the API class problem is resolved, even if for the short term. Some of the classes are in the endorsed directory and some of the classes don't exist in the RI (e.g., javax.activation). The quick fix is to require the JDK9 option to make the EE classes in the SE visible. -----Original Message----- From: David M. Lloyd [mailto:david.lloyd at redhat.com] Sent: Thursday, April 20, 2017 6:49 PM To: Stephen Felts; Alan Bateman; jigsaw-dev Subject: Re: How to actually ship JSR-250? To address the first point only... I think if Java EE 8 required Java SE 9, that would be surprising news for all. For the last few Java EE releases at least, each Java EE release has required the Java SE version of the same number. And there has been plenty of talk over the past couple years that seems to indicate that this will continue to 9. Thus I have no expectation that Java EE 8 will do anything special for Java SE 9. However, we definitely want our implementation to run on Java SE 9. My understanding was that you cannot replace classes in upgradeable modules via the class path, but if that's wrong then I suppose it's time to do another round of experiments. On 04/20/2017 11:45 AM, Stephen Felts wrote: > First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define modules. > It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as opposed to adopting the new module system. > > Since javax.annotation.* classes are now hidden in JDK 9, every project that uses these classes will need to ship a copy of these classes. > > For a project that is not adopting the module system, these classes will be on the classpath. They can just ship the RI jar file (currently glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 endorsed is no longer supported but no longer needed for these classes (that's the reason for hiding the classes). > To provide the jax-ws annotations (they seem to live in glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the classpath, it just works. > Both jar files need to be provided by project that uses these annotations and added to the classpath directly or indirectly via a manifest classpath. > (As a side note, there are some API's that are not in the endorsed > directory that will need to be additionally shipped for projects that > use them.) > > For a project that is adopting the module system, the jar files need to be turned into modules with the correct names and the associated module-info.class in the root. > Both modules need to be shipped and both jar files need to be in the module path or upgrade module path? > > If two projects run in the same JVM, one using the classpath and one using the module path, the module path wins? > > > > > -----Original Message----- > From: David M. Lloyd [mailto:david.lloyd at redhat.com] > Sent: Thursday, April 20, 2017 9:21 AM > To: Alan Bateman; jigsaw-dev > Subject: Re: How to actually ship JSR-250? > > On 04/20/2017 08:18 AM, Alan Bateman wrote: >> On 20/04/2017 13:57, David M. Lloyd wrote: >> >>> Let's say I want to create a module distribution with my own JSR 250 >>> classes. Let's also assume that I or the spec team want the module >>> to be named java.annotations.common. >>> >>> How do I properly upgrade the JDK's java.xml.ws.annotation module >>> such that java.xml.ws can see it, *and* I have my proper >>> java.annotations.common module name? Am I forced to ship my >>> annotations module as java.xml.ws.annotation? Or manually replace >>> java.xml.ws with one that looks for my annotations (and where does >>> that leave the original java.xml.ws.annotation module)? >>> >> java.xml.ws.annotation is upgradable so all you need to do is deploy >> the compiled form of the following on the upgrade module path: >> >> module java.xml.ws.annotation { >> requires transitive java.annotations.common; } >> >> Separately, I don't know what name that JSR-250 will eventually choose. >> It could be indeed be "java.annotations.common", maybe >> "java.ee.annotation", maybe something else. > > I'm not too worried about that; it has to be decided by the time of Java EE 9 (obviously) but until then I just want to ensure that it is definitely possible to do this, as (unless I missed something) I don't believe that it was adequately covered in prior discussions. > > -- > - DML > -- - DML From adinn at redhat.com Fri Apr 21 10:04:04 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 21 Apr 2017 11:04:04 +0100 Subject: Using lookups in place of reflection Message-ID: <54df89bb-b3de-34af-3993-73c723d8eb6b@redhat.com> Being a good OpenJDK citizen I have attempted to make my agent use lookups in jdk9 in place of using reflection. This is mostly working fine. However, I have run across a rather arbitrary limitation (not just my conclusion -- the jdk source code acknowledges it as such) and am wondering whether there will be any chance of remedying it before (or after) jdk9 release. The problem (I'll come to the motivation as to /why/ it is a problem in a second) is this method of class java.lang.invoke.MethodHandles.Lookup private static void checkUnprivilegedlookupClass(Class lookupClass, int allowedModes) { String name = lookupClass.getName(); if (name.startsWith("java.lang.invoke.")) throw newIllegalArgumentException("illegal lookupClass: "+lookupClass); // For caller-sensitive MethodHandles.lookup() disallow lookup from // restricted packages. This a fragile and blunt approach. // TODO replace with a more formal and less fragile mechanism // that does not bluntly restrict classes under packages within // java.base from looking up MethodHandles or VarHandles. if (allowedModes == FULL_POWER_MODES && lookupClass.getClassLoader() == null) { if ((name.startsWith("java.") && !name.equals("java.lang.Thread") && !name.startsWith("java.util.concurrent.")) || (name.startsWith("sun.") && !name.startsWith("sun.invoke."))) { throw newIllegalArgumentException("illegal lookupClass: " + lookupClass); } } } This is indeed a 'blunt approach' -- I'm not sure about the fragility and it would be good to know what motivated this specific choice of blunt instrument and what might constitute a more honed instrument. What makes this so egregious is that this check method is invoked from method Lookup.privateLookupIn() which, before instituting the check, ensures, amongst other things, that the target class is open to the module of the Lookup's 'caller' class. What that adds up to is this: the the original Lookup cannot be used to access protected or private fields or methods of java.* or sun.* classes using a method handle reflection /can/ be used to access those same fields or methods That seems like a rather perverse incentive to stick with reflection. Now, why am I so concerned about this detail? Well, as an example, here is a snippet of a Byteman rule used to test HttpURLConnection code: RULE java-net: Java HttpUrlConnection connect entry CLASS ^java.net.HttpURLConnection METHOD connect() HELPER io.opentracing.contrib.agent.OpenTracingHelper AT ENTRY IF !$0.connected && retrieveSpan($0) == null && !ignore($0) DO associateSpan($0, getTracer().buildSpan($0.getRequestMethod()); ... ENDRULE I won't provide a full account of what this rule does but basically it defines code for the agent to inject into the connect() method of java.net.HttpURLConnection and its subclasses (the latter indicated by the ^). The purpose is to track the connection state so operation can be validated at end of the test run. HELPER class OpenTracingHelper is just a POJO that defines methods retrieveSpan(), ignore(), buildSpan() etc which construct and maintain this tracking info n.b. there are several more rules, defined on other methods of HttpURLConnection, which update the Span object. A few more specifics are called for. $0 identifies the target instance for the connect() call i.e. an instance of HttpURLConnection or one of its subclasses. In practice the rule code actually gets injected in method connect() of the underlying implementation class sun.net.www.protocol.http.HttpURLConnection so at runtime that will be the type of $0. The critical expression to attend to is the first term in the IF condition '$0.connected'. This reads boolean field 'connected' defined by superclass java.net.URLConnection of class HttpURLConnection. A test of this field is needed because it is only appropriate to track connection information for a URLConnection which has actually been connected. Unfortunately, field 'connected' is protected. Worse, none of the classes in the URLConnection hierarchy provide an accessor for it. So, the only way to implement this test/rule is to strong-arm a read of the protected field. The Byteman agent has to apply one or other form of leverage -- either reflection or a getter method handle. In jdk8 it successfully reads the field using reflection. In jdk9 it tries to behave well and use a getter but that is ruled out by the rather arbitrary check above. Other rules run into problems with fields/methods of the target class java.net.HttpURLConnection. So, what am I asking: Is there a clearer rationale for this check which might lead to a less restrictive variant? Can I haz it in jdk9 pleeze? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri Apr 21 10:57:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Apr 2017 11:57:32 +0100 Subject: Using lookups in place of reflection In-Reply-To: <54df89bb-b3de-34af-3993-73c723d8eb6b@redhat.com> References: <54df89bb-b3de-34af-3993-73c723d8eb6b@redhat.com> Message-ID: <3abba0da-ea3f-d7d8-03f0-64b809421c44@oracle.com> On 21/04/2017 11:04, Andrew Dinn wrote: > Being a good OpenJDK citizen I have attempted to make my agent use > lookups in jdk9 in place of using reflection. This is mostly working > fine. However, I have run across a rather arbitrary limitation (not just > my conclusion -- the jdk source code acknowledges it as such) and am > wondering whether there will be any chance of remedying it before (or > after) jdk9 release. > The check in checkUnprivilegedlookupClass isn't new, I think it's a defense-in-depth check that goes back to JDK 7 to catch usages of full power lookups in fully privileged code. There was recent discussion on core-libs-dev about this, prompted by work that Paul Sandoz was doing to retrofit LockSupport and TLR to use privateLookupIn. My recollection is that he relaxed the check to allow the target class be Thread or a class in j.u.concurrent and the more general question on whether this check is needed was kicked down the road. I'm sure John Rose or Paul will jump in on this thread. BTW: None of the modules defined to the boot loader open packages so I wouldn't expect too many people will run into this. You run into in the example because java.net.HttpURLConnection is in java.base and defined to the boot loader. I guess another possible scenario would be someone opening a package in a core module with `--add-opens` and the raiding party uses privateLookupIn. -Alan. From doug.simon at oracle.com Fri Apr 21 11:46:11 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 21 Apr 2017 13:46:11 +0200 Subject: RFR: 8177845: Need a mechanism to load Graal In-Reply-To: <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> References: <9F8C5BD3-F7A6-4C66-B083-BDAD262BCFD7@oracle.com> <8C3D9D03-293B-41E2-BB47-D64086CBB218@twitter.com> <0647633E-32C7-4D4D-822E-14658DE5ECBF@oracle.com> <39D11403-8706-4014-BB68-56D24CA28634@oracle.com> <95E2B6BC-345D-4E66-947C-B6662565A405@oracle.com> Message-ID: <20D7FA70-7D7F-4F9D-B8BE-B5A9F24E618F@oracle.com> There has been some discussion about whether we want to update Graal in the JDK at this late stage. The main (only?) risk is a regression in the AOT tool. If we don't update Graal from upstream, then the qualified exports from JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition to updating Graal to remove the qualified exports, there would also need to be changes in the relevant make files to add --add-exports options when compiling Graal and jaotc as they use the dynamically exported JVMCI packages. I have an updated hotspot patch that adapts Graal to the JVMCI API changes: http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/ Note that this patch does not include the changes removing use of JDK internal API from Graal. Cherry picking those upstream Graal changes would be more work than simply doing a complete update from upstream Graal. As I see it, there are 2 options here: 1. Go with the current webrev (including hotspot.02 patch) and live with the qualified exports. 2. Go with the current webrev (including hotspot.02 patch) and create a follow up bug to update Graal from upstream, perform the relevant make file changes and remove the qualified exports. I've tested the current webrev (including hotspot.02 patch) against both upstream Graal and with jprt. -Doug > On 20 Apr 2017, at 20:50, Doug Simon wrote: > > I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an > exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg > tests to prevent Graal being selected and initialized by the JVMCI compiler auto-selection mechanism. > Initializing Graal will currently fail with errors (see stack trace below) until Graal is updated to > the version compatible with the JVMCI API changes. > > In addition to resolving the compatibility issue, explicitly selecting the "null" compiler for these > tests better isolates them from parts of the runtime they are not aiming to test. > > org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217) > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138) > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83) > at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) > at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native Method) > at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185) > at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59) > at compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64) > at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1378) > at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:563) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.ClassCastException: java.base/java.util.ImmutableCollections$MapN cannot be cast to java.base/java.util.Properties > at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215) > ... 26 more > > -Doug > >> On 19 Apr 2017, at 23:26, Doug Simon wrote: >> >> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these changes: >> >> 1. JVMCIServiceLocator.getProvider(Class) is now protected >> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission >> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> jdk.vm.ci.services.internal.ReflectionAccessJDK >> >> -Doug >> >>> On 19 Apr 2017, at 23:12, Doug Simon wrote: >>> >>>> >>>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote: >>>> >>>>> >>>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote: >>>>> >>>>>> >>>>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote: >>>>>>>> >>>>>>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not hashed with java.base to allow it to be upgraded and there is no integrity check. Such qualified export will be granted to any module named jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not to use any internal APIs and eliminate the qualified exports. >>>>>>>> >>>>>>>> The main thing is that jdk.vm.ci.services API would need to be guarded if it?s used by non-Graal modules. >>>>>>> >>>>>>> This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? >>>>>> >>>>>> It's unqualified and no restriction in this change. >>>>> >>>>> The public methods currently in jdk.vm.ci.services are: >>>>> >>>>> 1. JVMCIServiceLocator.getProvider(Class) >>>>> 2. JVMCIServiceLocator.getProviders(Class) >>>>> 3. Services.initializeJVMCI() >>>>> 4. Services.getSavedProperties() >>>>> 5. Services.exportJVMCITo(Class) >>>>> 6. Services.load(Class) >>>>> 7. Services.loadSingle(Class, boolean) >>>>> >>>>> 1 should be made protected. I'll update the webrev with this change. >>>> >>>> Good. >>>> >>>>> >>>>> 2 should check for JVMCIPermission. I'll update the webrev with this change. >>>> >>>> Good. >>>> >>>>> >>>>> 3 is harmless from a security perspective in my opinion. >>>> >>>> Would be good if one of Oracle?s security engineers could take a quick look just to be sure. >>> >>> Vladimir, can you please bring this to the attention of the relevant engineer. >>> >>>>> >>>>> 4 checks for JVMCIPermission. >>>> >>>> Ok. >>>> >>>>> >>>>> 5, 6 and 7 will be removed in a follow bug that updates Graal from upstream (and removes its usage of these methods). >>>> >>>> About this, will this Graal update happen for JDK 9? >>> >>> Yes. >>> >>>> It?s awfully late in the cycle... >>> >>> These are jigsaw related changes and I've been told jigsaw has an FC exception (although I don't exactly know what that is). >>> >>> -Doug >> > From adinn at redhat.com Fri Apr 21 12:51:13 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 21 Apr 2017 13:51:13 +0100 Subject: Using lookups in place of reflection In-Reply-To: <3abba0da-ea3f-d7d8-03f0-64b809421c44@oracle.com> References: <54df89bb-b3de-34af-3993-73c723d8eb6b@redhat.com> <3abba0da-ea3f-d7d8-03f0-64b809421c44@oracle.com> Message-ID: On 21/04/17 11:57, Alan Bateman wrote: > The check in checkUnprivilegedlookupClass isn't new, I think it's a > defense-in-depth check that goes back to JDK 7 to catch usages of full > power lookups in fully privileged code. There was recent discussion on > core-libs-dev about this, prompted by work that Paul Sandoz was doing to > retrofit LockSupport and TLR to use privateLookupIn. My recollection is > that he relaxed the check to allow the target class be Thread or a class > in j.u.concurrent and the more general question on whether this check is > needed was kicked down the road. I'm sure John Rose or Paul will jump in > on this thread. I'd be very pleased if they did :-) > BTW: None of the modules defined to the boot loader open packages so I > wouldn't expect too many people will run into this. You run into in the > example because java.net.HttpURLConnection is in java.base and defined > to the boot loader. I guess another possible scenario would be someone > opening a package in a core module with `--add-opens` and the raiding > party uses privateLookupIn. Ah, well, actually ... my agent can run into this even when java.base does not open a package. Byteman will open a package to its own private module if it wants to access protected/private members of classes in that otherwise unexported package. Of course, it only does so to do the specific, targetted accesses specified in rules provided by whoever installed the agent. It does not make the handles (never mind the packages) available to non-agent code. So, strictly ... I agree you are correct when you note that this is something that will mostly only affect a small number of people -- it only limits the options available to agent developers. Of course, that doesn't mean it won't have a knock-on effect for users of those agent (perhaps a rather larger commmunity :-). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From alan.bateman at oracle.com Fri Apr 21 16:59:36 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 21 Apr 2017 16:59:36 +0000 Subject: hg: jigsaw/jake/jdk: Load SecurityManager's non-exported packages when needed rather than eagerly Message-ID: <201704211659.v3LGxaq2003386@aojmv0008.oracle.com> Changeset: 8d25210fce7b Author: alanb Date: 2017-04-21 17:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8d25210fce7b Load SecurityManager's non-exported packages when needed rather than eagerly ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/Modules.java From alan.bateman at oracle.com Fri Apr 21 19:50:22 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 21 Apr 2017 19:50:22 +0000 Subject: hg: jigsaw/jake/jdk: SecurityManager should not record packages of modules defined to app loader Message-ID: <201704211950.v3LJoMDH006177@aojmv0008.oracle.com> Changeset: b38f70bbe88d Author: alanb Date: 2017-04-21 20:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b38f70bbe88d SecurityManager should not record packages of modules defined to app loader ! src/java.base/share/classes/java/lang/SecurityManager.java From mandy.chung at oracle.com Fri Apr 21 20:53:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Apr 2017 13:53:52 -0700 Subject: Review Request: 8179025: Exclude deployment modules from FieldSetAccessibleTest.java and VerifyJimage.java Message-ID: <2FA6295D-B490-4747-93DB-E80D4400FBD1@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.00/index.html These tests failed due to IAE when loading types from the deployment modules which are expected to be defined when running with javaws or plugin. This revises the tests to exclude these modules to remove the tests from the problem list. In the long term, we should look into some way not to link in these modules in the image. This patch also updates JdkQualifiedExportTest.java test to take out the exception for deployment modules to have qualified exports to upgradeable modules. thanks Mandy From alan.bateman at oracle.com Sat Apr 22 08:18:44 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 22 Apr 2017 08:18:44 +0000 Subject: hg: jigsaw/jake/hotspot: Rename "modules" tag for -Xlog to "module", allow -Xlog:module+load Message-ID: <201704220818.v3M8IiPE023856@aojmv0008.oracle.com> Changeset: 542daf99d1d4 Author: alanb Date: 2017-04-22 09:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/542daf99d1d4 Rename "modules" tag for -Xlog to "module", allow -Xlog:module+load ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! test/runtime/logging/ModulesTest.java ! test/runtime/logging/StartupTimeTest.java ! test/runtime/modules/ModuleStress/ModuleStress.java ! test/runtime/modules/ModuleStress/ModuleStressGC.java From peter.levart at gmail.com Sat Apr 22 08:22:38 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Apr 2017 10:22:38 +0200 Subject: Review Request: 8179025: Exclude deployment modules from FieldSetAccessibleTest.java and VerifyJimage.java In-Reply-To: <2FA6295D-B490-4747-93DB-E80D4400FBD1@oracle.com> References: <2FA6295D-B490-4747-93DB-E80D4400FBD1@oracle.com> Message-ID: <2ef2788f-002a-3324-e502-4a792334b25a@gmail.com> Hi Mandy, In order to make the FieldSetAccessibleTest more resilient to future changes (i.e. adding / renaming modules), perhaps the modules to be excluded in the check should be explicitly listed by their names? Currently your rule, when negated, lists the following modules: javafx.deploy jdk.deploy jdk.javaws jdk.plugin.dom jdk.plugin jdk.deploy.controlpanel jdk.plugin.server ...which is not to much to put in a Set.of(....) instance. There's no harm if future changes forget to add/change this set, but it would be wrong if the rule you have now, inadvertently excludes some future module that should be checked. Regards, Peter On 04/21/2017 10:53 PM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.00/index.html > > These tests failed due to IAE when loading types from the deployment > modules which are expected to be defined when running with javaws > or plugin. This revises the tests to exclude these modules to > remove the tests from the problem list. In the long term, we > should look into some way not to link in these modules in the image. > > This patch also updates JdkQualifiedExportTest.java test to take out > the exception for deployment modules to have qualified exports to > upgradeable modules. > > thanks > Mandy From forax at univ-mlv.fr Sat Apr 22 11:20:15 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 22 Apr 2017 13:20:15 +0200 (CEST) Subject: Changing the default file system provider is broken :( Message-ID: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> Ooops ! if you use the module path, you can not change the default system provider mechanism anymore, mostly because the module implementation internally uses java.nio.file.Path at different places. First, trying to initialize the default system provider in Java code do not work at all, calling System.setProperty("java.nio.file.spi.DefaultFileSystemProvider", "..."); in a main does nothing because the jigsaw implementation has already loaded the default implementation to be able to inspect the modules. Then, if you try to use the command line -Djava.nio.file.spi.DefaultFileSystemProvider=... you have various bootstrapping issues. With exploded modules, when trying to initialize the default file system, the part of jigsaw that reads exploded modules uses path.toFile() that fails it checks that the path belongs to the default file system which is not already initialized (see below for the whole stacktrace) With modular jars, when trying to initialize the default file system, the JarModuleReader also uses path.toFile(), leading to the same error One way to solve that is to change the code in FileSystems.getDefault() to add a nullcheck, FileSystem defaultFileSystem = DefaultFileSystemHolder.defaultFileSystem; if (jdk.internal.misc.VM.isBooted() && defaultFileSystem != null) { return defaultFileSystem; } else { return BuiltinFileSystemHolder.builtinFileSystem; } Another solution is to change the code of jigsaw to only use the builtinFileSystem, delaying the initialization of the default system which will also solve the case where an application uses System.setProperty. cheers, R?mi Stacktrace with exploded modules: Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) at java.base/java.nio.file.Path.toFile(Path.java:655) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) at java.base/java.lang.Class.forName(Class.java:447) at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. at java.base/java.nio.file.Path.toFile(Path.java:658) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:374) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) ... 22 more StackTrace with modular jars: Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) at java.base/java.nio.file.Path.toFile(Path.java:655) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) at java.base/java.lang.Class.forName(Class.java:447) at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. at java.base/java.nio.file.Path.toFile(Path.java:658) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:374) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) ... 22 more From peter.levart at gmail.com Sat Apr 22 15:14:32 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Apr 2017 17:14:32 +0200 Subject: Changing the default file system provider is broken :( In-Reply-To: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, On 04/22/2017 01:20 PM, Remi Forax wrote: > Ooops ! > if you use the module path, you can not change the default system provider mechanism anymore, > mostly because the module implementation internally uses java.nio.file.Path at different places. > > First, trying to initialize the default system provider in Java code do not work at all, > calling > System.setProperty("java.nio.file.spi.DefaultFileSystemProvider", "..."); > in a main does nothing because the jigsaw implementation has already loaded the default implementation to be able to inspect the modules. > > Then, if you try to use the command line > -Djava.nio.file.spi.DefaultFileSystemProvider=... > you have various bootstrapping issues. > > With exploded modules, when trying to initialize the default file system, the part of jigsaw that reads exploded modules uses path.toFile() that fails it checks that the path belongs to the default file system which is not already initialized > (see below for the whole stacktrace) > > With modular jars, when trying to initialize the default file system, the JarModuleReader also uses path.toFile(), leading to the same error > > One way to solve that is to change the code in FileSystems.getDefault() to add a nullcheck, > FileSystem defaultFileSystem = DefaultFileSystemHolder.defaultFileSystem; > if (jdk.internal.misc.VM.isBooted() && defaultFileSystem != null) { > return defaultFileSystem; > } else { > return BuiltinFileSystemHolder.builtinFileSystem; > } > Another solution is to change the code of jigsaw to only use the builtinFileSystem, delaying the initialization of the default system which will also solve the case where an application uses System.setProperty. I think the problem is that what FileSystems.getDefault() returns, changes over time. So you have Path instances associated with "builtin" filesystem, constructed before VM.isBooted() and after it is booted, Path instances are associated with what is configured to be the "default" filesystem. If those two differ and an instance, constructed before VM.isBooted() lives past the boot time and then .toFile() is called on such instance, we get "UnsupportedOperationException: Path not associated with default file system"... Maybe Alan could shed some light into this. As part of jigsaw implementation, the FileSystems.getDefault() was changed from: public static FileSystem getDefault() { return DefaultFileSystemHolder.defaultFileSystem; } to: public static FileSystem getDefault() { if (jdk.internal.misc.VM.isBooted()) { return DefaultFileSystemHolder.defaultFileSystem; } else { return BuiltinFileSystemHolder.builtinFileSystem; } } Probably because of early bootstrap issues. Module system needs FileSystem and custom FileSystem classes can not be loaded at that time yet. So I think that your second solution would be the right one. Jigsaw should only use the builtin filesystem explicitly, refraining from initializing the default filesystem. And Path.toFile() should allow creating a File from a Path in either case: whether Path is associated with builtin or default filesystem. Regards, Peter > cheers, > R?mi > > > Stacktrace with exploded modules: > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) > at java.base/java.nio.file.Path.toFile(Path.java:655) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) > at java.base/java.lang.Class.forName(Class.java:447) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) > Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.Path.toFile(Path.java:658) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:374) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) > ... 22 more > > > StackTrace with modular jars: > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) > at java.base/java.nio.file.Path.toFile(Path.java:655) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) > at java.base/java.lang.Class.forName(Class.java:447) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) > Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.Path.toFile(Path.java:658) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:374) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) > ... 22 more > From mandy.chung at oracle.com Sat Apr 22 15:42:05 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 22 Apr 2017 08:42:05 -0700 Subject: Review Request: 8179025: Exclude deployment modules from FieldSetAccessibleTest.java and VerifyJimage.java In-Reply-To: <2ef2788f-002a-3324-e502-4a792334b25a@gmail.com> References: <2FA6295D-B490-4747-93DB-E80D4400FBD1@oracle.com> <2ef2788f-002a-3324-e502-4a792334b25a@gmail.com> Message-ID: <016A721A-D5BC-46A5-8F24-0C7DFE0D92DD@oracle.com> Have an explicit list is another alternative. OTOH I think only deployment modules will name with these words though which was what I initially want to cover. Since only 4 modules we are concerned about, I updated the patch to list the ones needed to be excluded rather than a superset as you suggest: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.01/ thanks Mandy > On Apr 22, 2017, at 1:22 AM, Peter Levart wrote: > > Hi Mandy, > > In order to make the FieldSetAccessibleTest more resilient to future changes (i.e. adding / renaming modules), perhaps the modules to be excluded in the check should be explicitly listed by their names? Currently your rule, when negated, lists the following modules: > > javafx.deploy > jdk.deploy > jdk.javaws > jdk.plugin.dom > jdk.plugin > jdk.deploy.controlpanel > jdk.plugin.server > > ...which is not to much to put in a Set.of(....) instance. > > There's no harm if future changes forget to add/change this set, but it would be wrong if the rule you have now, inadvertently excludes some future module that should be checked. > > Regards, Peter > > > On 04/21/2017 10:53 PM, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.00/index.html >> >> These tests failed due to IAE when loading types from the deployment >> modules which are expected to be defined when running with javaws >> or plugin. This revises the tests to exclude these modules to >> remove the tests from the problem list. In the long term, we >> should look into some way not to link in these modules in the image. >> >> This patch also updates JdkQualifiedExportTest.java test to take out >> the exception for deployment modules to have qualified exports to >> upgradeable modules. >> >> thanks >> Mandy > From forax at univ-mlv.fr Sat Apr 22 18:10:48 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 22 Apr 2017 20:10:48 +0200 (CEST) Subject: Changing the default file system provider is broken :( In-Reply-To: References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> Message-ID: <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> Hi Peter > Hi Remi, > On 04/22/2017 01:20 PM, Remi Forax wrote: >> Ooops ! >> if you use the module path, you can not change the default system provider >> mechanism anymore, >> mostly because the module implementation internally uses java.nio.file.Path at >> different places. >> First, trying to initialize the default system provider in Java code do not work >> at all, >> calling >> System.setProperty("java.nio.file.spi.DefaultFileSystemProvider", "..."); >> in a main does nothing because the jigsaw implementation has already loaded the >> default implementation to be able to inspect the modules. >> Then, if you try to use the command line >> -Djava.nio.file.spi.DefaultFileSystemProvider=... >> you have various bootstrapping issues. >> With exploded modules, when trying to initialize the default file system, the >> part of jigsaw that reads exploded modules uses path.toFile() that fails it >> checks that the path belongs to the default file system which is not already >> initialized >> (see below for the whole stacktrace) >> With modular jars, when trying to initialize the default file system, the >> JarModuleReader also uses path.toFile(), leading to the same error >> One way to solve that is to change the code in FileSystems.getDefault() to add a >> nullcheck, >> FileSystem defaultFileSystem = DefaultFileSystemHolder.defaultFileSystem; >> if (jdk.internal.misc.VM.isBooted() && defaultFileSystem != null) { >> return defaultFileSystem; >> } else { >> return BuiltinFileSystemHolder.builtinFileSystem; >> } >> Another solution is to change the code of jigsaw to only use the >> builtinFileSystem, delaying the initialization of the default system which will >> also solve the case where an application uses System.setProperty. > I think the problem is that what FileSystems.getDefault() returns, changes over > time. So you have Path instances associated with "builtin" filesystem, > constructed before VM.isBooted() and after it is booted, Path instances are > associated with what is configured to be the "default" filesystem. If those two > differ and an instance, constructed before VM.isBooted() lives past the boot > time and then .toFile() is called on such instance, we get > "UnsupportedOperationException: Path not associated with default file > system"... > Maybe Alan could shed some light into this. As part of jigsaw implementation, > the FileSystems.getDefault() was changed from: > public static FileSystem getDefault() { > return DefaultFileSystemHolder.defaultFileSystem; > } > to: > public static FileSystem getDefault() { > if (jdk.internal.misc.VM.isBooted()) { > return DefaultFileSystemHolder.defaultFileSystem; > } else { > return BuiltinFileSystemHolder.builtinFileSystem; > } > } > Probably because of early bootstrap issues. Module system needs FileSystem and > custom FileSystem classes can not be loaded at that time yet. > So I think that your second solution would be the right one. Jigsaw should only > use the builtin filesystem explicitly, refraining from initializing the default > filesystem. And Path.toFile() should allow creating a File from a Path in > either case: whether Path is associated with builtin or default filesystem. I think your right for the modular jars case, ModulePath store an array of Path created before the VM is considered as booted and consume them lazily :( I believe that replacing the path.toFile() by new File(path.toString()) will fix this issue. > Regards, Peter R?mi >> cheers, >> R?mi >> Stacktrace with exploded modules: >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" java.lang.Error: >> java.lang.UnsupportedOperationException: Path not associated with default file >> system. >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) >> at java.base/java.nio.file.Path.toFile(Path.java:655) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) >> at >> java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) >> at >> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) >> at >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) >> at java.base/java.lang.Class.forName(Class.java:447) >> at >> java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) >> at >> java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) >> Caused by: java.lang.UnsupportedOperationException: Path not associated with >> default file system. >> at java.base/java.nio.file.Path.toFile(Path.java:658) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) >> at >> java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) >> at >> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) >> at >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:374) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) >> ... 22 more >> StackTrace with modular jars: >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" java.lang.Error: >> java.lang.UnsupportedOperationException: Path not associated with default file >> system. >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) >> at java.base/java.nio.file.Path.toFile(Path.java:655) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) >> at >> java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) >> at >> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) >> at >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) >> at java.base/java.lang.Class.forName(Class.java:447) >> at >> java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) >> at >> java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) >> Caused by: java.lang.UnsupportedOperationException: Path not associated with >> default file system. >> at java.base/java.nio.file.Path.toFile(Path.java:658) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) >> at >> java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) >> at >> java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) >> at >> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) >> at >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:374) >> at >> java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) >> ... 22 more From peter.levart at gmail.com Sat Apr 22 19:47:03 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Apr 2017 21:47:03 +0200 Subject: Changing the default file system provider is broken :( In-Reply-To: <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> Message-ID: <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> On 04/22/2017 08:10 PM, forax at univ-mlv.fr wrote: > Hi Peter > > Hi Remi, > > On 04/22/2017 01:20 PM, Remi Forax wrote: > > Ooops ! > if you use the module path, you can not change the default system provider mechanism anymore, > mostly because the module implementation internally uses java.nio.file.Path at different places. > > First, trying to initialize the default system provider in Java code do not work at all, > calling > System.setProperty("java.nio.file.spi.DefaultFileSystemProvider", "..."); > in a main does nothing because the jigsaw implementation has already loaded the default implementation to be able to inspect the modules. > > Then, if you try to use the command line > -Djava.nio.file.spi.DefaultFileSystemProvider=... > you have various bootstrapping issues. > > With exploded modules, when trying to initialize the default file system, the part of jigsaw that reads exploded modules uses path.toFile() that fails it checks that the path belongs to the default file system which is not already initialized > (see below for the whole stacktrace) > > With modular jars, when trying to initialize the default file system, the JarModuleReader also uses path.toFile(), leading to the same error > > One way to solve that is to change the code in FileSystems.getDefault() to add a nullcheck, > FileSystem defaultFileSystem = DefaultFileSystemHolder.defaultFileSystem; > if (jdk.internal.misc.VM.isBooted() && defaultFileSystem != null) { > return defaultFileSystem; > } else { > return BuiltinFileSystemHolder.builtinFileSystem; > } > Another solution is to change the code of jigsaw to only use the builtinFileSystem, delaying the initialization of the default system which will also solve the case where an application uses System.setProperty. > > > I think the problem is that what FileSystems.getDefault() returns, > changes over time. So you have Path instances associated with > "builtin" filesystem, constructed before VM.isBooted() and after > it is booted, Path instances are associated with what is > configured to be the "default" filesystem. If those two differ and > an instance, constructed before VM.isBooted() lives past the boot > time and then .toFile() is called on such instance, we get > "UnsupportedOperationException: Path not associated with default > file system"... > > Maybe Alan could shed some light into this. As part of jigsaw > implementation, the FileSystems.getDefault() was changed from: > > public static FileSystem getDefault() { > return DefaultFileSystemHolder.defaultFileSystem; > } > > to: > > public static FileSystem getDefault() { > if (jdk.internal.misc.VM.isBooted()) { > return DefaultFileSystemHolder.defaultFileSystem; > } else { > return BuiltinFileSystemHolder.builtinFileSystem; > } > } > > Probably because of early bootstrap issues. Module system needs > FileSystem and custom FileSystem classes can not be loaded at that > time yet. > > So I think that your second solution would be the right one. > Jigsaw should only use the builtin filesystem explicitly, > refraining from initializing the default filesystem. And > Path.toFile() should allow creating a File from a Path in either > case: whether Path is associated with builtin or default filesystem. > > > I think your right for the modular jars case, ModulePath store an > array of Path created before the VM is considered as booted and > consume them lazily :( > I believe that replacing the path.toFile() by new > File(path.toString()) will fix this issue. Or this might work too: http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ A variant of this might be for FileSystems.getDefault() to start returning the custom default filesystem as soon as initLevel reaches 2 (after module system is initialized). This might allow custom default file system to be effective even before the VM is fully booted (for custom security manager or system class loader or java agent to already take advantage of it). But that probably would mean that the custom default filesystem loading logic would have to be modified in order to cope with system class loader not being setup already - it could use the builtin app class loader for locating and loading the classes... Do you happen to have a custom default filesystem to try this with? Regards, Peter > > > Regards, Peter > > > R?mi > > > cheers, > R?mi > > > Stacktrace with exploded modules: > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) > at java.base/java.nio.file.Path.toFile(Path.java:655) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) > at java.base/java.lang.Class.forName(Class.java:447) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) > Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.Path.toFile(Path.java:658) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:374) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) > ... 22 more > > > StackTrace with modular jars: > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.Error: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:101) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188) > at java.base/java.nio.file.Path.toFile(Path.java:655) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:532) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:585) > at java.base/java.lang.Class.forName(Class.java:447) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:585) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:523) > Caused by: java.lang.UnsupportedOperationException: Path not associated with default file system. > at java.base/java.nio.file.Path.toFile(Path.java:658) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.newJarFile(ModuleReferences.java:229) > at java.base/jdk.internal.module.ModuleReferences$JarModuleReader.(ModuleReferences.java:239) > at java.base/jdk.internal.module.ModuleReferences.lambda$newJarModule$0(ModuleReferences.java:96) > at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:88) > at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:953) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719) > at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:945) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:702) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:651) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:576) > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:374) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129) > ... 22 more > > > From forax at univ-mlv.fr Sat Apr 22 20:06:41 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 22 Apr 2017 22:06:41 +0200 (CEST) Subject: Changing the default file system provider is broken :( In-Reply-To: <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> Message-ID: <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> [...] > Or this might work too: > http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ yes, it's better > A variant of this might be for FileSystems.getDefault() to start returning the > custom default filesystem as soon as initLevel reaches 2 (after module system > is initialized). This might allow custom default file system to be effective > even before the VM is fully booted (for custom security manager or system class > loader or java agent to already take advantage of it). But that probably would > mean that the custom default filesystem loading logic would have to be modified > in order to cope with system class loader not being setup already - it could > use the builtin app class loader for locating and loading the classes... > Do you happen to have a custom default filesystem to try this with? sure, a dummy one that delegates everything to the builtin https://gist.github.com/forax/615828b41c33eccda33afdf2eba1db87 > Regards, Peter regards, R?mi From Alan.Bateman at oracle.com Sat Apr 22 20:26:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Apr 2017 21:26:59 +0100 Subject: Changing the default file system provider is broken :( In-Reply-To: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> Message-ID: On 22/04/2017 12:20, Remi Forax wrote: > Ooops ! > if you use the module path, you can not change the default system provider mechanism anymore, > mostly because the module implementation internally uses java.nio.file.Path at different places. > > First, trying to initialize the default system provider in Java code do not work at all, > calling > System.setProperty("java.nio.file.spi.DefaultFileSystemProvider", "..."); > in a main does nothing because the jigsaw implementation has already loaded the default implementation to be able to inspect the modules. > > Then, if you try to use the command line > -Djava.nio.file.spi.DefaultFileSystemProvider=... > you have various bootstrapping issues. > > Sigh, this is a bug here. A custom default file system can't be used during early startup so this is why the module system uses the built-in implementation. The bug is that is should always derive paths and never use Paths.get or toFile as that risks mixing paths from the built-in file system provider with the custom provider. The patch to fix is straight-forward and I'll get that in jake soon. The only change needed in the file system code is that FileSystems.getDefault should use VM.isModuleSystemInited() rather than is VM.booted() to allow for the corner case that is a custom system class loader or custom security manager using the file system API. -Alan. From Alan.Bateman at oracle.com Sat Apr 22 20:37:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Apr 2017 21:37:50 +0100 Subject: Changing the default file system provider is broken :( In-Reply-To: <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> Message-ID: <80f7a70a-abf7-a3a5-c54d-96babb135dc1@oracle.com> On 22/04/2017 20:47, Peter Levart wrote: > : > > Or this might work too: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ Only partly as there is also the issue of resolving paths associated with one provider against a path associated with another. > > A variant of this might be for FileSystems.getDefault() to start > returning the custom default filesystem as soon as initLevel reaches 2 > (after module system is initialized). This might allow custom default > file system to be effective even before the VM is fully booted (for > custom security manager or system class loader or java agent to > already take advantage of it). When running with a custom file system provider then it's important that objects associated with the built-in provider don't leak to user code. So yes, getDefault() should return the custom file system after the module system is initialized so that custom system class loaders, custom security manager, and agents get objects associated with the custom provider. -Alan From peter.levart at gmail.com Sat Apr 22 20:48:43 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Apr 2017 22:48:43 +0200 Subject: Changing the default file system provider is broken :( In-Reply-To: <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> Message-ID: On 04/22/2017 10:06 PM, forax at univ-mlv.fr wrote: > > Or this might work too: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ > > > yes, it's better > > > > A variant of this might be for FileSystems.getDefault() to start > returning the custom default filesystem as soon as initLevel > reaches 2 (after module system is initialized). This might allow > custom default file system to be effective even before the VM is > fully booted (for custom security manager or system class loader > or java agent to already take advantage of it). But that probably > would mean that the custom default filesystem loading logic would > have to be modified in order to cope with system class loader not > being setup already - it could use the builtin app class loader > for locating and loading the classes... > > Do you happen to have a custom default filesystem to try this with? > > > sure, a dummy one that delegates everything to the builtin > https://gist.github.com/forax/615828b41c33eccda33afdf2eba1db87 Well, it works at least when -Djava.nio.file.spi.DefaultFileSystemProvider=... is specified on the command line. But when the system property is set as 1st thing in main() method, it is already too late. It seems that after boot sequence is finished (VM.isBooted() == true)and before main() method is called, some code needs the FileSystem again, so default file system is already initialized before the main() is executed. Perhaps there needs to be another initLevel which would be set just before the invocation of the main() method? Regards, Peter From peter.levart at gmail.com Sat Apr 22 21:03:43 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Apr 2017 23:03:43 +0200 Subject: Changing the default file system provider is broken :( In-Reply-To: <80f7a70a-abf7-a3a5-c54d-96babb135dc1@oracle.com> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> <80f7a70a-abf7-a3a5-c54d-96babb135dc1@oracle.com> Message-ID: Hi Alan, On 04/22/2017 10:37 PM, Alan Bateman wrote: > On 22/04/2017 20:47, Peter Levart wrote: > >> : >> >> Or this might work too: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ > Only partly as there is also the issue of resolving paths associated > with one provider against a path associated with another. So module system would need to keep using the builtin filesystem for any Path manipulation after VM.isBooted. At least within the boot Layer. There's no public API in module system that would return Path objects to user, is it? > >> >> A variant of this might be for FileSystems.getDefault() to start >> returning the custom default filesystem as soon as initLevel reaches >> 2 (after module system is initialized). This might allow custom >> default file system to be effective even before the VM is fully >> booted (for custom security manager or system class loader or java >> agent to already take advantage of it). > When running with a custom file system provider then it's important > that objects associated with the built-in provider don't leak to user > code. So yes, getDefault() should return the custom file system after > the module system is initialized so that custom system class loaders, > custom security manager, and agents get objects associated with the > custom provider. > > -Alan Right. No user code should see builtin Path(s) when custom default file system is configured. Regards, Peter From Alan.Bateman at oracle.com Sun Apr 23 10:38:21 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Apr 2017 11:38:21 +0100 Subject: Changing the default file system provider is broken :( In-Reply-To: References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> Message-ID: On 22/04/2017 21:48, Peter Levart wrote: > > Well, it works at least when > -Djava.nio.file.spi.DefaultFileSystemProvider=... is specified on the > command line. But when the system property is set as 1st thing in > main() method, it is already too late. It seems that after boot > sequence is finished (VM.isBooted() == true)and before main() method > is called, some code needs the FileSystem again, so default file > system is already initialized before the main() is executed. > > Perhaps there needs to be another initLevel which would be set just > before the invocation of the main() method? I don't think we go there as there are just too many scenarios where "user code" can execute before the application main method. Instead, I think this is a case where the default file system provider can only be overridden by setting the property on the command line. -Alan From alan.bateman at oracle.com Sun Apr 23 10:40:01 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 23 Apr 2017 10:40:01 +0000 Subject: hg: jigsaw/jake/jdk: Override default file system provider does not work with module path or patching Message-ID: <201704231040.v3NAe2kf013669@aojmv0008.oracle.com> Changeset: aa0e5a215c2d Author: alanb Date: 2017-04-23 11:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa0e5a215c2d Override default file system provider does not work with module path or patching ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/jdk/internal/module/Resources.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java + test/java/nio/file/spi/m/module-info.java + test/java/nio/file/spi/m/p/Main.java From alan.bateman at oracle.com Sun Apr 23 10:52:59 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 23 Apr 2017 10:52:59 +0000 Subject: hg: jigsaw/jake/jdk: Invoking isModifiableModule with an unnamed module not clear Message-ID: <201704231052.v3NAqxmI017350@aojmv0008.oracle.com> Changeset: 3cd57b38881e Author: alanb Date: 2017-04-23 11:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3cd57b38881e Invoking isModifiableModule with an unnamed module not clear ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java From alan.bateman at oracle.com Sun Apr 23 11:01:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 23 Apr 2017 11:01:56 +0000 Subject: hg: jigsaw/jake/hotspot: Call JVMTI IsModifiableModule with an unnamed module not clear Message-ID: <201704231101.v3NB1uEY019726@aojmv0008.oracle.com> Changeset: 614a60bb7a26 Author: alanb Date: 2017-04-23 12:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/614a60bb7a26 Call JVMTI IsModifiableModule with an unnamed module not clear ! src/share/vm/prims/jvmti.xml From Alan.Bateman at oracle.com Sun Apr 23 11:09:57 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Apr 2017 12:09:57 +0100 Subject: Review Request: 8179025: Exclude deployment modules from FieldSetAccessibleTest.java and VerifyJimage.java In-Reply-To: <016A721A-D5BC-46A5-8F24-0C7DFE0D92DD@oracle.com> References: <2FA6295D-B490-4747-93DB-E80D4400FBD1@oracle.com> <2ef2788f-002a-3324-e502-4a792334b25a@gmail.com> <016A721A-D5BC-46A5-8F24-0C7DFE0D92DD@oracle.com> Message-ID: <76583706-5640-706b-9964-5e1314c93878@oracle.com> On 22/04/2017 16:42, Mandy Chung wrote: > Have an explicit list is another alternative. OTOH I think only deployment modules will name with these words though which was what I initially want to cover. > > Since only 4 modules we are concerned about, I updated the patch to list the ones needed to be excluded rather than a superset as you suggest: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179025/webrev.01/ > > The updated filter looks okay to me. In JdkQualifiedExportTest.accept then "cf.findModule(target).orElse(null) == null" looks a bit odd (I assume this is what promoted Peter bringing up isEmpty on core-libs-dev. There are a dozen ways you could do this of course, only alternative is: return cf.findModule(target).map(m -> false).orElse(true); -Alan From forax at univ-mlv.fr Sun Apr 23 18:28:38 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 23 Apr 2017 20:28:38 +0200 (CEST) Subject: Changing the default file system provider is broken :( In-Reply-To: References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> Message-ID: <919483182.3528183.1492972118727.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Dimanche 23 Avril 2017 12:38:21 > Objet: Re: Changing the default file system provider is broken :( > On 22/04/2017 21:48, Peter Levart wrote: > >> >> Well, it works at least when >> -Djava.nio.file.spi.DefaultFileSystemProvider=... is specified on the >> command line. But when the system property is set as 1st thing in >> main() method, it is already too late. It seems that after boot >> sequence is finished (VM.isBooted() == true)and before main() method >> is called, some code needs the FileSystem again, so default file >> system is already initialized before the main() is executed. >> >> Perhaps there needs to be another initLevel which would be set just >> before the invocation of the main() method? > I don't think we go there as there are just too many scenarios where > "user code" can execute before the application main method. Instead, I > think this is a case where the default file system provider can only be > overridden by setting the property on the command line. This should be added to the compatibility list because mocking the FileSystem for testing purpose is common, at least in my own bubble. > > -Alan R?mi From Alan.Bateman at oracle.com Mon Apr 24 08:05:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Apr 2017 09:05:49 +0100 Subject: Changing the default file system provider is broken :( In-Reply-To: <919483182.3528183.1492972118727.JavaMail.zimbra@u-pem.fr> References: <794753796.3333919.1492860015417.JavaMail.zimbra@u-pem.fr> <1464006412.3377147.1492884648095.JavaMail.zimbra@u-pem.fr> <0c087ccc-a137-97aa-6a84-8c33b49b7cbe@gmail.com> <790263688.3383846.1492891601124.JavaMail.zimbra@u-pem.fr> <919483182.3528183.1492972118727.JavaMail.zimbra@u-pem.fr> Message-ID: <2dad8d64-2a55-2d1b-40ed-83e0fc8672f8@oracle.com> On 23/04/2017 19:28, Remi Forax wrote: > : > This should be added to the compatibility list because mocking the FileSystem for testing purpose is common, at least in my own bubble. > I would prefer not introduce compatibility issues in this area if possible. I think the best we can do is read the java.nio.file.spi.DefaultFileSystemProvider property on first usage after the module system is initialized. So assume you set the property in your main method: 1. If an agent is started before your main, and the agent uses the file system API in its initialization, then the built-in provider will be used. This is the same as JDK 7 and JDK 8. 2. If a custom system class loader or a custom security manager is configuration, and if the initialization of either uses the file system API, then the built-in provider will be used. This is the same as JDK 7 and JDK 8. If set on the command line: (a) If an agent uses the file system API then it will use the custom provider. This is the same as JDK 7 and JDK 8. (b) If a custom system class loader or a custom security manager attempts to use the file system API then it will fail with a recursive initialization error or exception (it varies). This is because the custom file system provider is located using the system class loader. This is the same as JDK 7 and JDK 8 although the exception/error is different as this area has been cleared up a lot in JDK 9. We could improve (b) by changing the spec to allow custom file system providers be located before the system class loader is initialized but it hardly seems worth it. Do you agree with this? If so then we can get the implementation aligned and create some issues in JIRA to ensure that we have tests to cover all these scenarios. -Alan From alan.bateman at oracle.com Mon Apr 24 08:15:00 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 24 Apr 2017 08:15:00 +0000 Subject: hg: jigsaw/jake/hotspot: -verbose:module should imply -Xlog:module+unload Message-ID: <201704240815.v3O8F08d022014@aojmv0008.oracle.com> Changeset: d0212a5d61a4 Author: alanb Date: 2017-04-24 09:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d0212a5d61a4 -verbose:module should imply -Xlog:module+unload ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/runtime/arguments.cpp ! test/runtime/logging/ModulesTest.java From alan.bateman at oracle.com Mon Apr 24 11:23:11 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 24 Apr 2017 11:23:11 +0000 Subject: hg: jigsaw/jake/jdk: Make module resolution diagnostic output easier to read and grep Message-ID: <201704241123.v3OBNBx1014500@aojmv0008.oracle.com> Changeset: e331594e4367 Author: alanb Date: 2017-04-24 11:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e331594e4367 Make module resolution diagnostic output easier to read and grep ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/libjli/java.c From manovotn at redhat.com Mon Apr 24 11:41:32 2017 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 24 Apr 2017 07:41:32 -0400 (EDT) Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> Message-ID: <1247509897.320605.1493034092697.JavaMail.zimbra@redhat.com> Hi, thanks for your time. Comments inline. ----- Original Message ----- > From: "Alan Bateman" > To: "Matej Novotny" > Cc: jigsaw-dev at openjdk.java.net, "Martin Kouba" , "Tomas Remes" > Sent: Thursday, April 20, 2017 10:52:04 AM > Subject: Re: setAccessible() alternative with Jigsaw - feedback on Lookup > > On 20/04/2017 07:43, Matej Novotny wrote: > > > So I did some hacking and tried to make Weld use MethodHandles.Lookup and > > here is a bit of a feedback for you. > > But first of all, thanks for your quick advice on how to approach this. > Thank you for writing down your experiences. > > > > > > > So, how did Lookup work for us? > > > > 1) privateLookupIn + drop private mode > > This was the way to go, as the bean classes can be anywhere (in classes not > > openly accessible to us, especially if we consider modules). > > BTW I am not sure about the purpose of the private mode as you always need > > to drop it to be able to use lookup. > This should work fine for existing bean classes as presumably they are > in the class path or at least not in modules that are strongly > encapsulated. In the future then if the bean classes are compiled and > deployed as modules then the owner of the module will have to open the > packages to at least the library that wants to reflect deeply. > > The reason you have to drop the PRIVATE mode is because it is expected > to be used in the future. JDK-8171335 [1] and JEP 181 [2] provide some > context as how this could evolve. Thanks for explanation, it makes some sense now. > > > > > 2) Lookup approach carries along the need to pass the reference to the base > > lookup class at all times. > > This is kind of weird because in some (not-so-rare) cases, we need to > > create "artificial packages" in which we place proxy classes. For instance > > when we create a proxy for Interger, Map, Principal,... > > Ofc we cannot place in into java.* packages, so we create our own. For this > > to work with Lookup, we need to have that package created ahead of time > > and have a reference to some "dummy" useless class inside to be able to do > > the lookup. > > Or is there a way to define a whole new (open by default) package where we > > could place it using Lookup? Having the "dummy" package/class just to use > > Lookup is lame and very error prone (I can think of several ways to break > > the proxy creation even now). > What is the defining loader of the proxy class that you spin for types > such as java.lang.Integer? If it's your class loader implementation then > you can invoke its defineClass method to define the class, your don't > need a Lookup to an existing class for that scenario. Not really sure, but it is certainly not one under our control. I suppose these "basic" classes will be loaded by, say, Wildfly as soon as you bootstrap it, before any CDI-enabled deployment takes place. > > If you are looking to define a class in a new runtime package and the > class loader that is not your implementation then you are out of luck. > Lookup is designed for doing computations in the context of an existing > class. There is a note in the archives here from John Rose about > extending the lookup API for cases like this but it would come with a > lot of complexity. Also there isn't any notion of adding a package to a > named module at this time. When java.lang.reflect.Proxy spins proxy > classes then it doesn't add packages to named modules, it instead spins > the proxy classes into its own module (something you could do too, > assuming the classes that you are proxying are accessible). I think it's more or less what we did/are doing - we spin the proxies either into the same package the came from or to our own package/module. But in order to avoid proxy name clash in the same package, we just took the original package and replaced the prefix 'java' with something like 'org.jboss.weld.proxies'. This effectively means that 'java.util.Map' proxy will end up as something like 'org.jboss.weld.proxies.util.Map$Proxy'. Obviously, 'org.jboss.weld.proxies.util' did not exist beforehand and putting everything into one existing package using Lookup is bound to blow up very quickly. So there is basically no way to achieve this with JDK 9? > > > > > 3) All in all the changes carried along a lot of complexity compared to > > plain old ClassLoader.defineClass > > We need to create A LOT of Lookups (might present performance overhead, > > haven't tested yet). > > Extra care needs to be given to the packages for Lookup not to blow up > > while we in fact don't really care where the proxy lands as long as it is > > usable. > Can you expand on the "don't really care" comment? Do you mean that you > don't care about either the defining loader or runtime package? I was referring to the runtime package. What we need is to ensure that there won't be a clash - there can be two classes with same name and different packages, which, for some reason, will have to land in a package created by us. If this happened and we were using a fixed existing package to place them in, it would blow up. So what I meant was that with JDK 8 I don't need to care for this, I just use prefix and I am done with it. In JDK 9, this seems like quite an obstacle. > > > > > > > Another nasty thing is that the code of course needs to work with both, JDK > > 9 and 8. > > While it isn't impossible, it will add a not-so-nice reflection magic layer > > to the mix. > > > Multi-release JARs (JEP 238 [3]) and the ability to compile to older > releases (JEP 247 [4]) might be useful here (you might know about these > features already). Haven't really explored this yet, it might be a way. Gotta see how Maven deals with this feature to allow us to create MRJARs in a reasonable manner. Matej > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/JDK-8171335 > [2] http://openjdk.java.net/jeps/181 > [3] http://openjdk.java.net/jeps/238 > [4] http://openjdk.java.net/jeps/247 > From Alan.Bateman at oracle.com Mon Apr 24 12:33:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Apr 2017 13:33:25 +0100 Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: <1247509897.320605.1493034092697.JavaMail.zimbra@redhat.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> <1247509897.320605.1493034092697.JavaMail.zimbra@redhat.com> Message-ID: <1b7d7363-4474-01a3-bfc6-69b5f746529f@oracle.com> On 24/04/2017 12:41, Matej Novotny wrote: > : > Not really sure, but it is certainly not one under our control. > I suppose these "basic" classes will be loaded by, say, Wildfly as soon as you bootstrap it, before any CDI-enabled deployment takes place. The reason I picked out java.lang.Integer from your other mail is because it's defined to the boot loader and so would be interesting to know the defining loader for the proxy class generated for java.lang.Integer. > : > I think it's more or less what we did/are doing - we spin the proxies either into the same package the came from or to our own package/module. > But in order to avoid proxy name clash in the same package, we just took the original package and replaced the prefix 'java' with something like 'org.jboss.weld.proxies'. > This effectively means that 'java.util.Map' proxy will end up as something like 'org.jboss.weld.proxies.util.Map$Proxy'. > Obviously, 'org.jboss.weld.proxies.util' did not exist beforehand and putting everything into one existing package using Lookup is bound to blow up very quickly. > So there is basically no way to achieve this with JDK 9? If you can find the defining loader of org.jboss.weld.proxies.util.Map$Proxy then I think it would be useful to this discussion. If the defining loader is your own implementation then there be no issue invoking that class loader's defineClass (from the right context of course). -Alan From forax at univ-mlv.fr Mon Apr 24 13:24:40 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 24 Apr 2017 15:24:40 +0200 (CEST) Subject: setAccessible() alternative with Jigsaw - feedback on Lookup In-Reply-To: <1247509897.320605.1493034092697.JavaMail.zimbra@redhat.com> References: <1589159853.9782995.1490967962632.JavaMail.zimbra@redhat.com> <13842815.17309396.1492670584486.JavaMail.zimbra@redhat.com> <43fc2dae-606c-f867-ed85-3bde33b96bdc@oracle.com> <1247509897.320605.1493034092697.JavaMail.zimbra@redhat.com> Message-ID: <1370815690.337252.1493040280876.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Matej Novotny" > Hi, > > thanks for your time. Comments inline. > [...] >> >> If you are looking to define a class in a new runtime package and the >> class loader that is not your implementation then you are out of luck. >> Lookup is designed for doing computations in the context of an existing >> class. There is a note in the archives here from John Rose about >> extending the lookup API for cases like this but it would come with a >> lot of complexity. Also there isn't any notion of adding a package to a >> named module at this time. When java.lang.reflect.Proxy spins proxy >> classes then it doesn't add packages to named modules, it instead spins >> the proxy classes into its own module (something you could do too, >> assuming the classes that you are proxying are accessible). > > I think it's more or less what we did/are doing - we spin the proxies either > into the same package the came from or to our own package/module. > But in order to avoid proxy name clash in the same package, we just took the > original package and replaced the prefix 'java' with something like > 'org.jboss.weld.proxies'. > This effectively means that 'java.util.Map' proxy will end up as something like > 'org.jboss.weld.proxies.util.Map$Proxy'. > Obviously, 'org.jboss.weld.proxies.util' did not exist beforehand and putting > everything into one existing package using Lookup is bound to blow up very > quickly. > So there is basically no way to achieve this with JDK 9? You can spin one module per package, by creating one ModuleLayer per package, not unlike j.l.r.Proxy does. R?mi > >> >> > >> > 3) All in all the changes carried along a lot of complexity compared to >> > plain old ClassLoader.defineClass >> > We need to create A LOT of Lookups (might present performance overhead, >> > haven't tested yet). >> > Extra care needs to be given to the packages for Lookup not to blow up >> > while we in fact don't really care where the proxy lands as long as it is >> > usable. >> Can you expand on the "don't really care" comment? Do you mean that you >> don't care about either the defining loader or runtime package? > > I was referring to the runtime package. > What we need is to ensure that there won't be a clash - there can be two classes > with same name and different packages, which, for some reason, will have to > land in a package created by us. > If this happened and we were using a fixed existing package to place them in, it > would blow up. > So what I meant was that with JDK 8 I don't need to care for this, I just use > prefix and I am done with it. In JDK 9, this seems like quite an obstacle. > >> >> > >> > >> > Another nasty thing is that the code of course needs to work with both, JDK >> > 9 and 8. >> > While it isn't impossible, it will add a not-so-nice reflection magic layer >> > to the mix. >> > >> Multi-release JARs (JEP 238 [3]) and the ability to compile to older >> releases (JEP 247 [4]) might be useful here (you might know about these >> features already). > > Haven't really explored this yet, it might be a way. > Gotta see how Maven deals with this feature to allow us to create MRJARs in a > reasonable manner. > > Matej > >> >> -Alan. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171335 >> [2] http://openjdk.java.net/jeps/181 >> [3] http://openjdk.java.net/jeps/238 >> [4] http://openjdk.java.net/jeps/247 From sander.mak at luminis.eu Mon Apr 24 13:53:04 2017 From: sander.mak at luminis.eu (Sander Mak) Date: Mon, 24 Apr 2017 13:53:04 +0000 Subject: --permit-illegal-access and non-reflective access Message-ID: I was trying out the --permit-illegal-access flag with a simple class that uses an encapsulated type from the JDK by (non-reflectively) instantiating it in the main method: $ java Test Exception in thread "main" java.lang.IllegalAccessError: class Test (in unnamed module @0x7b3300e5) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x7b3300e5 at Test.main(Test.java:5) $ java --permit-illegal-access Test WARNING: --permit-illegal-access will be removed in the next major release What I expected to see was a warning message about sun.security.x509.X500Name during the second invocation of java. Then, after reading [0] again, I realized the warnings only pertain to reflective access. What's the idea behind this distinction? The Test class fails just as well with an IllegalAccessException without the --permit-illegal-access flag. Only, I don't get to see the problem when running with --permit-illegal-access unless the access is done reflectively. Is it because non-reflective uses can be found statically by jdeps, and are not 'worthy' of a warning? Just looking for the rationele here. It does mean fixing all warnings logged by --permit-illegal-access is not a guarantee there won't be IllegalAccessExceptions anymore afterwards. Sander [0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html From Alan.Bateman at oracle.com Mon Apr 24 14:17:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Apr 2017 15:17:03 +0100 Subject: --permit-illegal-access and non-reflective access In-Reply-To: References: Message-ID: <845a0fac-4404-df83-78d7-b2230e3d3f8b@oracle.com> On 24/04/2017 14:53, Sander Mak wrote: > : > > What's the idea behind this distinction? The Test class fails just as well with an IllegalAccessException without the --permit-illegal-access flag. Only, I don't get to see the problem when running with --permit-illegal-access unless the access is done reflectively. Is it because non-reflective uses can be found statically by jdeps, and are not 'worthy' of a warning? Just looking for the rationele here. It does mean fixing all warnings logged by --permit-illegal-access is not a guarantee there won't be IllegalAccessExceptions anymore afterwards. > Doing the equivalent in the VM for static references is deeply intrusive and would involve significant effort. It didn't seem worth it. As you noted, it's easy to run `jdeps` to find static references to internal APIs. So I think it's best to think of `jdeps` and `--permit-illegal-access` as complementary. Start out by using `jdeps` to scan the application and the libraries that is uses. Then do some test runs with `--permit-illegal-access` to locate code that is doing illegal access with core reflection. -Alan From mark.reinhold at oracle.com Mon Apr 24 16:14:13 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 24 Apr 2017 09:14:13 -0700 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: References: <20170403093500.721331054@eggemoggin.niobe.net> Message-ID: <20170424091413.372101903@eggemoggin.niobe.net> 2017/4/3 10:34:14 -0700, Stephen Colebourne : > On [1] the conclusion given the premise is not unreasonable. The file > name can be easily changed by a developer or build tool to match the > expected module name. However, it is the premise I strongly object to: > > "The fundamental problem here is that we're trying to infer a .. name..." > > Inferring a name (identifier) is generally a bad idea in any > programming context, but especially so in this one where it will be > baked into the compiled artifacts. Accepting that inferring a name is > a fundamentally bad idea leads to examination of alternatives to > automatic modules [3]. > > Such an examination yields an approach where a module only specifies > dependencies on proper modules, with some ability to express that its > dependencies are incomplete. This appears not to have been considered > despite being equivalent in aiding migration yet avoiding any need to > infer a name. The problem with any approach that allows you to give a stable name to what is otherwise an automatic module is that the API of that module is inherently unstable. If and when the module is completely modularized then its API will almost certainly change, which in turn will require incompatible changes to any previously-published fully-modularized modules that depend upon it. Further thoughts here: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000682.html - Mark From jay.a at outlook.in Mon Apr 24 16:14:31 2017 From: jay.a at outlook.in (Jayaprakash Artanareeswaran) Date: Mon, 24 Apr 2017 16:14:31 +0000 Subject: Java Platform Module System Message-ID: Hello everyone, The JLS makes references to the "Java Platform Module System" in several places but we are not sure where this is specified. The Eclipse JDT team has been making do with whatever informal documents we can get our hands on such as "State of the Module System", Javac etc. It would be really nice to get some update on this as this would give us the much needed confidence that we (JDT) are indeed going in the right direction. Regards, Jay From mark.reinhold at oracle.com Mon Apr 24 16:18:31 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 24 Apr 2017 09:18:31 -0700 Subject: Java Platform Module System In-Reply-To: References: Message-ID: <20170424091831.557135740@eggemoggin.niobe.net> 2017/4/24 9:14:31 -0700, jay.a at outlook.in: > The JLS makes references to the "Java Platform Module System" in > several places but we are not sure where this is specified. The > Eclipse JDT team has been making do with whatever informal documents > we can get our hands on such as "State of the Module System", Javac > etc. It would be really nice to get some update on this as this would > give us the much needed confidence that we (JDT) are indeed going in > the right direction. JSR 376 home page: http://openjdk.java.net/projects/jigsaw/spec/ Current draft specification, linked from that page: http://cr.openjdk.java.net/~mr/jigsaw/spec/ - Mark From brianf at infinity.nu Mon Apr 24 17:39:25 2017 From: brianf at infinity.nu (Brian Fox) Date: Mon, 24 Apr 2017 13:39:25 -0400 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: <20170424091413.372101903@eggemoggin.niobe.net> References: <20170403093500.721331054@eggemoggin.niobe.net> <20170424091413.372101903@eggemoggin.niobe.net> Message-ID: On Mon, Apr 24, 2017 at 12:14 PM, wrote: > The problem with any approach that allows you to give a stable name to > what is otherwise an automatic module is that the API of that module is > inherently unstable. If and when the module is completely modularized > then its API will almost certainly change, which in turn will require > incompatible changes to any previously-published fully-modularized > modules that depend upon it. > I don't quite follow, why does modularizing a module imply its public api will change? From mark.reinhold at oracle.com Mon Apr 24 18:54:18 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 24 Apr 2017 11:54:18 -0700 Subject: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames) In-Reply-To: References: <20170403093500.721331054@eggemoggin.niobe.net> <20170424091413.372101903@eggemoggin.niobe.net> Message-ID: <20170424115418.634239596@eggemoggin.niobe.net> 2017/4/24 10:39:25 -0700, Brian Fox : > On Mon, Apr 24, 2017 at 12:14 PM, mark.reinhold at oracle.com wrote: >> The problem with any approach that allows you to give a stable name to >> what is otherwise an automatic module is that the API of that module is >> inherently unstable. If and when the module is completely modularized >> then its API will almost certainly change, which in turn will require >> incompatible changes to any previously-published fully-modularized >> modules that depend upon it. > > I don't quite follow, why does modularizing a module imply its public api > will change? The effective API of a module is determined by the packages that it exports and, also, by the packages exported by the modules it depends upon, directly and indirectly, via `requires transitive` clauses. The effective API of an existing library that's used as an automatic module is inherently unstable in two ways: - When you modularize the library explicitly, with a `module-info.java` file, you'll have to decide which packages to export. Packages that are meant only for internal use should not be exported, but when your library was used as an automatic module those packages were exported. If you choose not to export those packages when you modularize then code in other modules that references types in those packages will break. - When you modularize the library explicitly you'll also have to decide which modules it requires transitively. This will almost certainly further reduce the number of packages accessible to modules that use your module, and perhaps dramatically so: When your library was an automatic module it transitively required every other automatic module observable at compile time or run time, thus making every package of every automatic module accessible to modules that use your module. Even worse, this set of packages depended upon the context in which the library was used; you can't compute it just by examining the library and its known dependencies. An explicit module that depends upon one or more modules that are automatic today is, itself, no more stable than those automatic modules. It could be broken when those automatic modules are modularized explicitly, and if it `requires transitive` an automatic module then any modules that depend upon it could be broken when that automatic module is modularized explicitly. If we define a way to give stable names to automatic modules, as the `Module-Name` manifest attribute would do, then that would tend to encourage the publication of named automatic modules and, further, the publication of explicit modules that depend upon them. All of these modules would rest on shaky ground, if not actual quicksand. If we encourage developers at large to take this approach then I worry that many will give up in frustration when they try to modularize their named automatic modules, later on, with explicit `module-info.java` files. We'd wind up, in the long run, with public repositories that contain lots of named automatic modules but few actual explicit modules, when what we want to see is lots of explicit modules. The best way to attain that long-term goal is to minimize the chances for pain and confusion along the way, and if that means a slower pace of migration then so be it. - Mark From alan.bateman at oracle.com Mon Apr 24 19:06:26 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 24 Apr 2017 19:06:26 +0000 Subject: hg: jigsaw/jake/jdk: Make it easy to validate the modules on the module path Message-ID: <201704241906.v3OJ6QSG024006@aojmv0008.oracle.com> Changeset: 12dd6436acea Author: alanb Date: 2017-04-24 20:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/12dd6436acea Make it easy to validate the modules on the module path ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/native/libjli/java.c From gunnar at hibernate.org Mon Apr 24 20:23:23 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 24 Apr 2017 22:23:23 +0200 Subject: Getting the automatic module name of non-modular JAR Message-ID: Hi, Given a non-modular JAR (e.g. represented as Path), what's the easiest way to obtain the automatic module name derived for this JAR? I found the following: Path nonModularJar = ...; String automaticModuleName = ModuleFinder.of( nonModularJar ) .findAll() .iterator() .next() .descriptor() .name(); Is this the best I can do? More generally speaking, is using ModuleFinder with a single path the only way to obtain a ModuleReference/ModuleDescriptor for a specific JAR? Thanks, --Gunnar From stephan.herrmann at berlin.de Tue Apr 25 00:22:50 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 25 Apr 2017 02:22:50 +0200 Subject: Java Platform Module System In-Reply-To: <20170424091831.557135740@eggemoggin.niobe.net> References: <20170424091831.557135740@eggemoggin.niobe.net> Message-ID: On 24.04.2017 18:18, mark.reinhold at oracle.com wrote: > 2017/4/24 9:14:31 -0700, jay.a at outlook.in: >> The JLS makes references to the "Java Platform Module System" in >> several places but we are not sure where this is specified. The >> Eclipse JDT team has been making do with whatever informal documents >> we can get