See you at JVMLS

[Christoph Engelbert]

Hey Peter,

Interesting catch but as long as Bar doesn’t have any generic methods why do we have to create a generalized class? Methods won’t be generalized anyways, do they? I have the feeling I’m missing something in your explanation :)

Chris



> On 19 Aug 2015, at 16:55, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 08/18/2015 11:59 PM, Rémi Forax wrote:
>> It can not work because if the method in B is package visible it should in Foo$any or not depending if the code that use Foo$any is in the same package as B or not.
> 
> That's a problem. There would have to be a Bar$any interface with methods from Bar (and Foo$any extends Bar$any) even though Bar is not using "any T" generics in it's declaration...
> 
> Also, if Foo<any>.class is an interface, one could create a:
> 
>     Foo<any> proxy = Proxy.newProxyInstance(..., new Class<?>[] { Foo<any>.class }, ...);
> 
> and try to assign:
> 
>    Bar bar = proxy;
> 
> So it seems that Bar.class.isAssignableFrom(Foo<any>.class) would have to return false...
> 
> Peter
> 
>> 
>> regards,
>> Rémi
>> 
>> Le 18 août 2015 23:53:21 CEST, Brian Goetz <brian.goetz at oracle.com> a écrit :
>>> Yes, that has to work, though it doesn't currently.  On the list...
>>> 
>>> On 8/18/2015 5:49 PM, Palo Marton wrote:
>>>> Yes, that's a nice sidestep ;-)
>>>> My question was meant in a general way, not only about results of
>>>> instanceof/isAssignableFrom. What about methods of Bar? Will you
>>>> recreate them in Foo$any? What about eg call to
>>>> f.barMethod()?
>>>> On ut, 18. aug 2015 at 23:39 Brian Goetz <brian.goetz at oracle.com
>>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>> 
>>>>     I'll sidestep your clever question by pointing out that the left
>>> operand
>>>>     of an instanceof check is an expression, not a type.
>>>> 
>>>>     If you have:
>>>> 
>>>>           Foo<any> f = ...
>>>> 
>>>>           if (f instanceof Bar) { ... }
>>>> 
>>>>     this works just fine, because all instantiations of Foo<T> are
>>>>     represented by classes whose supertype is Bar.  The harder
>>> question is
>>>>     the reflective one (Class.isAssignableFrom.)  But reflection is
>>> still a
>>>>     work in progress (as is the whole thing, of course.)
>>>> 
>>>>     On 8/18/2015 5:30 PM, Palo Marton wrote:
>>>>      > Thanks. I have just watched your talk on Valhalla. Just one
>>> curious
>>>>      > question on xxx$any interfaces: How do you handle this?
>>>>      >
>>>>      > class Foo<any T> extends Bar { }
>>>>      >
>>>>      > Foo$any instanceof Bar?
>>>>      > On ut, 18. aug 2015 at 19:02 Brian Goetz
>>> <brian.goetz at oracle.com
>>>>     <mailto:brian.goetz at oracle.com>
>>>>      > <mailto:brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>>>
>>>>     wrote:
>>>>      >
>>>>      >     JVMLS talks up at:
>>>>      > https://www.youtube.com/user/java
>>>>      >
>>>>      >
>>>>      >     On 8/8/2015 12:05 PM, Brian Goetz wrote:
>>>>      >      > I'll be doing a talk on the path from Model 1 to Model
>>> 2
>>>>     (and a
>>>>      >     glimpse
>>>>      >      > of Model 3) at JVMLS next week.  Hope to see some of
>>> you
>>>>     there.
>>>>      >     Videos
>>>>      >      > should go up on the Java YouTube channel fairly quickly
>>>>     after the
>>>>      >      > conference.
>>>>      >      >
>>>>      >      > In the meantime ... I'll just note that we've had 50+
>>>>     messages on the
>>>>      >      > various "Model 2" threads and none of them started with
>>> "I
>>>>     tried
>>>>      >     it out
>>>>      >      > and..."
>>>>      >      >
>>>>      >      > So a reminder ... the most valuable input the community
>>>>     can give
>>>>      >     in this
>>>>      >      > process is to provide *actual experience reports*.
>>> That's
>>>>     the main
>>>>      >      > reason we make the significant investment in making the
>>>>     code and
>>>>      >     design
>>>>      >      > sketches available early -- so that people can actually
>>> try it
>>>>      >     out, and
>>>>      >      > help us see the holes that we might have missed.
>>>>      >      >
>>>>      >      >
>>>>      >
>>>>      > --
>>>>      > Pavol Marton
>>>> 
>>>> --
>>>> Pavol Marton
>