Re: Jigsaw prototype, take 2

On 09/06/2013 10:22 PM, Tim Boudreau wrote: Gregg, We've worked together and I respect your judgement. That said, I have to disagree pretty strongly with the idea of *not* enforcing that dependencies be a directed acyclic graph as the default. Fundamentally, if you are developing two things,

Re: Avoiding same-package conflicts

On 10/29/2015 05:59 AM, Martin Lehmann wrote: Hi all, I stumbled across the same "issue". that having multiple versions of the same library isn't a best practice to say the least. Full ACK. Bad practice. I disagree, actually. I think that this is a completely needless and artificial

Re: Jigsaw @ JavaOne 2015

We've been (with JBoss Modules and thus our various application server offerings) using module name conventions that match package names for several years, and the number of people who have actually been confused by it to my knowledge is exactly zero. The actual problem is probably quite

Re: Avoiding same-package conflicts

On 10/30/2015 04:12 AM, Martin Lehmann wrote: Hi David, hi all, thanks, David, for your response. Sure, reply is inline. Full ACK. Bad practice. I disagree, actually. I think that this is a completely needless and artificial restriction that arose from implementation decisions, not from

Re: Jigsaw EA feedback on running an internal app

On 09/12/2015 10:26 AM, Alan Bateman wrote: On 11/09/2015 16:52, Peter Levart wrote: Building the app with Maven doesn't work though. Maven compiler module doesn't seem to be able to use the javac compiler API correctly. Maven folks would have to look at it. I met Chris Newland today at an

Re: Is there really a jdk.proxy1 module?

Or better yet, to the module defining the proxy interface(s)... of course, then you must ensure that they all are from the same module. This is another area where having per-module class loaders is superior: the getProxyClass()/newProxyInstance() methods already expect a class loader for the

Re: Is there really a jdk.proxy1 module?

ader that is usually used is not the module class loader but one of its parent. Rémi - Mail original - De: "David M. Lloyd" <david.ll...@redhat.com> À: jigsaw-dev@openjdk.java.net Envoyé: Mardi 8 Décembre 2015 16:05:06 Objet: Re: Is there really a jdk.proxy1 module? O

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/02/2015 08:46 AM, Remi Forax wrote: - Mail original - De: "Alan Bateman" À: "Stephane Epardaud" , jigsaw-dev@openjdk.java.net Envoyé: Mercredi 2 Décembre 2015 14:56:00 Objet: Re: is ClassLoader.loadClass() supposed to work on module-info

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/02/2015 09:05 AM, Remi Forax wrote: - Mail original - De: "David M. Lloyd" <david.ll...@redhat.com> À: jigsaw-dev@openjdk.java.net Envoyé: Mercredi 2 Décembre 2015 15:52:56 Objet: Re: is ClassLoader.loadClass() supposed to work on module-info classes? On 12/

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 09:18 AM, Alan Bateman wrote: On 04/12/2015 12:59, David M. Lloyd wrote: So you're saying that if I have C depending on A, then update A or I split A and B in my distribution, I need to recompile C? I don't think that's a realistic proposition. Do I then have to recompile

Re: Feature complete?

On 12/04/2015 09:48 AM, Alan Bateman wrote: On 04/12/2015 13:50, Reinier Zwitserloot wrote: : Emphasis mine: "only"? "Just add some command line switches" is not exactly a nice solution. From personal experience, the vast majority of java users do not know how to add configure command line

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/04/2015 08:18 AM, Cédric Champeau wrote: Just a related question: Do you expect the class file format to change in JDK9 and for what features? If it is only for supporting the module-info.class then would something like the following be possible: javac -source 9 -target 8 -mp modlib

Re: The rationale for runtime modularization

On 12/03/2015 06:19 PM, mark.reinh...@oracle.com wrote: 2015/12/3 1:36 -0800, Rafael Winterhalter : I am writing this after looking into Jigsaw for about two months and after running my open-source libraries and several enterprise applications of my current employer using

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 12/03/2015 07:03 PM, Alex Buckley wrote: On 12/3/2015 4:47 AM, David M. Lloyd wrote: On 12/02/2015 04:49 PM, Alex Buckley wrote: Now we reach the disagreement. We don't think the module declaration will be as fluid as you do. Yes, frameworks and other tools will want to modify module

Re: Feature complete?

On 12/04/2015 03:24 PM, Paul Benedict wrote: On Fri, Dec 4, 2015 at 2:58 PM, David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> wrote: This is backwards though: instead of saying "these modules can have some elevated privilege", which BTW is

Re: the acyclic module graph

On 12/05/2015 11:16 AM, Jochen Theodorou wrote: Hi all, in the sadly few hours of my spare time these days I am trying to understand jigsaw better and I came across the condition that the module graph should be acyclic... which made me wonder... So Let us assume there is a module

Re: Feature complete?

This is backwards though: instead of saying "these modules can have some elevated privilege", which BTW is (in a way) the inverse of using a security manager to restrict permissions, doesn't it make more sense from a security POV to say "no modules have special access, however a module can

Re: Feature complete?

I would take that with a big grain of salt though, as a lot of the design reasoning in Jigsaw and presented there is self-justifying. For example: "Strong encapsulation is about being able to prevent access even if the accessing class and the target class are in the same class loader and

Re: Feature complete?

ec 1, 2015 at 8:54 AM, David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> wrote: This is something I hope to address in my alternative JDK module implementation. I feel that Jigsaw as it stands right now has too many practical problems to be a candidat

Re: Feature complete?

This is something I hope to address in my alternative JDK module implementation. I feel that Jigsaw as it stands right now has too many practical problems to be a candidate for JSR 376, and I'm hoping to either influence Jigsaw into a different state or move to an alternative design (like

Re: Unnamed module and duplicate package

I presume this wouldn't happen if the packages were sealed though, whether in Java 8 or earlier or under the unnamed module in Java 9. Right? On 03/09/2016 03:17 PM, Paul Benedict wrote: But isn't what your proposing a security issue? Let's say my package A is in the unnamed module and your

Re: Unnamed module and duplicate package

One case to consider is javax.transaction.xa, which is part of the JDK and also in the JTA API along with javax.transaction. On 03/09/2016 05:13 PM, Alex Buckley wrote: Paul, thank you for asking. The module system's treatment of the unnamed module vis-a-vis named modules is probably the

Re: Unnamed module and duplicate package

On 3/12/16 9:57 AM, Alan Bateman wrote: On 11/03/2016 15:30, David M. Lloyd wrote: What are the limiting factors? In my analysis the only problem that seemed close to insurmountable was the special natives that are used in the JDK but these only seem to be used from java.base. Does it all

Re: modulepath and classpath mixture

The only rational solution to this problem is to completely forego the JDK's capabilities and generate the file exclusively from the build tooling. I expect that at some point we'll end up with a series of tools which construct the exports list from annotated package-infos, the requires list

Re: Unnamed module and duplicate package

On 03/11/2016 09:23 AM, Alan Bateman wrote: On 11/03/2016 14:52, David M. Lloyd wrote: What about javax.transaction.xa? Ideally we won't just throw that into some unnamed module right? With it being a part of java.sql though, it's going to be pretty tough to separate out. Can

Re: Unnamed module and duplicate package

On 03/11/2016 09:23 AM, Alan Bateman wrote: On 11/03/2016 14:52, David M. Lloyd wrote: What about javax.transaction.xa? Ideally we won't just throw that into some unnamed module right? With it being a part of java.sql though, it's going to be pretty tough to separate out. Can

Re: Unnamed module and duplicate package

On 03/11/2016 04:42 AM, Alan Bateman wrote: On 11/03/2016 10:04, Neil Bartlett wrote: : Whatever the motivation, I referred to this package as “broken” because it has caused a great many problems for OSGi users. Applications that import the javax.transaction package may encounter

Re: Proxy classes and reflection (IllegalAccessException)

Having the proxy class be public in most circumstances is a 15-plus-year-old contract. You can't justify breaking it out of the blue by saying "well it's deprecated now". Deprecating this method is fine, but you can't break it at the same time. There are two problems here, and they're both

Re: modulepath and classpath mixture

On 03/22/2016 07:06 AM, Peter Levart wrote: On 02/24/2016 08:30 PM, Robert Scholte wrote: On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman wrote: On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has

Re: Need help testing the EA builds

On 03/02/2016 09:00 AM, Alan Bateman wrote: We are starting to think through how to bring the module system that is the monster patch in jigsaw/jake forest into the JDK 9 main line. Isn't there any way to break it up into functional sections or stages that can be individually reviewed? --

Re: Mutable modules

On 05/18/2016 12:36 PM, Alan Bateman wrote: On 18/05/2016 17:13, David M. Lloyd wrote: At present, you can remove a module or a bundle even if existing dependent module classes are statically referring to their contents. It'll work fine as long as those classes haven't been loaded yet. So

Re: Mutable modules

On 05/20/2016 09:12 AM, Alan Bateman wrote: On 18/05/2016 22:47, David M. Lloyd wrote: I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. I don't t

Re: module-info.java just causes problems

On 05/11/2016 07:39 AM, Alan Bateman wrote: On 11/05/2016 08:45, Gunnar Morling wrote: : Assuming a developer needs to change the module requirements of one of the modules they use, this means - as far as I understand the current design - they need to get the source of the module's

Re: module-info.java just causes problems

On 05/11/2016 08:15 AM, Alan Bateman wrote: On 11/05/2016 13:52, David M. Lloyd wrote: In practice this happens a lot. A module's dependency graph depends just as much on the environment as it depends on the classes in the module (if not more so). Modules are merged and split, replaced

Re: module-info.java just causes problems

On 05/11/2016 09:21 AM, Stephane Epardaud wrote: I don't understand the problem with the module-info.java class. We also repackage jars to add module descriptors (for OSGi, Maven and JBoss Modules) and for Jigsaw we generate the `module-info.class` file when we need to repackage them. Between

Re: module-info.java just causes problems

to the module information before it gets applied by the JDK. Cheers, Paul On Thu, May 12, 2016 at 6:46 AM, David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> wrote: On 05/12/2016 02:28 AM, Alan Bateman wrote: On 11/05/2016 15:14, David M.

Re: Mutable modules

I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: Related to #MutableConfigurations, in order to support dynamically changing deployments for containers (including, I believe, OSGi-compliant

Re: Mutable modules

On 05/18/2016 10:35 AM, Alan Bateman wrote: On 18/05/2016 16:04, David M. Lloyd wrote: I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: Related to #MutableConfigurations, in order to support

Re: module-info.java just causes problems

On 05/12/2016 02:28 AM, Alan Bateman wrote: On 11/05/2016 15:14, David M. Lloyd wrote: We package several hundred JARs in our modular environment today, only some of which originate in-house. The dependency information for these modules is established not by the author of these JARs

module-info.java just causes problems

Tools like Maven and JUnit are yet still having a difficult time coping with the oddball module-info.java file. Can we just drop this thing and let the layer provide metadata for the module? This way of defining module metadata is clearly causing trouble. Reference: all previous arguments

Re: none of our software actually functions

On 05/04/2016 02:46 PM, Alan Bateman wrote: On 04/05/2016 19:33, David M. Lloyd wrote: Tools like Maven and JUnit are yet still having a difficult time coping with the oddball module-info.java file. Has been discussion on the JUnit tests about this? Aside from a few usability issues then I

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

On 07/14/2016 05:28 AM, Alan Bateman wrote: On 14/07/2016 11:16, Andrew Haley wrote: : OK. But "in the very long term" such a basic language change needs all stakeholders to be consulted. I agree (although it's not really a language change in that it's API way to suppress access checks

Re: Exporting - the wrong default?

On 07/27/2016 10:26 AM, Remi Forax wrote: - Mail original - De: "dalibor topic" À: jigsaw-dev@openjdk.java.net Envoyé: Mercredi 27 Juillet 2016 14:39:05 Objet: Re: Exporting - the wrong default? On 26.07.2016 18:42, Stephen Colebourne wrote: In many

Re: Exporting - the wrong default?

On 07/28/2016 07:33 AM, dalibor topic wrote: On 27.07.2016 17:37, Stephen Colebourne wrote: While the JDK cannot afford to compromise on security, many real-world systems can and do. Software is mostly a trade-off between security, quality, features, delivery date, design, resources... etc. As

Re: Exporting - the wrong default?

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

Re: Exporting - the wrong default?

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

Re: It's not too late for access control

On 07/12/2016 04:53 AM, Alan Bateman wrote: On 11/07/2016 15:21, David M. Lloyd wrote: The crux of this access control discussion is that, up until JDK 9, "public" meant "public". End of story. If you did not want something to be visible, you made it not public. Very s

Re: It's not too late for access control

On 07/13/2016 04:17 PM, mark.reinh...@oracle.com wrote: 2016/7/11 7:21:46 -0700, david.ll...@redhat.com: ... I propose, once again, that rather than changing the meaning of "public" to something unintuitive (and indeed counter to the definition of the actual word), we instead allow the

Re: It's not too late for access control

On 07/12/2016 04:00 AM, Remi Forax wrote: - Mail original - De: "David M. Lloyd" <david.ll...@redhat.com> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> Envoyé: Lundi 11 Juillet 2016 16:21:46 Objet: It's not too late for access control The crux o

Re: It's not too late for access control

On 07/12/2016 10:43 AM, John Rose wrote: On Jul 12, 2016, at 2:00 AM, Remi Forax > wrote: First, there is already in the Java ecosystem a notion of non-exported package, packages startings with com.sun or packages containing internal, it was just a

Re: It's not too late for access control

On 07/12/2016 11:07 AM, John Rose wrote: On Jul 12, 2016, at 9:00 AM, John Rose wrote: lurk mode P.S. I forgot one more point: As JVM/JIT guy I find the prospect of sealing packages very appealing. Maybe it's a false promise, but it would be a home run if we could

Re: It's not too late for access control

Not commenting on the entire piece here, just one bit... On 07/12/2016 11:00 AM, John Rose wrote: On Jul 12, 2016, at 8:01 AM, Paul Benedict > wrote: This makes great sense to me. Why? Because when I develop a library, I really don't see any

Re: It's not too late for access control

On 07/12/2016 03:25 PM, Alan Bateman wrote: On 12/07/2016 18:31, Sanne Grinovero wrote: : As a maintainer and contributor to several popular Java open source libraries my experience is that in practice very few existing libraries will "just work" in Java 9 out of the box: people will have to

Proposal: #DefaultModule

I propose that the concept of "unnamed module" be dropped in favor of "default module". The main difference is that the class loader (or module finder or layer configuration or someone else) would be allowed to (but not required to) assign a free-form name and version string to this module.

Re: Proposal: #DefaultModule

Sent from my Samsung device. Original message ---- From: David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> Sent: 07/07/2016 03:40:22 am To: Paul Benedict <pbened...@apache.org <mailto:pbened...@apache.org>> Cc: jig

Re: Proposal: #DefaultModule

ibutes. Cheers, Paul On Wed, Jul 6, 2016 at 12:22 PM, David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> wrote: No, the intent is that default modules are still outside of resolution altogether. Being unnamed isn't what puts the module outside the

Re: Proposal: #DefaultModule

operty and use name that refers to the concept said an old professor of me. Rémi - Mail original - > De: "David M. Lloyd" <david.ll...@redhat.com <mailto:david.ll...@redhat.com>> > À:jpms-spec-expe...@openjdk.java.net <mailto:jpms-spec-expe

It's not too late for access control

The crux of this access control discussion is that, up until JDK 9, "public" meant "public". End of story. If you did not want something to be visible, you made it not public. Very simple and very clear. The word "public" literally means "accessible to all" after all; that's why the term

Re: hg: jigsaw/jake/jdk: Add AccessibleObject::canAccess and trySetAccessible

I don't recall any corresponding discussion of this, but the change looks like a good idea to me. On 02/04/2017 05:41 PM, mandy.ch...@oracle.com wrote: Changeset: 335657c73d0b Author:mchung Date: 2017-02-04 15:41 -0800 URL:

Re: Automatic module names

On 02/06/2017 12:51 PM, Alan Bateman wrote: On 06/02/2017 18:25, David M. Lloyd wrote: I don't think there is really a substantial increase in risk between manually modularizing a library and relying on automatic modules. If several projects take on the responsibility to modularize a library

Re: Automatic module names

On 02/03/2017 11:42 AM, Alan Bateman wrote: On 03/02/2017 16:42, David M. Lloyd wrote: : Sure, but the set of JARs you can't rewrite is really pretty spare. I've no doubt that many people would be uncomfortable taking responsibility to modularize a component that they don't maintain or have

Re: Automatic module names

I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. On 02/03/2017 05:44 AM, Robert Scholte wrote: Hi Nicolai, let's consider that my project depends on the following

Re: Automatic module names

On 02/03/2017 08:43 AM, Andrew Dinn wrote: On 03/02/17 14:29, David M. Lloyd wrote: I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. I don't think this is thinking about

Re: Automatic module names

On 02/03/2017 09:40 AM, Alan Bateman wrote: On 03/02/2017 11:44, Robert Scholte wrote: Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module

Re: Automatic module names

So far I haven't commented on automatic modules because while I don't see them as useful, I also didn't see them as harmful. However this keeps popping up, so, see inline comments. On 01/27/2017 08:11 AM, Stephen Colebourne wrote: [...] The issue is clear. If I write this: module

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

On 02/13/2017 11:30 AM, fo...@univ-mlv.fr wrote: - even as a temporary workaround, it's really weird to have to require a module named java.xml.ws.annotation for that. It does not really make sense from an end user perspective. the module name reflect the fact that it's a part of jax-ws and

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

On 02/14/2017 05:52 PM, mark.reinh...@oracle.com wrote: 2017/2/13 9:17:47 -0800, Guillaume Smet : On Mon, Feb 13, 2017 at 6:10 PM, alan.bate...@oracle.com wrote: On 13/02/2017 16:58, Guillaume Smet wrote: On Mon, Feb 13, 2017 at 5:12 PM, alan.bate...@oracle.com wrote:

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

On 02/13/2017 08:49 AM, Alan Bateman wrote: On 13/02/2017 14:32, David M. Lloyd wrote: I think this is an error. It makes more sense to have the javax.annotation package exist in its own module. If the long-idle JSR 250 and specifications like it are really a concern, then this module should

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

I think this is an error. It makes more sense to have the javax.annotation package exist in its own module. If the long-idle JSR 250 and specifications like it are really a concern, then this module should follow the pattern of all other such modules and be upgradeable. Note that until

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

On 02/13/2017 08:58 AM, David M. Lloyd wrote: On 02/13/2017 08:49 AM, Alan Bateman wrote: On 13/02/2017 14:32, David M. Lloyd wrote: I think this is an error. It makes more sense to have the javax.annotation package exist in its own module. If the long-idle JSR 250 and specifications like

Re: Multiple versions of a non-exported dependency

There are two dimensions to the version range issue: build reproducibility and future-proofing. In the former category, single versions are generally used for build because that ensures that the build will not change over time as new versions of things become available. In other words, I

Re: Multiple versions of a non-exported dependency

It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like this are going to come up a lot otherwise; let's consider making that change. On 08/31/2016 07:45

Re: Multiple versions of a non-exported dependency

On 09/01/2016 08:59 AM, Alan Bateman wrote: On 01/09/2016 13:29, David M. Lloyd wrote: It seems like there is no good reason why the application modules aren't loaded with classloader-per-module now. The platform stuff could all be in one, but the application stuff? Problems like

Re: Using non-parallel custom class loaders for Layer configurations

On 09/09/2016 11:26 AM, Alan Bateman wrote: On 08/09/2016 23:29, David M. Lloyd wrote: Is it not necessary that any class loader in use by a Layer must be parallel-capable? Otherwise it seems like deadlocks could occur in certain situations when there are references that are cyclic

Re: Using non-parallel custom class loaders for Layer configurations

On 09/08/2016 06:48 PM, Mandy Chung wrote: On Sep 8, 2016, at 3:29 PM, David M. Lloyd <david.ll...@redhat.com> wrote: Would it be possible to include a method like this (pretty old patch I had laying around): diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java b/j

Using non-parallel custom class loaders for Layer configurations

Is it not necessary that any class loader in use by a Layer must be parallel-capable? Otherwise it seems like deadlocks could occur in certain situations when there are references that are cyclic with respect to class loaders mapped by the mapping function. On that note, there is in fact no

Re: Using non-parallel custom class loaders for Layer configurations

On 09/09/2016 02:05 PM, Mandy Chung wrote: On Sep 9, 2016, at 8:44 AM, David M. Lloyd <david.ll...@redhat.com> wrote: On 09/08/2016 06:48 PM, Mandy Chung wrote: On Sep 8, 2016, at 3:29 PM, David M. Lloyd <david.ll...@redhat.com> wrote: Would it be possible to include a

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 09/28/2016 07:01 AM, Alan Bateman wrote: On 28/09/2016 10:37, Gunnar Morling wrote: : I don't think that is what those folks asking about using the SM had in mind. Rather, the idea would be - IIUC - to grant code in module B (say an ORM tool) reflective access to non-exported (and of

Re: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

On 09/21/2016 12:50 AM, Jochen Theodorou wrote: On 12.09.2016 17:08, Mark Reinhold wrote: Issue summary - #ReflectiveAccessToNonExportedTypes --- Some kinds of framework libraries require reflective access to members of the non-exported types of other modules; examples

Alternatives and fixes to #ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation proposals

in various areas, and to cover what our minimum requirements are in each area. On 09/16/2016 10:30 AM, David M. Lloyd wrote: After a fairly detailed review of this proposal, we have determined that it is not acceptable to Red Hat in its present form. I will list the primary problems here

Revisiting JDK-8161269

Hi Alan, In JDK-8161269 you said [1] that the "null" class loader has never been specified to contain all Java SE types, using this as a justification to reject this issue as "Not an Issue", regardless of the compatibility impact (particularly the common case of a class loader with a null

Re: Revisiting JDK-8161269

On 09/16/2016 10:30 AM, Alan Bateman wrote: On 16/09/2016 07:21, David M. Lloyd wrote: Hi Alan, In JDK-8161269 you said [1] that the "null" class loader has never been specified to contain all Java SE types, using this as a justification to reject this issue as "Not an Iss

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html On 21 September 2016 at 17:39, David M. Lloyd <david.ll...@redhat.com> wrote: In our internal discussion of the proposal for #ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of various behaviors and have co

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Hi all, I've been requested to ask if the OpenJDK development team have had a chance to review this email, and when we might expect a response. Thanks! On 09/21/2016 11:39 AM, David M. Lloyd wrote: In our internal discussion of the proposal for #ReflectiveAccessToNonExportedTypes, we

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

On 09/28/2016 04:37 AM, Gunnar Morling wrote: If I'm compiling a class A that has a reference to a member in type B then do you really want the compiler calling into a security manager to ask if this access is allowed? I don't think that is what those folks asking about using the SM had in

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

to successfully link. Of course that's just one idea to illustrate that the requirement can be addressed; it's not a proposal. 2016-09-27 16:30 GMT+02:00 David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@redhat.com>>: Hi Stephen, I just want to point out that this isn't a

Re: Sharing experiences with the latest EA build // #ReflectiveAccessToNonExportedTypes #ResourceEncapsulation

On 10/03/2016 10:15 AM, Rafael Winterhalter wrote: [...] However, for the adoption process, I think it is crucial that non-modularized code behaves as it did before, i.e. that non-modularized code shows the same behavior when its run on a Java 9 VM. I agree with the sentiment here however I

Solving #ConcealedPackageConflicts

By my analysis, the only possible and useful solution for #ConcealedPackageConflicts, other than rewriting how class loaders work, is to map non-automatic application (i.e. non-JDK) modules in the default layer each to their own class loader. This also potentially solves (or provides to means

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/26/2016 10:39 AM, Alan Bateman wrote: On 26/10/2016 16:28, David M. Lloyd wrote: : Some background is in order I guess. I've been reworking a couple of our projects to support both Java 9 and Java 8, using MR JARs and also without MR JARs. In the MR JAR case it's been easiest (so far

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/26/2016 08:52 AM, Alan Bateman wrote: On 26/10/2016 14:28, David M. Lloyd wrote: I am not a reviewer. I have a question though: Does this mean that you have to establish the name of your class loader in the constructor? Yes, it's named at creation time. The VM uses the name when

Re: uses is useless ?

On 11/16/2016 04:44 AM, Alan Bateman wrote: On 16/11/2016 10:25, fo...@univ-mlv.fr wrote: : The whole point of uses is to enable a kind of static analysis on the service dependencies, if 'uses' is not required, if you can easily bypass it or it doesn't provide useful information, then it

Re: uses is useless ?

On 11/16/2016 08:06 AM, Alan Bateman wrote: On 16/11/2016 14:00, David M. Lloyd wrote: That's really a usability regression though, isn't it? In the past, I could always use ServiceLoader with a ClassLoader argument to specify on whose behalf I'm loading. In fact we do this quite a lot

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

I just want to point out the two obvious (closely related) major problems with this approach which prevent it from being a practical replacement for setAcceptable, lest they are forgotten/ignored in the excitement around the new ideas: 1. It requires the target class to be initialized 2. It

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

On 11/01/2016 09:23 AM, John Rose wrote: On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote: Can we clarify "privileged code"? Privileged like in a SecurityManager in a PrivilegedAction for example, for privileged like only jdk internal code? Just to see it black on

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

On 11/01/2016 10:09 AM, Andrew Dinn wrote: On 01/11/16 14:39, David M. Lloyd wrote: On 11/01/2016 09:23 AM, John Rose wrote: On Nov 1, 2016, at 10:22 AM, Jochen Theodorou <blackd...@gmx.org> wrote: Can we clarify "privileged code"? Privileged like in a SecurityManager in a

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

On 11/01/2016 11:02 AM, Andrew Dinn wrote: On 01/11/16 15:35, David M. Lloyd wrote: On 11/01/2016 10:09 AM, Andrew Dinn wrote: There is a very easy way to provide tightly controlled access to a framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. java.lang.[invoke].MethodHandles

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/27/2016 09:59 AM, Mandy Chung wrote: On Oct 27, 2016, at 7:30 AM, David M. Lloyd <david.ll...@redhat.com> wrote: It looks like if you have a class loader name but not a module (i.e. it's unnamed), you get output that looks like this: [...] at org.jboss.as.cont

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

It looks like if you have a class loader name but not a module (i.e. it's unnamed), you get output that looks like this: [...] at org.jboss.as.controller//org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:390) [...] In this case the

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/26/2016 10:43 AM, David M. Lloyd wrote: On 10/26/2016 10:39 AM, Alan Bateman wrote: On 26/10/2016 16:28, David M. Lloyd wrote: : Some background is in order I guess. I've been reworking a couple of our projects to support both Java 9 and Java 8, using MR JARs and also without MR JARs

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/25/2016 06:10 PM, Mandy Chung wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.00/ Specdiff: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/specdiff/overview-summary.html This is a long-standing RFE for adding support for class loader

  1   2   >