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

On 15/04/18 07:33, mandy chung wrote: > FYI.  I have sent a proposal [1] for item #1 to serviceability-dev and > you for discussion.  JBS issue is: >    https://bugs.openjdk.java.net/browse/JDK-8200559 > > Mandy > [1] >

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

Thanks Mandy, I appreciate it! Best regards, Rafael 2018-04-15 8:33 GMT+02:00 mandy chung : > Hi Rafael, > > FYI. I have sent a proposal [1] for item #1 to serviceability-dev and you > for discussion. JBS issue is: >https://bugs.openjdk.java.net/browse/JDK-8200559 >

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

Hi Rafael, FYI.  I have sent a proposal [1] for item #1 to serviceability-dev and you for discussion.  JBS issue is:    https://bugs.openjdk.java.net/browse/JDK-8200559 Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-April/023529.html On 4/2/18 5:02 AM, Rafael

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

Yes, of course. This was merely a proof of concept to show that it works. 2018-04-13 8:48 GMT+02:00 Peter Levart : > > > 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

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: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

I have not thought of that but you are of course right, that works. The solution is however far from pretty as it needs a case basis since the resolution of the proxy class is only possible if the proxy is in fact loaded into an unnamed module what is not always the case. This does however cover

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

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 the special invocation. I just tried

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

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 the special invocation. I just tried this out too and I did not find a way, could you

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

On 10/04/2018 12:15, Rafael Winterhalter wrote: Thanks for the reference. As for the proxy API, I think that this should be reworked anyways as the lookup on each call would be rather expensive. In the mean-time, I think you should be able to make progress with findSpecial for the common case

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

Thanks for the reference. As for the proxy API, I think that this should be reworked anyways as the lookup on each call would be rather expensive. I also see the other issues that I mentioned as more pressing. Thank you and best regards, Rafael 2018-04-10 11:54 GMT+02:00 Alan Bateman

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

On 09/04/2018 20:48, Rafael Winterhalter wrote: Hei Alan, maybe I am doing it wrong but this is my example. I created a module with two interfaces bar.Bar and qux.Qux that both define a default method String foo() { return "foo"; }. The module exports bar and exports and opens qux. From

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

Hei Alan, maybe I am doing it wrong but this is my example. I created a module with two interfaces bar.Bar and qux.Qux that both define a default method String foo() { return "foo"; }. The module exports bar and exports and opens qux. >From another module that reads that first module I run the

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

On 9 April 2018 at 08:33, Alan Bateman wrote: >> 2. Java proxies cannot invoke default methods of proxied interfaces >> >> The Java proxy API does not currently allow the invocation of an >> overridden >> default method since >> the InvocationHandler API only supplies an

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

On 01/04/2018 22:02, Rafael Winterhalter wrote: : 1. Java agents cannot define auxiliary classes. : The reason for using Unsafe is that many instrumentations need to define auxiliary classes to aid an instrumentation similar to javac which sometimes needs to define anonymous classes or even

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

As for final methods, this is a problem with delegating and subclassing proxies. For delegation, I would even claim that this is a bigger problem as the original code is invoked on an unprepared instance. With subclassing, the final method is simply invoked in its non-proxied form what should

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

Answers inline On 4 April 2018 at 08:05, Rafael Winterhalter wrote: > Hei Henri, > > for Maven, Gradle and IDEs I think it is sensible to expect that these > runners would resolve such a test module unless it is explicitly specified > otherwise. Already today, those

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

: jigsaw-dev@openjdk.java.net Subject: 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: > > -

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

Hei Henri, for Maven, Gradle and IDEs I think it is sensible to expect that these runners would resolve such a test module unless it is explicitly specified otherwise. Already today, those runners patch the module under test in order to include the test code. I would expect of these runners to

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: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

Meh. Answered without thinking it through. I love this basic approach: >>> b) Add a module jdk.test to JDK 11 with a class >>> JavaTest::getInstrumentation that returns an instrumentation instance for >>> the current JVM. This module should not be resolved by default but only >>> when requiring

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

Hi Rafael, This is the point of multi-release jars. There is a new supported way of creating classes. As of Java 9, you are supposed to do: > return MethodHandles.privateLookupIn(anchorClass, MethodHandles.lookup()) > .dropLookupMode(MethodHandles.Lookup.PRIVATE); >

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

Hi Rafael, I don't like the idea to have to explicitly load a module to create mocks. Because Unsafe.allocateInstance is of course used to create mock but also proxies. For instance, Spring uses it extensively through Objenesis. And different frameworks doing serialization. Also, It means

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

Hello, I am the/a maintainer of the libraries Byte Buddy, cglib and Mockito with countless dependencies upstream and I wanted to give a summary of adopting the JPMS and migrating away from sun.misc.Unsafe. 1. Java agents cannot define auxiliary classes. Byte Buddy does support the JPMS fully,