Long and short is really in the question title. For a language which compiles to an intermediate language like MSIL or Java byte-code, if there's concern about something like reverse engineering or hacking to disable security features, should AOT (ahead of time) compilation be considered rather than just obfuscation? Obviously, there's a bit of wiggle room in this question as there's no one answer I wouldn't imagine, but when would you start looking at performing an AOT compilation before distributing something versus sending it out obfuscated?
For anyone that stumbles across this and isn't familiar:
Wikipedia Entry on AOT Compilers: http://en.wikipedia.org/wiki/AOT_compiler
Mono AOT Compiler feature: http://www.mono-project.com/AOT
Best Answer
Its my understanding that .NET assemblies (and, I assume java .class files, too) include a hash value of some sort. If the hash value fails when the .class or assembly is loaded then, I believe, its rejected and an exception is thrown. So, if someone did decide to take a hex editor to an assembly or .class file, they'd have to know how the hash value was calculated and update that part of the file with the correct value as well.
In addition, .NET assemblies can also be Strongly Named which can also help in ensuring an assemblies integrity and provenance.