> * CDI allows to dynamically obtain beans of specific parameterized > List customers = response.readEntity( new > * JAX-RS allows to read response message entities into parameterized > List stringList = container.get( stringListType ) > cannot obtain a List without casting from such container.

> and another value for a List in such container. > Class, which means that one cannot have a value for a List > store and retrieve objects of different types. > book 'Effective Java' introduces a container which allows to safely > * The 'type-safe heterogenous container' pattern from Joshua Bloch's > allow to implement such cases in a type-safe fashion. > specific generic types, link specific behaviour to them or expose > libraries have the need to apply some sort of configuration to > Actual class literals can only represent raw types. > class library, to be used for representing generic types such as > I'd like to suggest the addition of a type token class to the Java > suggested that it may fall into the scope of project Valhalla, hence

> I've sent this proposal to core-libs-dev recently and it has been Some revamp of reflection will certainly be in order after Valhalla - so probably best to wait and see how that settles out. Whether this is lumped in with Class, or whether it is a new thing, is still under exploration. That said, Valhalla will need something to describe at least the portion of parameterized types that are reified, such as ArrayList. Now, this isn't a slam-dunk indictment, but its a concern. Pulling on this thread means building in subtyping too, not just 'do I describe the same type.' Which isn't trivial. And one could pull on this thread further - such as intersection types. Now, you could claim that this is too esoteric an example, but if the goal is patching the inadequacies of an existing facility. = container.get( (type literal for List) ) In your type-safe hetergeneous container example:Ĭontainer.put(aListOfInts, (type literal for List)) Places, is that while it increases the range of Java language types thatĬan be expressed via reflective tokens, it still falls short ofĭescribing all the types that occur in real programs.įor example, it does not support variance. One of the known defects of this approach, as implemented in various

Next message: RFR: : vdefault / vwithfield.

No type checks, assumes memory layout of VCC and DVT to be the same.

Previous message: hg: valhalla/valhalla/hotspot: Summary: Basic C2 support for the vbox/vunbox bytecodes.

Proposal: Add a type token class for representing generic types Brian Goetz brian.goetz at Proposal: Add a type token class for representing generic types

Java type token