Re: Jigsaw @ JavaOne 2015

since it seems nobody mentioned it yet... is there sound on the youtube video? Because I seem not to have that. bye blackdrag On 27.10.2015 21:15, mark.reinh...@oracle.com wrote: 2015/10/23 7:39 -0700, mark.reinh...@oracle.com: FYI, Alan, Alex, Mandy, and I will present five sessions related

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

On 02.11.2015 11:24, Alan Bateman wrote: [...] Uwe Schindler has created a bug on this topic here: https://issues.apache.org/jira/browse/GROOVY-7587 It makes me wonder if Groovy has ever been used with a security manager as it seems to wrap or need access to all JDK-internal types. This

Re: Avoiding same-package conflicts

On 02.11.2015 22:03, Alex Buckley wrote: [...] The initial modularization of JavaFX had a similar pattern: more split packages than you would think, due to a "horizontal" module wanting to share packages with numerous "vertical" domain modules. There, the "horizontal" module was a 'builder'

Re: Avoiding same-package conflicts

I can second that by an example using Groovy. We have not yet taken steps to make jigsaw modules, but we quite some time ago we have split the code base in what would become eventually become modules in the future. Because of history this did mean to split packages. So we have a couple of jars

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

On 03.11.2015 16:03, Alan Bateman wrote: On 03/11/2015 13:41, Jochen Theodorou wrote: Well, what we currently do is fill a ClassInfo class (a kind of reflection cache from which we generate our meta class) with the all the members we can access. This is the non-private members from the parents

Re: Avoiding same-package conflicts

On 03.11.2015 22:28, Alex Buckley wrote: [...] groovy-compiler will obviously have a hard dependency on groovy-base, but you can avoid groovy-base having a hard dependency on groovy-compiler by using services. Of course this assumes a suitable split between the interface of your compiler and its

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

On 03.11.2015 13:06, Alan Bateman wrote: [...] Good to hear, so I'm guess you have to talk the hierarchy of the runtime time to find the type that is part of the API. With modules then could this look at the exportness? Well, what we currently do is fill a ClassInfo class (a kind of

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

Hi, Jochen here, not Rory, but Groovy maintainer ;) So for Groovy reporting on the mailing list is good, if you also want to discuss the bug a bit there. If you really only want to report it, then you can just write it in the bug tracker. Of course Gradle is Gradle and Groovy is Groovy bye

Re: Groovy with Jigsaw

Am 11.09.2015 10:16, schrieb Alan Bateman: On 11/09/2015 08:47, Cédric Champeau wrote: For what it's worth, the issue that triggered this conversation is the one reported by Uwe. For Groovy we have a chicken and egg problem for testing, because this change breaks Groovy, and Groovy uses Gradle

Re: Groovy with Jigsaw

Am 11.09.2015 11:33, schrieb Alan Bateman: On 11/09/2015 10:21, Jochen Theodorou wrote: the error in Guava is not a failed attempt, it is a VerifyError, because AccessibleObject#setAccessible is now final and com.google.common.reflect.Element overrides the method. As far as I have seen Guava

Re: Groovy with Jigsaw

Am 11.09.2015 13:00, schrieb Uwe Schindler: Just to conclude, there are 2 problems around setAccessible: First, it throws a new Exception type. This makes almost any Groovy script fail at some point, because it tries to add some meta class on the scripting level, and this call setAccessible

Re: Groovy with Jigsaw

Am 11.09.2015 14:29, schrieb Alan Bateman: [...] Supporting dynamic languages and creating dynamic modules is very much an advanced topic at this time and there isn't support in the exported API for this. There is of course low-level support in the implementation and you'll find that Proxy and a

Re: Groovy with Jigsaw

Am 11.09.2015 14:47, schrieb Alan Bateman: [...] It's always been possible to configure the system class loader to be something else. So I'm curious what you do if it is a URLClassLoader, are you just looking for the class path? Then it would not work. But since the cases for @Grab have not

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

since the world does not only consist of java and javac and since there are many more bytecode files producing languages out there, I expect multiple such tools working on the bytecode plus language based tools, for those that want to support strong encapsulation at runtime. > Gesendet:

Aw: Re: The rationale for runtime modularization

> Gesendet: Freitag, 04. Dezember 2015 um 10:43 Uhr [...] > Here is however one point I disagree with: Maven does not offer > compile-time moduarization. Maven only assures that all dependencies are in > scope but it does not offer any means to cut down this dependency tree to > the set of

Re: the acyclic module graph

On 05.12.2015 18:38, Alan Bateman wrote: [...] The strict requirement is that there isn't a cycle in the dependency graph. This should be caught at compile-time, and at run-time when creating a configuration (think startup for now). ok, understood... I mixed up readability and dependency

using modules for caching

Hi, I was wondering if it will be possible to reuse module information between runs.. Currently I am collecting a lot of reflective information and use it to build a meta class system, which I then need to do method invocations, what fields are available and other things like that. Since that

Aw: Re: Feature complete?

> Gesendet: Dienstag, 01. Dezember 2015 um 16:24 Uhr > Von: "Alessio Stalla" > An: "Paul Benedict" > Cc: jigsaw-dev@openjdk.java.net > Betreff: Re: Feature complete? > [...] > Mind you, Spring is just an example, it is no different in that >

Re: question on exports to

On 01.06.2016 20:54, Peter Levart wrote: [...] Modules are part of language. Their exports / requires form a logical layer of additional access checks to what we had before (public/protected/package/private qualifiers on classes / members), but are treated the same way during runtime. Together

Re: RFR 8158736: Adapter class loaders can avoid creating named dynamic modules

On 06.06.2016 11:38, Sundararajan Athijegannathan wrote: [...] There is no need for named dynamic module - as there is nothing to encapsulate. Nashorn module can still selectively export packages to adapter module [ so that generated adapter class can access nashorn internals as needed]. does

Re: question on exports to

On 03.06.2016 22:20, Alex Buckley wrote: [...] Why don't you believe it? The "Under The Hood" presentation shows that layer creation makes the JVM aware of modules and their relationships. because I was thinking it will lower performance. Sure, benchmarks are often driven by code of

Re: question on exports to

On 01.06.2016 21:07, Alex Buckley wrote: Pretend you never heard of Module::addReads, it's for a use case that doesn't matter here (generation of bytecode with constant pool references to classes in other modules). good advice, that I will follow ;) Core Reflection is still bound by the

Re: question on exports to

On 04.06.2016 10:54, Peter Levart wrote: [...] Reflection code (Method.invoke, Field.[get|set], Constructor.newInstance) are @CallerSensitive methods. They "know" which class is calling them and perform access checks on behalf of the caller class that are "equivalent" (with mentioned

Re: creating proxies for interfaces with default methods

On 25.05.2016 20:08, Alex Buckley wrote: On 5/25/2016 12:22 AM, Jochen Theodorou wrote: so in earlier mails to this list I described a bit the problems I got into with the way Groovy produces proxies and handles default methods for those. Pointer? The most relevant thread I could find

Re: Implied readability: calling toString()

Ljava/lang/String; Sander On 27 May 2016, at 14:18, Jochen Theodorou <blackd...@gmx.org> wrote: On 27.05.2016 13:39, Sander Mak wrote: I'm running into the following compilation error (build 9-ea+116-2016-04-28-175027.javare.4913.nc): $ javac -modulesourcepath src -d out $(find . -name '*.

question on exports to

Hi all, Let me outline an example: named module GeneralInvoker, exports com.foo.gi. package com.foo.gi; public class TheInvoker{ public static Object invoke(Object receiver, String name, Object.. args) { Method m = receiver.getClass().getDeclaredMethod(name, toClass(args)); return

Re: question on exports to

On 31.05.2016 23:23, Alex Buckley wrote: On 5/31/2016 1:40 PM, Jochen Theodorou wrote: named module GeneralInvoker, exports com.foo.gi. package com.foo.gi; public class TheInvoker{ public static Object invoke(Object receiver, String name, Object.. args) { Method m = receiver.getClass

Re: creating proxies for interfaces with default methods

On 26.05.2016 09:03, Alan Bateman wrote: On 26/05/2016 07:04, Jochen Theodorou wrote: you cannot invoke the default method with reflection without implementation of the interface It sounds like you want to invoke the default method without a receiver. This does seem like sorcery for mlvm-dev

Re: question on exports to

On 01.06.2016 18:57, Peter Levart wrote: [...] Anyway... the groovy runtime would be almost something like java.base, but instead of being like a root element, this one will have to sit in the middle, because we depend on java as well. If that is true, then perhaps there is a simpler solution

Re: question on exports to

On 01.06.2016 02:37, Alex Buckley wrote: On 5/31/2016 5:09 PM, Jochen Theodorou wrote: On 31.05.2016 23:23, Alex Buckley wrote: On 5/31/2016 1:40 PM, Jochen Theodorou wrote: named module GeneralInvoker, exports com.foo.gi. package com.foo.gi; public class TheInvoker{ public static

Re: question on exports to

On 01.06.2016 14:43, Peter Levart wrote: [...] I also don't wish to cause further confusion, but I have a feeling that Jochen might have the following situation: - MyOtherLib contains classes and code that is using these classes (invoking their methods), but it wishes to call those methods

Re: Proxy classes and reflection (IllegalAccessException)

On 08.04.2016 13:58, Dawid Weiss wrote: [...] I modified this locally and removed the proxy cache. On subsequent run everything worked until I hit another problem, this time somewhere inside Groovy (reflective scan of all fields, very likely). java.lang.reflect.InaccessibleObjectException:

Re: running Groovy on JDK9

On 10.04.2016 21:44, Alan Bateman wrote: On 10/04/2016 19:29, Jochen Theodorou wrote: Hi all, today I had a few hours spare time and decided to invest that in trying to make the Groovy build compile and run tests. I am not trying to make a module on my own yet. for compilation to work my

running Groovy on JDK9

Hi all, today I had a few hours spare time and decided to invest that in trying to make the Groovy build compile and run tests. I am not trying to make a module on my own yet. for compilation to work my biggest problem was the direct usage of the javac compiler set through gradle. Which is

Re: running Groovy on JDK9

On 13.04.2016 14:10, Alan Bateman wrote: On 11/04/2016 16:57, Jochen Theodorou wrote: [...] org.codehaus.groovy.runtime.InterfaceConversionTest > testDefaultInterfaceMethodCallOnProxy FAILED java.lang.AssertionError: java.util.Comparator/2 at java.lang.invoke.MethodHand

Re: running Groovy on JDK9

On 10.04.2016 20:29, Jochen Theodorou wrote: [...] so another change in JDK9 makes tests failing and that is that I can no longer use ClassLoader#getResource to get an URL to a class. I remember reading about this change here. I can work around this by using a class, that does not originate

Re: running Groovy on JDK9

On 16.04.2016 19:16, Uwe Schindler wrote: Hi, You can still get a InputStream to bytecode of JDK-internal classes: if you get the module of the Class and then call getResourceAsStream from there. I walked that route for the forbidden-apis checker with reflection: This tool needs the bytecode

Re: running Groovy on JDK9

On 10.04.2016 20:29, Jochen Theodorou wrote: [...] Compile error during compilation with javac. /tmp/stubgentests77510877964035184621460309483098/bar/GroovyClass.java:12: error: package groovy.lang does not exist groovy.lang.GroovyObject { Looks like I actually found out why this happens

creating proxies for interfaces with default methods

Hi all, so in earlier mails to this list I described a bit the problems I got into with the way Groovy produces proxies and handles default methods for those. I would like to see how the correct solution to this is supposed to be so we have code like m.sortReversed{a,b -> a.value <=>

Re: usage of com.sun.tools.javac.Main

On 26.07.2016 09:11, Alan Bateman wrote: On 26/07/2016 07:58, Jochen Theodorou wrote: Hi all, when I tried the Groovy build jigsaw about 2 months ago the usage of com.sun.tools.javac.Main required me to make the module it was defined in to be accessible for the unnamed module. In the latest

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

On 14.07.2016 17:54, mark.reinh...@oracle.com wrote: 2016/7/14 5:35:25 -0700, Andrew Haley : At Red Hat we have many Java programmers. We also have many customers who are Java programmers. I am trying to persuade people to try out JDK 9 in order to give us the feedback we

Re: creating proxies for interfaces with default methods

On 23.07.2016 01:12, John Rose wrote: On May 27, 2016, at 1:16 AM, Alan Bateman > wrote: I don't think it's possible to create a Lookup via support API with just the PRIVATE lookup mode. It only seems to work because this code seems to

automatically downloading and enabling a jigsaw module

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

usage of com.sun.tools.javac.Main

Hi all, when I tried the Groovy build jigsaw about 2 months ago the usage of com.sun.tools.javac.Main required me to make the module it was defined in to be accessible for the unnamed module. In the latest version I tried this was not required anymore, which was I think JDK9 b128. Did I use

Re: Using modules in open source libraries

Groovy-core 44 exported and 25 maybe not exported On 26.07.2016 12:10, Stephen Colebourne wrote: There has been a lot of discussion about exporting packages - at compile time vs runtime and also the related problem of resources. I decided to take a look at some open source projects to see

Re: Issue with an automatic module

On 02.08.2016 15:19, Peter Levart wrote: Hi, Top-package (unnamed package) classes can not be referenced from classes in named packages anyway, so they usually represent just reflective entry points (such as Main class with main() method). In Java that is you mean. The JVM does not care about

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

On 14.07.2016 23:24, Alan Bateman wrote: On 14/07/2016 21:20, Jochen Theodorou wrote: What I would wish for at this moment is a document explaining the runtime aspects of the module system, including limitations reflection and normal method calls, as well as things like layers / runtime

Re: It's not too late for access control

On 15.07.2016 14:55, dalibor topic wrote: [...] A large part of what we do initially within the Quality Outreach effort is to help open source projects understand problems with their own code and practices that can adversely affect their ability to migrate to new JDK (update) releases as they

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

On 16.07.2016 00:03, Alex Buckley wrote: On 7/15/2016 6:21 AM, Jochen Theodorou wrote: I will give you an analysis of my situation so far: assuming the whole Groovy runtime is a module, and assuming I have other modules as well, and then I want to use a Groovy script at runtime, to access

Re: It's not too late for access control

On 16.07.2016 00:26, dalibor topic wrote: On 15.07.2016 15:39, Jochen Theodorou wrote: On 15.07.2016 14:55, dalibor topic wrote: [...] And if adopting the more correct practices requires them to make a huge breaking change? Maybe even getting rid of base principles? Commitment bias

Re: It's not too late for access control

On 13.07.2016 13:47, David M. Lloyd wrote: On 07/12/2016 03:25 PM, Alan Bateman wrote: On 12/07/2016 18:31, Sanne Grinovero wrote: [...] The issue that `public` no longer implies accessible is listed in JEP 261 (first item in the Risks and Assumption) but to be honest, has barely come up to

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09.07.2016 09:50, Alan Bateman wrote: [...] As regards "enjoy special power" then the only module that is known to the VM and module system is "java.base". The java.base module, as you probably know, is the core of the system. The java.base modules has the VM, java.lang.**, the implementation

A lot of questions around the configuration of a reflective style library

Hi, since Alan suggested to make a new thread for this (coming from "Feedback on proposal for #ReflectiveAccessToNonExportedTypes"), I will do just this. Let me rephrase the scenario from there a bit: I am trying to figure out the configuration and implications of the configuration and what

Re: A lot of questions around the configuration of a reflective style library

On 11.07.2016 09:46, Alan Bateman wrote: On 10/07/2016 11:04, Jochen Theodorou wrote: [...] Let me rephrase the scenario from there a bit: I am trying to figure out the configuration and implications of the configuration and what is different to from before using modules. Let us

Re: A broken setAccessible use case: enhanced diagnostics

On 26.01.2017 13:34, Russell Gold wrote: The Glassfish Primitive Function Library (PFL) contains an interesting use case for setAccessible: an enhanced object-to-string capability. Now, in an ideal world, this shouldn’t be needed, as each object provides an adequate toString() method; however,

Re: problem with Class#getResource

On 04.09.2016 22:05, Alan Bateman wrote: On 04/09/2016 14:35, Jochen Theodorou wrote: Hi all, I am using build 9-ea+132 I have a test, that does in the setup this.class.getResource("/jars"), to get a URL to the jars directory. The parent directory is on the classpath, but the ca

Re: problem with Class#getResource

On 05.09.2016 15:15, Jochen Theodorou wrote: On 04.09.2016 22:05, Alan Bateman wrote: On 04/09/2016 14:35, Jochen Theodorou wrote: Hi all, I am using build 9-ea+132 I have a test, that does in the setup this.class.getResource("/jars"), to get a URL to the jars directory.

Re: problem with Class#getResource

On 05.09.2016 17:00, Alan Bateman wrote: On 05/09/2016 15:50, Jochen Theodorou wrote: getResource did not get caller sensitive, right? The Class getResource/getResourceAsStream methods are but this is only relevant if you are invoke them on classes in named modules. This is why I was asking

problem with Class#getResource

Hi all, I am using build 9-ea+132 I have a test, that does in the setup this.class.getResource("/jars"), to get a URL to the jars directory. The parent directory is on the classpath, but the call returns null... This code is not run in a named module. Can anyone tell me why that returns

Re: problem with Class#getResource

hmmm... makes a sad sense to me. Though it seems to extend to ClassLoader#getResources(). That can´t be because of multi-release JAR files, can it? bye Jochen On 04.09.2016 17:32, Uwe Schindler wrote: Hi, I think this is related to multi-release JAR files because directories are no

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

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 include dependency injection (Guice), persistence

Re: Class names in java.lang.Module

On 26.09.2016 11:25, Neil Bartlett wrote: Module is already in the name: “java.lang.module.Configuration”. Wouldn’t “java.lang.module.ModuleConfiguration” look really odd? ah, you mean like List is enough for java.util.List and java.awt.List? Configuration is a really common name in

Re: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

On 02.10.2016 02:25, Malachi de Ælfweald wrote: With build 125, Gradle 3.1 works fine. With build 138, I have not yet figured out how to get it running. The Gradle guys had been very proud of their "we support jdk9" story, but #AwkwardStrongEncapsulation really destroyed that for them... for

Re: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

On 02.10.2016 09:53, Alan Bateman wrote: On 02/10/2016 01:25, Malachi de Ælfweald wrote: : This appears to come from a setAccessible from inside getEnv https://github.com/adammurdoch/native-platform/blob/master/src/main/java/net/rubygrapefruit/platform/internal/WrapperProcess.java#L113

Re: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

On 02.10.2016 12:12, Alan Bateman wrote: On 02/10/2016 10:20, Jochen Theodorou wrote: [...] All I can suggest is bring up the topic on core-libs-dev. I don't wish to get into the discussion here on whether it's a good idea or not to add such a method. Also with Project Panama looking good

Re: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

On 02.10.2016 11:42, Alan Bateman wrote: [...] In prior releases when updates to the Java Language would have required to IDEs and some tools but wouldn't have wide impact on tools. This is the reason for early access releases and the ongoing outreach to create awkward of issues and impact. it

Re: JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)

On 02.10.2016 14:43, Claes Redestad wrote: On 2016-10-02 14:26, Jochen Theodorou wrote: Do you know anything about the ClassLoader::getPackages issue? Is this a case where the (new) public getDefinedPackages returns the Packages that Gradle is looking for? hmm... if I look at https

Re: The split package problem

On 05.11.2016 13:56, Alan Bateman wrote: On 05/11/2016 10:29, Jochen Theodorou wrote: On 05.11.2016 08:39, Alan Bateman wrote: The application module reads other modules rather than layers, in this case it results in the application module reading C, B-1, D, and B-2 (assuming

Re: The split package problem

On 05.11.2016 08:39, Alan Bateman wrote: On 04/11/2016 16:50, Jochen Theodorou wrote: : Attempting to do this with multiple configuration + layers isn't going to help, it's just not safe, and you'll get the same exception. One layer with B-1 and C and another with B-2 and D and my

Re: Few questions

On 26.11.2016 12:53, Michał Zegan wrote: I know that osgi sits on top of jigsaw, but osgi was created when jigsaw did not exist, so it is itself a module system for java that does not need jigsaw. So then it would probably look like a module system on top of another module system... seems weird

Re: Few questions

On 26.11.2016 18:29, Michał Zegan wrote: well... But jigsaw itself can become a foundation for such a higher level framework build directly on top of jigsaw that adds such dynamic capabilities? if you want more than jigsaw offers out of the box, you have add runtime capabilities and you can

Re: Few questions

On 25.11.2016 23:21, Michał Zegan wrote: Well, I specifically mean setAccessible usage between modules. If your code really requires setAccessible it is going to break with jigsaw. And there is no way to for example emulate that on java.base without using command line arguments intended only

Re: Can't call certain accessible methods using reflection

On 28.11.2016 12:23, Peter Levart wrote: [...] // Module m1: module m1 { exports pkg1; } package internal; public class InternalImpl { public void m() { System.out.println("m()"); } } package pkg1; public class Public extends internal.InternalImpl { } is it legal for

Re: modules and tests

On 24.11.2016 16:41, Alan Bateman wrote: [...] to Alan and Sander: setting command line arguments or using a build tool to fiddle them for you is exactly what we do not want here! We want fidelity between the compile time configuration and the runtime configuration. Having to play with -Xpatch

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

On 01.11.2016 15:04, John Rose wrote: On Nov 1, 2016, at 9:53 AM, David M. Lloyd wrote: 1. It requires the target class to be initialized 2. It requires the target class to proactively donate MethodHandles or a Lookup to the lookup class Both of these can be

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

I must say I am partially to the whole story. My main problem is code I do not have under control, but suddenly need "extended" rights for. If this comes from a another module I will have by default no chance of doing this anymore because of #AwkwardStrongEncapsulation. This proposal shows

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

On 01.11.2016 16:44, Alan Bateman wrote: On 01/11/2016 15:32, Jochen Theodorou wrote: : Well... it makes me ask the question: Does #AwkwardStrongEncapsulation impose additional limitations for the redefinition of already loaded classes? No but if the methods in the new class redefinition

Unsafe and AwkwardStrongEncapsulation

On 04.11.2016 00:32, mark.reinh...@oracle.com wrote: 2016/11/1 14:17:43 -0700, neil.bartl...@paremus.com: ... In scenarios where a module's author can't foresee the need for such access (e.g., intrusive serialization frameworks) then the framework's author must take more drastic measures

Re: The split package problem

On 04.11.2016 09:25, Remi Forax wrote: There are two issues with split packages, - if you have the same class in each part of the package, the behavior of your problem depend on the order in the classpath, i've experienced this kind of bugs with two different libraries requiring different

The split package problem

Hi all, I do often read about this "split package problem", but I never did see a proper explanation about why it matters to jigsaw so much that we do not allow it. Can somebody enlighten me? bye Jochen

Re: The split package problem

On 04.11.2016 10:33, Alan Bateman wrote: [...] This is all part of reliable configuration where you can prove correctness by construction. Alex's "Under the Hood" session from JavaOne 2016 [1] is a great resource for understanding the science. -Alan [1]

Re: The split package problem

On 04.11.2016 11:50, Andrew Dinn wrote: [...] - Modules stop you providing two versions of a package in the same layer, a problem for classpath deployment which, as Remi noted, can easily lead to you mixing classes from two different versions of a library. but sometimes you have to do

Re: The split package problem

On 04.11.2016 12:36, Sander Mak wrote: On 04 Nov 2016, at 12:06, Cédric Champeau wrote: It's a very big issue, typically all Gradle plugins written in Groovy would break. Gradle itself would break. There are things to mitigate that, like rewriting classes at load

Re: The split package problem

On 04.11.2016 15:29, Alan Bateman wrote: On 04/11/2016 13:22, Jochen Theodorou wrote: : well... assume you have an application and it requires the library A, which transitively requires B-1. the application also requires library C, which transitively requires B-2. B-1 and B-2

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09.12.2016 23:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no

Re: AccessbileObject setAccessible array version vs non-array version

On 10.12.2016 13:08, Alan Bateman wrote: On 10/12/2016 09:13, Jochen Theodorou wrote: Hi all, motivated by the recent "Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch" thead, I thought I ask... there is AcccessibleObject#setAccessible(boolean), whic

Re: Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

On 13.12.2016 23:17, Peter Levart wrote: [...] You might have access to a protected method, but you can not delegate that access to a 3rd party unless you make the Method object .setAccessible(true) and pass it to the 3rd party as a capability. (I recommend using MethodHandle(s) for such

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

: Jochen Theodorou [mailto:blackd...@gmx.org] Sent: Saturday, December 10, 2016 9:23 AM To: Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.net> Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch O

Re: Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

On 12.12.2016 20:56, Alex Buckley wrote: [...] The ability of protected members to be accessed from outside their package means they are essentially public members for the purposes of inheritance and reflection. So, setAccessible should work for protected members of exported packages. I know

Re: Suggestion: allow accessible reflection on protected methods of exported types.

On 10.01.2017 15:40, Andrew Dinn wrote: [...] That's possible because an agent can use its Instrumentation instance to 'export open' the MethodHandles package to a module of its own making and then create the Lookup from within that module. but that won't work for me in Groovy as a library.

Re: Suggestion: allow accessible reflection on protected methods of exported types.

On 09.01.2017 12:47, Andrew Dinn wrote: [...] If you carefully review discussion on the subject of this (slightly false) dichotomy between static and dynamic capabilities I think you will find that there has been a lot of explicit discussion. In my view, your summary of the status quo is at best

Re: MethodHandle performance

On 12.01.2017 15:23, Stephen Colebourne wrote: [...] The real problem however is performance. In my tests, I am seeing a MethodHandle approach being 2 to 3 times slower than a reflection approach for identical functionality, which is quite a significant degradation. (using Java 8 b122) just

Re: Services and Bindings - expected usage scenarios

On 30.11.2016 17:31, mark.reinh...@oracle.com wrote: [...] The SE Platform has ServiceLoader rather than a built-in DI mechanism because the former is more primitive and imposes less overhead, while the latter can be built on top of the former. (I don't really know, nor care, whether

Re: Services and Bindings - expected usage scenarios

I am not of the expert group, but I would like to give a partial answer. Let us think of a kind of plugin architecture. There is a public interface from your framework and there are other modules that are going to provide plugins by implementing that interface. Now assume the framework will

#CyclicDependences with ServiceLoader

Hi, for my understanding I would like to ask the following: Given: * Module A: uses service S1 and provides service S2 * Module B: uses service S2 and provides service S1 In my understanding this forms a cyclic dependency, but since this is not directly on the API level I am wondering if this

Re: #CyclicDependences with ServiceLoader

On 30.11.2016 10:16, Alan Bateman wrote: On 30/11/2016 08:53, Jochen Theodorou wrote: Hi, for my understanding I would like to ask the following: Given: * Module A: uses service S1 and provides service S2 * Module B: uses service S2 and provides service S1 In my understanding this forms

Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException

On 05.01.2017 21:07, Phil Race wrote: Sort of .. it depends whether you could use getDeclaredMethod instead. One question I have is, how would you update the code if you were given the instance "foo", and need to programmatically work out what is the correct super-type of Foo that exports the

Re: Suggestion: allow accessible reflection on protected methods of exported types.

On 29.12.2016 17:24, Rafael Winterhalter wrote: Hello everybody, I did another round of testing a recent build of Java 9 with some applications and framework that I work with or maintain. I ran into an issue that I consider rather severe and I want to make a suggestion on how to potentially

Re: Suggestion: allow accessible reflection on protected methods of exported types.

On 29.12.2016 18:24, Rafael Winterhalter wrote: Hei Jochen, thank you for your feedback. I must have missed your posting, I regularly fail to follow up on the things discussed on the mailing list and its not easy to seatch for topics, sorry for that. don´t worry, my complaints have not been

Re: Suggestion: allow accessible reflection on protected methods of exported types.

On 03.01.2017 18:04, David M. Lloyd wrote: [...] Here's an important point about adoption (these are my own observations, not the EG's or my employer's). One of the effects of the way Java is produced and its historical entrenchment is that no matter what happens, adoption is more or less

  1   2   >