John, Lois and I have been studying the Template Classes in the VM proposal: http://cr.openjdk.java.net/~jrose/values/template-classes.html
We had some questions we were hoping you could either answer in email or in the next draft. thanks, Karen Where in the template class file are holes allowed? "almost anywhere in the constant pool" Type parameters today are allowed in ClassFile, field_info and method_info for class, interface, constructor, method or field who declarations use type variables or parameterized types (JVMS 4.7.9) Add at use sites for field and method descriptors. Assume this applies both to the reference class and the parameters/return types Add at use sites for CONSTANT_Class_info: e.g. superclass comment about other languages wanting to assign different superclasses for species What about the user mode assumption that: if Foo extends Bar, Foo<Point> is a subclass of Bar<Point> superinterfaces Add for annotations for field and method descriptors other attributes? Where are holes allowed in specialized class files? "API types, class instances and method invocations never have holes" Assume add "field descriptors" "Because of overloading the type part of a method needs to be spelled with non-class holes intact, since that is how the API element seems to be distinguished from its peers. This seems to be a necessary exception to the rule that constants with holes cannot participate in resolution." bytecodes can not be type-checked until all CP entries are complete potential w/partial verification/2 pass - but that is an implementation optimization, not semantic is the key point here that verifier can not see any holes, but e.g. attributes only viewed by e.g. reflection may see holes which are not caught by verification? clearer if "no holes in specialized class file", verification only extends as far as it does today Is it the case that a specialization could always have two segments There is a requirement that only the root segment can be shared Could we therefore have two segments for a given specialization - a common root segment and a per-species segment and not need multiple segments in the specialized class file and then, from an implementation standpoint, we could have a common root for all the raw types Could we see more complex examples more than one parameter type segments that depends on multiple parameter types template classfile and specialized result "reduction" JVMS level does the specialization including the root segment does verification verify the root segment note: implementation may be able to optimize e.g. implementation may be able to verify the root segment and separately verify specialization relative to the root segment Why extend super-interfaces to Constant_Dynamic? When would the BSM be invoked? Is the intent here to allow superinterfaces with holes - couldn't that be handled via a template type species? Relationship between: raw type, template class, erased species proposal is that the erased species has exact match of members as template class proposal is that the template class is not instantiable challenge is: older class files with instantiated raw type "new Foo" class file: new LFoo; – requires instantiation one proposal: re-translate the bytecode into new LFoo<erased>; and keep a non-instantiable template class, and keep the statics in java.lang.Class as they are today TODO: walk examples of raw type bytecodes and BC Clarifications/explorations on relationship of template class potential for multiple inheritance Concern about the requirement for ordering of holes - must depend on an earlier one, also the requirement to point to the "last" hole in a segment does this cause problems for Lookup.defineClass with re-use of byte[] and constant pool extension mechanisms? does this cause problems for bytecode instrumentors, redefinclasses - what if they want to add an additional hole in a segment - do they need to need to change all references to the "last" hole in a segment? Could we explore having two segments in the template classfile, one root and one specializable, and each entry you could trace dependencies instead of requiring ordered segments? Request from vm runtime in the specialized class file, we need both the name/UTF8 string AND the Constant_Class to have a place to store the passed-in resolved type parameter It would be valuable to be able to share any resolved classes to achieve "same resolution" results going forward Redefineclasses will need to have a way to indentify types resolved externally and passed in as live-types, so they are NOT re-reresolvable Detail: How are Template Attributes used e.g. by Class, method, field? What does it mean to have a template attribute on a static field? Is that a way of clarifying which conditional species it belongs to? Template Attribute and TemplateParameter dependency relationship? Later email: not clear why a BSM-based template expansion logic would not use existing class loaders, system dictionary and loader constraints