Changeset: 61f6e06960a1
Author:alanb
Date: 2017-03-11 09:45 +
URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/61f6e06960a1
Top-level "java" package not handled correctly in modules
! src/share/vm/classfile/moduleEntry.hpp
! src/share/vm/classfile/modules.cpp
Changeset: eb788ea0f527
Author:alanb
Date: 2017-03-11 09:47 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb788ea0f527
Top-level "java" package not handled correctly in modules
! src/java.base/share/classes/java/lang/reflect/Layer.java
! test/java/lang/reflect/Layer/Bas
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 kind of changes.
So, if the JVM can automa
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
On 11/03/2017 10:50, Jochen Theodorou wrote:
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
Changeset: 1b26ff0b6e34
Author:alanb
Date: 2017-03-11 11:59 +
URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1b26ff0b6e34
check_prohibited_package needs update for java packages
! src/share/vm/oops/instanceKlass.cpp
On 11.03.2017 12:13, Alan Bateman wrote:
[...]
It doesn't having to be a new/different class loader, there is no issue
creating layers of modules where the modules are defined to the same
class loader as modules in other layers.
ok, missed that information, very good to know.
That will backfi
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
Hi Mickael,
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
> 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
I have implemented support for Lookup::defineClass in my library Byte Buddy
and my first impression is quite positive, I think this can offer a great
alternative for at least some use cases.
For this to work, I do however think it is crucial to add a parameter to
the ClassFileTransformer::transfor
> 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
You are right, that is a problem. However, I do not think that the lookup
would need to be based on the class as long as it has the same priviledges.
In this case, the lookupClass method could return null or throw an
unsupported operation exception if the class is yet unloaded. I do not
think that
On Mar 11, 2017, at 9:55 AM, Michael Rasmussen
wrote:
>
> What should the Lookup be based on though, since you don't have a Class yet?
Lookups are designed to represent computations in the context of a pre-existing
class.
I guess a Lookup for this use case would have to be based on a pre-exist
On 11/03/2017 15:12, Michael Rasmussen wrote:
Yes, you are correct that the current implementation doesn't update
the classloader's mapping of package -> module.
But I did a quick and dirty test/hack, calling addPackage on the
Module, and then registering the package in the classloader.
After t
15 matches
Mail list logo
