On 07/04/2016 12:25, Dawid Weiss wrote:
Tried again, it works. By the way -- jar's help says upgrademodulepath
are directories, it's useful to know they can be exact file pointers
too.
-upgrademodulepath ...
A ; separated list of directories, each directory
> I'm curious what the following lists for you:
>
> java
> -Xpatch:java.annotations.common=mods/[email protected]
> -listmods:java.annotations.common
I noticed that patch JARs cannot have module-infos so a plain jar file
with javax.annotation.Priority annotation inside would prin
On 07/04/2016 11:26, Dawid Weiss wrote:
Ok, got it to work by patching the default module this package comes from:
-Xpatch:java.annotations.common=mods\[email protected]
I'm curious what the following lists for you:
java
-Xpatch:java.annotations.common=mods/javax.annotation
On 07/04/2016 10:40, Dawid Weiss wrote:
I just hit the same issue with JBoss RestEasy. We have an embedded
server (not EE class, a simple servlet with some web services
exposed), but RestEasy relies on annotations in jaxrs
(javax.annotation.*, javax.ws.rs.*). I tried to somehow make it work,
but
Ok, got it to work by patching the default module this package comes from:
-Xpatch:java.annotations.common=mods\[email protected]
The name of the module was kind of misleading (different than packages
inside). I kept trying to patch javax.annotation... also, I couldn't
get it to w
> thank you for the detailed response! I am reassured that there is a
> reasonable technical solution, yet this seems like quite a burden for
> end users of JavaSE embedding any of these popular libraries.
I just hit the same issue with JBoss RestEasy. We have an embedded
server (not EE class, a s
On 05/04/2016 12:09, Sanne Grinovero wrote:
Hi Alan,
thank you for the detailed response! I am reassured that there is a
reasonable technical solution, yet this seems like quite a burden for
end users of JavaSE embedding any of these popular libraries.
I'll be looking forward to hear more about
Hi Alan,
thank you for the detailed response! I am reassured that there is a
reasonable technical solution, yet this seems like quite a burden for
end users of JavaSE embedding any of these popular libraries.
I'll be looking forward to hear more about this, in the meantime I'll
post my doubts to t
On 31/03/2016 11:20, Sanne Grinovero wrote:
Thanks Alex,
that clarifies a lot, I was just about to try with a different dependency.
So this is not a reflection bug, but I'm just realising now that has
quite significant impact on JavaEE:
the Synchronization type is defined as public API of the sp
Thanks Alex,
that clarifies a lot, I was just about to try with a different dependency.
So this is not a reflection bug, but I'm just realising now that has
quite significant impact on JavaEE:
the Synchronization type is defined as public API of the specification [1].
Changing the JavaEE API isn'
The JDK 9b111 runtime image includes the java.transaction module which
exports the javax.transaction package. The application class loader will
try to load javax.transaction.* types from there, not from a JAR on the
classpath. As you probably guess, the JDK's java.transaction module does
not co
Hello all,
looks like I've found an issue on invoking Class#getMethod.
This method is used by Maven when scanning the project's classpath to
identify JUnit tests - which it does by default on any Maven project -
so I'm afraid the impact could be quite large.
I've been able to narrow it down to th
12 matches
Mail list logo
