flink-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timo Walther <twal...@apache.org>
Subject Re: Java 8 and type erasure
Date Fri, 28 Aug 2015 08:15:43 GMT
Hey Kristoffer,

sorry for the late reply. I was on vacation.

Here you can find my initial email that also contains a description and 
a link to the patch: 
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-January/009220.html

The Eclipse JDT team didn't really need a patch. Their compiler does not 
throw away generic type information in early stages so it was easy to 
add them to the generic signature (which "accidentally" happened at the 
beginning and now works again with help of a compiler option): 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063

The OpenJDK/Oracle JDK compiler mainly works without generic type 
information (they call "erasure()" intentionally), so the produced class 
files do not contain information that can be determined by any hacks.

It would be great if we could convince them. I think many projects need 
more type-safety for lambda expressions.


On 18.08.2015 14:58, Stephan Ewen wrote:
> Timo should still have the patch!
>
> If you want to re-vive the thread, that'd be great. I'd be happy to 
> support it.
>
>
>
> On Tue, Aug 18, 2015 at 2:51 PM, Kristoffer Sjögren <stoffe@gmail.com 
> <mailto:stoffe@gmail.com>> wrote:
>
>     Do you have a link to these patches?
>
>     Reading through the thread, I get the feeling they didn't reject the
>     idea completely.
>
>     Considering there are also other projects (Crunch, Spark, Storm, etc)
>     that would benefit from this, maybe we can convince them together?
>
>
>     On Tue, Aug 18, 2015 at 2:27 PM, Stephan Ewen <sewen@apache.org
>     <mailto:sewen@apache.org>> wrote:
>     > Yep, Timo wrote the patch, both for OpenJDK and JDT - the JDT
>     one was
>     > accepted in the end.
>     >
>     >
>     > On Tue, Aug 18, 2015 at 2:09 PM, Robert Metzger
>     <rmetzger@apache.org <mailto:rmetzger@apache.org>> wrote:
>     >>
>     >> Exactly, Timo opened the thread.
>     >>
>     >> On Tue, Aug 18, 2015 at 2:04 PM, Kristoffer Sjögren
>     <stoffe@gmail.com <mailto:stoffe@gmail.com>>
>     >> wrote:
>     >>>
>     >>> Yeah, I think I found the thread already... by Timo Walther?
>     >>>
>     >>> On Tue, Aug 18, 2015 at 2:01 PM, Stephan Ewen
>     <sewen@apache.org <mailto:sewen@apache.org>> wrote:
>     >>> > Would have been great. I had high hopes when I saw the trick
>     with the
>     >>> > "constant pool", but this is only to make what Flink does
>     already
>     >>> > applicable
>     >>> > to non-serializable lambdas.
>     >>> >
>     >>> > If you want to help us with this, I'll ping you for some
>     support on the
>     >>> > OpenJDK mailing list ;-)
>     >>> >
>     >>> > On Tue, Aug 18, 2015 at 1:59 PM, Kristoffer Sjögren
>     <stoffe@gmail.com <mailto:stoffe@gmail.com>>
>     >>> > wrote:
>     >>> >>
>     >>> >> I suspected that you already had looked into this, but it
>     was worth a
>     >>> >> try. It would make everything so much easier.
>     >>> >>
>     >>> >> Thanks for the explanation :-)
>     >>> >>
>     >>> >>
>     >>> >> On Tue, Aug 18, 2015 at 1:50 PM, Stephan Ewen
>     <sewen@apache.org <mailto:sewen@apache.org>>
>     >>> >> wrote:
>     >>> >> > Hi Kristoffer!
>     >>> >> >
>     >>> >> > I looked through the code as well. In fact, Flink
>     currently uses the
>     >>> >> > trick
>     >>> >> > mentioned for Serializable Lambdas in the gist you sent
me.
>     >>> >> >
>     >>> >> > This works well for lambdas that return simple types
>     (primitives or
>     >>> >> > classes
>     >>> >> > without generics). The information for the generic
>     parametrization
>     >>> >> > is
>     >>> >> > unfortunately really erased, it is in no signature or
>     anything.
>     >>> >> >
>     >>> >> > Java has the concept of "generic method signatures",
>     which means
>     >>> >> > that a
>     >>> >> > method gets a signature string that includes the generic
>     types.
>     >>> >> > These
>     >>> >> > signatures are generated for regular functions, but
>     OpenJDK and
>     >>> >> > OracleJDK do
>     >>> >> > not generate them for synthetic methods (like lambdas).
>     >>> >> >
>     >>> >> > We tried to submit a patch to OpenJDK to add these generic
>     >>> >> > signatures to
>     >>> >> > lambda methods, but they did not like the fact that we
>     try to figure
>     >>> >> > out
>     >>> >> > the
>     >>> >> > generic types of lambdas. I hope they change their minds
>     at some
>     >>> >> > point...
>     >>> >> >
>     >>> >> > Stephan
>     >>> >> >
>     >>> >> >
>     >>> >> >
>     >>> >> >
>     >>> >> > On Tue, Aug 18, 2015 at 11:46 AM, Aljoscha Krettek
>     >>> >> > <aljoscha@apache.org <mailto:aljoscha@apache.org>>
>     >>> >> > wrote:
>     >>> >> >>
>     >>> >> >> Unfortunately, this also doesn't work for the same
>     reasons. The
>     >>> >> >> generic
>     >>> >> >> types of generic parameters of a lambda are not stored
>     anywhere.
>     >>> >> >> Stephan
>     >>> >> >> mentioned to me that the only possibility right now
>     would be to
>     >>> >> >> look at
>     >>> >> >> the
>     >>> >> >> code using something like ASM to find a cast in the
code
>     to the
>     >>> >> >> concrete
>     >>> >> >> type of the generic parameter.
>     >>> >> >>
>     >>> >> >> On Tue, 18 Aug 2015 at 11:35 Kristoffer Sjögren
>     <stoffe@gmail.com <mailto:stoffe@gmail.com>>
>     >>> >> >> wrote:
>     >>> >> >>>
>     >>> >> >>> How about https://github.com/jhalterman/typetools?
>     >>> >> >>>
>     >>> >> >>> On Tue, Aug 18, 2015 at 11:16 AM, Aljoscha Krettek
>     >>> >> >>> <aljoscha@apache.org <mailto:aljoscha@apache.org>>
>     >>> >> >>> wrote:
>     >>> >> >>> > Hi Kristoffer,
>     >>> >> >>> > I'm afraid not, but maybe Timo has some further
>     information. In
>     >>> >> >>> > this
>     >>> >> >>> > extended example we can see the problem:
>     >>> >> >>> >
>     https://gist.github.com/aljoscha/84cc363d13cf1dfe9364. The
>     >>> >> >>> > output
>     >>> >> >>> > is:
>     >>> >> >>> >
>     >>> >> >>> > Type is: class
>     >>> >> >>> > org.apache.flink.examples.java8.wordcount.TypeTest$Thing
>     >>> >> >>> > class
>     org.apache.flink.examples.java8.wordcount.TypeTest$Thing
>     >>> >> >>> > Type is: class
>     >>> >> >>> > org.apache.flink.examples.java8.wordcount.TypeTest$Thing
>     >>> >> >>> > class
>     org.apache.flink.examples.java8.wordcount.TypeTest$Thing
>     >>> >> >>> > Type is :
>     >>> >> >>> >
>     >>> >> >>> >
>     >>> >> >>> >
>     >>> >> >>> >
>     org.apache.flink.examples.java8.wordcount.TypeTest.org.apache.flink.examples.java8.wordcount.TypeTest$Thing<java.lang.String>
>     >>> >> >>> > class
>     org.apache.flink.examples.java8.wordcount.TypeTest$Thing
>     >>> >> >>> >
>     >>> >> >>> > So with the two lambda calls it does not
correctly
>     determine the
>     >>> >> >>> > generic
>     >>> >> >>> > parameter of Thing while it works with the
anonymous
>     class.
>     >>> >> >>> >
>     >>> >> >>> > I was exited when I saw the example because
we've
>     been trying
>     >>> >> >>> > for so
>     >>> >> >>> > long to
>     >>> >> >>> > get this to work. Maybe we have to wait for
java 19
>     to get this
>     >>> >> >>> > to
>     >>> >> >>> > work. ;-)
>     >>> >> >>> >
>     >>> >> >>> > Thanks a lot for helping, though. :D
>     >>> >> >>> > Aljoscha
>     >>> >> >>> >
>     >>> >> >>> > On Tue, 18 Aug 2015 at 11:01 Kristoffer Sjögren
>     >>> >> >>> > <stoffe@gmail.com <mailto:stoffe@gmail.com>>
>     >>> >> >>> > wrote:
>     >>> >> >>> >>
>     >>> >> >>> >> Hi
>     >>> >> >>> >>
>     >>> >> >>> >> Potential fix for writing flink jobs
using lamdas
>     without
>     >>> >> >>> >> Eclipse
>     >>> >> >>> >> JDT?
>     >>> >> >>> >>
>     >>> >> >>> >>
>     https://gist.github.com/aslakhellesoy/3678beba60c109eacbe5
>     >>> >> >>> >>
>     >>> >> >>> >> Cheers,
>     >>> >> >>> >> -Kristoffer
>     >>> >> >
>     >>> >> >
>     >>> >
>     >>> >
>     >>
>     >>
>     >
>
>


Mime
View raw message