Is Java still incompatible with UNIX ?

I remember how when I first heard of Java back in '96 I got pretty excited not because of the OOP language it offered (I was already sold on C++) and not because of the grandeur API it had (I simply don't believe in APIs more complex than LEGO bricks) but because its JVM offered a glimpse of what at the time seemed like a potential escape from the conundrum of modern CPUs – they all are but a VM for a C language. The only reason you've got MMUs in every decent CPU these days is because C VM has to support pointers. If only JVM could be efficiently cast in iron...

Unfortunately this particular nut proved to be quite difficult to crack. The demise of the Project Barcelona was even more frustrating, simply because its premise, requiring a single “instance” of JVM for running all Java applications – even from different users, seemed to be an ideal compromise between the difficulty of switching all the way to JVM-based CPUs and constantly having to lug a pretty hefty JVM around for running even the tiniest Java application (just for fun, try measuring how much RAM and CPU cycles would be consumed by a “Hello World” written in on your system). All of that, of course, means that 10 years later I find myself in a situation where when I have to implement a bunch of small GUI tools and utilities according to the UNIX tooling principle – each tool is small, convenient, does exactly one thing but does it well – Java is still not a good choice for me. I simply can not afford spending that amount of resources every time I need an 'echo' or 'ls' functionality of the GUI world. Platforms (such as NetBeans) are even worse in that regard, since not only do I have to tax myself with JVM, but each instance of JVM would have to suck in a fat layer of the platform itself. Since all of the JVMs are separate it means no sharing whatsoever even if I use the very same NetBeans classes in all of my little tools. Is Java still incompatible with basic UNIX philosophy ? You decide – for me the answer is clear and my only hope is that with Sun OpenSourcing Java somebody will pick up where Project Barcelon left off. But for now – I guess I have to teach myself some Qt :-(
Comments:

Interesting point. The paradox is that Mac OS X (which is a flavour of Unix), does exactly what you want, bytecode and VM resources sharing. From http://www.apple.com/macosx/features/java (and now I'm pretty curious about the two last sentences): Less Memory, Faster Start On other platforms, each Java application consumes some system memory, so you might end up using more memory than you need to when running multiple Java applications. Other languages, such as C or C++, solve this problem using what’s called shared libraries. Apple developed an innovative new technology that allows Java code to be shared across multiple applications. This reduces the amount of memory that Java applications normally use. And it fits right into Sun’s Java HotSpot VM, allowing Mac OS X to remain compatible with standard Java. In addition, Apple has given this implementation to Sun so the company can deploy it on other platforms. It’s just one example of how Apple supports standards and shares ideas to benefit all.

Posted by Fabrizio Giudici on October 23, 2006 at 04:32 AM PDT #

> It’s just one example of how Apple supports
> standards and shares ideas to benefit all.

I am genuinely curious how does it benefit all when there's no access to their source code and it only runs on Mac OS X ?
Other than that -- thanks for the tip, I try to do some experiments with Apple's JVM.
Thanks, Roman.

Posted by Roman Shaposhnik on October 23, 2006 at 10:35 AM PDT #

Class Sharing - sharing loaded .class data structures across JVMs is in Sun's JDK 5+ - but only for platform classes (i.e., a subset of classes in rt.jar). By default, -client JVM uses class sharing.

Also, it is possible to use scripting feature of JDK6 to get the feel of standard Unix shell [Please refer to jrunscript ]. Scripting may be used to run multiple small tools (which may be Java classes or script files) inside the same VM). There are many choices of languages - please refer to http://scripting.dev.java.net.

Posted by A. Sundararajan on October 23, 2006 at 05:12 PM PDT #

The AJile line of processors does run Java natively. That processor supports the JDK1.8 VM natively with about 450ns context switches on threading. It's a great processor that gets very little attention. Part of the problem is the Sun licensing burden extends the price per part out of the market's expectations.

There are lots of different models for containerizing java applications so that you don't have to have large complicated systems. But, Java is not ideal for quick one off tools. I do tend to use it for things which allocate memory and do GUI stuff though, just because I can create working code faster.

Posted by Gregg Wonderly on May 17, 2007 at 12:30 AM PDT #

Greg, I'm not familiar with issues around licensing Java, but I'm curious -- does opensourcing Java change any of that?

Posted by Roman V. Shaposhnik on May 17, 2007 at 02:32 AM PDT #

Great post and draw. Thank you for sharing.

Posted by links london jewelry on November 30, 2009 at 10:26 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

rvs

Search

Top Tags
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today