Publishing flamebait [Fwd: Pragmatic Bookshelf releases "FromJava To Ruby"]

Ross Werner ross at indessed.com
Thu Jun 29 10:30:36 MDT 2006


On Thu, 29 Jun 2006, Hans Fugal wrote:
>> I'd have to agree that Java is typically more memory-hungry than other
>> applications--however, in my experience that's only a one-time cost. In
>
> Half a Gig!!! Even emacs can't approach that.

Yeah, but Open Office can, and it's more similar in terms of the
functionality it provides. Pretty UIs are very expensive in terms of 
memory, and emacs and vi avoid that cost. But that's why I say Eclipse 
makes for a crappy text editor--for much the same reasons why Open Office 
makes for a crappy text editor.

>> little overhead above that, as well as half a dozen other Java apps. The
>> intial memory cost to have something running in a JVM seems to be rather
>> high, but once you hit that point everything else seems to be very
>> comparable to non-Java applications in terms of memory usage.
>
> The same is true of gnome and qt/kde, the ruby interpreter, rails (if
> you're not using a frozen copy in vendor/), php, apache, etc. It's the
> beauty of shared memory.

Exactly my point. When you're using most other (non-Java) programs, you 
get a memory "bonus" of some typical low-level libraries (at least glibc) 
already being available in memory. Java programs start from scratch (more 
or less), so it's only expected that they'd have a greater overhead for 
their libraries.

What really interests me is the idea of a Java operating system created 
in Java from the ground up. Like, for example, jnode 
(http://www.jnode.org/node/132). It seems to me that in such an 
environment Java applications would have a similar memory footprint and 
similar speed as similar non-Java applications running on a "normal" 
operating system, since the JVM and common libraries would always be 
running and in memory.

 	~ Ross



More information about the PLUG mailing list