Am 31.08.2012 01:22, schrieb John Rose: [...] to sum it up... JVMS 4.2.2 says it is not allowed, JVMS 4.4.6 kind of allows it... the discussion in 4.10.1.4 says usages of <init> and <cinit> are not typesafe ...
> So if you want your code to pass the verifier, avoid <init> (and <clinit>). ok, so it is the name after all, because <init> and <clinit> are not regular names at all. I was aware of the restriction of not being able to call "super()" in a constructor, but that this extends to not being able to do a "new ArrayList()" using no extra method name argument, is new to me... Why is that? Because the verifier only checks for the inits and we didn't want to change the verifier here? Given that you can use "new ArrayList()" by reflection I don't think that security concerns really hold here. They where given for super()... and even though I don't understand why (if someone can explain it would be nice) I see a "new ArrayList()" security wise as a whole different case than "super()" Basically it means that even if you wanted to do a Java using invokedynamic only, you cannot do. You will at least need an invokeSpecial as well. Either only for super() and you do extra method name work, or for both. > P.S. Value types (see my blog) will need to make <init> be private, > since the new & invokespecial <init> idiom is totally incompatible with > value types. If we bake them into the class file format (which I don't > advocate at present) we would have to define a syntax for building > value-type instances that does not mention <init>; this leads to ideas > like canonical factory methods, of which the obvious name is <new>. For > now, I'm just proposing a design pattern (public static factory methods, > which internally use private new & <init>) that the JVM internally rewrites. I see that you may want to let the VM create them. But why is new & invokespecial totally incompatible? Ignoring the verifier problem, a new and invokespecial is still something that could be done kind of intrinsic for value types - or not? or do you mean something else? bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
