Anonymous classes are not final according to reflection API

[Dan Smith]

> On Jul 2, 2015, at 4:25 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> and to answer your question about who is using getModifiers() on a class,
> a lot of tools that generate proxies at runtime (Hibernates, Weld etc) because if the class is not final,
> you can generate a class that inherits from it.

Looking closer at Peter's and Maurizio's code snippings, I guess it's clear that the UID computation uses reflection too.  (I also see that the strange combination of javac and reflection logic leads the serialization code to always get "false" for ACC_FINAL, which is why Maurizio argued that javac turning off the flag consistently is a more attractive course of action than turning it on all the time.)

The reflection behavior is convenient for serialization, which wants to be lied to.  But why would Hibernate want to be told that a class was non-final, only to find out that, oops, the VM won't let me extend it?  Am I misunderstanding?

More generally, if reflection provides accurate results for getModifers(), the client can always turn off ACC_FINAL if it wants to, based on some calls to isInner and getName.  But if reflection provides incorrect results for getModifiers(), there's no way for a client to undo that and get at the original flags.

—Dan