Notes from JVM Symposium

prostoalex writes "Steve Anglin, author of such O'Reilly books as "C# in a Nutshell" and "VB.NET Core Classes in a Nutshell" from recent Java Virtual Machine Symposium. Among the questions discussed are intelligent garbage collection, faster implementations of Java bytecode, getting JVM's for even smaller and lighter devices and stopping thinking outside the box."

How 'bout that link?!?

[bay43270]

Long enough for you?

Re:How 'bout that link?!?

[topham]

How about the article? I mean, it had virtually no political undertones at all.

damnit, what the hell happened to Slashdot?!

Oh, don't worry.

[Da VinMan]

It's still going to hell. If anyone with a technical backbone actually bothered to read and comment upon the article I might think otherwise. But then again, I guess we vertebrates have something better to do.

Easier Programming, oh no, I want Job security!

[unDiWahn]

Whats with writing all this functionality into the base language itself? If I don't have to worry about it, I can write horrible, sloppy code, and.... not worry about it!

Soon we'll be able to just tell the compiler the idea of what we want, and it'll write the program for us!!

*flame mode*
Garbage collections is for wusses! _Real_ programmers write everything from the ground up, every time!
*/flame mode*

JPM (Java Physical Machine) vs JVM

[knorthern knight]

The Intel i686 is a RISC core, with a legacy X86 emulation layer on top. Transmeta is another CPU that can morph its instruction set to emulate other CPUs. Why not scrap the emulation under an OS, and simply execute Java bytecode directly by the CPU ?

And if we really want to get fancy, maybe Transmeta could be set up to directly run the Emacs OS, from which you could run vim when you wanted to do serious editing.

Transmeta has done this

[alienmole]

Transmeta had a demo which executed Java bytecode directly on a Crusoe CPU, I'm too lazy to look for a link right now. It didn't go anywhere commercially, afaik.

Also, Sun has made chips that run Java bytecode, iirc "picoJava" was one such effort.

Right now, though, if you're an OEM designer, there's more support for traditional architectures, in terms of development tools and the functionality provided by traditional embedded operating environments. Performance is not usually such an issue that a JPM would be a necessity to the success of a project. In short, there just isn't a good enough reason to make the leap. It might become more viable in future, as tool support and the capabilities of the Java "platform" converge to provide everything that's needed.