Wizard1988

I don't think Java "hides" the code, it is all there but you can't explicitly access those values in your code. This is to reduce the number of bugs in your code.

__________________
JG-Webdesign

Mad_guy

Technically speaking, Disassembly is, by itself, an undecidable problem. Decompilation is a much harder subject, although strides twords a solution have been made (Google "DCC decompiler" and "boomerang decompiler.") This can be seen and understood by doing some computer science research, if you're interested (in particular, look into the halting theorm, as via problem reduction, disassembly can be reduced to the halting problem. Therefore, undecidable.)

The JVM is a little different story, as with .NET (you'll see why I'm saying 'JVM' and not Java itself in a second.) JVM opcodes can be decompiled back to [Java] source code fairly successfully. This is due to the nature in which Java can run on it's own platform: the JVM. However, there is no problem with compiling it to native code via GCJ, etc; in that case, you're back where you started.
.NET is the same story, but .NET is quite interoperable, so many decompilers for .NET (google "Lutz Roeder's Reflector.Net") can decompile one executable back to many different languages. This is also due to the way in which .NET and .NET executables are architectured. I say this because many languages exist for the JVM platform, but then again, none are as highly touted and worked with as Java itself, so simply saying 'java' is just for simplicity. The basic premise is still there

It's also worth noting that much of the information that can be retrieved in the decompilating of JVM/.NET executables is done through advanced heuristics and techniques such as Dataflow analysis. Powerful disassemblers such as IDA Pro make use of this and other techniques as well (namely Control-flow analysis as well,) which is how IDA Pro can output quite a bit of good information such as structure definitions, function parameters, and in the latest version, graphic representations of a program's control flow.


That probably is not the answer you want however. So I will answer your question with probably the most simplistic and straight forward answer, although it still might not be what you want to hear: Don't expect anything phenominal. I say this because it is an undecidable problem, inherently. Work is being done in the area, but it will still always be an undecidable problem, at least as far as current system architectures go. Don't expect everything you desire.

__________________
os: mac os 10.5.4
revision control: git
editor: emacs

site

bl00dninja

i seem to recall a "DUMPBIN" utility or something in visual studio that can show asm...google.

__________________
i put on my robe and wizard hat...

Have you ever heard of Plato, Aristotle, Socrates?...Morons.

BinarySurfer

@Wizard1988: I know Java doesn't "hide" the code. I just figured it is a fast, simple, and unimportant detail. Technically, when calling private classes/methods, it can be described as "hidden" because an analogy of private is a "black box". Where garbage goes in and out without knowing exactly what's going on unless you have the code of that class/method at hand.

@Mad_guy: It's probably me, but it seems you're "beating around the bush." I did pickup that JVM and Java decompile differently, but you don't give a definite answer to whether Java classes are vulnerable to being decompiled. Perhaps when you say "undecidable problem" you mean Java developers are trying to prevent decompiling or there isn't a definite answer because it depends on the complexity and structure of the program. What is the "problem"? Do you mean "answer"?

DaWei

Undecidable problem.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

BinarySurfer

Ah, now it makes much more sense. Thank you.