Slashdot Mirror

You could use a decompiler. Here is a list of Java decompilers: http://www.program-transformation.org/Transform/JavaDecompilers
Since we are talking about making a bytecode standard, it should be very easy to build such decompilers, if needed.
In Java bytecode the method and class names are saved, so with a decompiler it's a lot easier to understand the bytecode then with the minimized JQuery code.

You totally fail because you miss one point - JAVA IS NOT A COMPILED LANGUAGE. It's an interpreted language, so your arguments about compiler optimization simply don't apply.

You just failed computer 101. Java is in fact a compiled language. It is compiled into an intermediate code called bytecode. This is done by the java compiler, command line is javac. Example javac MyClass.java. This compiler can do, and DOES do optimizations. So, your dreaded getter and setter is compiled into inline bytecode assignments, direct assignments if you wish, in bytecode.

What happens to the bytecode once it has been compiled depends on the runtime environment. Most Java runtime environments today utilize a JIT compiler. This stands for Just In Time. A JIT compiler takes the compiled bytecode and compiles it, on the fly, just in time, to native code.

And you assume, to your error, that I'm a n00b

I have no idea what kind of experience you have with various programming tasks. You proved in your posting that you have NO CLUE what Java is however. If you need to know my credentials in Java I delivered my companies first enterprise class Java application in 1998. That was before J2EE.

Sheesh. Kids nowadays.

Funny comment. I could also tell you about the work I have done in the telecom industry with embedded agents on million-dollar telecom equipment. Agents written in very, very tight quarters, mostly in C. It would be cruel though, particularly since it appears that you are still living in the age where the inline keyword was still important. When writing generic code for embedded stuff, using the inline keyword in C code was not appropriate however, since inline in C is only a suggestion to the compiler, it doesn't have to follow your suggestion. The only way to ensure inline was using macros.

But hey, you just showed the entire world that you have absolutely no clue what Java is - "interpreted language" - sheesh, clueless morons these days.

If you want to learn interesting things about JIT compilers, a technology that has the possibility of achieving FAR better optimizations than even static compilers can do, this list is a place to start: http://www.program-transformation.org/Transform/JavaDynamicCompilers. I suggest you read that, and A LOT more before you say REALLY stupid things like "JAVA IS NOT A COMPILED LANGUAGE". You are just flaunting your ignorance.

Morfik's founders identified JavaScript as the limiting factor in the development of complex interactive Web-based software applications and decided to develop some proof-of-concept prototypes for the translation of a high-level language to JavaScript.

The first part of your post is right on. If your job is head's down coding without any need for "face time" interaction with co-workers, then you're done for. If you don't lose your job to outsourcing, you'll lose it to generative programming.

Instead of going hopeless and just learning to live with less, reposition yourself so that "face time" is a critical part of what you do. Then your position won't be able to be outsourced. Chances are you won't be working for any CCM level 3 and above companies so I hope that you are comfortable with anarchy.

If anybody else goes to Simonyi's company and still can't figure out what they're talking about (mostly because it's vapourware at the moment, I believe), may I direct you to this Wiki. It turns out that he thinks source transformation tools will change the world.

I'm told that my university is one of the leading source transformation research centres in the world, but the only interesting things they're producing right now are for understanding legacy systems. So yes, there's probably a lot of money in source transformation, but it's also boring as hell.

One thing that needs to be said is that this is worth millions of dollars in free publicity for IBM. There are many programmers who, before IBM started supporting Open Source, would not have considered working for IBM.

I'm not saying that IBM is asking for Java to be Open Source because of publicity. But that support has a wonderful side-effect for the company.

It's great to have a large organization like IBM that can use its voice to do something that has long been needed. The world needs better GUI support for Java.

We need true native Java compilers, so that it is not easy to de-compile Java, as it is now. (I get the impression that GCJ merely makes calls to libgcj, as the home page says, and is therefore easy to decompile. Does anyone know if that is true?) Business logic is very easy to steal through de-compilation.

Whether you like Java or not depends a lot on whether you try to use a GUI with Java, and whether you mind Decompilation.

It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java and those in .NET like C# for two reasons:

1) Pseudo-compiled languages are easily decompiled. If a small competitor writes an especially useful program, it is easy to see the logic by just decompiling the source code. In business programming, the business systems logic can be EXTREMELY complicated. It's easier to copy it from a competitor who has proven success. See these links for information about decompilation. Of course, the best methods of decompilation are not made public:

.NET Decompilers

Java Decompilers

A friend wrote this:

"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity. :) Thank you IBM.

"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."

2) Pseudo-compiled languages are slower. That raises the cost of hardware. Sun makes most of its money from selling hardware. Slower software requires more expensive hardware. Microsoft makes most of its money selling operating systems. The customers most important to Microsoft are not you and I. Microsoft's important customers are the systems builders like Dell and HP. Systems builders want slow software so they can sell more hardware. Microsoft wants slow software so people buy more systems and therefore more operating systems licenses.

It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java and those in .NET like C# for two reasons:

1) Pseudo-compiled languages are easily decompiled. If a small competitor writes an especially useful program, it is easy to see the logic by just decompiling the source code. In business programming, the business systems logic can be EXTREMELY complicated. It's easier to copy it from a competitor who has proven success. See these links for information about decompilation. Of course, the best methods of decompilation are not made public:

.NET Decompilers

Java Decompilers

A friend wrote this:

"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity. :) Thank you IBM.

"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."

2) Pseudo-compiled languages are slower. That raises the cost of hardware. Sun makes most of its money from selling hardware. Slower software requires more expensive hardware. Microsoft makes most of its money selling operating systems. The customers most important to Microsoft are not you and I. Microsoft's important customers are the systems builders like Dell and HP. Systems builders want slow software so they can sell more hardware. Microsoft wants slow software so people buy more systems and therefore more operating systems licenses.

It's a mistake to think that because I didn't mention something I don't know it. Everything below is from an October 1 email message to the CEO I mentioned in the grandparent post:

.NET Decompilers

Java Decompilers

A friend wrote this:

"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity. :) Thank you IBM.

"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."

It's a mistake to think that because I didn't mention something I don't know it. Everything below is from an October 1 email message to the CEO I mentioned in the grandparent post:

.NET Decompilers

Java Decompilers

A friend wrote this:

"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity. :) Thank you IBM.

"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."

For those who don't know about it already: The Decompilation Page