Well, public is technically module-private for any non-exported package.
/Michael
From: jigsaw-dev on behalf of Mike Hearn
Sent: 24 September 2019 18:24
To: jigsaw-dev@openjdk.java.net
Subject: Could we get module-private visibility?
Hello,
Often you want a m
There will be commercially supported versions available of Java next year (just
like there is today).
There will be free versions available of Java next year, just like there is
today - for instance the GPL licensed OpenJDK versions available from
http://jdk.java.net/
This doesn't mean though
I can echo a lot of what Rafael said.
JRebel is also a heavy user of the mentioned APIs here, especially
Unsafe.defineClass and Unsafe.allocateInstance -- we actually use all 4 ways
mentioned for creating an instance without calling the constructor (depending
on Java version and vendor).
Like t
This one?
http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
/Michael
On Sep 20, 2017 18:44, "Stephen Colebourne" wrote:
> As per this email:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> February/011365.html
> the idea was to add a new annotat
On 15 June 2017 at 21:31, Jeremy Manson wrote:
> My initial thought in this general direction was to write a JVMTI agent
> that takes a list of JAR files as arguments. It then does two things:
>
> - Intercepts all loads of classes using the ClassFileLoadHook, checks to
> see if there is a class w
On 19 May 2017 at 11:22, Alan Bateman wrote:
> One thing that jlink
> could do is emit a warning that the resulting run-time image doesn't have
> the management and instrumentation features, might that be the right
> balance.
As a users of those kind of agents, and as an agent vendor myself
(thou
On 16 May 2017 at 16:52, Reto Merz wrote:
> They need weeks to plan and test an upcoming server-side
> software update before they can install it on the production system.
> Java 9 will be released on 2017/07/27, so we are under high business pressur.
Assuming Java 9 follows a similar path at Jav
On 12 May 2017 at 11:22, Alan Bateman wrote:
> However for #3 then you've
> missed several important error cases, e.g. illegal package names, or the
> package is already in another module defined to the class loader.
These checks are already present in implAddPackage, so why duplicate
those check
On 12 May 2017 at 17:37, Stephen Colebourne wrote:
> On 12 May 2017 at 01:43, David M. Lloyd wrote:
>> 1. Layer primitive: addExports() - mirrors the existing Module.addExports()
>> method for ModuleLayer.Controllers
>> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
Hi
Has the class file format, or more specifically the module-info.class
file format, been finalized, or should we still expect changes in that
area?
/Michael
On 10 April 2017 at 00:04, wrote:
> Okay, so how about this revised proposal:
>
> - Define a new JAR-file manifest attribute, `Launcher-Agent-Class`.
> If this attribute is present in the manifest of an executable JAR
> file then the `agentmain` method of the specified class will be
>
On 6 April 2017 at 02:34, wrote:
> Interesting. Perhaps we need a `Self-Premain-Class` attribute, or some
> such.
>
> Out of curiosity, would it do any harm in your `java -jar` case if the
> agent is activated?
As it is right now, yes, that would cause the execution to potentially fail.
Should
se than running them as agents.
For instance, in the case of JRebel, java -jar jrebel.jar is used for
license activation/control, and should not activate the agent part.
Kind regards
Michael Rasmussen
JRebel, Product Manager
ZeroTurnaround
On 23 March 2017 at 17:05, Simon Nash wrote:
> Michael Rasmussen mentioned other cases of this in JDK 9 but I'm
> not sure what these are.
An example of those is regarding intrinsic methods and the new
annotation for those. As mentioned in this thread on hotspot-dev:
http://mail.openj
with the general gist of it (and what Jochen wrote).
JDK9 seems to be adding (too) many stderr outputs that are on by
default (not limited to jigsaw), and you have to go digging for
specific properties or special -XX JVM flags to set in order to
disable them (if at all possible).
Regards,
Michael Rasmussen
JRebel, ZeroTurnaround
> For this to work, I do however think it is crucial to add a parameter to
> the ClassFileTransformer::transform method where a lookup object should be
> provided as an additional argument in order to allow defining additional
> classes in the instrumented class's loader and module.
What should th
> i do not think you can use addPackage() directly because
> Module.getResourceAsStream() will not work on the resources associated with a
> package added by addPackage.
>
> The code of Module.getResourceAsStream() currently supposes that only proxies
> can add private packages, and proxies can
Looking a bit closer in the source, and not just the public API, I did find
addPackage in the private API part of Module (and the corresponding
native JVM_AddModulePackage).
So the capability for dynamically evolving a named module is present,
supported, and utilized by Proxy!
Adding a new package
the JVM can automatically do it for unnamed modules, why is this not
a supported redefinition for (named) modules?
Regards,
Michael Rasmussen
JRebel, ZeroTurnaround
On 17 February 2017 at 01:19, Stephen Colebourne
wrote:
>
> However, I remain of the opinion that they are highly dangerous for
> the wider ecosystem without some additional ability to qualify them.
> The are many more private jars than public jars, and the clashes seen
> today on Maven Central ar
>
> E.g. if I need to register/reach my service already at the early stages of
> JVM initialization, e.g. when a class java.lang.Thread gets initialized,
> can I assume a service from my extension module would be available?
>
No. At that time only java.base classes can be loaded.
If you look at th
Doing a quick JMH benchmark here, with a constructor taking 4
arguments, invokeWithArguments was about 15-30x slower than invoke and
invokeExact.
Otherwise, static final MH was 2.5x faster then reflection, and
instance field MH was 1.3x faster
For output and test code:
https://gist.github.com/anon
See the javadoc for java.lang.reflect.Layer
http://download.java.net/java/jdk9/docs/api/java/lang/reflect/Layer.html
There is a simple example of something similar there.
/Michael
On Jan 11, 2017 6:04 PM, "Piotr Chmielewski" wrote:
> For one of my projects, I decided to create "plugin" system
> To turn back to the root cause: using reflection a public class from
> java.desktop is loaded, one of
> its public static methods gets employed and returns an object of the type of
> that public
> java.desktop class. Under the covers, however, an object gets returned which
> got instantiated b
On 6 January 2017 at 10:24, Alan Bateman wrote:
> There have been a couple of threads here (going back to 2015) on this
> topic. Peter included a method [1] in one threads to walk the superclasses
> and directly implemented interface of each class to find the accessible
> method. Rony's example m
On 5 January 2017 at 10:22, Ess Kay wrote:
> There are utilities out there now that
> manipulate bytecode that are driven by script files that specify Java
> identifiers using a Java-style syntax. I raised the initial question
> because I have the job of updating such a utility to support Java 9
I really hope that some official API makes the cut.
In the case of defineClass, java.lang.reflect.Proxy also needs this
functionality, and uses its own native defineClass0 in order to inject the
proxy classes into the correct class loader.
I don't know if making that defineClass method accessible
For the stack trace at hand, doesn't that simply boil down to, that the
OSGi framework used doesn't know that jdk.internal.reflect should be boot
delegated, meaning it never calls the parent classloader when trying to
load the class?
/Michael
On 16 December 2016 at 00:10, David Holmes wrote:
>
On 30 November 2016 at 11:46, Alan Bateman wrote:
> I can't quite tell what the hack is, is it reading the private `classes`
> field?
I assume reflectively calling ClassLoader::findLoadedClass ?
/Michael
It might be worth noting that invoking it using MethodHandles works:
MethodHandle mh = MethodHandles.lookup().findVirtual(Public.class, "m",
MethodType.methodType(void.class));
mh.invoke(p);
/Michael
On 28 November 2016 at 15:17, Jochen Theodorou wrote:
>
>
> On 28.11.2016 12:23, Peter Levart w
Hi
I don't know if it already exists somewhere, but it shouldn't be hard to
create a main method that's loaded with -jar which then bootstraps all the
modules found inside the jar file.
For instance, say all your modules are inside your fatjar.jar!/mods
directory, and you have the name of the main
elp with this issue.
Regards
Michael Rasmussen
ZeroTurnaround
[1] https://bugs.openjdk.java.net/browse/JDK-8159145
[2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023480.html
> Aside from it being an uncommon way to
> deploy a library in the past, the additional challenge now is that many
> non-core modules are no longer defined to the boot loader and so not all
> libraries can be deployed with -Xbootclasspath/a anyway.
I can only say that I'm disappointed that the nul
Hi
I was looking over the specs for the multi release jars, and couldn't find
any information if this applied to jars on boot classpath as well (for
instance javaagents that add themselves there). All the docs and tasks
seems to focus on URLClassLoader, JarFile, etc.
So will multi release jars pi
> Thanks Jochen, makes total sense that you'd need readability since the Text
> type could of course override toString().
It is no different from how works now (Java 8)
If you expose private classes in your API, you will get the same error message.
Example code: http://www.hastebin.com/obukoyodey
> Thanks very much for offering me this code but before I can look at it I
> actually need explicit confirmation that I am able to release it under
> LGPL (sorry to be fussy but I don't want any legal issues to cause my
> employer a problem). If you could acknowledge that permission then I'll
> be
> Is your code open source? More importantly, is its license compatible
> with the LGPL license used by Byteman? If so then can I take a peek?
> (and maybe steal it :-)
Nothing fancy about it, just a simple class generated via ASM and then
defined using unsafe
Here's a simple main class with it (
> I'm not sure that I get the question. I think you might be asking about
> classes loaded into modules that are in Layers but I don't know if the
> context is java.lang.instrument or JVM TI.
Sorry, I could have been more specific, and I might have misunderstood
what you were saying.
I was referri
If the no split package rule is only applicable to boot layer, how will the
instrumentation API provide the correct module for other layers, as
currently that is implemented by mapping package to module ?
/Michael
While waiting for some proper way of doing this, in my current prototype
for supporting jigsaw I'm simply injecting a class into the
java.lang.reflect package that can call setAccessible0, in order to
circumvent these checks.
Probably not what was envisioned either :)
/Michael
Hi
Loading classes from the unnamed boot module (for instance an agent) causes:
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding"
with message transform method call failed at JPLISAgent.c line: 884
Due to trying to dereference the null-loader in
sun.instrument.InstrumentationImpl
ehand which module they are
defined in, by basically mapping packages to modules. At the moment,
this only works for named modules in the boot-layer though.
/Michael Rasmussen
> Just a quick mail to say that can_generate_early_class_hook_events (new
> capability) is in jdk9/hs so it should make it into JDK 9 master and into a
> promoted build soon (maybe jdk-9+117 or jdk-9+118).
>
> -Alan
Thank you very much!
Looking forward to trying it out
On 8 April 2016 at 15:58, Alan Bateman wrote:
> I think it would be better if we could post CFLH events in the primordial
> phase but this is only possible if agents opt-in via a new capability, maybe
> can_generate_early_class_hook_events that would have to be added along with
> can_generate_all_
.
/Michael
On Apr 4, 2016 14:30, "Alan Bateman" wrote:
> On 04/04/2016 12:09, Michael Rasmussen wrote:
>
>> So in order to patch any of the well-known preloaded classes, I will need
>> to prepatch them, put them in a folder/jar, and then need to ask the user
>> to specify
at is the case, that is a significant setback from Java8...
/Michael
On 4 April 2016 at 13:57, Alan Bateman wrote:
>
> On 04/04/2016 11:31, Michael Rasmussen wrote:
>>
>> Hi Alan
>>
>> Finally had time today to do some testing of can_generate_early_vmstart.
>>
instance java.lang.Class or java.lang.reflect.Method.
A quick comparison with Java8, there are about 100 classes that do not
generate CFLH events.
/Michael
On 29 March 2016 at 12:51, Alan Bateman wrote:
> On 29/03/2016 10:14, Michael Rasmussen wrote:
>>
>> With the new -Xpatch fo
With the new -Xpatch format, are there any plans to add support for
adding (or modifying) these from JVMTI in the OnLoad phase?
/Michael
On 28 March 2016 at 20:30, Alan Bateman wrote:
>
> Sorry, it is a bit confusing as we aren't quite done with the transition
> from an older form of a -Xpatch t
Hi Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8144730
> [2] https://bugs.openjdk.java.net/browse/JDK-8136930
> [3] https://bugs.openjdk.java.net/browse/JDK-8146454
Thank you for the references, I just wanted to mention them again; but of
course they are logged in the system, silly me j
Hi
Now that some changes are going into the JVMTI implementation in order to
support modules, I just wanted to bring up the question I asked back in
early December regarding support for setting the -Xpatch from JVMTI in
the OnLoad phase, as well as the inability for JVMTI agents to instrument
clas
On 5 December 2015 at 11:43, Alan Bateman wrote:
> The boot class path is essentially gone. All the types in the platform and
> JDK modules are in named modules. The only way to have types in the unnamed
> module of the boot loader is -Xbootclasspath/a or JVM TI
> AddToBootstrapClassLoaderSearch.
On 5 December 2015 at 00:12, Alan Bateman wrote:
> One other thing to say
> about -Xpatch is that it's much more powerful than -Xbootclasspath/p because
> it independent on class path, you'll find it can be used to patch modules
> defined to any of the built-in class loaders.
Using -Xbootclasspat
The usage of -Xpatch is to be a replacement for -Xbootclasspath/p, to
enable to patch boot CP classes, but at the moment it only seems to
support pointing to an "exploded" directory, containing the individual
.class files.
Are there any plans to extend this to also support some kind of container
f
On 3 December 2015 at 16:49, Alan Bateman wrote:
> Good to hear you got it going and I hope you will be able to try things out
> and work with us as JVM TI evolves to work with module aware agents.
I'm looking forward to it.
> Just so I understand, are you changing the memory in the value return
On 3 December 2015 at 14:08, Alan Bateman wrote:
> I'm guessing you are working around some of this by adding to or
> patching java.base.
> (...)
> Is -Xpatch working for you? Can you use this in conjunction with
> -agentlib/-agentpath until there is further progress in this area.
Correct, at the
On 2 December 2015 at 15:31, Alan Bateman wrote:
> "JVM TI agents can no longer instrument Java code that runs early in the
> startup of the run-time environment. The vm start event is not sent until
> the module system is initialized, so JVM TI agents that do load-time
> instrumentation will not
m is initialized, since this is
before premain, thus before you can add a instrumentation transformer).
/Michael
On 2 December 2015 at 11:45, Alan Bateman wrote:
> On 01/12/2015 22:08, Michael Rasmussen wrote:
>>
>> Are there any plans to support setting -Xpatch from JVMTI in OnLoad
Are there any plans to support setting -Xpatch from JVMTI in OnLoad
phase, or even setting the "jdk.launcher.patchdirs" system property,
and have it take effect? (Also applies to the other module -X options)
Agent_OnLoad should is still so early in the process that it should
be possible to influen
On 26 November 2015 at 09:33, Alan Bateman wrote:
> On 25/11/2015 22:56, Michael Rasmussen wrote:
>>
>>
>> 3) Why was the implementation of java.lang.Package changed, so it no
>> longer returns the content of the Manifest file?
>> Previousl
he JDK9 now states that
these values are unspecified.
Best regards
Michael Rasmussen
ZeroTurnaround
60 matches
Mail list logo
