In the current translation proposal, it is a real class. That said, the generic method translation is the weakest part of the current proposal, in that it is more similar to Model 1 than Model 3. In particular, the dispatch characteristics for instance generic methods are not currently very attractive — but we are actively looking for something better. But in the meantime, we have something that works acceptably for prototyping.
On Feb 1, 2016, at 5:44 AM, Andrey Breslav <[email protected]> wrote: > Another question on the "Generic Methods" section: does the proposed encoding > mean a new class file per generic method? Or is it purely about "fake" > class-like entries in the CP of the enclosing class? > > On Mon, Feb 1, 2016 at 8:33 AM Andrey Breslav <[email protected]> > wrote: > A question about these examples: > R(Foo<raw>) = Class["Foo"] or ParameterizedType['L', "Foo", "_"] > R(Foo<String>) = Class["Foo"] orParameterizedType['L', "Foo", "_"] > R(Foo<int[]>) =ParameterizedType['L', "Foo", ArrayType[1, "I"]] > Apparently, we want to preserve the information about int[], while we don't > care about String. Why? Isn't int[] just a class, like String? > > On Fri, Jan 22, 2016 at 7:53 PM Brian Goetz <[email protected]> wrote: > Please find a document here: > > http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html > > that describes our current thinking for evolving the classfile format to > clearly and efficiently represent parametric polymorphism. The early > concepts of this approach were outlined in my talk at JVMLS last year; > this represents a refinement of those ideas, and a reasonable "stake in > the ground" description of what seems the most sensible way to balance > preserving parametric information in the classfile without imposing > excessive runtime costs for loading specializations. > > We're working on an updated compiler prototype which people will be able > to play with soon (along with a formal model.) > > Please ask questions! > > Some things this document does not address yet: > - How we deal with types implicit in the bytecodes (aload vs iload) > and how they get specialized; > - How we represent restricted methods in the classfile; > - How we represent the wildcard type Foo<any> > > > -- > Andrey Breslav > Project Lead of Kotlin > JetBrains > http://kotlinlang.org/ > The Drive to Develop > -- > Andrey Breslav > Project Lead of Kotlin > JetBrains > http://kotlinlang.org/ > The Drive to Develop
