Disadvantages of Java

Hi can any one please let me know a few disadvantages of java.?

As compared to... ?

It has four letters. Had it been named "Jav" instead millions of keystrokes and hundreds of dollars in bandwidth would have been saved. Some extremists even advocate "Ja", those lunatics.

Generally speaking:

It is usually slower then some languages, but the reason it is brings many benefits to the table.

It is not nearly as platform independant or portable as many claim it is. There are many platforms that you can not run java on, but you can with other langauges(C for one) which brings me to another disadvantage. It is not the best choice for real embedded programming, although it is great for things like cell phones. It fact, for many embedded projects, Java can not even be considered. You can also make a strong argument that Java is not platform independant at all, but is a platform. Take a language like C or C++, they are easily just as portable, or even more portable then Java is. Stick to standard C and C++ and portability is not an issue. Of course, things like GUI and Socket are not part of those standards, but there are platform independant libraries to cover that.

Your question not specific enough, but those are a few thoughts that popped up.

My biggest complaints are really due to the JVM, it really is great but annoys me. One reason is that it also feels like someone is holding my hand, but there is a lot to like in a managed platform. The other is closely related to the JVM. Many 'non-professional' programmers play with Java, it is not as bad as VB is, but gets ugly. Too many people who really do not know computers are able to learn a tiny bit of programming and get jobs based on shallow certifications. That might sound elitist, but it irks me that people call themselves programmers and don't understand the underlying concepts of computer science. You know the type: "If it is in the library why do I need to learn the concepts/algorithms?"

Anyway, with any language there are plenty of disadvantages. Java is simply a tool. Good for some jobs, bad for others.
[ April 20, 2006: Message edited by: Robert Hill ]

One that I know of, is that in terms of performance it is generally slower because of the need for it to be interpreted by JVM.

This is sacrificed over portability, the same .class can run in Java and NIX machine. It also generally consumes more memory - I would say it's not a bad trade, really - considering how fast processors have become and how expendable RAM's are these days.

Altho, its v easy for a Java programmer to just 'dont care about how much memory the system chew' because the tought of 'just dump an extra gig of mem into it' would fix the problem. Apparently if you do think this way, on large multiuser application, you will see a lot of OutOfMemoryException floating around, once you have some regression/live testing going on.

...

just my 2 cents

Originally posted by Zenikko Sugiarto:
One that I know of, is that in terms of performance it is generally slower because of the need for it to be interpreted by JVM...

Interestingly, Horstmann and Cornell cite this as a "common misconception about Java." They respond...

In the early days of Java, the language was interpreted. Nowadays, except on "micro" platforms such as cell phones, the Java virtual machine uses a just-in-time compiler. The "hot spots" of your code will run just as fast in java as they would in C++.

~Core java 2, Volume I (7th edition, 2005).

Likewise, this is another misconception:

It is not nearly as platform independant [sic] or portable as many claim it is.

Java, the specification(s), are completely platform independent. It is when users and implementers - of the platform step outside of the specification - usually inadvertantly, that one can observe effects that are attributed as "Java must not be platform independent".

It is not the user's fault that the specification(s) are ambiguous (implied by English). Of course, one can find what appear to be explicit platform abstraction leaks all throughout the specs (especially the API spec.), but still this "leak" remains within the context of "the Java platform", and does not impose itself on the underlying platform in any way at all (despite intuition) implied by the definition of the Java platform itself (and not an arbitrary intuition or personal internalisation).

It is not the fault of the employees of IBM who implement the specification, get it wrong - they are extremely unskilled - what does one expect? Sociologists who attempt to explain corporate culture might postulate that this inherent lack of skill also applies to Sun Microsystems, but I won't speculate, because I am not a Sociologist nor an employee of Sun. In simple terms, set your expectations lower, and it all starts to make sense.

Originally posted by Ken Blair:
It has four letters. Had it been named "Jav" instead millions of keystrokes and hundreds of dollars in bandwidth would have been saved.

Microsoft tried to make use of this with J++, but surprisingly it died nevertheless...

Have to comment on this one...

You can also make a strong argument that Java is not platform independant at all, but is a platform. Take a language like C or C++, they are easily just as portable, or even more portable then Java is. Stick to standard C and C++ and portability is not an issue. Of course, things like GUI and Socket are not part of those standards, but there are platform independant libraries to cover that.

In practically all cases, involving GUI on windows, a C or C++ program written with one IDE will not work on another. Too many compiler specific pragmas, like those needed for MFC. And this is for the same machine !!

Not saying that Java doesn't have some platform portability problems -- but c'mon... worse than C/C++? Frankly, I think it would be much easier to work with the 99.44% of Java that is compatible, than to "stick to standard C and C++".

Henry


Henry

Originally posted by Robert Hill:
Take a language like C or C++, they are easily just as portable, or even more portable then Java is.

The code may be portable but the programs are not. You have to compile C or C++ programs specifically for each platform. Java "programs" (class files) do not need to be recompiled between platforms.
Cross-platform libraries are problematic as well as they usually require seperate installs. For example, install the Gnu Image Manipulation Program (GIMP) on Linux and Windows. Not only do you need the platform specific executable, but also one must seperately install the platform specific dependencies (GTK, GLib and so on).

I love it when people who assume Java is too slow or slower than X come across benchmarks that show Java can be faster than C. They're gobstruck. Many people view C as a physical constant, like the speed of light (that's lowercase C ). How can anything be faster than the speed of light? Hmmm... Java's HotSpot compiler and GC strategies can, in some settings, outperform C's static optimization and malloc/free routines.

And in any case, don't fixate on performance (said the tart to the vicar?), unless your profiling shows it is an issue.

The same people generally can't accept that FORTRAN is hella faster than C (for operations involving large arrays and matrices, anyway.)

Originally posted by Ilja Preuss:
Microsoft tried to make use of this with J++, but surprisingly it died nevertheless...

... so they could shorten it even further to J#.

Originally posted by Jeff Albertson:
...benchmarks ... GC strategies...

Benchmarks can be skewed to favor GC languages if GC doesn't occur during the benchmark. Dynamic garbage collection can be problematic in some environments because of the lack of predictability - you never know when it will strike and how long it will take.
[ April 21, 2006: Message edited by: Peer Reynders ]

"Java, the specification(s), are completely platform independent. It is when users and implementers - of the platform step outside of the specification - usually inadvertantly, that one can observe effects that are attributed as "Java must not be platform independent"."

Java is NOT platform independant. It is dependant on a compiler and JVM It only runs on platforms for which there are compilers and JVM. This number is far less then the number of platforms that support C for example. Yet, many think C is not.

If these are not available on a certain platform, guess what? Java will not run on it.

There are a few(very few) classes in the API that behave differently on different platforms.

Originally posted by Henry Wong:
Have to comment on this one...



In practically all cases, involving GUI on windows, a C or C++ program written with one IDE will not work on another. Too many compiler specific pragmas, like those needed for MFC. And this is for the same machine !!

Not saying that Java doesn't have some platform portability problems -- but c'mon... worse than C/C++? Frankly, I think it would be much easier to work with the 99.44% of Java that is compatible, than to "stick to standard C and C++".

Henry


Henry

Use MFC and you deserve the headaches that come with it.

Have you heard of WxWidgets or QT? Both are C++ platform independant implementations of a GUI library(also has Socket functionality). It is write once, run anywhere, as much as Java is. Of course, you have to recompile, but that is no big deal.


There are many platforms that simply can not run Java. It might be due to a lack of Java tools for that platform, but often as not it is because java on a specific platform is not workable(mainly embedded devices).

Of course, you have to recompile, but that is no big deal.

i thought that this is exactly what is meant by java being platform independant... you compile it once, and can deliver the SAME FILES to ANY platform that has a JVM (assuming it is written within certain parameters).

you can't do that with C. And that is the point. or so i thought.

Nobody mentioned yet that in the quest for portability Java deliberately left out access to system-specific things. You can't directly call Windows APIs or COM or DDE or 3rd party DLLs. I don't know Unix well enough to know what you can't do there. If you really need to get "down to the metal" as the C and assembler folks like to say, you'll need to get out of the JVM to do it. Java business logic with a small number of JNI calls to custom C code is a pleasant enough architecture.

Originally posted by Ken Blair:
It has four letters. Had it been named "Jav" instead millions of keystrokes and hundreds of dollars in bandwidth would have been saved...

Similar optimizations have met with curious market resistance. For example, the language represented only by an empty String never seemed to take off, despite the obvious advantages. Indeed, when I tell prospective employers "I can program in _______," they typically respond with quizzical expressions.

Marc, is _______ realated to Whitespace? That's the language I prefer for maintainability.

Originally posted by Jim Yingst:
Marc, is _______ realated to Whitespace? That's the language I prefer for maintainability.

Yes, _______ is an optimized version of Whitespace. In particular, tabs and spaces are ignored by the compiler (although _______'s precise treatment of newlines remains a matter of contention). Also, because the _______ VM is restricted to the conceptual subtier (CST) of the CPU, there is virtually no cycle time associated with execution.

I've deployed incalculable programs using _______, and have yet to encounter a single error (even on Windows machines).

(Thanks for the link! )

Originally posted by fred rosenberger:
i thought that this is exactly what is meant by java being platform independant... you compile it once, and can deliver the SAME FILES to ANY platform that has a JVM (assuming it is written within certain parameters).

you can't do that with C. And that is the point. or so i thought.

That is EXACTLY the point. Who says compiling is no big deal? There's this package we use here at work; it was written by some people in Europe and it's in Java. Now these people have never heard of the IBM iSeries, but it has a JVM so I took their package and ran it on the iSeries and it works just fine. I didn't have to pester them to release an iSeries version.

If they had had to get an iSeries compiler and an iSeries machine to run their tests on, I wouldn't be using their package. Because they wouldn't have done that.

The same goes for all those open-source packages I am using to do PDF and Web Services and other things that I have forgotten about because they Just Work on our iSeries machine. No, you can't do that with C.

Actually, I would say that lingering misconceptions are perhaps the biggest disadvantage Java has today. Especially perceptions of it being a slow interpreted language that's not good for much more than applets.

Has anyone been on eBay?
Looks as though Java performs well enough to run on one of the busiest websites on the net.

Originally posted by Vasilis Karas:
Has anyone been on eBay?
Looks as though Java performs well enough to run on one of the busiest websites on the net.

Excellent case in point! eBay's performance is simply amazing, and if you click on eBay's "Java technology powered by Sun" icon, you will see...

eBay is Java� Powered running on powerful Sun Fire UltraSPARC� and AMD Opteron� servers supported by Sun services and solutions. eBay has chosen Sun�s Solaris Operating System, the most advanced operating system on the planet, and its Sun Fire servers to help power The World�s Online Marketplace.

Originally posted by Robert Hill:
"Java, the specification(s), are completely platform independent. It is when users and implementers - of the platform step outside of the specification - usually inadvertantly, that one can observe effects that are attributed as "Java must not be platform independent"."

Java is NOT platform independant. It is dependant on a compiler and JVM It only runs on platforms for which there are compilers and JVM. This number is far less then the number of platforms that support C for example. Yet, many think C is not.

If these are not available on a certain platform, guess what? Java will not run on it.

There are a few(very few) classes in the API that behave differently on different platforms.

This reasoning is flawed. Try digressing a little and apply the same reasoning to other things (e.g. try a CPU and what it depends on) only to come up with a conclusion that is apparantly absurd (though maybe correct under a new definition/axiom?).

They (yes them) should teach logic in school, instead of the inverse on tv.
*unruffles feathers*