Jack said:
. Java programs are slower (Swing and JVM)
Urban legend, imprecisely stated in flame-bait fashion.
. Swing layouts are not efficient to get desired result
Assertion requiring evidence.
. There is a memory footprint overhead (compared to primitive sizes)
What doest hat mean?
. The GC freezes the application from time to time
This happens sometimes. Of course, the application only freezes for a moment,
then resumes, and noticeable pauses in every case I've seen have been curable
with deployment policies; no recoding necessary. Lack of GC, OTOH, often
causes non-Java applications to freeze also, and those neither start up again,
nor get fixed without code changes.
. It's impossible to add a method to a JDK class
That's considered a bad thing?
Anyway, it has zero impact. The normal and best-practice idiom in any
platform for API code is to use the class, not extend it, unless, as in the
Java API, you are using one of the classes designed to be extended.
The truth is that the Java standard API contains a mix of classes intended for
subclassing and classes not intended for subclassing. The choice of which was
made by the API designer, and not necessarily for bad reasons. If there is a
valid criticism, it would be directed at specific library classes, along with
a rational explanation of why the API designer's decision was wrong, and why
it's easier and preferable to change the Java standard API than to write code
oneself.
. The difference between checked and unchecked exception
What about it? Are you saying that the fact that there is such a difference
is bad? Are you saying that something about how they differentiate the two is
bad? Should they be more different? Less? In what ways? Why?
Are you even clear what the difference is and what the different purposes of
the two are? What would you do instead, and how would you avoid failing those
purposes? Or would you abandon their purposes altogether? If so, what
advantage would that bring?
. Collections class are badly designed, they try to do too much
Rrrr? (Scooby-Doo noise.)
On the face of it, that's a singularly poorly-framed thesis. Are you
expecting a chorus of partisans to plaintively wail, "No, no! The collections
classes are works of beauty! We worship them!"?
. Starting thread is easy but synchronizing results in the GUI is harder
Luckily Java makes that situation easier than in most languages.
Concurrency is hard, folks. Inherently. Synchronization in any GUI is
harder. People who whine that it's hard probably aren't interesting in
putting in the effort to get it right.
This is not a Java problem. This is a
concurrency-is-hard-vs.-the-lazy-programmer problem, extant in every platform.
. Having to code methods to access fields is dumb, it should be
"transparent"
Very funny.
"Having to code methods to access fields" is not a feature of the Java
language. If people are doing that, it's because there are practical
advantages that they see to the idiom, not because the language requires it.
Whether they are correct or not is a separate question, and not anything for
which one can blame or praise the language.
"dumb" is not an engineering evaluation. Calling a variable "getFeature()"
instead of "feature" is only a few extra characters. Writing "setFeature(
value )" isn't all that much harder than writing "feature = value". Both
these idioms buy maintainability and flexibility at negligible cost.
Five or six extra characters typing to save hours of some hapless future
maintainer's or enhancer's time is hardly "dumb". That's assuming your IDE,
unlike mine, doesn't save you those keystrokes right back with auto-completion.
Anyway, it's up to you to use or not use the idiom. Most programmers use it,
simply because in their not-"dumb" thinking, it's worth it.
. The JDK gives access to a ridiculously small part of an OS features
Words like "ridiculously" are clearly designed to inflame rather than assert.
Put this in engineering terms, please.
In practice, Java and its API have caught on because many people find that
they provide enough to do what they need, and enough more than competing
platforms that they chose Java.
Free marketplaces of languages are more effective than religious wars to
determine "goodness" of a language. Many people choose LAMP with PHP over
Java as a web platform.
. It's not possible to free memory when i'm [sic] sure i [sic] wont use it again
That's not factual. It's not only possible, the JVM generously does that for you.
I hope the next release will address these concerns.
It won't. First of all, it's clear your goal is to flame, and I doubt anyone
inventing Java cares much about that. Secondly, you haven't really expressed
anything concrete that can be addressed. Things that are changing in Java,
such as speed (at which Java has for some time been roughly even with other
languages like C or C++) and GC, are being handled in ways that seem quite
effective. A couple of your comments, like "[t]he difference between checked
and unchecked exception
", don't even express a criticism, so there's
nothing for the Java mavens to address.
Java is far from a perfect language or platform, but the valid criticisms are
pretty specific and technical. Words like "dumb" and "ridiculously" don't
give much handle for productive resolution. Recast in technical terms, with
precise terminology, and for Goddess's sake study the reasons why things are
the way they are before you start taking shots at them. Be careful when
presenting a laundry list like this; get one thing stupidly wrong and you will
cast aspersion on the validity of all your points, even if some of them are
worthy. If you convince people that you are a trollish putz, they will ignore
even your best advice.
