A distinguishing characteristic of Jikes RVM is that it is implemented in the Java programming language and is self-hosted i.e., its Java code runs on itself without requiring a second virtual machine. Most other virtual machines for the Java platform are written in native code (typically, C or C++). A Java implementation provides ease of portability, and a seamless integration of virtual machine and application resources such as objects, threads, and operating-system interfaces.
Woops, should have hit "preview". What I wanted to say was:
Judging from what is said in the atricle I linked, I'd say no:
Second, since the shared archive contains class data in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the original class information in rt.jar is not needed.
You do realize that C++ code can be recompiled to take advantage of a 64 bit word size. What you're missing is that the JVM, in its quest for ultimate portability, defines a fixed 32-bit size for your common integer type. Meaning that java applications do not take advantage of 64 bit precision on 64 bit machines.
The philosophy of Java is, that if you need 64 bit precision, use a datatype that uses 64 bits.
IMO, it is a great advantage of Java that the primitives are declared so precisely.
It sure beats the "how large is an int exactly" mess you get in c/c++.
How long did it takes most linux programs to become 64 bit clean? This was never a problem for Java apps.
Ok, let's say you have a preinstalled JRE. You upgrade your JRE and half the features in your Java App stop working. Your second Java-App needs the new version? Too bad.
Care to back this up with some facts? If Java has done anything, it is trying to stay backward compatible too long. Not a single method that has been deprecated has been removed. There are quite a few Java developers that would like to see the JDK cleaned up of those.
For example, even the entire Swing library hasn't been updated to use JDK 1.2, eg., it still uses Vectors instead of Lists, just for keeping the backward compatibility.
too many things in Java are only available as precompiled packages (open source in Java is a very rare thing)
In your list of pretty run-of-the-mill statements, that must be the must ridiculous one.
Anyone who has done some serious development on Java know that you can develop entire apps using only open source software (except the core classes), as there are many libraries for all kinds of things (webservers, application server, (embedded) databases, or mappers, image libraries,...) available.
As a few people here have mentioned already, Java is the 3rd most used language in Freshmeat projects.
and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.
You don't really share a JVM, at least not on Sun's latest implementation (doesn't the Apple Implemenation actually share the JVM? I'm not sure).
What does happen is that all the core classes get memory mapped to a file at startup, which is then marked readonly. Subsequent JVM's can then also use the same mmapped file, allowing for faster startup and diminished memory usage. This process is explained in detail here.
Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time or something, and programs would just attach themselves to an already-initialized VM;
Startup time for commandline apps has impoved a lot with JDK 1.5^H^H^H 5.0.
The (albeit limited) implemetation of classdata sharing
makes things run better.
All those "omg java is teh suxx0r !!1!111" people should try it once before perpetuating so called facts that stem from the days of JDK 1.O
Re:I hope his book isn't like his webpage..
on
Linux for Non-Geeks
·
· Score: 1
I hope his book isn't like his webpage..
I can't even start to imagine reading a book with white letters printed on black paper.
The pain that would cause would probably make me want to poke my eyes out:)
Speaking of which, didn't the US government during WWII translate some of their top-secret documents into one of the languages of the Native Americans?
Yes they did. Navajo in combination with a code language was used. There was even a bad movie about it.
Learn about pass by reference vs. pass by value. In Java Objects are always passed by reference, primitive types by value. In C++ you have much more control. Specifically objects are passed by value by default leading to sometimes unnecessary copies.
You are incorrect about Java.
In Java, everything is passed by value. You never pass objects by reference, you pass references to objects by value.
If your program have an awt/swing gui, your only way to stop the program is calling System.exit().
That is not true, you just have to assure that the last (J)Frame is disposed of by calling dispose() on it.
Although there was a bug in a certain JRE version that didn't allow for GUI programs to finish correctly, even when all the frames were disposed, IIRC.
There never has been liberty and justice for all.
However, the U.S. has accomplished some great things regarding freedom. The U.S. fought a war against itself to free slaves. Banning slavery was quite rare at that time, and the US started to change that around the world
You have your time table screwed up:
23 February 1807: British Parliament votes to abolish the trade in slaves.
22 September 1862: Emancipation Proclamation issued by US President Abraham Lincoln.
When the Brits abolished slavery, a big part of the British empire and Europe followed their lead. Remember that at that time, the British Empire was pretty much the ruler of the world. IIRC, only Spain and Portugal kept the slave trade going in Europe.
I write C C++ java etc but I have yet to see what the extra cruft adds to these languages. I don't really enjoy tracking down curly braces in heavily nested code.
Any decent Java IDE/editor should have matching bracket highlighting, wich alleviates that problem (unless you have really long/deeply nested methods).
But particularly javax.* is strictly proprietary land, and that includes: servlets, portlets, JSPs, JavaMail, EJB, and JCE to start with.
Wether classes in javax.* or java.* depend on other com.sun.* classes is irrelevant.
What matters is the the API of java.* and javax.* or free to be implemented by anyone. So it's a bit far fetched to call everything in javax.* proprietary. The implementation may be, bu the API sure isn't.
If you write a program using the java.* and javax.* API, you'll be sure it runs on any offical (as in certified) Java implementation. Wether Sun uses some com.sun classes to do this, doesn't matter, the program you write does not depend on those classes directly. Another implementation may use other classes. That is also why a program like Eclipse can run with gcj at the moment. It is written to standard interfaces (not considering SWT), that gcj already happens to implement.
for "real" programming, we have C and C++. Java really hasn't made much of an inroads (most of its penetration is with compsci students), C# has barely made any impact at all, and that seems to be limited by those developers who are tied to the Windows platform and need to generate next-gen windows apps. Perl's been around for a long time and, although arguably the ugliest damn language in common usage today, is invaluable for website programming.
Exactly, that's why there are only 11731 Java projects registered at Sourceforge, which is nothing compared to the 13174 C and 13225 C++ projects. That only makes it the 3rd most popular language for opensource projects. It's just laughable.
And no serious business applications could be written in Java, as we can see by the lack of things like application- and webservers for Java. It also barely has webservices support. If only that J2EE thingy could catch on, Java might have a chance. How could anyone write serious applications with it outside of academia?
I was a KDE user for a long time because it was close to what I was familiar with (windows; yeah, the shame:). Some time ago I switched to Fluxbox at the recommendation of an IRC friend, and learned to set it up the way I wanted it to be (thanks CyberDaemon:).
You're comparing apples and oranges here.
KDE is an entire Desktop Environment that consists of a Window Manager (Kwin), a desktop shell (KDesktop) and lots of programs written for it (Konqueror, Kmail, Konsole,...). It is also a set of API's that developers can use when creating their application.
Fluxbox on the other hand is just a Window Manager, and also lets you launch programs. That's it.
Now when you say
I find that I get a lot more done now than I used to, and the UI doesn't get in the way.
how does that relate to all the programs you're running? And what programs are you running? All that was changed is the window manager and the way you launch programs. A badly designed program will still be badly designed, and it doesn't matter wether you run it under fluxbox or KDE.
Environmental Variables. Java used to have them. But because of the Mac (oS 9 and before, mind younot OSX) it was removed from the language. Instead, we have -D parameters on the command line. Oh Joy. So to run a program with a different config directory than expected I get:
Actually, as of JDK 1.5, System.getenv() is undeprecated (is that even a word?:). I'm sure that was a first in the java libraries though:)
Slashdot Mirror
Congratulations, now how about learning to spell weird correctly? Don't throw that spell checker out yet :)
Wouldn't Kraftwerk's Tour De France Soundtrack be much more appropiate?
I know you're trying to be funny, but they (they meaning IBM) have: It's called the Jikes RVM
From the link:
Woops, should have hit "preview". What I wanted to say was:
Judging from what is said in the atricle I linked, I'd say no:
The philosophy of Java is, that if you need 64 bit precision, use a datatype that uses 64 bits. IMO, it is a great advantage of Java that the primitives are declared so precisely.
It sure beats the "how large is an int exactly" mess you get in c/c++.
How long did it takes most linux programs to become 64 bit clean? This was never a problem for Java apps.
Judging from what is said in the atricle I linked, I'd say no:
Care to back this up with some facts? If Java has done anything, it is trying to stay backward compatible too long. Not a single method that has been deprecated has been removed. There are quite a few Java developers that would like to see the JDK cleaned up of those.
For example, even the entire Swing library hasn't been updated to use JDK 1.2, eg., it still uses Vectors instead of Lists, just for keeping the backward compatibility.
In your list of pretty run-of-the-mill statements, that must be the must ridiculous one. ...) available.
Anyone who has done some serious development on Java know that you can develop entire apps using only open source software (except the core classes), as there are many libraries for all kinds of things (webservers, application server, (embedded) databases, or mappers, image libraries,
As a few people here have mentioned already, Java is the 3rd most used language in Freshmeat projects.
You don't really share a JVM, at least not on Sun's latest implementation (doesn't the Apple Implemenation actually share the JVM? I'm not sure).
What does happen is that all the core classes get memory mapped to a file at startup, which is then marked readonly. Subsequent JVM's can then also use the same mmapped file, allowing for faster startup and diminished memory usage. This process is explained in detail here.
Startup time for commandline apps has impoved a lot with JDK 1.5^H^H^H 5.0.
The (albeit limited) implemetation of classdata sharing makes things run better.
All those "omg java is teh suxx0r !!1!111" people should try it once before perpetuating so called facts that stem from the days of JDK 1.O
I can't even start to imagine reading a book with white letters printed on black paper.
The pain that would cause would probably make me want to poke my eyes out :)
Yes they did. Navajo in combination with a code language was used.
There was even a bad movie about it.
I'm not incorrect. The OP said
while I saidThat's not the same and there's quite a semantic difference between those two.
The way I told it is correct. And even you yourself say:
Now, you're only rehashing what I said, while at the same time saying I'm wrong. You might want to think this over again some time.You are incorrect about Java.
In Java, everything is passed by value. You never pass objects by reference, you pass references to objects by value.
No it isn't, unless you went to the Alanis Morissette school of irony.
That is not true, you just have to assure that the last (J)Frame is disposed of by calling dispose() on it.
Although there was a bug in a certain JRE version that didn't allow for GUI programs to finish correctly, even when all the frames were disposed, IIRC.
One minor correction:
I should have mentioned the following date also:
You have your time table screwed up:
- 23 February 1807: British Parliament votes to abolish the trade in slaves.
- 22 September 1862: Emancipation Proclamation issued by US President Abraham Lincoln.
When the Brits abolished slavery, a big part of the British empire and Europe followed their lead. Remember that at that time, the British Empire was pretty much the ruler of the world. IIRC, only Spain and Portugal kept the slave trade going in Europe.Any decent Java IDE/editor should have matching bracket highlighting, wich alleviates that problem (unless you have really long/deeply nested methods).
Wether classes in javax.* or java.* depend on other com.sun.* classes is irrelevant.
What matters is the the API of java.* and javax.* or free to be implemented by anyone. So it's a bit far fetched to call everything in javax.* proprietary. The implementation may be, bu the API sure isn't.
If you write a program using the java.* and javax.* API, you'll be sure it runs on any offical (as in certified) Java implementation. Wether Sun uses some com.sun classes to do this, doesn't matter, the program you write does not depend on those classes directly. Another implementation may use other classes. That is also why a program like Eclipse can run with gcj at the moment. It is written to standard interfaces (not considering SWT), that gcj already happens to implement.
Exactly, that's why there are only 11731 Java projects registered at Sourceforge, which is nothing compared to the 13174 C and 13225 C++ projects. That only makes it the 3rd most popular language for opensource projects. It's just laughable.
And no serious business applications could be written in Java, as we can see by the lack of things like application- and webservers for Java. It also barely has webservices support. If only that J2EE thingy could catch on, Java might have a chance. How could anyone write serious applications with it outside of academia?
Yes, but it's a negative one :)
You're comparing apples and oranges here.
KDE is an entire Desktop Environment that consists of a Window Manager (Kwin), a desktop shell (KDesktop) and lots of programs written for it (Konqueror, Kmail, Konsole, ...). It is also a set of API's that developers can use when creating their application.
Fluxbox on the other hand is just a Window Manager, and also lets you launch programs. That's it.
Now when you say
how does that relate to all the programs you're running? And what programs are you running? All that was changed is the window manager and the way you launch programs. A badly designed program will still be badly designed, and it doesn't matter wether you run it under fluxbox or KDE.
That's not as far of as you think:
You can create servlets using Groovy.
Actually, as of JDK 1.5, System.getenv() is undeprecated (is that even a word? :). I'm sure that was a first in the java libraries though :)