When I run
> @Test
> public void test2()
> {
> MapFunction<String, Integer> fn = str -> Integer.valueOf(str);
> Class<?>[] typeArgs =
> TypeResolver.resolveRawArguments(MapFunction.class, fn.getClass()); //
> Using Jonathan Halterman's TypeResolver
> System.out.println("typeArgs.length: " + typeArgs.length);
> for (Class<?> clazz : typeArgs)
> {
> System.out.println(clazz);
> }
> }
with openjdk 8, I get
> typeArgs.length: 2
> class java.lang.String
> class java.lang.Integer
but when I run it with IBM jdk 8, I get
> typeArgs.length: 2
> class org.jboss.resteasy.test.contextresolver.TypeResolver$Unknown
> class org.jboss.resteasy.test.contextresolver.TypeResolver$Unknown
I see that IBM jdk 8 has sun.reflect.ConstantPool, but that doesn't seem
to be enough.
I think we should revisit this issue when JDK 9 is released. It's
probably too late to make a request, right?
I would say so, there was some deadline for proposals till the end of 2016 and planned
release of Java 9 is July 2017.
Tomaz - any comment on this ?
Rostislav
-Ron
On 04/07/2017 02:54 AM, Rostislav Svoboda wrote:
>
https://github.com/jhalterman/typetools#on-lambda-support
>
> Lambda type argument resolution is currently supported for:
> Oracle JDK 8
> Open JDK 8
>
> IBM JDK 8 will need some attention too.
>
> Rostislav
>
> ----- Original Message -----
>> Hi Steven,
>>
>> That's really interesting. It works for both Oracle JDK 1.8.0_91 and JDK
>> 9 build 163 from
java.net. !!
>>
>> One problem I see is that Jonathan Halterman's TypeResolver class has
>> the line
>>
>>> String constantPoolName = JAVA_VERSION < 9 ?
>>> "sun.reflect.ConstantPool" :
"jdk.internal.reflect.ConstantPool";
>> so I don't think we could use it for any JDK < 9. Once JDK 9 stabilizes
>> and Resteasy is releasing JDK 9 code, maybe it would be OK.
>>
>> Even better would be if Class.getGenericInterfaces() were to work in JDK
>> 9, but, as of build 163, it doesn't.
>>
>> In any case, you've helped to verify that the solution requires external
>> tricks. Let's hope that your "right approach" is followed.
>>
>> Thank you very much,
>>
>> Ron
>>
>> On 04/03/2017 01:49 PM, Steven Schlansker wrote:
>>>> On Apr 3, 2017, at 10:11 AM, Ron Sigal <rsigal(a)redhat.com> wrote:
>>>> ...
>>>>
>>>> So, it seems that, for lambdas, Java doesn't keep the
implementation
>>>> type
>>>> and value of the type variable at run time. Does anyone have any ideas
>>>> or
>>>> tricks?
>>> I did not have time to play with it myself, but I did run across this:
>>>
https://stackoverflow.com/questions/23863716/java-how-to-resolve-generic-...
>>> maybe that helps?
>>>
>>> It sounds like the "right approach" would be to request Java stash
the
>>> type
>>> information better for lambdas...
>>>
>> --
>> My company's smarter than your company (unless you work for Red Hat)
>>
>> _______________________________________________
>> resteasy-dev mailing list
>> resteasy-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/resteasy-dev
>>
--
My company's smarter than your company (unless you work for Red Hat)