Sun admits: Java is crap

[Theatre Mgmt]

Sun project seeks to solve Java memory, execution issues

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=

San Francisco (InfoWorld) - Sun Microsystems Laboratories (Sun Labs) is
working on a research effort to address issues with the memory
footprint, startup and execution times when running multiple Java
applications concurrently.

The Multi-Tasking Virtual Machine (MVM), developed as a prototype by Sun
Labs’s Barcelona, Spain research team, is a general purpose virtual
machine for executing multiple Java applications, according to a
description on the java.sun.com Web site. Based on the Java HotSpot
Virtual Machine and its client compiler, MVM increases the scalability
of Java by hosting multiple tasks.

 

[TheLetterK]

Sun project seeks to solve Java memory, execution issues

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=


San Francisco (InfoWorld) - Sun Microsystems Laboratories (Sun Labs) is
working on a research effort to address issues with the memory
footprint, startup and execution times when running multiple Java
applications concurrently.

The Multi-Tasking Virtual Machine (MVM), developed as a prototype by Sun
Labs’s Barcelona, Spain research team, is a general purpose virtual
machine for executing multiple Java applications, according to a
description on the java.sun.com Web site. Based on the Java HotSpot
Virtual Machine and its client compiler, MVM increases the scalability
of Java by hosting multiple tasks.

Admitting there's a problem, and eadmitting your product is crap are two
different things. Java isn't crap, but it does have problems.

 

[Cut Across Shorty]

Admitting there's a problem, and eadmitting your product is crap are two
different things. Java isn't crap, but it does have problems.

It has problems.

The problems that crap would have.

 

[Jim Hubbard]

Admitting there's a problem, and eadmitting your product is crap are two
different things. Java isn't crap, but it does have problems.

I'm just damned glad that .Net doesn't have any problems!

Jim Hubbard

 

[* * * Y o u r . S h e p h e r d . A q u i]

Sun project seeks to solve Java memory, execution issues

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=

San Francisco (InfoWorld) - Sun Microsystems Laboratories (Sun Labs) is
working on a research effort to address issues with the memory
footprint, startup and execution times when running multiple Java
applications concurrently.

The Multi-Tasking Virtual Machine (MVM), developed as a prototype by Sun
Labs's Barcelona, Spain research team, is a general purpose virtual

machine for executing multiple Java applications, according to a
description on the java.sun.com Web site. Based on the Java HotSpot
Virtual Machine and its client compiler, MVM increases the scalability
of Java by hosting multiple tasks.

Like .NET Application Domain? It's convenient but not a very solid
solution, since real isolation can only be achieved by OS kernel (you
MUST use processes). For example, your app opens port 80 via JNI, and
it's not closed after quiting, then the port will remain occupied until
the whole VM shutdown.

 

[Jose Maria Lopez Hernandez]

Admitting there's a problem, and eadmitting your product is crap are two
different things. Java isn't crap, but it does have problems.

And it's still the best choice. .NET it's vaporware.
When there's something similar to JBoss for .NET I will take a look
at it. Until there I will consider it crap.
And we should have in mind that what they are trying to do with Java
it's something .NET it's far away from even trying.

Regards.

--

Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
(e-mail address removed)
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

 

[Tim Tyler]

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=
[...]

Like .NET Application Domain? It's convenient but not a very solid
solution, since real isolation can only be achieved by OS kernel (you
MUST use processes). For example, your app opens port 80 via JNI, and
it's not closed after quiting, then the port will remain occupied until
the whole VM shutdown.

The article deals with the issue of running lots of Java apps on
a shared server. Presumably none of these would be permitted to
use JNI - on grounds of basic security - so it seems unlikely that
that issue would come up.

 

[* * * Y o u r . S h e p h e r d . A q u i]

"* * * Y o u r . S h e p h e r d . A q u i l a . D e u s .

( d 2 0 0 5 x x , d 2 0 0 4 x x , d 2 0 0 3 x x , d 2 0 0 2 x

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=

[...]

Like .NET Application Domain? It's convenient but not a very solid
solution, since real isolation can only be achieved by OS kernel (you
MUST use processes). For example, your app opens port 80 via JNI, and
it's not closed after quiting, then the port will remain occupied until
the whole VM shutdown.

The article deals with the issue of running lots of Java apps on
a shared server. Presumably none of these would be permitted to
use JNI - on grounds of basic security - so it seems unlikely that
that issue would come up.

What if one app running on the server invokes some system call that
hangs all other threads? Then all other apps on the same server will
just freeze!

 

[Tim Tyler]

"* * * Y o u r . S h e p h e r d . A q u i l a . D e u s .

[...]

The article deals with the issue of running lots of Java apps on
a shared server. Presumably none of these would be permitted to
use JNI - on grounds of basic security - so it seems unlikely that
that issue would come up.

What if one app running on the server invokes some system call that
hangs all other threads? Then all other apps on the same server will
just freeze!

A "system" call? You mean via something like JNI again?

Making such calls is not possible in a secure environment like the
sandbox Java server processes execute in.

 

[* * * Y o u r . S h e p h e r d . A q u i]

In comp.lang.java.advocacy "* * * Y o u r . S h e p h e r d .

A q u i l a . D e u s . ( d 2 0 0 5 x x , d 2 0 0 4 x x , d 2

s .

[...]

What if one app running on the server invokes some system call that
hangs all other threads? Then all other apps on the same server will
just freeze!

A "system" call? You mean via something like JNI again?

Making such calls is not possible in a secure environment like the
sandbox Java server processes execute in.

Yes, but finally the JRE has to use system calls, right? Without JNI
it's possible to achieve a total isolation -- but how much would it
cost, to wrap every such calls prefectly? For instance, the VM would
need to record each ports and files opened, so that it can release them
if some app dies, and it may also need to setup the priorities for each
threads correctly. So why not just use the OS's process model? .NET has
shown that doing isolation inside processes is a pain and can hardly be
used for any serious purpose (such as an app server for public web
hosting).

 

[Tim Tyler]

Yes, but finally the JRE has to use system calls, right? Without JNI
it's possible to achieve a total isolation -- but how much would it
cost, to wrap every such calls prefectly? For instance, the VM would
need to record each ports and files opened, so that it can release them
if some app dies, and it may also need to setup the priorities for each
threads correctly. So why not just use the OS's process model?

I believe some JVMs offer the choice of green threads or native
threads.

Probably the main reason for using the underlying OS's facilities
in this sort of area is portability.

If you rely on features from the underlying OS, you have to re-write
those features on every operating system you port your VM to - and
get them to behave the same way on each one.

On a system like Java that runs on a large number of OSes, that sort
of effort would become painful, and would be a source of compatibility
headaches. In many respects, it's better to do it yourself - and
then you can be more certain of your system behaving uniformly in
different environments.

Doing it yourself also gives you full control over factors such as
which resources can be shared. You can run multiple JVMs each in
their own OS process today - the problem is that that fails to make
effective use of shared resources.

 

[tab]

Would you say that Java might be it's own OS that runs on top
of other OS's?

 

[Tao Mein Poi Sen Zing]

Would you say that Java might be it's own OS that runs on top
of other OS's?

I would only say that if a user could open a window called java and type

 

[Thomas G. Marshall]

Tao Mein Poi Sen Zing coughed up:

I would only say that if a user could open a window called java and
type

Which is evidence of a *SHELL* not an *OS* .

 

[* * * Y o u r . S h e p h e r d . A q u i]

In comp.lang.java.advocacy "* * * Y o u r . S h e p h e r d .

A q u i l a . D e u s . ( d 2 0 0 5 x x , d 2 0 0 4 x x , d 2

 

[Olaf Baeyens]

Admitting there's a problem, and eadmitting your product is crap are two

I'm just damned glad that .Net doesn't have any problems!

I would not say this too loud.
..NET is still in it's early stages, some other big problems might occure
regarding backwards compatibility and stuff.
I love .NET but I am also realistic enough that nothing is perfect.

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Olaf Baeyens
<[email protected]>
wrote

I would not say this too loud.
.NET is still in it's early stages, some other big problems might occure
regarding backwards compatibility and stuff.
I love .NET but I am also realistic enough that nothing is perfect.

I think the previous poster was being slightly sarcastic, as the
speed of adoption of .NET has apparently been comparable to
that of a snail stuck in jelled treacle, or perhaps that of
a snail stuck in molasses during the month of January.

And of course, since .NET depends for a large amount of its
proprietary functionality on Windows, .NET inherits many of
the problems of Windows, which for the most part revolve
around various bits of malware infecting one's system.

However, with Mono one might have a fighting chance to
work around some of these issues; the main problem with Mono
is that it faces, AFAICT, a rather uncertain future, mostly
because Microsoft might very well patent the interesting bits
and leave Mono with the unprofitable dregs.

And yes, Java has problems; I've posted at length about some
of them. It's a very usable environment, though.

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Thomas G. Marshall
<[email protected]>
wrote

Tao Mein Poi Sen Zing coughed up:

Which is evidence of a *SHELL* not an *OS* .

True, although Jython might make a tolerable shell on top
of Java the OS -- if Java is in fact an OS. Depends in
part how one defines an OS; the main bit missing in Java
is the ability to handle device interrupts, DMA transfers,
and the like.

But at its heart, an OS is a series of promises made to the
user (or the application programmer in lieu thereof) that,
if one calls a certain routine, one gets a result back and
it does something. Put that generally, it sounds a bit
silly, but certainly that's what most operating systems
do nowadays, at some level:

- timer handling -- set a timer and alarm, get the time, convert the
time to a more user-friendly form
- file and directory manipulation -- create a directory, open a file,
get the entries of a directory
- volume/partition manipulation -- initialize a volume, make a volume's
files available ("mount")
- disk manipulation -- handle interrupts on a disk, transfer data
from/to, create volumes, delete volumes, etc.
- video handling
- audio handling
- process creation, manipulation, and deletion
- process communication
- network communication
- user event interception/handling (keyboard, mouse, etc.)
- etc.

Java is missing disk manipulation and volume/partition manipulation
(although Java can inquire roots; not sure if that's the same
thing as mountpoints or merely a way to get the single-letter
Windows drives).

There was a concept long ago called JavaOS but I for one have no
idea whatever happened thereto. It kinda died.

 

[JTK]

Sun project seeks to solve Java memory, execution issues

http://story.news.yahoo.com/news?tmpl=story&u=/infoworld/20050325/tc_infoworld/58059&e=1&ncid=


San Francisco (InfoWorld) - Sun Microsystems Laboratories (Sun Labs) is
working on a research effort to address issues with the memory
footprint, startup and execution times when running multiple Java
applications concurrently.

The Multi-Tasking Virtual Machine (MVM), developed as a prototype by Sun
Labs’s Barcelona, Spain research team, is a general purpose virtual
machine for executing multiple Java applications, according to a
description on the java.sun.com Web site. Based on the Java HotSpot
Virtual Machine and its client compiler, MVM increases the scalability
of Java by hosting multiple tasks.

This is a red herring. Java was almost as fast as compiled C++ when it
was released. Then they improved the speed in the next release, and it
was even more almost as fast as complied C++. But Sun wasn't finished
yet: another release, and Java was so fast it was almost as fast as
compiled C++!

But that's ancient history. Today's modern Java has blown the
proverbial doors off. What with yer JVMs and JITs and JINIs and
whatnot, why, today's Java is almost as fast as complied C++.

All that said, I have to give Sun credit for realizing that there is
still room for improvement, and for working even at this late date
toward a bright new future where Java is even faster. Why, if we're
lucky, this new "multitasking" (whatever that is, sounds newfangled!)
will make Java so fast it will be almost as fast as compiled C++!!!

These are indeed heady days, fellow Javapologists!

 

[14 7/8\ x 8 1/2\]

This is a red herring. Java was almost as fast as compiled C++ when it
was released. Then they improved the speed in the next release, and it
was even more almost as fast as complied C++. But Sun wasn't finished
yet: another release, and Java was so fast it was almost as fast as
compiled C++!

But that's ancient history. Today's modern Java has blown the
proverbial doors off. What with yer JVMs and JITs and JINIs and
whatnot, why, today's Java is almost as fast as complied C++.

All that said, I have to give Sun credit for realizing that there is
still room for improvement, and for working even at this late date
toward a bright new future where Java is even faster. Why, if we're
lucky, this new "multitasking" (whatever that is, sounds newfangled!)
will make Java so fast it will be almost as fast as compiled C++!!!

These are indeed heady days, fellow Javapologists!

Mabye we didn't read the same thing.

What I see is the inability of java to run more than one instance on the
same machine without gathering memory errors and crashing. Obviously,
java didn't cross the border into the 21st century...