[Openmcl-devel] CCL images, consumer apps, and piracy
rwiker at gmail.com
Mon Apr 11 05:39:23 CDT 2011
On Mon, Apr 11, 2011 at 11:54 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> On 10 Apr 2011, at 04:55, Brandon Van Every wrote:
>> It is trivially easy to decompile a bytecoded language such as Java or
> Is this true? I'm sure it's easy to essentially *disassemble* the bytecode, in the same way it's possible to disassemble native code, and for the JVM say, that disassembly might take the form of Java source, but I wonder how useful such disassembly is: surely the hallmark of a decent compiler is that the source->object mapping is very far from being 1-1? Certainly my, now fairly distant, experience of looking at disassembly from serious (native code) compilers was that it just was not that helpful because so much stuff was optimised away.
You'd be surprised :-)
Take a look at .NET reflector, jd-gui and decompyle - each of these is
able to decompile into readable source code which can even be modified
and folded back into syetm you got it from. .NET reflector even has
the capability to decompile into VB.NET, C#, Delhpi, F#, MC++ (though
not all of these are fully covered, I think).
Now, the fact that .NET code can be decompiled back into both VB and
C# probably says something about the degree to which the byte-code has
I've used each of these to decompile closed-source programs/components
for debugging, and have been able to use the decompiled code to
pinpoint the exact location of bugs. In an ideal world, this would
have given me a bug fix within a day or so.
> In the case of the JVM how would such decompilation know whether the source language was Java or, say, Clojure, or one of the other languages which target the JVM (I forget the name of the CL implementation - is it Armed Bear?).
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel