Fast, Open Alternative to Java

DrInequality writes: "For those of you out there who admire the portability of Java but want something faster or open source, the answer to your prayers is finally here. The Internet Virtual Machine is open source, fast and supports C, C++, Java and ObjectiveC. There are some cool demos for Linux (requires Redhat 6.0 or above, and OpenGL 1.2 or Mesa 3.41) here (1.5MB) and for Windows (requires glut32.dll, here) here (1.5MB)." We mentioned this last year; perhaps it has improved. I'm sure a lot of people would be interested in a language as portable as Java but speedier.

Comments

A fried of Mono?

[Whyte Wolf]

COuld this possibly be useful with Ximian's Mono project, or Gnu.NET? I could imagine using this as a VM for C# could seriously PO M$ :)

Some quick thoughts. (No sound, GPLed)

[BrookHarty]

The demos are nice and small, very impressive. Ill need to try this on my linux box in a few moments. (Looks like from the /. posts is crashs on some redhat installs..)

No sound, but its still in beta, so things should be added. The most impressive thing, is IVM is GPLed! No pesky Sun or Microsoft License! Now give me a QNX, Ipaq and Gameboy Advance IVM and im set!

Re:I wonder...

[small_dick]

In the future, there will be middleware.

I don't know how else to put it. The laws, the technology...everything is going to middleware.

Java, C#, this product...a better question is : how will i find apps that don't run off the internet?

Answer: a computer museum. I'm totally serious.

this is good but not great

[Anonymous Coward]

Having a VM to make C, C++, Obj-C (and Java) alll portable and still fast is great. Java does reduce the need for this and since the VM isn't portable to my platform of choice (OS X) this certainly isn't the answer for me at the moment. If it grows and moves to other platforms, tremendous.

People here have already started rebutting the need for this as Java is fast, has great libraries and enforces good writing style. In response to that, from a person who makes his living writing Java:

• Java is fast. It runs close to C/C++ in basic algorithm tests from what I've seen, depending on your runtime settings and VM.
  
  
• Java's lack of direct pointer manipulation (e.g. pointer arithmetic) does help people from hurting themselves and that alone leads to better code. The OO nature helps a bit, but really, not much more than taking C++, removing pointer manipulation and removing huge reliance on globals. Obj-C, which I use in my hobbies for OS X, is just as good an OO language, with some minor quibbles about its syntax being more awkward. The lack of memory control in Java loses out big time to the option of manual or automatic memory deallocation in Obj-C. Big Time Loss, even in 1.4.
  
  
• Java's libraries lead to code bloat. People substitute poor use of OO code and APIs for their poor use of pointers in their C work. Sun encourages this poor use by advertising its APIs' functionality and not their many weak points and the fact that its APIs aren't particularly efficient outside of a limited scope.
  Example: People commonly use a Vector when they just want an array of simple types (e.g. int) that will always be "large enough". Vector implements things that have nothing to do with this functionality and Vector doesn't support simple types. Code using the Vector with an Integer rather than an array with an int runs at less than 2/3 the speed and has a much larger memory overhead. Yes, teaching will help people reduce this error but with many classes the poor API coding is two, three or four parent classes above the class you think about using and oftentimes performance of the code is obfuscated - you don't want to have to write replacement code and test yours by theirs in order to determine if you should write replacement code. Java substitutes interfaces and Object-Orientedness (e.g. "Integer" support but not int) as so-called functionality while sacrificing efficiency and usefulness. Whereas efficient programs like to keep good form while remaining close to the bone, java likes to wrap your whole body in saran wrap and then cover that in tupperware and then let you touch the code through those nice OO pieces of plastic surrounding your hands. People teaching Java generally never tell the students the API code sucks, often because they don't really realize it themselves (in academia) or ..? Or if not that I don't know why they don't. I guess the modus operandi for many Java programmers is to rarely research the code beyond the published docs. It came to heart for me after I had to write an editable text component extending from JPanel as everything they offered was wretched for something requiring complex formatting.
  
  
• Java's libraries are very buggy and often poorly written. In final release versions their code still has questions, e.g. "How should this be handled?". They have some bugswhich are 3 or 4 years old, easily noticeable and in a basic part of their API which aren't even fixed as of 1.4. Leading to...
  
  
• Sun doesn't support community fixes to its libraries. This is the worst thing possible given their oft-shit code. If they simply had a "submit bug fix" section in an easily found place that would help so much. This is the major downfall of them not having truly open source code - you can look, but you can't fix and post so no one else will have to fix. This, above all the other reasons, is why Java still has such a poorly implemented API and thus (through its poorly made API) why it is not automatically the language of choice when considering C++, Java or other OO languages. It's really not the language that is so slow, it's the poor implementations in and the misuse of the APIs.
  

So, please, all you fellow Java programmers, realize that Java is far from perfect, and even just among the languages with an OO nature, it is not the best (none of them are). If Sun made it easy to fix its code, and offered more classes with less "functionality" and better performance it would become vastly better. I don't see Sun really making the changes necessary to make Java fast and memory efficient and, well, responsive to programmer's needs. If this VM can become a practical substitute for coding across platforms I would happily make the switch and would certainly hope that my company does the same. Unfortunately for both these paths the promises therein are still well in to the future.

Re:Faster?

[mj6798]

I have experince in all three languages, Java is no where NEAR the speed of C

Sure it is, but it's harder than in C. Basically, in C, it's easy to write code that runs fast, but it's hard to write code that's correct and robust. In Java, it's easy to write code that's correct and robust, but it's hard to write code that runs fast. If you invest enough effort, you can write code that runs fast and is correct in either language. Which language makes the better tradeoff? 20 years ago, the choice was clearly C. On today's hardware, the choice is pretty clearly Java.

[Java] must be run through in an interpreter in order to run (which is most of the slow down)

Sun's JDK and IBM's runtime both are compiled implementations; they run Java at machine speeds, not interpreted.

Re:Faster -- with evidence

[Thorgal]

Ok, I multiplied counters by 100 to get more reasonable times on Athlon1.1Ghz/143MHz SDRAM and to minimize JVM startup overhead. Results:

fantomas:te/> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010827 (Debian prerelease)
fantomas:te/> gcc c.c -o c -O2
fantomas:te/> time ./c
9007199254740992.000000

real 0m19.273s
user 0m19.220s
sys 0m0.000s

fantomas:te/> java -version
java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)

fantomas:te/> time java Compute
9.0071993E15

real 0m18.699s
user 0m18.570s
sys 0m0.030s

Well, enough said.