Re: module annotations

Hi Michał, On 10/09/2018 09:11 PM, Alan Bateman wrote: On 09/10/2018 17:27, Michał Zegan wrote: Hello, I know that modules/module declarations can be annotated. Contrary to other elements from packages downwards, java has a way to read module descriptions before creating modules themselves (in

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

src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L123 [3] https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#ClassLoader-java.lang.String-java.lang.ClassLoader- On Thu, 24 May 2018 12:29:33 +0200, Alan Bateman wrote: On 23/05/2018 21:28, Peter Levart w

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

On 05/29/2018 10:20 PM, Alan Bateman wrote: On 29/05/2018 21:00, Jochen Theodorou wrote: 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

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

On 05/23/18 19:04, Alan Bateman wrote: On 23/05/2018 16:39, Peter Levart wrote: I thought so. This is what debugger told be me about TCCL (debugger calls .toString() on it by default): ClassRealm[plugin>com.marand.misc:misc-mojo-git:1.24, parent: jdk.internal.loader.ClassLoad

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

On 05/23/2018 05:39 PM, Peter Levart wrote: On 05/23/2018 05:08 PM, Alan Bateman wrote: On 23/05/2018 15:29, Peter Levart wrote: : Maven seems to load plugins in a child class loader of the "system" (application) class loader and also sets this class loader as thread con

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

On 05/23/2018 05:08 PM, Alan Bateman wrote: On 23/05/2018 15:29, Peter Levart wrote: : Maven seems to load plugins in a child class loader of the "system" (application) class loader and also sets this class loader as thread context class loader. ServiceLoader does no

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

Hi, I stumbled on a problem of a maven plugin that uses JDK's JavaScript engine and doesn't work when maven is run with JDK 9 or 10. The code in plugin to initialize the JavaScript engine is as follows:     jsEngine = new ScriptEngineManager().getEngineByName("JavaScript");

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

On 04/12/18 10:40, Alan Bateman wrote: On 11/04/2018 21:07, Rafael Winterhalter wrote: I do not think that this is possible. If the module containing the interface does not open a package, I cannot change the privileges of the main module such that I can resolve a method handle for invoking

Re: The baby and the bathwater

On 03/28/2018 11:18 AM, Stephen Colebourne wrote: On 28 March 2018 at 08:28, Peter Levart <peter.lev...@gmail.com> wrote: That's easy to enforce in runtime. Just take a "victim" class from your library that is most often needed when your library is being used (or take

Re: The baby and the bathwater

On 03/26/18 20:08, mark.reinh...@oracle.com wrote: Stephen closes with a specific suggestion: "There needs to be a way for a library author to insist that the modular jar file they are producing can only be run on the module-path (with any attempt to use it on the class-path

Re: Reflection: how does one access a protected member in a superclass reflectively?

lasses be accessible and when not (and yes, this part should belong to dynamically created subclasses, which also need adjustments to the module system). Best regards, ---rony On 22.01.2018 10:58, Peter Levart wrote: Hi Rony, On 01/18/2018 04:11 PM, Rony G. Flatscher wrote: On 18.01.2018 10:58

Re: Reflection: how does one access a protected member in a superclass reflectively?

mechanism of such authentication will be left as an exercise to the reader... Regards, Peter On 01/22/2018 02:04 PM, Peter Levart wrote: Hi Rony, On 01/22/2018 10:58 AM, Peter Levart wrote: The 2nd problem is not trivial as you want to access a protected member on behalf of some other

Re: Reflection: how does one access a protected member in a superclass reflectively?

On 01/22/2018 12:18 PM, Alan Bateman wrote: On 22/01/2018 09:58, Peter Levart wrote: : The 2nd problem is not trivial as you want to access a protected member on behalf of some other sub-class of the member's declaring class which is not cooperating (voluntarily handing you an instance

Re: Reflection: how does one access a protected member in a superclass reflectively?

Hi Rony, On 01/22/2018 10:58 AM, Peter Levart wrote: The 2nd problem is not trivial as you want to access a protected member on behalf of some other sub-class of the member's declaring class which is not cooperating (voluntarily handing you an instance of its Lookup object). This currently

Re: Reflection: how does one access a protected member in a superclass reflectively?

Hi Rony, On 01/18/2018 04:11 PM, Rony G. Flatscher wrote: On 18.01.2018 10:58, Alan Bateman wrote: On 17/01/2018 18:53, Rony G. Flatscher wrote: : Would you have concrete suggestions for this use-case, i.e. a framework that is not part of a module, but having a need to access public types

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

On 01/15/2018 11:02 PM, David Holmes wrote: I recall a very similar discussion in the past. You have to start with (public) statically known types, not with the dynamic type of the instances involved. In essence you have to reflectively emulate the method resolution process that occurs with

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

Hi Jeffrey, See my answer inline... On 01/12/18 19:26, jeffrey kutcher wrote: This is a good discussion but none of the suggestions satisfy the need I'm looking for.https://stackoverflow.com/questions/450807/how-do-i-make-the-method-return-type-generic The example code below shows

Re: Scanning multi version jars?

On 09/19/2017 09:34 AM, Alan Bateman wrote: On 19/09/2017 05:37, Greg Wilkins wrote: : Which raises an interesting point   with the multi versioned jar I have used as an example, which contains:     - org/example/Foo.class     - org/example/Foo$Bar.class     -

Re: Exporting a package with no Java sources

Hi Alexander, Have you tried to put a package-info.java into the exported package? It might work. Regards, Peter On Jun 30, 2017 6:42 PM, "Alexander Udalov" wrote: > I'm trying to figure out how to compile a mixed-language (in this > case, Java + Kotlin) JVM

Re: Incompatible change to java.lang.instrument.Instrumentation

with in the meantime (probably more projects could be hit by the problem) @Alan: Shall I file a bug? Thanks for the fast responses Sven On Fri, Jun 16, 2017 at 10:21 AM, Peter Levart <peter.lev...@gmail.com <mailto:peter.lev...@gmail.com>> wrote: Hi Sven, Just an idea.

Re: Incompatible change to java.lang.instrument.Instrumentation

Hi Sven, Just an idea... What NetBeans could probably do is to create a special sub-interface of java.lang.instrument.Instrumentation in its bootstrap jar file (the jar passed to class-path) and make that jar file MR jar with two versions of say org.netbeans.core.Instrumentation interfaces

Re: 8181087: Module system implementation refresh (6/2017 update)

Hi Alan, On 06/15/2017 09:34 AM, Alan Bateman wrote: 2453 reflectionFactory.getExecutableSharedParameterTypes(method), reflectionFactory should be accessed via getReflectionFactory(). I see Peter already comments on this. Thanks, it should be getReflectionFactory(). ...and I would also

Re: 8181087: Module system implementation refresh (6/2017 update)

Re-reading my post in the morning... On 06/14/2017 11:44 PM, Peter Levart wrote: In j.l.Module: There are two places in the same method that contain exactly the same fragment of code: 566 if (targets.contains(EVERYONE_MODULE) || targets.contains(other)) 567

Re: 8181087: Module system implementation refresh (6/2017 update)

Hi Alan, Looking just at changes in jdk part... On 06/14/2017 06:52 PM, Alan Bateman wrote: It's time to bring the changes accumulated in the jake forest into jdk9/dev. I'm hoping we are near the end of these updates and that we can close the jake forest soon. A summary of the changes that

Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9

n be suppressed completely via one or more `--add-opens` options. - The first proposal [1] opened every package in every explicit module, rather than just the packages in modules in the run-time image, to every unnamed module. Peter Levart pointed out [5] that this could

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

bers via reflection, they should perhaps be equivalent to open modules with all packages exported in addition. What do you think? Regards, Peter On 05/19/2017 04:27 PM, Peter Levart wrote: On 05/19/2017 04:05 PM, Alan Bateman wrote: On 19/05/2017 14:54, Peter Levart wrote: : Opening the whole

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

On 05/19/2017 04:05 PM, Alan Bateman wrote: On 19/05/2017 14:54, Peter Levart wrote: : Opening the whole JDK (--illegal-access=permit by default) means that all internal "public" APIs are made accessible if by chance someone can grab an instance of target object and/or a

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

Hi Alan, On 05/19/2017 02:28 PM, Alan Bateman wrote: On 19/05/2017 13:02, Peter Levart wrote: Ok, I can understand that such interpretation of "opens" is necessary for JDK 8 compatibility story. If something is "open" then it behaves exactly like in JDK 8 or before (ap

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

Hi Alan, On 05/19/2017 01:05 PM, Alan Bateman wrote: On 19/05/2017 10:48, Volker Simonis wrote: : From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P for some other module M2 it also, implicitly exports P to M2). The "big kill switch" in

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

On 05/19/2017 01:14 PM, Alan Bateman wrote: On 19/05/2017 11:58, Peter Levart wrote: : ...the example works (does not throw exception), but when run with: --add-opens java.base/jdk.internal.misc=ALL-UNNAMED ...the example still works OOOPS - this is a bug!!! This is definitely

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

On 05/19/2017 12:58 PM, Peter Levart wrote: It's easy. Take this example: public class Test { public static void main(String[] args) throws Exception { Object theUnsafe = Class.forName("jdk.internal.misc.Unsafe") .getMethod(

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

-add-exports but it also works with --add-opens. so long ... Nicolai On 19.05.2017 12:24, Peter Levart wrote: Hi Volker, On 05/19/2017 11:48 AM, Volker Simonis wrote: From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P fo

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

Hi Volker, On 05/19/2017 11:48 AM, Volker Simonis wrote: From my understanding, at run-time, "open" implicates "exports" (i.e. if a module M1 opens a package P for some other module M2 it also, implicitly exports P to M2). The "big kill switch" in both, its old and in the newly proposed form,

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

On 05/19/2017 01:17 AM, Nicolai Parlog wrote: With illegal access being permitted by default much fewer developers will be aware of the problem and much less pressure will be put on library and framework maintainers as well as on project management to invest into paying back this particular form

Re: How to load resources from base module

Hi Wolfgang, You are using instance method Class#getResource(String) which states in javadoc: /If this class is in a named Module then this method will attempt to find the resource *in the module*./ "this class" is the class represented by the Class object which is the receiver of the

What happened to ModuleClassLoader?

Re-sending since I don't see my previous post in the jigsaw-dev archives due to problems with mailing list in the past days... Forwarded Message Subject:What happened to ModuleClassLoader Date: Sun, 14 May 2017 23:11:37 +0200 From: Peter Levart <peter.

Re: An alternative to "restricted keywords"

On 05/12/2017 06:08 PM, Peter Levart wrote: For me, a restricted keyword is a keyword which is activated if you are at a position in the grammar where it can be recognized and because it's a keyword, it tooks over an identifier. by example for module m { if the next token is 'requires

Re: An alternative to "restricted keywords"

Hi Remi, On 05/12/2017 08:17 AM, Remi Forax wrote: [CC JPMS expert mailing list because, it's an important issue IMO] I've a counter proposition. I do not like your proposal because from the user point of view, '^' looks like a hack, it's not used anywhere else in the grammar. I agree that

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Hi Kevin, On 05/10/2017 03:19 AM, Kevin Rushforth wrote: inline Peter Levart wrote: Hi Kevin, On 05/02/2017 02:21 AM, Kevin Rushforth wrote: This review is being cross-posted to both openjfx-dev and jigsaw-dev. Please review the proposed fix for: https://bugs.openjdk.java.net/browse/JDK

Re: Problems with non-exported split packages (for resources/files)

Hi, Two modules can have packages with same name if they are not exported *and* each of the modules loads classes using distinct class loaders, right? This is a limitation imposed primarily because of ability to load multiple modules using same class loader. But if the modules that have

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Hi Kevin, On 05/02/2017 02:21 AM, Kevin Rushforth wrote: This review is being cross-posted to both openjfx-dev and jigsaw-dev. Please review the proposed fix for: https://bugs.openjdk.java.net/browse/JDK-8177566 http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ Details of

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

On 05/02/2017 06:56 PM, Mandy Chung wrote: On May 2, 2017, at 3:14 AM, Peter Levart <peter.lev...@gmail.com> wrote: I don't quite understand the need for bypassing the inflation of native into generated method accessor The VM native reflection implementation does not know

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

Hi Mandy, On 05/02/2017 04:37 AM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ The big hammer check disallowing MethodHandles::lookup be called by system classes defined by the bootstrap class loader was added as defense-in-depth to prevent

Re: Changing the default file system provider is broken :(

Hi Alan, On 04/22/2017 10:37 PM, Alan Bateman wrote: On 22/04/2017 20:47, Peter Levart wrote: : Or this might work too: http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ Only partly as there is also the issue of resolving paths associated with one provider against a path

Re: Changing the default file system provider is broken :(

On 04/22/2017 10:06 PM, fo...@univ-mlv.fr wrote: Or this might work too: http://cr.openjdk.java.net/~plevart/jdk9-dev/Path.toFile/webrev.01/ yes, it's better A variant of this might be for FileSystems.getDefault() to start returning the custom default filesystem as soon

Re: Changing the default file system provider is broken :(

On 04/22/2017 08:10 PM, fo...@univ-mlv.fr wrote: Hi Peter Hi Remi, On 04/22/2017 01:20 PM, Remi Forax wrote: Ooops ! if you use the module path, you can not change the default system provider mechanism anymore, mostly because the module implementation

Re: Changing the default file system provider is broken :(

Hi Remi, On 04/22/2017 01:20 PM, Remi Forax wrote: Ooops ! if you use the module path, you can not change the default system provider mechanism anymore, mostly because the module implementation internally uses java.nio.file.Path at different places. First, trying to initialize the default

Re: Review Request: 8179025: Exclude deployment modules from FieldSetAccessibleTest.java and VerifyJimage.java

Hi Mandy, In order to make the FieldSetAccessibleTest more resilient to future changes (i.e. adding / renaming modules), perhaps the modules to be excluded in the check should be explicitly listed by their names? Currently your rule, when negated, lists the following modules: javafx.deploy

Re: RFR: 8177845: Need a mechanism to load Graal

On 04/19/2017 11:49 AM, Peter Levart wrote: I was not aware of the new Map.ofEntries method. Nice to see more space efficient map implementations being added to the JDK. Admittedly, I used this method in a way not envisioned by the author. Maybe there's a reason there is no Map.copyOf(Map

Re: RFR: 8177845: Need a mechanism to load Graal

for the following idiom: Collections.unmodifiableMap(new HashMap<>(someMap)) Regards, Peter Thanks! -Doug On 19 Apr 2017, at 10:12, Peter Levart <peter.lev...@gmail.com> wrote: On 04/19/2017 09:42 AM, Peter Levart wrote: On 04/19/2017 09:37 AM, Peter Levart wrote: http://cr.open

Re: RFR: 8177845: Need a mechanism to load Graal

On 04/19/2017 09:42 AM, Peter Levart wrote: On 04/19/2017 09:37 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ Also, while we are at it, the following javadocs in the getSavedProperty() do not apply any more: 138

Re: RFR: 8177845: Need a mechanism to load Graal

On 04/19/2017 09:37 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk9-dev/8177845_VM.getSavedProperties/webrev.01/ Also, while we are at it, the following javadocs in the getSavedProperty() do not apply any more: 138 * It accesses a private copy of the system

Re: Intended usage of `java --dry-run`?

On 04/12/2017 04:22 PM, Alan Bateman wrote: On 11/04/2017 17:13, Andrew Guibert wrote: : Thanks for clarifying Alan. I misunderstood the use case of --dry-run to be that it did not require any main class, but instead the point is to *load* but not *execute* the main class. Perhaps this

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

Hi Mandy, On 04/03/2017 11:50 PM, Mandy Chung wrote: JDK 8 JDK 9 - - OS_NAMELinux linux SunOS solaris Darwin macos Windows windows OS_ARCH

Re: Better tools for adjusting to strong encapsulation

On 03/23/2017 08:04 PM, Alan Bateman wrote: On 23/03/2017 18:44, Alan Snyder wrote: If I understand JEP 264 correctly, it should be possible to direct platform generated error messages to locations other than the standard error stream (System.err). Is that correct? If so, would it not

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

On 03/19/2017 11:42 PM, Peter Levart wrote: No problem. Here it is (against tip of jake/jdk): http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.02/ This patch changes a little when the stacktrace requested by sun.reflect.debugModuleAccessChecks system

Re: #VersionsInModuleNames

+1 I have been planning to write a similar comment. I understand that the main desire is to discourage version numbers to creep into module names, but no rule can prevent that entirely. We can only advise against it, not police it. If one wants to do it otherwise, let him do it. He'll soon

Re: RFR: 8175010: ImageReader is not thread-safe

ng to be found there... Regards, Peter Thanks! /Claes On 2017-02-15 21:52, Peter Levart wrote: Hi Claes, Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then the change that was just pushed, I can't seem to figure out what was the problem with original code. I

Re: RFR: 8175010: ImageReader is not thread-safe

Hi Claes, Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then the change that was just pushed, I can't seem to figure out what was the problem with original code. I can't find evidence for claims in https://bugs.openjdk.java.net/browse/JDK-8175010 . Is the problem

Re: Confusing error message for inner non-public service provider

Hi, Just wanted to note that the confusing javac error message is not specific to services and service providers. Take the following example: src/moda/module-info.java: module moda { exports pkga; } src/moda/pkga/Outer.java: package pkga; class Outer { public static class

Re: 8173393: Module system implementation refresh (2/2017)

Hi Alan, On 02/09/2017 10:28 PM, Alan Bateman wrote: On 07/02/2017 13:23, Alan Bateman wrote: I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. I've sync'ed up jake to jdk-9+156 and

Re: Reusing module name token `*` in -d

Hi, On 01/27/2017 03:27 PM, Nicolai Parlog wrote: Being able to compile a bunch of modules together, and put the resulting single output directory on the module path would seem to be more convenient and thus more desirable. You make it sound like it's "either or" but that would not be the

Re: Review Request: JDK-8173096 jmod files are not world-readable

Hi Mandy, On 01/21/2017 03:32 AM, Mandy Chung wrote: Updated webrev to put the temporary file in the same containing directory of the target file: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.01 That's ok. Maybe also specify ATOMIC_MOVE to CopyOption ... options in

Re: Review Request: JDK-8173096 jmod files are not world-readable

Hi Mandy, On 01/20/2017 05:55 PM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.00/index.html A recent change in jmod tool [1] creates the JMOD file with no group and other readable permission as that’s the default permission when creating a

Re: Valid characters in a module name

On 01/10/2017 08:28 AM, Ess Kay wrote: > He would write it in source like: > #"#\"u0022\\\"\"" Of course the above is itself a valid 25 character module, package, class, field or method name. It doesn't matter how deep you nest. It is, but as it is written (starting with characters

Re: Valid characters in a module name

Hi Ess, On 01/09/2017 01:55 AM, Ess Kay wrote: > If this sequence of characters appear in source at position where identifier is expected: > #"\\u0022\\\"" > then they are interpreted as an identifier with following characters: > \u0022\" Then what happens when a user wants to specify the

Re: Valid characters in a module name

Hi Ess, On 01/08/2017 02:33 AM, Ess Kay wrote: Why wouldn't Peter's syntax proposal suffice For any syntax to work (in ANY context) you need to be able to distinguish between the use of that syntax and the specification of an identifier (e.g. a module, package, class, field or method name)

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

of unique methods (no duplicates). Regards, Peter On 01/07/2017 08:54 PM, Peter Levart wrote: Hi Rony, Implementing explicit cast is easy in this scheme (the Java side): public static void cast(Object object, ReturnTypesList rtList, Class typeToCastTo) throws ClassCastException { typeToCastT

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

signableFrom(newType)) { // newType is more specific -> remove less specific one iter.remove(); } } } } } Regards, Peter On 01/07/2017 08:33 PM, Peter Levart wrote: On 01/07/2017 07:25 PM, Rony G. Flatscher wrote: Hi Peter, t

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

signableFrom(newType)) { // newType is more specific -> remove less specific one iter.remove(); } } } } } Regards, Peter On 01/07/2017 08:33 PM, Peter Levart wrote: On 01/07/2017 07:25 PM, Rony G. Flatscher wrote: Hi Peter, thank you again fo

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

le method's return type. There will be rare occasions where multiple types will be registered. Regards, Peter ---rony On 07.01.2017 19:16, Peter Levart wrote: Hi Rony, On 01/07/2017 03:53 PM, Rony G. Flatscher wrote: Hi Peter, thank you very much for your efforts! However, in this context the

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

asses in Rexx! In that case there is a Java proxy class available for proxying Rexx objects and on the Rexx side there is a Rexx Directory to maintain the proxied Rexx objects for their Java proxies. Fun stuff! :) On 06.01.2017 23:22, Peter Levart wrote: Hi Rony, On 01/06/2017 02:28 PM,

Re: Valid characters in a module name

Hi Ess, On 01/06/2017 05:27 AM, Ess Kay wrote: chances of meeting a module-info.class with funky module names is low When I raised the initial question, I had no idea that the Java verifier had been changed (with Java 6?) to allow "funky" package, class, field and method names. Somehow that

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

Hi Rony, On 01/06/2017 02:28 PM, Rony G. Flatscher wrote: >The j.l.r.Method object on which you call invoke() should not be obtained by inspecting the >methods of the implementation class given by getDefaultToolkit().getClass(). Implementation >classes (i.e. classes in non-exported packages)

Re: RFR: 8171855: Move package name transformations during module bootstrap into native code

Hi Claes, On 01/06/2017 03:36 AM, Claes Redestad wrote: New webrevs: http://cr.openjdk.java.net/~redestad/8171855/hotspot.04/ http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ In Module.c, it seems you applied the "techinique" of conditional allocation (lines 49...57), but forgot to

Re: Invoking default methods from a Proxy's InvocationHandler in JDK9

Hi Matthew, On 01/03/2017 04:28 AM, Matthew Hall wrote: I'm a member of the JDBI [1] project, an open source SQL access library atop JDBC. A major part of our API provides implementations of declarative interfaces defined by users (similar to MyBatis). Interface methods may be default (in

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

Hi David, On 12/14/2016 07:17 AM, David Holmes wrote: But let me explain why .setAccessible(true) can't be allowed for protected members in general. I'm confused as to what is being argued for/against here. Rony asked why .setAccessible(true) can't be used for protected members even if

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

Hi Jochen, On 12/13/2016 06:32 PM, Jochen Theodorou wrote: 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

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

Hi Rony, On 12/13/2016 07:07 PM, Rony G. Flatscher wrote: To make a long story short: I have always adhered to the Java rules for the Rexx users, in that they are only allowed to access public Java classes, public fields and public methods ("there must be a reason why the Java language has

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

I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), CREATE, WRITE)) { 2. badBuffers could include a duplicate and a slice of a

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

On 12/11/2016 09:59 PM, Peter Levart wrote: The alternative is of course: ByteBuffer wrap(long address, int capacity) void unmap(MappedByteBuffer) The wrap method allow be similar to JNI's NewDirectByteBuffer for those that are managing the underlying memory themselves. This makes

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

Hi Alan, On 12/11/2016 12:16 PM, Alan Bateman wrote: On 10/12/2016 17:11, Chris Hegarty wrote: : How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ The alternative is of course: ByteBuffer wrap(long address, int capacity)

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

is using anyways. Yes, internally, at least in java.base, the code can always directly invoke the DirectBuffer's and Cleaner's methods... Regards, Peter Uwe *From:*Peter Levart [mailto:peter.lev...@gmail.com] *Sent:* Saturday, December 10, 2016 10:23 PM *To:* Uwe Schindler <uschind...@apache.

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

Hi Chris, On 12/11/2016 10:26 AM, Chris Hegarty wrote: >"Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer

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

Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart <peter.lev...@gmail.com>: Hi Chris, On 12/10/2016 06:11 PM, Chris Hegarty wrote: How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ Apart from th

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

Hi Chris, On 12/10/2016 06:11 PM, Chris Hegarty wrote: How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I think this approach is reasonable. Is the method

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

remen, Germany http://lucene.apache.org/ *From:*Peter Levart [mailto:peter.lev...@gmail.com] *Sent:* Saturday, December 10, 2016 12:10 PM *To:* Alan Bateman <alan.bate...@oracle.com>; Uwe Schindler <uschind...@apache.org>; jigsaw-dev@openjdk.java.net; Core-Libs-Dev <core-libs-...@openjdk.java.n

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

Hi, On 12/10/2016 06:14 AM, Alan Bateman wrote: On 09/12/2016 22: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

Re: Reading bootstrap class bytecode from Java 7

Hi, On 12/05/2016 08:42 AM, Alan Bateman wrote: On 05/12/2016 07:21, Remi Forax wrote: Hi, Object.class.getClassLoader().getResourceAsStream(Object.class.getName().replace('.', '/') + ".class") should work across all jdks. This should work as before (ignoring the issue that

Re: testing for a class having been loaded

(null, B.class); } catch (ReflectiveOperationException ignore) { // A$Rendezvous not visible } } public static void use() { System.out.println("B used."); } } Regards, Peter On Nov 30, 2016, at 9:52 AM, Peter Levart <peter.lev...@gmail.com <mailto:peter.

Re: testing for a class having been loaded

Hi Alan, On 11/29/2016 10:14 PM, Alan Snyder wrote: Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader whether a class with a given name had been loaded without actually forcing it to be loaded. This hack will not work in JDK9, so I am wondering if there is a way to

Can't call certain accessible methods using reflection

Hi, I encountered a situation in which calling a method using reflection is not possible, while the same method can be called with bytecode instruction. Here's an example: // Module m1: module m1 { exports pkg1; } package internal; public class InternalImpl { public void m() {

Re: Replacement for JDK8 APIs

On 11/28/2016 10:39 AM, Peter Levart wrote: final class Trees extends ReflectionWrapper { private Trees(Object instance) { super(com.sun.source.util.Trees.class, instance); } ...ah, you would probably want to use Class.forName("com.sun.source.util.Trees") above... Peter

Re: Replacement for JDK8 APIs

Hi Stephan, I thin this is a classical problem with reflection access checking that existed before jigsaw, but is now encountered even more frequently. The problem is that your ReflectionWrapper, given an instnace of some object, takes its runtime Class and searches methods in that class. The

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Hi Alan, Overall this looks very good. I noticed a couple of nits... 1. I wonder if the new ServiceLoader API signature should be tweaked a bit... There is a new method in ServiceLoader with the following signature: public Stream stream() ...where Provider declares the

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

Hi Remi, On 11/01/2016 11:59 PM, Remi Forax wrote: Iteration 3, https://gist.github.com/forax/c08ce0a8dc88705bce97b17b63e7e2d5 GrantAccess can now be put on a class, on a package or on a module, and give access to several frameworks by their names. Getting access to the lookup of a class is

Re: module-info hygiene

Hi Robert, On 10/16/2016 08:52 PM, Robert Scholte wrote: Hi, with the introduction of the module-info something interesting is happening. Up until now the scope of a Java project was limited to the compilation of the classes. In case of Maven the end-user was in full control regarding the

Re: Lack of "export dynamic" requires to export everything for existing frameworks

Hi Paul, On 10/03/2016 11:23 AM, Paul Bakker wrote: I have updated the migration demo that Sander and I showed at JavaOne to the latest Jigsaw prototype ( https://github.com/sandermak/java9-migration-demos). This is a Spring/Hibernate application. The goal is to migrate the app's code to a

delegating module access

Hi, Building on the idea presented here (the part that talks about method ''assumeAccessOf'): http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009520.html ...which tries to solve the problem that some modules have when they don't know in advance the name of the module(s) to

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

Hi David, I'm not the one to answer your queries, but may I ask you some questions about your requirements and also give some comments... On 09/28/2016 02:13 PM, David M. Lloyd wrote: Hi all, I've been requested to ask if the OpenJDK development team have had a chance to review this email,

  1   2   >