So I gave three examples; Open Office, NetBeans and OpenSolaris.
OpenOffice 1.x is not tied to Java. It can be used without any Java installation. You can use Java to provide additional functionality, but you can also use Python to do this.
OpenOffice 2.x has more Java functionality, but is still in beta, and when it comes out, will work with open source Java - gcj.
NetBeans is tied to Java, because it is a Java IDE! However, it is not tied to Sun's Java - it will work with IBM's, Apple's, HP's, etc.
You ignore the third product I mentioned - OpenSolaris. This is not tied to Java.
No. Sun provides Java implementations for Solaris, Windows and Linux. Companies can license Sun's source code to produce ports of Java for their operating systems. This is what IBM and Apple do. Other companies produce Java independently, such as HP.
This is why the Java versions produced by IBM, Apple and others lags behind the Sun version - it is the time taken to produce ports.
But they don't. E.g. Java Sun Creator 2 EA doesn't work correctly with 5.0 JDK. They (Sun) said: "JDK 1.5 is definitely in the plans for Creator." Really funny...
I'll admit that is pretty bad! I am not impressed, as Sun's NetBeans (which includes an app server and visual design tools) runs on just about any JVM.
Ugh? These are targeted to advanced users or developers, who probably know how to download JVM.
But when you buy a package, you expect everything there.
Almost ever development tool I've downloaded had a Java GUI installer invoked by a script, so I really don't see any reason for providing separate packages for different platforms.
Many applications don't provide different packages for different platforms - Tomcat and JBoss for example. NetBeans does because it is provided as an EXE.
[As for the 'start in minutes and eat all available memory' - that is just silly.]
No, it's reality. Have you ever seen something like BEA WebLogic?
WebLogic is not a typical Java application. It is an application server, and a large complex beast.
[Even a large application like tomcat can start in a few tens of seconds]
Tomcat being a large application? Maybe if you count lines of code or XML config files... I consider Apache being much more complex application and it starts almost instantly.
Apache serves web pages. Tomcat serves web pages and provides significant parts of J2EE as well.
[Even a large IDE like NetBeans runs in 96MB.]
You are kidding, right? Maybe version 1.0 or older...?
96MB was the default setting for version 3.6, which was up-to-date until last year.
[to say 'eat all available memory' is a wild exaggeration.]
Unfortunately not, look at WebLogic or Sun App Server. All those beasts start minutes even on recent hardware and after a few hours eat all the memory you throw at them. I can point you at discussion forums, where several people complained about Sun App Server, when their OS started to swap after less than half a day of development.
Again, these are not typical Java applications. They are application servers - equivalent to operating systems to run Java applications. They grab memory for a specific purpose - to provide cacheing of data and classes to give high performance.
To extrapolate from those to a typical Java program is like comparing Linux to a typical C program.
Simply offering software for free is obviously not good enough; they need to make it totally accessible for it to meet its potential.
I guess the truth of this depends on what you consider is 'good enough'. Java is offered for free, and it has become the most used language for new commercial development, at least for now.
Regardless of the fact that the new alternatives would no doubt mimic Java, the fact that their source would be universally available would give them an edge over the original.
I would suggest that most developers aren't after something that mimics Java. We use Java because the name implies pretty effective compatibility.
That's your answer to the question that blows a big hole in your "pet theory" -- that it's all about people hating Java for political "non-free" reasons. Wow, you really are an idiot, aren't you?
I hope not.
It couldn't be as simple as the fact that most peoples' experience of Java is slow, ugly, bloated and sucky applications. Could it? Nah... it's got to be political reasons.
Yes it has, because any anyone who has actually used Java and developed with Java over the past few years knows, this is a wildly out of date view.
An example of how out of date this is is that the Java IDE NetBeans recently won the developer.com award for best open source IDE. Hardly an indication of 'bloated and sucky'.
Most people use Java daily without knowing it, when they use their banking websites, or chatrooms or sites like E-Bay. Millions of people use Java games on their mobile phones. I hear no complaints about E-bay being slow, bloated and sucky!
I would have said that your point of view would have been correct about 4-5 years ago.
There is no doubt that there is huge 'geek' resistance to Java because it is not open source. Perhaps because of this many such people have not used it for years, and so have a widly out-of-date idea of what it is like.
Moving the backoffice stuff from expensive licenses of Unix and mainframes to Linux is a no-brainer.
No it isn't. There are many very high volume commercial and financial websites that use features of commercial Unixes, such as memory and resource partitioning, self-healing, fault management and very high scalability. Linux will certainly get all these at some point, but until then it is certainly not a 'no-brainer' to move. Even with smaller systems there are many applications that require certain Unix versions.
JBuilder, JDeveloper, Java Studio Creator are. So is Oracle Installer (which was even shipped with 2 JVMs in 9i). My college told me that he currently has 5 or 6 JVMs on his machine. Don't try to tell me that this is not bloat.
These are shipped with VMs because they are intended to be complete products and they don't assume that anyone else has installed a VM. You can configure all these programs to use the same single JVM, providing those JVMs are above a certain specification; they should all work fine with a 5.0 JDK.
You don't need to keep those 5 or 6 VMs on the machine one you have set things up.
I would agree that Oracle is bloat; but Oracle has always been bloated!
What is the problem with zip archive and *.sh and *.bat install scripts?
Because users expect more professional InstallShield-type systems.
I would like to know all those "thousands of substantial applications" written in Java. I can name you tens of real killer OSS applications, but neither of them is written in Java.
I'm sorry, but I don't consider applications which start in minutes and eat all available memory as substantial, but people criteria may be different.
Substantial applications are large applications that do a lot. Almost every large or medium commercial company has important applications written in Java. These almost never rely on a particular VM version (you don't get them requiring, say 'JDK 1.3.1, but not JDK 1.4.2').
As for the 'start in minutes and eat all available memory' - that is just silly. Even a large application like tomcat can start in a few tens of seconds (and considering all it has to load, that is not bad). Before version 5.0 all Java VMs had a default maximum memory use of 64MB. Even a large IDE like NetBeans runs in 96MB. so, to say 'eat all available memory' is a wild exaggeration.
Nevertheless, I still say java is slow. Why? Because I'm actually trying to use it for actual programs on sub-ghz machines.
Modern JVMs produce optimised machine code that can approach that of C++. This process is not dependent on the processor speed. If Java comes close to C++ speed on multi-GHZ machines, it will also come close to C++ speed on sub-GHZ machines.
What might be slow is the Swing GUI, especially with older Java versions.
I was using JDK 1.5-compatible Milestone builds of eclipse 3.1 as much as 8 months ago.
Admittedly, the 1.5 compatiblity wasn't complete at that time, but otherwise there were no problems one might expect with a beta release.
Incomplete support is not real support. There were a lot of features missing (or at least, so I found) until recently in the milestone builds - problems with generics and annotations for example.
Many organisations won't use milestone or beta releases, so the lack of full support in a stable version held back adoption of Java 1.5.
Luis De La Rosa in his 2005 predictions suggested that Eclipse will become the Java community's answer to Visual Studio.NET, as a de facto IDE; this being a good thing for the Java community, as Eclipse will help build a market/ecosystem for development tools much like Visual Basic, which is the real goal that Sun wants to reach: 10 million developers using Java.
Borland's decision to join IBM in basing their IDE on Eclipse is certainly bringing us closer to that prediction! What do you think?
I think that having a de-facto IDE for Java is a bad thing. Java has always been about having a range of choices. There are many who consider that Eclipse's dominance is already having a negative effect. Eclipse has taken a very long time to support the latest Java version, and has held back it's adoption.
What we need instead is a standard way for different IDEs to make use of the same tools, so a plug-in developer can release a single version for Eclipse, NetBeans etc. Such a standard is being worked on.
Or maybe a bunch of us still complain about Java's slowness because it _is_ slow if you don't happen to be running it on a Windows box.
What's the point of a "platform-independent platform" if it's really only meant to run well on one platform?
Interesting. None of the current benchmarks of Java performance show that it is slow on Linux, for example, as compared with Windows. Indeed, IBM's Linux VMs routinely rate as some of the fastest Java implementations.
Perhaps you could provide some code and benchmarks to illustrate the supposed slowness on Linux as compared to Windows?
Throwing extra unrelated stuff in to obscure the point is not the mark of an organized, rational, correct mind. This almost borders on a Straw Man fallacy.
Please don't be so silly. Attempting to classify someone who mentions 'embedded' along with 'real time' as irrational does not help your argument.
Much real-time processing is done by embedded systems. This is where software is included effectively as part of the 'hardware' of the device.
*bashes it into your head* Native code is faster than emulated code
You can compile new code while java is running, so it kinda does sort-of move towards "scriptness" on that dimension. It's not *designed* to do that as a core feature, but it's doable.
Interesting point.
This is exactly how modified JSP (Java Server Pages) files are translated to Java code and then compiled to Java class files while a Web Application is still running.
Unfortunately, it's like trying to run C++ programs through an interpreter on a machine at 3/4 of the power of the one you're using instead of actually compiling and tweaking it for maximum speed and efficiency.
If you ran some actual benchmarks (with modern Java) you will find you are mistaken. Modern Java VMs include an optimiser that tweaks the machine code for speed and efficiency just as you describe. Last year, a set of benchmarks for numerical computation showed Java within 4-5% of optimised C code.
I use Java apps at work and they are often slow and ponderous compared to similar apps written the normal way in C++
The reason for this is usually that some organisations are very slow at upgrading their Java. Java 1.5 was released last year and is generally acknowledged to be fast, both in terms of general performance and GUI speed. Many companies are still using Java 1.3, which is very old.
Most of my experiences with Java is that programs either barf runtime exceptions like crazy or exceptions get silently caught and not handled at all.
Think of the horror of C or C++ programs that had the same bugs but did not throw the exceptions. (I remember developing with C++ in the 80s on MSDOS, and in place of runtime exceptions we got random graphics on the screen, or software jams). Give me Java any day.
There is a slight problem with your logic. 20 years ago C++ was barely a toddler. Nobody used it and it was not generally known to the public.
Nonsense. I was using C++ for development in 1985, as were many others. The c-front translator for C to C++ was released in 1983.
Since when has widespread use of a language been any measure of its performance?
Java on the other hand is 14 years old and people are still talking about its slowness.
Yes, because those who object to it not being open-source have a political agenda to rubbish it. Those of us who actually use it realise this talk is meaningless.
C++ was 14 around 1997 and was widely used and known for its high performance.
Doesn't that say something to you?
Yes, it shows that a lot of developers have a reactionary attitude, and it takes them a long time to adopt new technologies.
It took a long time before developers realised that this 'new-fangled' object oriented C++ could match the speed of C. Meanwhile, some of us had been using it for years.
You're proably stretching the meaning of the word "real time". Components are probably written in Java, but the interrupt control or tight loop governing the "real time" aspects are probably written in another language.
Nice try, though.
A flippant and ignorant attempt to rubbish Java.
Why not do some actual research before posting?
Java has been used in embedded and real-time control systems for years.
Surely a simple pattern recognition system could have caught the fact that she was making a trade way in excess of her usual limits.
or even...
if (amount > big_number) {
if (confirm("This is really big. Are you sure?")) {
[Open Office, NetBeans]
Both of which are tied to Java.
So I gave three examples; Open Office, NetBeans and OpenSolaris.
OpenOffice 1.x is not tied to Java. It can be used without any Java installation. You can use Java to provide additional functionality, but you can also use Python to do this.
OpenOffice 2.x has more Java functionality, but is still in beta, and when it comes out, will work with open source Java - gcj.
NetBeans is tied to Java, because it is a Java IDE! However, it is not tied to Sun's Java - it will work with IBM's, Apple's, HP's, etc.
You ignore the third product I mentioned - OpenSolaris. This is not tied to Java.
Apple does not develop Java. Sun does.
No. Sun provides Java implementations for Solaris, Windows and Linux. Companies can license Sun's source code to produce ports of Java for their operating systems. This is what IBM and Apple do. Other companies produce Java independently, such as HP.
This is why the Java versions produced by IBM, Apple and others lags behind the Sun version - it is the time taken to produce ports.
But they don't. E.g. Java Sun Creator 2 EA doesn't work correctly with 5.0 JDK. They (Sun) said: "JDK 1.5 is definitely in the plans for Creator." Really funny...
I'll admit that is pretty bad! I am not impressed, as Sun's NetBeans (which includes an app server and visual design tools) runs on just about any JVM.
Ugh? These are targeted to advanced users or developers, who probably know how to download JVM.
But when you buy a package, you expect everything there.
Almost ever development tool I've downloaded had a Java GUI installer invoked by a script, so I really don't see any reason for providing separate packages for different platforms.
Many applications don't provide different packages for different platforms - Tomcat and JBoss for example. NetBeans does because it is provided as an EXE.
[As for the 'start in minutes and eat all available memory' - that is just silly.]
No, it's reality. Have you ever seen something like BEA WebLogic?
WebLogic is not a typical Java application. It is an application server, and a large complex beast.
[Even a large application like tomcat can start in a few tens of seconds]
Tomcat being a large application? Maybe if you count lines of code or XML config files... I consider Apache being much more complex application and it starts almost instantly.
Apache serves web pages. Tomcat serves web pages and provides significant parts of J2EE as well.
[Even a large IDE like NetBeans runs in 96MB.]
You are kidding, right? Maybe version 1.0 or older...?
96MB was the default setting for version 3.6, which was up-to-date until last year.
[to say 'eat all available memory' is a wild exaggeration.]
Unfortunately not, look at WebLogic or Sun App Server. All those beasts start minutes even on recent hardware and after a few hours eat all the memory you throw at them. I can point you at discussion forums, where several people complained about Sun App Server, when their OS started to swap after less than half a day of development.
Again, these are not typical Java applications. They are application servers - equivalent to operating systems to run Java applications. They grab memory for a specific purpose - to provide cacheing of data and classes to give high performance.
To extrapolate from those to a typical Java program is like comparing Linux to a typical C program.
Why does it matter? I think Sun wants to confuse the community, and make people think that they are on a bandwagon that they *are not on*.
Considering the amount of open source software that Sun has released - Open Office, NetBeans, OpenSolaris...
I would say that they certainly are on the bandwagon.
Simply offering software for free is obviously not good enough; they need to make it totally accessible for it to meet its potential.
I guess the truth of this depends on what you consider is 'good enough'. Java is offered for free, and it has become the most used language for new commercial development, at least for now.
Regardless of the fact that the new alternatives would no doubt mimic Java, the fact that their source would be universally available would give them an edge over the original.
I would suggest that most developers aren't after something that mimics Java. We use Java because the name implies pretty effective compatibility.
That's your answer to the question that blows a big hole in your "pet theory" -- that it's all about people hating Java for political "non-free" reasons. Wow, you really are an idiot, aren't you?
I hope not.
It couldn't be as simple as the fact that most peoples' experience of Java is slow, ugly, bloated and sucky applications. Could it? Nah... it's got to be political reasons.
Yes it has, because any anyone who has actually used Java and developed with Java over the past few years knows, this is a wildly out of date view.
An example of how out of date this is is that the Java IDE NetBeans recently won the developer.com award for best open source IDE. Hardly an indication of 'bloated and sucky'.
Most people use Java daily without knowing it, when they use their banking websites, or chatrooms or sites like E-Bay. Millions of people use Java games on their mobile phones. I hear no complaints about E-bay being slow, bloated and sucky!
I would have said that your point of view would have been correct about 4-5 years ago.
There is no doubt that there is huge 'geek' resistance to Java because it is not open source. Perhaps because of this many such people have not used it for years, and so have a widly out-of-date idea of what it is like.
Moving the backoffice stuff from expensive licenses of Unix and mainframes to Linux is a no-brainer.
No it isn't. There are many very high volume commercial and financial websites that use features of commercial Unixes, such as memory and resource partitioning, self-healing, fault management and very high scalability. Linux will certainly get all these at some point, but until then it is certainly not a 'no-brainer' to move. Even with smaller systems there are many applications that require certain Unix versions.
Let's see . . . that's . . . [pencil scratching] . . . 1%! Amazing!
Yes, 1% - but 1% of what? If you have thousands of machines, it can be quite a saving.
JBuilder, JDeveloper, Java Studio Creator are. So is Oracle Installer (which was even shipped with 2 JVMs in 9i). My college told me that he currently has 5 or 6 JVMs on his machine. Don't try to tell me that this is not bloat.
These are shipped with VMs because they are intended to be complete products and they don't assume that anyone else has installed a VM. You can configure all these programs to use the same single JVM, providing those JVMs are above a certain specification; they should all work fine with a 5.0 JDK.
You don't need to keep those 5 or 6 VMs on the machine one you have set things up.
I would agree that Oracle is bloat; but Oracle has always been bloated!
What is the problem with zip archive and *.sh and *.bat install scripts?
Because users expect more professional InstallShield-type systems.
I would like to know all those "thousands of substantial applications" written in Java. I can name you tens of real killer OSS applications, but neither of them is written in Java.
I'm sorry, but I don't consider applications which start in minutes and eat all available memory as substantial, but people criteria may be different.
Substantial applications are large applications that do a lot. Almost every large or medium commercial company has important applications written in Java. These almost never rely on a particular VM version (you don't get them requiring, say 'JDK 1.3.1, but not JDK 1.4.2').
As for the 'start in minutes and eat all available memory' - that is just silly. Even a large application like tomcat can start in a few tens of seconds (and considering all it has to load, that is not bad). Before version 5.0 all Java VMs had a default maximum memory use of 64MB. Even a large IDE like NetBeans runs in 96MB. so, to say 'eat all available memory' is a wild exaggeration.
Nevertheless, I still say java is slow. Why? Because I'm actually trying to use it for actual programs on sub-ghz machines.
Modern JVMs produce optimised machine code that can approach that of C++. This process is not dependent on the processor speed. If Java comes close to C++ speed on multi-GHZ machines, it will also come close to C++ speed on sub-GHZ machines.
What might be slow is the Swing GUI, especially with older Java versions.
I was using JDK 1.5-compatible Milestone builds of eclipse 3.1 as much as 8 months ago.
Admittedly, the 1.5 compatiblity wasn't complete at that time, but otherwise there were no problems one might expect with a beta release.
Incomplete support is not real support. There were a lot of features missing (or at least, so I found) until recently in the milestone builds - problems with generics and annotations for example.
Many organisations won't use milestone or beta releases, so the lack of full support in a stable version held back adoption of Java 1.5.
I was actually thinking about my Mac.
Apple has always been rather behind in releasing Java versions.
However, I don't think 'Java is slow on the Mac' is the same as 'Java is slow on anything but Windows'....
I would like to know, why is the parent modded "-1, Flamebait", when all it says is the f*cking _true_?
Because many of us have found it not to be true.
I'm a developer and I can say that almost every Java development tool is shipped with its own JVM.
The most popular Java development tool, Eclipse, isn't. Neither is NetBeans.
And why are those products shipped separately for each platform, when Java is called "cross-platform"?
Because different platforms have different ways of packaging software.
IMO, Java portability is a myth a it will stay so.
Eclipse, NetBeans, JBoss and thousands of substantial applications show that you are wrong.
It's just that Java is too bloody verbose to use it without a friggin' IDE that uses a thousand Amiga's worth of RAM. System.out.print my ass!
was verbose. Java 5.0 is different: you can do 'out.print'.
Luis De La Rosa in his 2005 predictions suggested that Eclipse will become the Java community's answer to Visual Studio.NET, as a de facto IDE; this being a good thing for the Java community, as Eclipse will help build a market/ecosystem for development tools much like Visual Basic, which is the real goal that Sun wants to reach: 10 million developers using Java.
Borland's decision to join IBM in basing their IDE on Eclipse is certainly bringing us closer to that prediction! What do you think?
I think that having a de-facto IDE for Java is a bad thing. Java has always been about having a range of choices. There are many who consider that Eclipse's dominance is already having a negative effect. Eclipse has taken a very long time to support the latest Java version, and has held back it's adoption.
What we need instead is a standard way for different IDEs to make use of the same tools, so a plug-in developer can release a single version for Eclipse, NetBeans etc. Such a standard is being worked on.
Throw java at a large numerical problem and watch it suck really really badly compared to C or Fortran.
On the contrary; I have found that the IBM Linux VM can actually out-perform optimised gcc-compiled C on numerical work.
A major study last year showed that Sun's latest JDK (5.0) was within 4-5% of good optimising C++ compilers running the Linpack benchmark.
Or maybe a bunch of us still complain about Java's slowness because it _is_ slow if you don't happen to be running it on a Windows box.
What's the point of a "platform-independent platform" if it's really only meant to run well on one platform?
Interesting. None of the current benchmarks of Java performance show that it is slow on Linux, for example, as compared with Windows. Indeed, IBM's Linux VMs routinely rate as some of the fastest Java implementations.
Perhaps you could provide some code and benchmarks to illustrate the supposed slowness on Linux as compared to Windows?
[Yes, because those who object to it not being open-source have a political agenda to rubbish it.]
Really? You think that's why it is?
Yes. I have been following this for years, and that is the only reason I have been able to come up with.
Odd, I wouldn't have expected those with a political agenda for open-source to be so enthusiastic about
Me neither.
Throwing extra unrelated stuff in to obscure the point is not the mark of an organized, rational, correct mind. This almost borders on a Straw Man fallacy.
Please don't be so silly. Attempting to classify someone who mentions 'embedded' along with 'real time' as irrational does not help your argument.
Much real-time processing is done by embedded systems. This is where software is included effectively as part of the 'hardware' of the device.
*bashes it into your head* Native code is faster than emulated code
When did anybody mention emulated code?
You can compile new code while java is running, so it kinda does sort-of move towards "scriptness" on that dimension. It's not *designed* to do that as a core feature, but it's doable.
Interesting point.
This is exactly how modified JSP (Java Server Pages) files are translated to Java code and then compiled to Java class files while a Web Application is still running.
Unfortunately, it's like trying to run C++ programs through an interpreter on a machine at 3/4 of the power of the one you're using instead of actually compiling and tweaking it for maximum speed and efficiency.
If you ran some actual benchmarks (with modern Java) you will find you are mistaken. Modern Java VMs include an optimiser that tweaks the machine code for speed and efficiency just as you describe. Last year, a set of benchmarks for numerical computation showed Java within 4-5% of optimised C code.
I use Java apps at work and they are often slow and ponderous compared to similar apps written the normal way in C++
The reason for this is usually that some organisations are very slow at upgrading their Java. Java 1.5 was released last year and is generally acknowledged to be fast, both in terms of general performance and GUI speed. Many companies are still using Java 1.3, which is very old.
Most of my experiences with Java is that programs either barf runtime exceptions like crazy or exceptions get silently caught and not handled at all.
Think of the horror of C or C++ programs that had the same bugs but did not throw the exceptions. (I remember developing with C++ in the 80s on MSDOS, and in place of runtime exceptions we got random graphics on the screen, or software jams). Give me Java any day.
There is a slight problem with your logic. 20 years ago C++ was barely a toddler. Nobody used it and it was not generally known to the public.
Nonsense. I was using C++ for development in 1985, as were many others. The c-front translator for C to C++ was released in 1983.
Since when has widespread use of a language been any measure of its performance?
Java on the other hand is 14 years old and people are still talking about its slowness.
Yes, because those who object to it not being open-source have a political agenda to rubbish it. Those of us who actually use it realise this talk is meaningless.
C++ was 14 around 1997 and was widely used and known for its high performance.
Doesn't that say something to you?
Yes, it shows that a lot of developers have a reactionary attitude, and it takes them a long time to adopt new technologies.
It took a long time before developers realised that this 'new-fangled' object oriented C++ could match the speed of C. Meanwhile, some of us had been using it for years.
Uh, are you serious?
Yes.
You're proably stretching the meaning of the word "real time". Components are probably written in Java, but the interrupt control or tight loop governing the "real time" aspects are probably written in another language.
Nice try, though.
A flippant and ignorant attempt to rubbish Java.
Why not do some actual research before posting?
Java has been used in embedded and real-time control systems for years.