• Subject: Re: How can Java eat up 160meg of memory?
  • From: Blair Wyman <wyman@xxxxxxxxxxxx>
  • Date: Tue, 29 Feb 2000 14:48:17 -0600 (CST)

Excerpts from midrange-l: 28-Feb'00 RE: How can Java eat up 160..
"Stone, Brad V @taylorco (1894*) 

> > 
> > Maybe you should try running it on a machine that has a Real Java VM, 
> > instead of MicroSoft's bolluxed-up version?  (My opinion.., see Sun's 
> > lawsuit against MS for further details..) 

> Let me get this straight.  I have an NT box.  This is were my data resides 
> (not by choice).  Someone writes an app that I need.  It's in Java.  Now I 
> should get a new machine?  Why wouldn't the vendor provide a VM for their 
> product?  Maybe this one did?  I don't know and I don't care. 

The recommendation is NOT to get new hardware, or even a new operating
system -- the recommendation is to get a new JVM.  ...a new Java
_Virtual_ Machine.  It's a software download-and-install kinda deal. 
Free from Sun or IBM, to mention two...  Just because your data is stuck
on NT doesn't mean you have to suffer the Microsoft JVM's vagaries. 

> --Rant mode on-- 
> Shouldn't the vendor warn me it's gonna be a pig to run because of the VM 
> used?  Why do they advertise it's in Java then, so you know it will be slow 
> and you should expect to have to reboot every few days even with 160meg of 
> memory?  

Several points:  First, the vendor probably figures that anyone using
Java knows better than to use the M$ JVM.  This may be elitist on their
part, but is common knowledge in Java circles.  Next, you should NOT
have to reboot unless the application (or the JVM it runs on) has a
memory leak.  Period.  Finally, the vendor probably advertises that
their application is Java so folks know they are not tied to WinXX --
folks know the app will run on their operating system of choice
(including OS/400). 

> Sounds like Java isn't so great.  I don't care if M$'s VM is bloated, if 
> Java is so great, it should work without these problems.  Auto clean up my 
> *ss. 

Well, no JVM is going to do THAT for you.  :) 

You cannot blame Java, as it has proven itself in spades -- you must
first suspect the JVM.   It is naive to assume that all JVMs are the
same, and the M$ JVM (which has a vested interest in destroying Java)
must be prime suspect number one. 

> So who's fault is it?  The java hypers?  M$?  The Vendor for not warning me 
> response would be not so great?  Sun for even putting the darn language out 
> there?  Me for using NT without any other choice? IT Managers/Marketers for 
> developing their software in Java just because of the hype so they can sell 
> more? 

Well, if your goal is to assign blame, I'm too late.  If you want the
application to work right, try a different JVM. 

> Enough of the excuses for why Java isn't as hot as they say.  Call it what 
> it is.  Nothing special.  It will take a lot to prove to me otherwise.  And 
> you know what, if it wasn't so hyped, I probably wouldn't be so hard on the 
> poor language.   But I have yet to see a java app put it's coffee where it's 
> beans are. 
> --Rant mode off-- 

There are abundant examples of Java meeting real world business needs,
and if you want to program to use the 'net then Java is quickly becoming
the lingua franca. 

Just my 2 cents worth. 

-blair 

  ___   _           Blair Wyman                  IBM Rochester 
 ( /_)  /  _  ' _   (507)253-2891            blairw@us.ibm.com 
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.