Red Hat CTO: Can Eclipse End 'Java Apartheid'? (eWeek)

Posted Feb 6, 2004 9:53 UTC (Fri) by cpm (subscriber, #3554) [Link]

Further, (I'd edit the other one if I could)
I am not natively hostile to java. I don't like the license, and think it is overly restrictive, and feel that the license is one of the things holding it back. That said, Folks who code in it, really seem to like it, I just wished
it worked! I have never seen anything that promised so much and delivered so little as java, except maybe CRM ;-).

Posted Feb 6, 2004 14:13 UTC (Fri) by gsc (guest, #6830) [Link]

I have not seen your Cannon application, but I have seen similar results. I'm unsure of the root causes, but I think Java doesn't always play well with all the different window managers out there. I don't know if this is a JVM issue (and there are different JVM's) or if it's more to do with the WM.

Although this must be irritating for you, I still feel Java is an excellent language. Do you expect applications compiled for KDE to be well behaved when you use Gnome? I think this is analogous to what you are experiencing.

As for the runtime cost, JDK 1.3 and later is very good. The first Java application I wrote (1997) was very slow and we ended up throwing it away.
Not a great start, but that seven years ago. I use it for nearly everything now, and I like it.

Posted Feb 10, 2004 11:52 UTC (Tue) by hozelda (guest, #19341) [Link]

When a java applet doesn't work, it probably really doesn't work on just
about any browser or host which is a little incompatible. Html is different
because it attempts less as a standard (it is much more limited in scope)
and the way it is designed (declarative in nature) bad or nonstandard html
peppered throughout usually does not mean complete destruction of the
whole html "program." That is obviously not the case with java/applets (a
comparison of java to javascript or perl would make a little more sense).

I posted a reply below to a different poster that is relevant here, and I don't
want to repeat it. A main point was that Java tries to be a standard like C
but doesn't do as good a job. Perl and many other oss projects don't
attempt to be a standard, but that is irrelevant as they usually involve only
one code base (and which is open to peer review).

I know that there is ambiguity and incomplete information on sun's site
which supposedly is the standard. This concerns principally the libraries
and there are a lot of them. This necessarily leads to cross-platform
inconsistencies which can certainly lead to a gray box [maybe that applet
was done using J++]. I for one had a recent applet gray-box until I
remembered to .setVisible(true) possibly even .setSize(..). On different
development environments or running platforms, even wether a container is
set to visible and then has a layout manager added w/ or w/o components
or vice-versa (i.e. setVisible afterwards) may make the difference on what,
if anything, is rendered. Consider further that different platforms may have
a different set of defaults so that a program/applet may only work properly
on a platform with a particular version of defaults. With the setVisible
example, it is certainly possibly that one jvm/lib flavor may automatically
render visible under some circumstances which would convince that app
makers that the program worked. A different jvm/lib/browser set may not
render anything or may fault elsewhere leading to the same effect (not
rendering). Some of these problems can involve bugs but many others
may signal problems in the so-called standard. Java is very very large in
scope, has changed quickly, and is relatively young. [not to mention that a
significant part of the perception is sometimes based on experiences with
older versions]

AND the different versions of java are not compatible with each other. This
is very unfortunate but has been the tradeoff in trying to improve java
quickly. Unfortunately, it is not a good idea (yet and perhaps for some
time to come) to develop an app on one platform and expect it to work
well on other platforms without testing (despite the "promise"). "Different
platforms" refers to differences among the various software layers (in
addition to hardware differences), including different os versions/vendors,
jvm versions, jvm vendors, wm v/v, etc..

Additionally, java is not an oss project as much as it could be (and Sun's
intentions most likely were never to have that be strictly that case if at all).
Any comparison to php, perl, etc would be as much a comparison of
proprietary vs oss. Each has pro's and cons.. anyway, java development
should become more and more cooperatively oss based.

On the enterprise end, java has made things much easier for many
programmers needing to deal with mixed environments while providing
security, transaction capabilities, etc.. (things that would otherwise be
ignored or lead much more to vendor lock-in).

Probably the main reason java has as much of a bad rap as it does is
over-promising. Java is not VB on Windows as it is sometimes sold. Java
projects just need to factor in less assumptions (despite promises) and
treat java more like C++ on drugs (he he).

Posted Feb 10, 2004 10:48 UTC (Tue) by hozelda (guest, #19341) [Link]

They say, "the right tool for the job." This applies with java. Java has,
amongst other things, a security infrastructure that I don't think emacs has.

My point isn't to state that JBuilder is a good product, but that you are not
comparing one Java implementation to another; you are comparing
apples to oranges. OK, you can make comparisons to prove some points
but you can't X out java on your 4 arguments.

Numbers 3 and 4 are implementation problems and have more to do with
Borland, Sun, or anyone else as implementors of their products. Over time
these become non issues as many previous issues have so become
(especially with machines that get faster and faster and bugs that get
fixed).

Numbers 1 and 2 are a combination of implementation "problems" and
Java spec requirements.

It would be nice for the standard (which leaves to be desired at least in
some areas.. and especially if WORA is desired) to evolve to where more
flavors would be accepted.. so that for example, a Trusted Java
environment would come with little overhead by way of security checks (not
to downplay security but it isn't always needed in the same dosages --
and notice I am using "Trusted" in the opposite sense as Microsoft's
similarly named endeavor -- to mean that trust is assumed on the network
or taken care of somehow without the need to involve the JVM/libraries.
Possibly though, the cure to some of that overhead is oss) .. in any case,
evolution and increased involvement in open source fashion will continue
to improve Java.

I do think that the java language sometimes encourages inefficient
programming.

The standard is also not defined well enough (in the area of the libraries:
java, javax) and I think this is a significant source of problems across
platforms.. but serves to sun's advantage if they can get their version to
dominate on the major platforms. Here, ISO standardization, while a
major drawback to the evolution speed of java (which is important), would
nevertheless help achieve better behavior across platforms and would
make it clearer who is to blame. [Sun's gain is that the blurry line between
standard and implementation (as currently defined) would be insignificant
if Sun's "feature" creature would become the de facto ....]

If a comparison were made to Perl, I believe Perl's "standard" is the
source code itself and the experience and good sense of the current core
developers (so that they maintain or at least pin-point and document
issues with compatability), plus to a lesser extent the docs. Perl is an oss
project with no major forks. Java on the other hand involves many fork-ish
things based on a standard that is much more incomplete and ambiguous
than say the C ISO standard. You either get a solid standard, a unified
code base, or Java.. but then java evolves the fastest of the three (Perl, c,
java) and that is part of its value.

The cure: consider what might be the best tool (consider ./configure-tarball
alternatives to solve cross-platform issues). Java has strengths and
should only get better in many of its weaker areas as it becomes more
oss based.

Posted Feb 10, 2004 15:17 UTC (Tue) by hozelda (guest, #19341) [Link]

"And I have a lot of problem with Java even for server projects..."

Just some comments on the above.

This link,
http://www-106.ibm.com/developerworks/library/j-nioserver/?ca=dnt-55 , to
a recent article gives an idea of a class of problems that may exist in java
based servers created with pre-1.4 "technology" or simply, without the use
of NIO.

Part of the conclusion from the article is that without the use of
nonblocking sockets (the only option with earlier versions of java), servers
were forced to create a new thread for each connection in order to provide
good throughput to clients (in parallel). The problem with this is that the
thread stayed around so long as the socket remained open (i.e. as long
as the session lasted). [I suppose the session state could be saved in
order to reduce threads but.. anyway the article discusses servlets not
ejb's.]

With NIO, you have one thread which serves as the point of contact with
the underlying os/hardware, to and from which all network connections
pass. There is no need to have very numerous threads doing this job (in
the example, I think only one "main" thread handles this task.. didn't read
whole article carefully yet). The job is simple. This main thread keeps no
state of each connection, it simply receives and dispatches appropriately.
The overhead associated with a full thread context switch is certainly not
necessary (neither for program efficiency nor for ease of programming)
and is trully overhead saved. [The key is that there is no blocking on each
request by that main thread, so few threads (maybe just one) are needed
for the job of babysitting connections for traffic.] Where threading plays a
part is exactly were it should (and most probably where it would if the
server were coded in C on say "unix"). Threads are added based on the
active load at any given instance. Here "active" doesn't refer to an open
connection but to a connection either currently involved in an actual
transfer of http material or currently processing the work of such a request.
Compared to the total time that all connections remain opened, an active
event/connection lasts much less time and so can be handled efficiently
(without blocking) by a relatively smaller number of "backend" reusable
threads.

[Once again: In the old system, a few number of threads would mean that
a few connections inactive would tie up those few threads in a wait state
while all other clients would not get a response.. thus, in practice, many,
and not just a few, threads would be used. Threading is not the most
expensive of things but there is apparently/potentially/probably some
added cost to having numerous threads (keep reading for examples).
Async io means that threading is not necessary as the mechanism of
waiting on input; the waiting or "blocking" doesn't happen, and it is instead
the responsibility of the application to return and query the socket again at
a later time, as frequently as necessary. This process of sending
"messages" and returning immediately (aio) without the need to save
thread state (as would most likely be the case in blocking io since all the
io won't be received (to unblock the caller/thread) before a new connection
needs to be handled) increases responsiveness to clients, especially
when the load is "high" and the main thread can serve several requests in
a row before a thread switch occurs (assuming threads don't each have
their unique processor -- a good assumption). For some cases, it is
preferable or irrelevent to just have the application (or sole thread) wait
without doing anything else, but clearly a server can't block on the socket
for a single connection "as long as it takes" since its whole job in life is to
service as many connections as possible with quick response time. Thus
to do a good job, the server spawns a new process, spawns a new
thread, or uses async io and puts just one thread to do the looping. The
latter is most likely the most efficient (eg, if one processor can be used
solely to handle aio then that processor's cache is consistently more up to
date.. a definite speed up.)]

Java didn't gain anything that was not already an efficiency in numerous
operating systems/libraries. What it did gain was ..on the lead that C and
other languages/platforms had over java in this area (async io) because
java did not previously provide a way for applications to take advantage
of aio (this wouldn't be an implementation issue, as the semantics
associated with blocking io are not interchangeable with those of aio). I
am not saying that NIO solves all of Java's problems on the server side. I
am saying that Java continues to improve a lot in important ways, and that
complaints against it would not hold as much water on current
implementations of java-based software (if done properly) as they did at
the time the complaints were first uttered.

Java is supposed to make life simpler for groups of programmers/
organizations in a number of ways, and that it does in a lot of cases I
believe. I don't think, for example, that it is that different to get javascript to
be portable as it is to achieve portability using java applets. In either case,
you would probably be very surprised with the lack of results if proper
testing was not done. And perl and html do not replace javascript/java.

Posted Feb 12, 2004 8:24 UTC (Thu) by ohanssen (subscriber, #2761) [Link]

A "bad" IDE like JBuilder or Visual studio can generate a lot of
frustration. My approach. An editor (like for instance Emacs), make and
Sun JDK. Eclipse is promising, however.

The improvements to the Java language which is expected to come with 1.5
are significant: Generics, etc.

Posted Feb 16, 2004 19:45 UTC (Mon) by hozelda (guest, #19341) [Link]

I address points 1 and 3 with these links (the second can be reached via
the first link):
http://www-106.ibm.com/developerworks/library/j-jtp01274.html?ca=dnt-54
http://www-106.ibm.com/developerworks/library/j-pj2ee10.html?ca=dnt-54


1: Potential Myth: jvm uses too much memory.. java apps are memory
hogs!

I think a reason the jvm may use up so much memory (and this is
probably tunable at startup time via the command line) is that the jvm does
its own garbage collection and the techniques require (I'm pretty sure) that
it ask for a large chunk of memory from the system at one time, then it
parcels this out as necessary. In effect, java apps on linux mean that both
glibc and rt.jar(?) manage system memory... besides the system itself of
course. Glibc just doesn't ask for as much at one time (I think) and may
share it amongst all apps linked to glibc (may not though).

Maybe instead of one large chunk though, the jvm asks for exponentially
larger chunks as objects are created (java apps would be expected to go
through objects/heap space quicker than c++ or c apps, which have a
different programming paradigm and have free() or equiv.); Eventually, the
jvm may stop asking and garbage collect. Maybe this last part didn't
happen with a crashed app or bad jvm, but there is another possibility
which is addressed by (3:) comming up.

Reference the first link above for some surprises about how future jvm's
from Sun and others may actually alloc/dealloc from the heap more
efficiently (faster) than the equiv by c libs (malloc et al). To use these
techniques efficiently, the jvm must handle memory in large parcels instead
of relying on many malloc calls (or equiv).


3: Potential Myth: JVM gc doesn't work.

Read the first half of the second linked article above. Basically, it is more
than very probable that the problem wasn't/isn't with the jvm but with the
app programmers who created many objects without releasing the
references to these objects (or objects to objects to objects etc). This can
happen in C++ too and is refered to (in article at least) as "unintentional
object retention" and not the related but different "memory leaks" problem.
BTW, references are released usually just by going out of scope, but can
be released explicitly by "objXXX=null;" .

Reading the bottom half gives one example of where very large objects (in
a possibly correctly written app) not explicitly made =null will slow app
down over time. Probably though this could have been avoided without
creating problems for the rest of the app if bigObject was local, but
bigObject is probably needed outside the test() method.. anyway, studying
these cases helps understand and prevent slowdowns and memory
problems in java apps. [follow the link:
http://www.javaspecialists.co.za/archive/Issue060.html to understand the
example better..]

The article has a link at bottom
(http://www-106.ibm.com/developerworks/java/library/j-leaks/ ) that refers
to this same "unintentional object retention" problem by the phrase
"memory leaks". In other words, 'memory leaks in java' are not the same
as the c/c++ case where an object is no longer referenceable but the
memory did not get released (i.e. there is no runtime gc support that
actually goes around testing to see what is referenceable and what is not..
so c/c++ programs suffer from the two types of so-called memory leaks,
the one with unreferenceable unreclaimed memory and the one with
unintentionally (i.e. no longer used by app in any meaningful way)
referenced memory that should have been released).


These articles have reference links that are interesting. Also there are sites
and newsletters dedicated to java and java performance and java
whatever, which can be consulted when trouble arises or even as
preventive measures.


In general, because of numerous things going on behind the scenes in
jvm's (like array subscript checking), optimizing java apps can be a
challenge since lots of these things are not obvious and the jvm/rt source
code isn't available.. on the other hand, many things are managed
automatically and this makes programs (at least those that are object
based) stronger and easier to code and maintain. Learning to optimize
java apps means reading up on current practices but (as articles above
indicate) is becoming less and less necessary with each mew version of
jvm released.

Other runtime environments also have support for gc, array bounds
checking, etc. These may be preferable to java or not depending on the
situation.


Also of relevance may be the following recent article:
http://linuxtoday.com/it_management/2004021600226OPSWDV .


UPDATE: the link:
http://www-106.ibm.com/developerworks/java/library/j-leaks/ actually
answers some of the 1: 3: issues more authoritatively than I just did. In
fact, when I finish reading that link I will probably go back and get rid of
all the "I think" written around here. Example:
"Chances are that the garbage collector will not even be invoked before
the application closes, because the JVM will probably have plenty of
memory to create all of the objects needed by the program with leftover
memory to spare."
In other words, the jvm asks for a bunch of memory from the system that
the app may not use.


Disclaimer: I am only slowly figuring out what is the best tool for the job. I
am not a big java programmer (and don't work for Sun etc).