Always enforce ACC_SUPER

[Keith McGuigan]

Hi Florian -

I haven't investigated (maybe you have), but does the JVMS allow this 
sort of behavior?  If it does (and if it doesn't, then that's the place 
to start), might it make sense to limit setting this flag implicitly to 
newer versions of classfiles (say >=51), or only to classes which have 
an ACC_SUPER set in their set of non-Object superclasses, or something 
like that?  Seems like we should have something in place to mitigate any 
backward-compatibility concerns in order to go forward with this.

(But pretty ACC_SUPER ignorant -- maybe there is no concern at all?)

--
- Keith

On 5/18/2012 3:49 AM, Florian Weimer wrote:
> It has been observed that the easy way of creating non-cloneable classes
> does not work because classes can opt out of the ACC_SUPER handling:
>
> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004742.html>
>
>
> I don't think this is desirable, so I propose a patch to treat all
> classes as if they have ACC_SUPER set. A new product flag is introduced,
> ForceAccSuper, which defaults to true. Disabling it preserves the old
> behavior. I think that assuming the presence of ACC_SUPER rather than
> rejecting classes without it completely is safer because non-javac
> bytecode generators might forget to set ACC_SUPER.
>
> The patch is against the Hotspot in OpenJDK 7u4, but it should apply to
> other versions as well. It has been tested only lightly (on 7u4 and 8).
>
> I have got a test case, but it uses ASM because to my knowledge, no
> released javac version has produced classes without ACC_SUPER (and I
> need to replace a type name, too). Should I include the class file
> contents as a string constant? Then the ASM dependency can go away.
>
> Florian