RE: Re: [LANG3] Issue with TypeUtils.isAssignableTo() using JDK ParameterizedType

2024-05-31 Thread Sunny Chan
So the issue is this: Type assignFrom = TypeUtils.parameterize(Container.class, Integer.class); Type assignToUsingTypeUtils = TypeUtils.parameterize(Container.class, String.class); Type assignToUsingReflection = constructors[0].getGenericParameterTypes().parameters[0];

Re: [LANG3] Issue with TypeUtils.isAssignableTo() using JDK ParameterizedType

2024-05-30 Thread Matt Benson
I am confused as to what could be wrong with determining that Container is *not* assignable to Container. But are you saying that the manually constructed parameterized Type *is* reported as being assignable despite the obviously incompatible type parameters? Matt On Thu, May 30, 2024, 10:31 AM

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-27 Thread big data
Sorry I've posted another solved issue to Spark groups. Below is the details. It seems that Java Generic operation in Commons Lang problem when in Spark Yarn. Or java generic machenism. The Spark code and Class deserialized code (using Apache Common Lang) like this: val fis =

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-27 Thread Tomo Suzuki
Glad to hear you made progress. Good luck! (Another possibility: you might have changed the package or class name since you saved the HDFS file.) On Thu, Jun 27, 2019 at 21:25 big data wrote: > Thanks. I've tried it, the new Block before it is OK. > > I've solved it and posted another issue to

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-27 Thread big data
Thanks. I've tried it, the new Block before it is OK. I've solved it and posted another issue to describe this progress. The details refer to another email: Java Generic T makes ClassNotFoundException 在 2019/6/27 下午8:41, Tomo Suzuki 写道: My suggestion after reading ClassNotFoundException is to

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-27 Thread Tomo Suzuki
My suggestion after reading ClassNotFoundException is to try to instantiate the class just before deserializing it: public static Block deserializeFrom(byte[] bytes) { // Dummy instantiation to ensure Block class and its related classes are available System.out.println("dummy = " + new

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-26 Thread big data
The XXX Class named Block, below is part codes of it: The deserialize code like this: public static Block deserializeFrom(byte[] bytes) { try { Block b = SerializationUtils.deserialize(bytes); System.out.println("b="+b); return b; } catch (ClassCastException e) {

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-26 Thread Tomo Suzuki
I'm afraid that I don't have enough information to troubleshoot problem in com.XXX.XXX. It would be great if you can create a minimal example project that can reproduce the same issue. Regards, Tomo On Wed, Jun 26, 2019 at 9:20 PM big data wrote: > Hi, > > Actually, the class com.XXX.XXX is

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-26 Thread big data
Hi, Actually, the class com.XXX.XXX is normally called in the before spark code, and this exception error is happened in one static method of this class. So the jar dependency problem can be excluded. 在 2019/6/26 下午10:23, Tomo Suzuki 写道: > Hi Big data, > > I don't use SerializationUtils, but

Re: [lang3]java.lang.ClassNotFoundException when use Apache Commons Lang3 SerializationUtils.deserialize

2019-06-26 Thread Tomo Suzuki
Hi Big data, I don't use SerializationUtils, but if I interpret the error message: ClassNotFoundException: com.. , this says com.. is not available in the class path of JVM (which your Spark is running on). I would verify that you can instantiate com.. in Spark/Scala

Re: [lang3]

2019-04-16 Thread Scott Palmer
> On Apr 15, 2019, at 6:55 PM, Rob Tompkins wrote: > > > >> On Apr 15, 2019, at 3:08 PM, Gary Gregory wrote: >> >> On Mon, Apr 15, 2019 at 6:06 PM Bruno P. Kinoshita >> wrote: >> >>> I think that should be fine. I think something similar already happened >>> in the past, but can't recall

Re: [lang3]

2019-04-15 Thread Rob Tompkins
> On Apr 15, 2019, at 5:23 PM, Bruno P. Kinoshita > wrote: > > Great! > > Rob, just in case I ever do the same. Could you share what steps you had to > do in order to upload the javadocs, please? > Thanks for the super quick fix! Yeah, I’m going to figure out how to really get it fixed.

Re: [lang3]

2019-04-15 Thread Bruno P. Kinoshita
Great! Rob, just in case I ever do the same. Could you share what steps you had to do in order to upload the javadocs, please? Thanks for the super quick fix! Bruno On Tuesday, 16 April 2019, 10:56:22 am NZST, Rob Tompkins wrote: > On Apr 15, 2019, at 3:08 PM, Gary Gregory

Re: [lang3]

2019-04-15 Thread Rob Tompkins
> On Apr 15, 2019, at 3:08 PM, Gary Gregory wrote: > > On Mon, Apr 15, 2019 at 6:06 PM Bruno P. Kinoshita > > wrote: > >> I think that should be fine. I think something similar already happened >> in the past, but can't recall which component. >>

Re: [lang3]

2019-04-15 Thread Rob Tompkins
> On Apr 15, 2019, at 3:08 PM, Gary Gregory wrote: > > On Mon, Apr 15, 2019 at 6:06 PM Bruno P. Kinoshita > wrote: > >> I think that should be fine. I think something similar already happened >> in the past, but can't recall which component. >> >>On Tuesday, 16 April 2019, 9:58:43 am

Re: [lang3]

2019-04-15 Thread Gary Gregory
On Mon, Apr 15, 2019 at 6:06 PM Bruno P. Kinoshita wrote: > I think that should be fine. I think something similar already happened > in the past, but can't recall which component. > > On Tuesday, 16 April 2019, 9:58:43 am NZST, Rob Tompkins < > chtom...@gmail.com> wrote: > > > > > On Apr

Re: [lang3]

2019-04-15 Thread Bruno P. Kinoshita
I think that should be fine. I think something similar already happened in the past, but can't recall which component. On Tuesday, 16 April 2019, 9:58:43 am NZST, Rob Tompkins wrote: > On Apr 15, 2019, at 2:49 PM, Bruno P. Kinoshita > wrote: > > > Hi Scott, > I believe it was a

Re: [lang3]

2019-04-15 Thread Rob Tompkins
> On Apr 15, 2019, at 2:49 PM, Bruno P. Kinoshita > wrote: > > > Hi Scott, > I believe it was a mistake. Had a look at 3.8 and we had published it before. > Just had a look at the vote thread, and it appears the javadocs jar was not > included in the process. Possibly something with our

Re: [lang3]

2019-04-15 Thread Bruno P. Kinoshita
Hi Scott, I believe it was a mistake. Had a look at 3.8 and we had published it before. Just had a look at the vote thread, and it appears the javadocs jar was not included in the process. Possibly something with our pom.xml and plugins set up. @Rob, @Gary, is it possible to upload just the

Re: [lang3]

2019-04-15 Thread Rob Tompkins
Hm. Curious. Let me look at that. -Rob > On Apr 15, 2019, at 12:58 PM, Scott Palmer wrote: > > I noticed there are no javadocs on Maven Central for commons-lang3 3.9. > Is that intentional or a mistake? > > Scott > (please copy me on responses as I am not subscribed to the list) > >

Re: [lang3] FastDateFormat fails on some locales?

2019-02-01 Thread Kevin Risden
I did some further testing and found out of the ~160 locales that my JDK8 had, only ja-JP-u-ca-japanese-x-lvariant-JP failed with the ArrayIndexOutOfBoundsException Kevin Risden On Wed, Jan 30, 2019 at 1:36 PM Kevin Risden wrote: > > I found this while looking at Apache Lucene/Solr and Hadoop

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

2018-09-06 Thread P. Ottlinger
Hi, thanks for quick response ... Am 06.09.2018 um 21:24 schrieb Oliver Heger: > So opening a ticket in Jira would be the correct action to take. https://issues.apache.org/jira/browse/LANG-1419 Done :-) Hopefully I didn't miss any important stuff in Jira. Cheers, Phil

Re: [lang3] Problem with the OSGi metadata: Bundle-SymbolicName / breaking change between 3.7 and 3.8

2018-09-06 Thread Oliver Heger
Hi Phil, as you already assume, this change in the OSGi meta data was caused by changes in the build process and not intended. So opening a ticket in Jira would be the correct action to take. Thank you for reporting! Oliver Am 06.09.2018 um 20:49 schrieb P. Ottlinger: > Hi, > > I've just