Hi Alan,
> I took a quite look at xml-apis-1.4.01.jar and it looks like a copy of
> the XML API classes (not the implementation) from a very old JDK or JAXP
> release. The class files v45.3 = JDK 1.0.2 :-)
Just FYI: the latest Apache Xerces release (that's June, 2018) still
depends on this jar...
They seem to be aware about it -- see this issue, for example:
https://issues.apache.org/jira/browse/XERCESJ-1689
Dawid
On Thu, Nov 14, 2019 at 12:33 PM Alan Bateman wrote:
>
> On 14/11/2019 10:07, Dawid Weiss wrote:
> > :
> > Just FYI: the latest Apache Xerces release (that&#
14, 2019 at 7:51 PM Alan Bateman wrote:
>
> On 14/11/2019 17:52, Dawid Weiss wrote:
> > They seem to be aware about it -- see this issue, for example:
> > https://issues.apache.org/jira/browse/XERCESJ-1689
> >
> Thanks but that looks to be xercesImpl.jar. The main tro
This kind of "package-list" by getResources seems to be used quite
frequently in the wild... Check out this issue I filed for Log4j2.
https://issues.apache.org/jira/browse/LOG4J2-1484
I agree it's a side-effect that isn't defined in the spec (and
shouldn't be working).
Dawid
On Sun, Sep 4, 2016
Guice 4.1.0 throws an exception from within the embedded cglib with
this release:
>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+135-jigsaw-nightly-h5500-20160914)
Java HotSpot(TM) 64-Bit Server VM (build
9-ea+135-jigsaw-nightly-h5500-20160914, mixed mode)
> [appte
flectUtils.(ReflectUtils.java:42)
at
com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73)
[truncated]
D.
On Mon, Sep 19, 2016 at 2:12 PM, Alan Bateman wrote:
> On 19/09/2016 00:12, Dawid Weiss wrote:
>
>> Guice 4.1.0 throws an exception fr
thought.
Dawid
On Mon, Sep 19, 2016 at 3:27 PM, Remi Forax wrote:
> I wonder what is the best way to fix the code of Guice ?
>
> Use Unsafe.defineAnonymousClass ?
>
> cheers,
> Rémi
>
> ----- Mail original -
>> De: "Alan Bateman"
>> À: "
> If you specify -XX:+IgnoreUnrecognizedVMOptions then JDK 8/older will ignore
> the JDK 9 options that it doesn't recognize.
But this only applies to -XX options, doesn't it? I can't quite use
the gnu-style options with the above because how would it know what is
an option and what is part of com
g ;)
Dawid
On Mon, Sep 19, 2016 at 11:06 PM, Alan Bateman wrote:
>
> On 19/09/2016 12:21, Dawid Weiss wrote:
>>
>> :
>>>
>>> jdk1.8-ibm\bin\java -XX:+IgnoreUnrecognizedVMOptions --add-modules
>>> jdk.xml.bind,java.activation -version
>>
>> JVM
> Yes, unfortunately when it comes to java libs this is "widespread" to
> say the least.
>
Often this isn't even intentional. For example the failure in the static
memory leak checker isn't caused by its codebase (no private class is
referenced); the exception is thrown at runtime when test case f
> 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
itPhase2(java.base@9-ea/System.java:1916)
Dawid
On Thu, Apr 7, 2016 at 11:40 AM, Dawid Weiss wrote:
>> 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 embe
> I'm curious what the following lists for you:
>
> java
> -Xpatch:java.annotations.common=mods/javax.annotation.prior...@1.0.jar
> -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
I don't want to hijack the other thread, so here's a new one I'm stuck
with. I get this exception (simplified stack trace a bit):
Caused by: java.lang.IllegalAccessException: class
org.jboss.resteasy.core.ContextParameterInjector cannot access class
com.sun.proxy.jdk.proxy2.$Proxy65 (in module jdk
>> > Stephane, I don’t think that would help since the package is not exported:
>> > "module jdk.proxy2 does not export com.sun.proxy.jdk.proxy2”.
>> >
>> > Regards,
>> > Neil
>> >
>> >> On 7 Apr 2016, at 13:13, Stephane Epardaud
> Have you been able to establish what the proxy interfaces are?
Considering the full stack trace I see they seem to be some internal
initialization services. I'll have to clone the sources of the library
and inject some code to debug it (or use runtime injection). I may try
to do it tomorrow, it'
Thank you for the magic switch, Mandy! Here's the full output,
including stack traces:
http://pastebin.com/uUb3aLwq
The one referencing the problematic class is:
PROXY: jdk.proxy2/com.sun.proxy.jdk.proxy2.$Proxy65 defined by
jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
java.a
> I don't have time to look it just now but
> java.annotations.common/javax.ws.rs.ext.Providers is
> / and I wouldn't have expected to see this type
> javax.ws.rs.ext.Providers in this module.
Yes, it's a mess, I agree. It comes from the patched module. Why is
this such a mess -- I've no idea, I'm
> Just so I have it clear. Someone has packaged the annotations with the
> JAX-RS classes and -Xpatch:java.annotations.common= is used to patch
> them into java.annotations.common module, is that right?
The jar with annotations is a maven dependency, here:
http://repo1.maven.org/maven2/org/jboss/r
2016, at 4:58 AM, Dawid Weiss wrote:
>>
>> Thank you for the magic switch, Mandy! Here's the full output,
>> including stack traces:
>>
>> http://pastebin.com/uUb3aLwq
>>
>> The one referencing the problematic class is:
>>
>
20 matches
Mail list logo
