"1) *The* Java VM is very difficult to port. Java VMs in general aren't, but if you want something that is performance competitive, you need one of the big ones. This is a pain at the application level, but would suck for a systems-level language like C/C++."
I think you're confusing the *java vm* with the *java runtime environment*, e.g.
http://java.sun.com/docs/books/vmspec/2nd-editio n/html/VMSpecTOC.doc.html - approximately compiled (on win32 platform) to << 1mb dll's (could probably squeze it into << 100kb if you wanted to remove some parts- e.g. CDC, using SWT instead of Swing + AWT etc.). If you consider porting this rather few native files hard... ok, so be it - and
http://java.sun.com/j2se/1.4.2/docs/api/index.ht ml - runtime environment which consists of "pure" java classes that when necessary binds with these earlier mentioned dll's. - this classes needs not be ported at all (don't mention bugs please - remember WORA;)
blah, blah interpreteded, blah blah blah
You should really try to investigate *what* makes a program fast - no, native compiling everything doesn't make something faster often quiet the opposite actually. And the.NET vm is actually more interpreted than most people know (for example do a google groups search on what eric gunnarson has to say about the subjet at comp.lang.java.advocasy - he wrote a c# book and is working on.NET project...)
"The problem with the Java VM is really that it's written to run Java, and Java only. All features and optimizations are geared towards this. For a few languages that turn out to have much the same features, it is doable, but for other languages it results in some incredibly ugly - and slow - hacks. CIL:s advantage is solely - but importantly - that it's designed to accomodate multiple languages (sort of the difference between a FORTH processor or signal processor and a general-purpose CPU). "
But the CLI is also a hack!
Check out why (or just replace java with c# in the above rant...) http://www.javalobby.org/clr.html
Not truly objective but the facts still aply - CLI is heavily optimized for C# and no other language.
something like:
String nameOfStupidPerson = null;
try {
BufferedReader br = new BufferedReader(System.in);
nameOfStupidPerson = br.readLine();
} catch (IOException ioe) {
System.err.println("A system problem: " + ioe.getMessage());
System.exit(1);
}
System.out.println(nameOfStupidPerson + " is a dumb ass");
Perfectly safe and a lot clearer than the c++ version...
(and for heavens sake: don't forget checking forexceptions - or else your customers will kill you)
Sure, java have not YET got all the small unix nicities with socket - but asynchronous is there now anyway (chechout jdk1.4beta3 + swt - www.eclipse.org, and you got a choice that is a LOT faster than c/c++ - native gui, interface in java, implementation in c with jni (windows/linux + java portability)
Slashdot Mirror
"1) *The* Java VM is very difficult to port. Java VMs in general aren't, but if you want something that is performance competitive, you need one of the big ones. This is a pain at the application level, but would suck for a systems-level language like C/C++."
o n/html/VMSpecTOC.doc.html - approximately compiled (on win32 platform) to << 1mb dll's (could probably squeze it into << 100kb if you wanted to remove some parts- e.g. CDC, using SWT instead of Swing + AWT etc.). If you consider porting this rather few native files hard... ok, so be it - and
t ml - runtime environment which consists of "pure" java classes that when necessary binds with these earlier mentioned dll's. - this classes needs not be ported at all (don't mention bugs please - remember WORA ;)
I think you're confusing the *java vm* with the *java runtime environment*, e.g.
http://java.sun.com/docs/books/vmspec/2nd-editi
http://java.sun.com/j2se/1.4.2/docs/api/index.h
http://industry.java.sun.com/javanews/stories/prin t/0,1797,16725,00.html ,p rint/0,1797,23836,00.html
http://industry.java.sun.com/javanews/stories/
yada yada yada
Gig of ram per web view? You're totally clueless...
LOL - sure nailed him/her with that comment :)
:)
((s)he probably didn't even get it
blah, blah interpreteded, blah blah blah You should really try to investigate *what* makes a program fast - no, native compiling everything doesn't make something faster often quiet the opposite actually. And the .NET vm is actually more interpreted than most people know (for example do a google groups search on what eric gunnarson has to say about the subjet at comp.lang.java.advocasy - he wrote a c# book and is working on .NET project...)
"The problem with the Java VM is really that it's written to run Java, and Java only. All features and optimizations are geared towards this. For a few languages that turn out to have much the same features, it is doable, but for other languages it results in some incredibly ugly - and slow - hacks. CIL:s advantage is solely - but importantly - that it's designed to accomodate multiple languages (sort of the difference between a FORTH processor or signal processor and a general-purpose CPU). "
But the CLI is also a hack!
Check out why (or just replace java with c# in the above rant...)
http://www.javalobby.org/clr.html Not truly objective but the facts still aply - CLI is heavily optimized for C# and no other language.
ahh, that was what I was saying - "do not forget handling exceptions 'and closing io-streams ;)"
hehe
here you go: ...
...
} catch (IOException ioe) {
... ...}
BufferedReader br =
try {
} finally {
try {
br.close();
catch(IOException ioe) {
}
something like: String nameOfStupidPerson = null; try { BufferedReader br = new BufferedReader(System.in); nameOfStupidPerson = br.readLine(); } catch (IOException ioe) { System.err.println("A system problem: " + ioe.getMessage()); System.exit(1); } System.out.println(nameOfStupidPerson + " is a dumb ass"); Perfectly safe and a lot clearer than the c++ version... (and for heavens sake: don't forget checking forexceptions - or else your customers will kill you)
Sure, java have not YET got all the small unix nicities with socket - but asynchronous is there now anyway (chechout jdk1.4beta3 + swt - www.eclipse.org, and you got a choice that is a LOT faster than c/c++ - native gui, interface in java, implementation in c with jni (windows/linux + java portability)
http://java.sun.com/j2se/1.4 there you go! try not to be blinded by the highspeed hacking though ;)