[ Quoting Denis Tonn to Scott Little ] 
 SL> To be of any real use it has to be compiled for specific CPUs. JITs and
 SL> interpreters just can't cut it.
 DT> What do you think a JIT compiler does? They are very CPU specific. 
 DT> (and OS and JVM specific)
I realise this.
 
 DT> I personally don't feel Java has evolved enough yet to warrant such 
 DT> "ROMming" of the JVM, but that is my opinion only.
I just don't think Java is the answer to everything. No doubt all the lazy
companies will jump on the Java bandwagon and we'll end up with an assortment
of software that could be better, but isn't since it was not written with any
OS or platform in mind.
 
 DT> Every "number" I have ever seen shows that a good JIT compiler will 
 DT> equal the results of running the same app on SUN's CPU.
I don't care about how fast it is compared to Sun's CPU. I want to know how
fast Java code is compared to native-compiled code. The more advaced the JIT,
the more memory it will use and the more CPU it will use, and therefore
decreasing overall system performance.
 
 DT> I am curious. What "add on support" is available for OS/2 to run Dos 
 DT> apps?
If I remember correctly, DOS support is optional during the setup process?
By addon I meant a kind of optional installation extra.
 DT> I am not saying it will run every Dos program, but it does a
 DT> very creditable job of the vast majority
Of course. However text scrolling speed (or maybe it's just OS2's idle
detection algorithms) leaves much to be desired.
 DT> (games having a large class of exceptions, where Win95 has problems too)
Your OS2 counterparts would argue games are just for the kiddies though. It
appears that stress relief is to be denied.
 DT> assembler takes 24 man months (not far off the reality), then that 30
 DT> dollar "app" just jumped to 240 dollars. How many "apps" could you
 DT> own, or could you afford?
Not many.
 DT> The same situation applies to Java, but magnified to multiple CPU's 
 DT> and platforms.
I doubt it. CDROMs were supposed to bring down the prices of software. When
they came out, they could not be pirated, the media was cheaper, less
packaging was needed, documentation could be electronic rather than in paper
form, etc. etc.
However the prices remained static. Same with Java. If developers implement
Java, it will be seen as simply reducing costs of production. They will not
pass on the savings to the customers, they will line their own and their
shareholders' pockets with the extra cash.
AND as an added point of interest, these Java apps (as you say) can/could be
decompiled. Wouldn't this pose a serious risk to the copyright of the source?
Wouldn't you expect plagarism to run rampant if software can be decompiled 
nd
portions of code extracted and reused in cheaper applications?
 DT> How much assembler vs high level code did you say you had written?
Pretty much zilch. I use assembler mainly for string conversions, CRC
calculations, sorting etc. Most of my code is standard Pascal (I never
said I was a decent programmer, I don't have to write tight C code :).
 DT> "Lazy" doesn't describe the whole picture by any means.
Take some games. Wolfenstein, while very simplistic compared to todays games,
was smooth as silk on a 286. But then you look at something like DOOM, which
still has trouble being as smooth on low-end 486's. And the latest games
require P166 w/MMX, 16meg RAM minimum (32 recommended), and hundreds of
meg of storage, even excluding video clips and music.
These could all have been much better if the programmers simply made their
code more efficient. They don't have to be written in assembler, C can still
be optimised a great deal.
 DT> "Computers" would never have come to the level they have
 DT> today if everything was forced to be written in tight assembler.
True, necessity is the mother of all invention. Like I said before, C is
perfect, as long as the programmer isn't lazy and isn't set to ridiculous
deadlines.
 DT> JIT compilers already do this.
Great. They shouldn't be called JITs though.
 DT> If it has to, it will leave it around. But most times it will 
 DT> "discard" the Java bytecodes after the JIT compile.
This is unacceptable. The JIT will have to be in memory for this. Only when
every piece of the code is compiled can the JIT be removed. With standard
JITs (the ones I have read about), the only code that is compiled is the code
that is used/expected to be used. This would create executables with 
ifferent
types of code in it. A straight out, manual precompile before the program is
used it the only acceptable answer (at least, for anything large).
 DT> Now you are starting to get it. But you don't seem to realize that
 DT> this is exactly what is being done today.
The JITs I read about did not include the ability to directly convert the 
ava
code to native code. They were strictly just-in-time.
 DT> JIT is a label, not a definitive description.
Oh? Since when whs JIT a label? I thought it (a JIT compiler) was a class of
compilers. JIT would be the adverb used to describe exactly what type of
compiler it was. JIT isn't a noun.
Regards,
 - Scott
[ admin@cyberia.asstdc.com.au | www.asstdc.com.au/~cyberia ]
--- FMailX 1.22
3:712/848)
---------------