"We don't have method pointers, so we use the method name and reflection"
In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.
"We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit"
Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time. There are usually better ways to achieve the same thing, in both C++ and Java.
"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need"
That is either a gross generalisation, or a bad understanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.
"Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
This is a criticism of bad Java programmers using an object-based technology. You could as easily say "Lets make everything a COM object, and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
Java and C++ are separate technologies, with different strengths. You wouldn't write Quake3 in Java, and you'd have trouble writing a cross-platform, easily deployable, non-memory-leaking business application in C++.
People who cannot understand a technology will do stupid things with it. This applies to both C++ and Java. The difference seems to be that mediocre developers have had more time to become decent C++ programmers than they've had to become decent Java programmers (since Java is newer). Good developers keep an open mind, and decide on a project-by-project basis what the most suitable language/technology is.
Some people are asking "why bother with the DC".
Perhaps a better question is "why bother with Java on a console?"
Java has turned out to be the biz for server-side web development, and enterprise computing in general.
Where Java has not had such a great success is in browsers. Historically, there have been problems with incompatibilities between Java implementations on even the big-name browsers (Netscape, IE). This was particularly a problem with the Java front-end APIs. With all this, and M$ studiously ignoring Java, I don't think it will become any more popular on the browser than it already is.
Java could yet evolve into the platform of choice for desktop applications, but for now it has missed. Who would want to run BEA's Weblogic on a dreamcast?
Maybe it's just me, but I think a 3d desktop is, by its very nature, inferior to a 3d one. When working at my office desk, I prefer things spread out in front of me (2d, like a present-day O/S desktop), rather than having everything stacked all on top of eachother (3d).
The main reason is that if there is space available, things are easier to find when you can see them, rather than having to search through 3d stacks.
This just seems like a solution looking for a problem (and not finding one).
A lot of what you're saying is correct. However, Java was never intended to run lightening-fast Quake clones.
Java is proving itself as a server-side technology, where intelligent servers (as in Enterprise JavaBean servers, for example) can run code that is instantly runnable on other architectures (Solaris,HPUX,etc), VERY scalable, clusterable... I would almost never write server-side code in C++ or C, where portability is an issue, and features such as scalability and clustering are practically non-existant. In such environments, the performance losses experienced by Java is made up for in scalability.
Like it or not, Java is fast becoming the standard language for server-side devleopment.
If Linux does not support Java well, people will just pick some other O/S for their servers. Linux will then be the loser, not Java.
The internet is bigger than the US. When the US put a blockade on the export of strong encryption, did that prevent other countries from adding strong encryption to their products? No, they just made their own strong products. The US, prevented from exporting such products, lost market share in that technology.
I can see the same thing happening if the US tries to police all the internet activity it can. People will just start avoiding US-based internet companies, to the benefit of foreign companies...
Slashdot Mirror
It's about maintainability of the source. Would you write a critical app in a language that you think will be obselete in a couple of years time?
A car manufactured fifty years ago is still compatible with today's roads, but good luck trying finding replacement parts to maintain it!
I think JBoss and Tomcat work well together by design. JBoss handles the EJBs, and Tomcat handles the JSPs.
How could the above be a troll?
You're comparing apples and oranges.
"We don't have method pointers, so we use the method name and reflection"
In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.
"We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit"
Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time. There are usually better ways to achieve the same thing, in both C++ and Java.
"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need"
That is either a gross generalisation, or a bad understanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.
"Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
This is a criticism of bad Java programmers using an object-based technology. You could as easily say "Lets make everything a COM object, and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
Java and C++ are separate technologies, with different strengths. You wouldn't write Quake3 in Java, and you'd have trouble writing a cross-platform, easily deployable, non-memory-leaking business application in C++.
People who cannot understand a technology will do stupid things with it. This applies to both C++ and Java. The difference seems to be that mediocre developers have had more time to become decent C++ programmers than they've had to become decent Java programmers (since Java is newer). Good developers keep an open mind, and decide on a project-by-project basis what the most suitable language/technology is.
Naah, doesn't make a difference in the long run.
M$ has God (in the guise of Mr. Bush) on its side, this is just a temporary stumble.
Some people are asking "why bother with the DC".
Perhaps a better question is "why bother with Java on a console?"
Java has turned out to be the biz for server-side web development, and enterprise computing in general.
Where Java has not had such a great success is in browsers. Historically, there have been problems with incompatibilities between Java implementations on even the big-name browsers (Netscape, IE). This was particularly a problem with the Java front-end APIs. With all this, and M$ studiously ignoring Java, I don't think it will become any more popular on the browser than it already is.
Java could yet evolve into the platform of choice for desktop applications, but for now it has missed. Who would want to run BEA's Weblogic on a dreamcast?
Oops - that should read "I think a 3d desktop is, by its very nature, inferior to a 2d one"
(Sorry)
Maybe it's just me, but I think a 3d desktop is, by its very nature, inferior to a 3d one. When working at my office desk, I prefer things spread out in front of me (2d, like a present-day O/S desktop), rather than having everything stacked all on top of eachother (3d). The main reason is that if there is space available, things are easier to find when you can see them, rather than having to search through 3d stacks. This just seems like a solution looking for a problem (and not finding one).
A lot of what you're saying is correct. However, Java was never intended to run lightening-fast Quake clones.
Java is proving itself as a server-side technology, where intelligent servers (as in Enterprise JavaBean servers, for example) can run code that is instantly runnable on other architectures (Solaris,HPUX,etc), VERY scalable, clusterable... I would almost never write server-side code in C++ or C, where portability is an issue, and features such as scalability and clustering are practically non-existant. In such environments, the performance losses experienced by Java is made up for in scalability.
Like it or not, Java is fast becoming the standard language for server-side devleopment. If Linux does not support Java well, people will just pick some other O/S for their servers. Linux will then be the loser, not Java.
I can see the same thing happening if the US tries to police all the internet activity it can. People will just start avoiding US-based internet companies, to the benefit of foreign companies...