> > This reminds me of an earlier version of the jl.constant API, where we tried > to track the varargs bit. In the end, we dropped this, because it washed off > too easily in the API. We could have a preload() bit that travels with the > ClassDesc, which would then have to be propagated into a bit mask in > MethodTypeDesc, which would have to carry the bits around (and expose them) > through combinators like dropArguments(). Seems possible, but also seems > like there's gonna be some whack-a-mole handling the wash-off cases.
If the preload() bit is tied to the ClassDesc, do we need to worry about a bit mask in MethodTypeDesc? Isn't the MethodTypeDesc composed of ClassDesc returnType and ClassDesc[] of parameters? I feel like I'm missing some complexity here... > > Stepping back, the ClassDesc type was originally intended to model the > C_Class constant pool entry. And there's not L* flavor of C_Class. But, it > is also reasonable to use ClassDesc as a way of describing a field descriptor > in a bytecode API (and similar for MethodTypeDesc.) > > Presumably the preload attribute is one attribute for the whole class. That > means that a classfile reader would have to parse that attribute, and when > dispensing ClassDesc to clients, would have to look in the table to see > whether the class is there? That sounds right. The classfile reader would need to expose whether the classfile was treating a given descriptor as an L or L*. It's kind of annoying but if we don't apply the stars when reading the classfile, we need to reify the preload attribute in some other way which will lead to consistency problems. Pulling on the reify the attribute thread a bit - jl.constant would then grow a PreloadDesc class (yuck!) that a classfile reader could fill in. Existing apis that deal with ClassDesc would then also need to know about the PreloadDesc and would need some way to pass it through resolution-related APIs so it could eventually be written back to a classfile. To be clear, I'm thinking of apis like the of*() methods on DynamicConstantDesc. All in all, this feels way worse than tracking the preload bit on the ClassDesc. > > Also, how would this affect ClassDesc::equals? Would LFoo and L*Foo be equal? I think they'd have to be equal as they represent the same descriptor. It's only the presence of side channel info - the star - that makes them different and the difference is only in the "go and look" behaviour. The VM will treat them as identical when dealing with descriptor strings. --Dan
