Re: replacements for Unsafe

On 29.04.20 13:37, Remi Forax wrote: Hi Jochen, Per the Java spec, calling an empty static method of the inner class works. but it has to work for any arbitrary inner class. The Class.forName variant Kasper mentioned and I thought I tired already (but did not) works for me. Thanks bye

Re: replacements for Unsafe

On 29.04.20 13:39, Kasper Nielsen wrote: Hi Jochen, Is there anything stopping you for doing something like: try { Class.forName(innerClassName, true, initalizeClass.getClassLoader()); } catch (ClassNotFoundException e) { throw new ExceptionInInitializerError(e); // Should never

replacements for Unsafe

Hi, when jigsaw started there was a lot of talk about providing alternatives to what Unsafe offers. Today I am facing a problem I cannot solve anymore it seems with this. My problem is that I need to ensure the static block of an inner class has been executed before I do something, because the

Re: excluding transitive module

On 14.04.20 19:38, Alex Buckley wrote: [...] It's fine for Library1 to require SharedApi, and for Library2 to require SharedApiImpl, but if the exported packages overlap, then it's not fine for Project to require, indirectly, both SharedApi (via Library1) and SharedApiImpl (via Library2). That

Re: excluding transitive module

On 14.04.20 20:20, Remi Forax wrote: Hi Jochen, JPMS has no notion of of API and implementation of the same jar. It's a concept of your build tool and not something JPMS knows. The notion of compilation dependencies and runtime dependencies is not a concept of JPMS but a concept of your build

Re: excluding transitive module

On 14.04.20 11:09, Alan Bateman wrote: On 14/04/2020 09:24, Jochen Theodorou wrote: Hi all, I am wondering if there is a solution purely in the module-info for this: * Project requires Library1 and Library2 * SomeLibrary requires SharedApi * OtherLibrary requires SharedApiImpl The problem

excluding transitive module

Hi all, I am wondering if there is a solution purely in the module-info for this: * Project requires Library1 and Library2 * SomeLibrary requires SharedApi * OtherLibrary requires SharedApiImpl The problem is, that it will not compile because SharedApi and SharedApiImpl implement the same

Re: From Gradle 6.0-rc-2 Onward, gradle-api-{$version}.jar Is Now A Working Automatic Module

artifacts. Instead, it is generated lazily whenever you're developing a Gradle plugin. It lives at {$GRADLE_USER_HOME}/caches/6.0-rc-2/generated-gradle-jars/gradle-api-6.0-rc-2.jar. Sincere thanks to Cédric Champeau (melix), Sterling Greene (big-guy), Alan Bateman, Jochen Theodorou (blackdrag

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

On 12.10.19 00:41, Plugins wrote: While trying to find a solution to what I lovingly call Gradle's „Anti-JPMS“ issue [1], I discovered that even if that one particular issue is worked around, Gradle then, frustratingly, presents yet another hurdle to developing with the JPMS! Specifically, it

Re: Missing a wildcard open statement

On 14.01.19 17:18, Kasper Nielsen wrote: [...] So you need some kind of bootstrap class in every module that registers their Lookup object somehow. And, you also have to make sure that the bootstrap class does not make the Lookup object available to someone who should not have access to it. This

Re: module readability and exceptions in api

On 11.10.2018 19:57, Michał Zegan wrote: W dniu 11.10.2018 o 19:03, Jochen Theodorou pisze: On 10.10.2018 22:09, Michał Zegan wrote: [...] Oh when we are at it, a bit offtopic, can bytecode generation be replaced with method handle usage, or method handles are still not fast enough

Re: module readability and exceptions in api

On 10.10.2018 22:09, Michał Zegan wrote: [...] Oh when we are at it, a bit offtopic, can bytecode generation be replaced with method handle usage, or method handles are still not fast enough... or whatever? In my experience they are fast enough in many, if not most cases. But if you cannot do

Re: The baby and the bathwater (the return)

On 03.06.2018 21:53, Jonathan Gibbons wrote: Rémi, Generally, you should consider the runtime "module path" to be composed of three elements: the upgrade module path (--upgrade-module-path), the system modules (--system) and the user module path (--module-path). Depending on your

Re: ServiceLoader.load(Class, ClassLoader) does not load services exposed in modules and loaded by parent CL

Am 24.05.2018 um 19:33 schrieb Robert Scholte: [...] I can quote Alan: Rhino used to be the JS engine in older releases and that may have been in rt.jar and so loaded by the boot loader. When Nashorn replaced it (in JDK 8) then it was configured to be defined to the extension class loader

Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

On 03.04.2018 21:26, Henri Tremblay wrote: [...] For completeness, there are 4 ways to create a class without calling a constructor right now that I'm aware of: - Unsafe.allocateInstance which is supposed to go away at some point -

Re: modules and resources [ was: suggested document enhancement]

Am 02.03.2018 um 15:14 schrieb Bernard Amade: [...] 2) then what is the simplest way to deploy jars if clicking on a jar does not work anymore with modules? (scripts are platform dependent, so are Jlink images ,...and what happens with jars delivered through java webstart? should we

Re: Unsafe and JPMS

On 19.01.2018 19:31, Jeremy Manson wrote: [...] I generally agree with the principle of making real APIs to do what we need to do with Unsafe and migrating. My concern is not the removal of Unsafe, it's that the replacement won't be equivalent if it doesn't let you cross module boundaries. It

Re: How does one handle a java method which returns a non-public sub-type via reflection?

Am 18.01.2018 um 14:59 schrieb jeffrey kutcher: In this example, if I can access and execute the method vbox.getChildren().add() with no warnings or errors, which is accessing a non-public class In Java the static type is the important one. Of course you can do VBox vbox = //

Re: How does one handle a java method which returns a non-public sub-type via reflection?

Am 12.01.2018 um 22:49 schrieb Michał Zegan: well you rather know what getChildren returns, so you know what the returned object is, like generally. but as soon as the method you want to call is not on the statically declared type, nor within a set of known statically types you are having

Re: Module system and services directory in META-INF

On 27.12.2017 13:55, Alan Bateman wrote: On 27/12/2017 12:22, Cédric Champeau wrote: : 1. is the spec saying somewhere that no-one should ever use `META-INF/services` for something else than a service for `ServiceLoader`? If not, then ModuleFinder should probably be patched to recognize that

Re: Module system and services directory in META-INF

On 27.12.2017 13:22, Cédric Champeau wrote: [...] 1. is the spec saying somewhere that no-one should ever use `META-INF/services` for something else than a service for `ServiceLoader`? If not, then ModuleFinder should probably be patched to recognize that sometimes it's not the case. or the

Re: Module system and services directory in META-INF

On 26.12.2017 19:30, Jochen Theodorou wrote: hi all, Do all files in META-INF/services now have to be well formed according to the SPI strucutres in Java, or is it still valid to have other files in there as well? Before the module system it was no problem to have in there service decriptors

Module system and services directory in META-INF

hi all, Do all files in META-INF/services now have to be well formed according to the SPI strucutres in Java, or is it still valid to have other files in there as well? Before the module system it was no problem to have in there service decriptors, that are services, but do not use the

Should we create a compiler independent module tool?

Hi all, I am wondering for quite a while already if there should not be an javac (and possibly jdk9) independent tool for handling module. I think the idea for such a tool would be a bit against several decision that have been taken by the jigsaw project, so bare with me, I am trying to be

Re: trySetAccessible​

On 11.07.2017 12:11, Alan Bateman wrote: On 11/07/2017 10:16, Uwe Schindler wrote: [...] But now it is impossible for us to check, if something is not open by default. Module::getDescriptor will return the module descriptor for named modules. So in this case,

Re: trySetAccessible​

On 10.07.2017 12:06, Alan Bateman wrote: On 10/07/2017 10:59, Cédric Champeau wrote: This is not really practical. Basically it means that for every Gradle build script on earth, we would either choose to make them fail on JDK 9, or be bloated with warnings, that are actually handled. My

Re: trySetAccessible​

On 10.07.2017 10:07, Alan Bateman wrote: [...] Remember the purpose of the warnings is to make you or your users aware that the code will behave differently when access to JDK internals, or other so-called illegal access, is denied. In the past we did create a MetaClass, which contains all

Re: trySetAccessible​

On 10.07.2017 10:49, Cédric Champeau wrote: I second Uwe's comment here: I was surprised as well, I expected the semantics of `trySetAccessible` to be: "let me know if I can do this, respecting the semantics of modules, and if not, return false" I suspect canAccess is supposed to be used

trySetAccessible​

Hi all, since the JVM now prints warnings if you call setAccssible there was the advise to move to trySetAccessible​ to prvent these warnings. Now I am told those warnings appear here as well. Now my question would be about what the intended behaviour here is. in what mode is a

Re: Compiling with automatic modules

ok, thanks for the answers On 30.05.2017 23:43, Alex Buckley wrote: On 5/30/2017 2:08 PM, Jochen Theodorou wrote: On 30.05.2017 21:42, Alex Buckley wrote: On 5/26/2017 4:12 AM, Jochen Theodorou wrote: On 26.05.2017 01:04, Alex Buckley wrote: [...] The semantics of an observed JAR without

Re: Compiling with automatic modules

On 30.05.2017 21:42, Alex Buckley wrote: On 5/26/2017 4:12 AM, Jochen Theodorou wrote: On 26.05.2017 01:04, Alex Buckley wrote: [...] The semantics of an observed JAR without module-info.class are specified as part of JPMS resolution, and JLS 7.3 explicitly defers to that, so I believe

Re: Will split-packages ever be supported?

On 30.05.2017 16:21, Remi Forax wrote: [...] the big monolithic module is a good transition solution, i've done that with Aether to get access to Maven Central inside a fully modularized project, but it's like with automatic modules, it's just a temporary solution that you can use in your

Re: Will split-packages ever be supported?

On 30.05.2017 14:16, Alan Bateman wrote: On 30/05/2017 11:52, wzberger wrote: Our project has around 45 jar libraries and we currently using split-packages as simplest modularization concept. It's a desktop project with different kind of controls - all have in common that they are located in

Re: Compiling with automatic modules

On 26.05.2017 01:04, Alex Buckley wrote: [...] The semantics of an observed JAR without module-info.class are specified as part of JPMS resolution, and JLS 7.3 explicitly defers to that, so I believe it is clear how a compiler must behave when a modular compilation unit 'requires' a module that

Re: Proposal: Allow illegal reflective access by default in JDK 9

On 19.05.2017 15:38, Stephen Felts wrote: [...] Here are a few public ones. org.python.core.PyJavaClass - Jython com.sun.xml.bind.v2.runtime.reflect.opt.Injector – standalone jaxb com.sun.xml.ws.model.Injector – standalone jaxws net.sf.cglib.core.ReflectUtils$ - cglib Summarizing the use

Re: Some suggested patches and improvements

On 12.05.2017 18:49, Michael Nascimento wrote: #1-#3, IMHO, meet the needs of a niche who knows how to work around these issues using other ways (although inconvenient). I see me as someone needing this, and only having hints about how to make it work, that are based on annotation

Re: Need help implementing Java modules

On 09.05.2017 20:51, Ralph Goers wrote: I am attempting to modularize Log4j and am running into some trouble understanding how this can work. Log4j supports many Appenders, such as the FlumeAppender, KafkaAppender, CassandraAppender, and JPAAppender. Each of these use their respective libraries

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

On 25.04.2017 16:38, David M. Lloyd wrote: [...] I think that Maven- and Gradle-based tooling will appear to fill this need. The only correct solution (automatic modules or not) to modularizing arbitrary groups of artifacts will likely involve a separate assembly step which will inevitably

Re: feedback on --permit-illegal-access

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

what is undesired usage of the Java API?

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

Re: Better tools for adjusting to strong encapsulation

I will interpret your answer as that there is no additional per method invocation cost due to this. bye Jochen On 23.03.2017 09:12, Alan Bateman wrote: On 22/03/2017 21:07, Jochen Theodorou wrote: the warnings you are seeing are from the groovy runtime trying to determine - in a pre JDK9

Re: Better tools for adjusting to strong encapsulation

On 23.03.2017 01:16, Claes Redestad wrote: [...] the warnings you are seeing are from the groovy runtime trying to determine - in a pre JDK9 compatible way - if it is allowed to call the methods on Objecz. This happens in a first step by setAccessible on all methods using the array version,

Re: Better tools for adjusting to strong encapsulation

On 22.03.2017 12:23, Alan Bateman wrote: [...] I assume your interest is Groovy where there are indeed some warnings that look like Groovy is to blame. For example, I get the following with a trivial script containing`println "Hello world!"` : $ groovy hello.groovy NOTE: Picked up the following

Re: Better tools for adjusting to strong encapsulation

On 21.03.2017 15:48, mark.reinh...@oracle.com wrote: [...] When an illegal reflective access operation succeeds due to the use of the `--permit-illegal-access` option, or the use of an `--add-opens` or `--add-exports` option, then a warning message of the following form is written to the error

Re: Alternatives to automatic modules as a concept

On 20.03.2017 13:22, Ceki Gülcü wrote: [...] As for jigsaw module declarations, I expect it to be trivial assuming building under Java 9 but targeting Java 6. Is Java 6 still supported through a Java 9 build? I thought Java 7 will be the minimum. bye Jochen

Re: RFR: 8177086: java.lang.reflect.AccessibleObject::canAccess should share access cache with internal method ::checkAccess

frankly I would migrate more from the normal reflection API to the MethodHandles API instead of extending the Reflection API further, but I see the use case and reasoning here. thanks. bye Jochen On 20.03.2017 10:04, Alan Bateman wrote: On 19/03/2017 22:47, Jochen Theodorou wrote

Re: Instrumentation.redefineModule -- extraPackages argument?

On 11.03.2017 10:51, Alan Bateman wrote: On 10/03/2017 16:12, Michael Rasmussen wrote: : It might not be the most common scenario, but creating new packages during development is definitely not uncommon, and from my experience with JRebel and our customers, I can also say that we do see these

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: 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: 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 10.01.2017 12:28, Uwe Schindler wrote: Hi, just coming to the example you brought, because I exercised this a week ago: [...] For example... can you call Object#clone on Object using MethodHandles? I actually did not try this, but since the method is protected and in a module I would

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: 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 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

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 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: 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 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: 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: 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: 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: 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: #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

#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: 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

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: 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 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 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: 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: 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: 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: 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 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 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

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: 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

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 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: 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: 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 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 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 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: 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: 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: 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

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 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

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

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: 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

automatically downloading and enabling a jigsaw module

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

Re: 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: 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

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: 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

  1   2   >