LWN: Comments on "Red Hat CTO: Can Eclipse End 'Java Apartheid'? (eWeek)"

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

hozelda — Tue, 17 Feb 2004 02:45:02 +0000

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).

Java, hip-hip hurray!!!

ptr — Sat, 14 Feb 2004 14:30:44 +0000

The JSDK as delivered by Sun has quite some problems, alright.

Not so bad (in my opinion)

- uses a lot of memory
- requires a long time to startup

Scary

- has occasional hickups when under _really_ high load (actually, I only had those problems with applications using full CPU for about half an hour, with a lot of object allocated and deallocated, but especially in such cases it's _very_ bad that it does such things)
- license issues, not totally free alternative

BUT

- with all their faults: The standard packages of java are a lot better than those of C++. The C++ libraries are a big heterogenous chunk of garbage (arrrg... just look at the interface of istream) I used to like the STL, but well, the resulting programs tend to take as much memory (for the code part mostly!) as java
- Java is a lot easier to debug (ever searched for :: in the type specification which spanned the whole screen? ever hunted a bug which triggered misbehavior at different places whether you used debug or non-debug libs?)
- especially for algorithmic code, Java is _not_ slow. If you are developing any complex data structure, just try out, how surprisingly well Java compares to C++

I hate Java too

ncm — Thu, 12 Feb 2004 15:45:28 +0000

This might be a good place to mention the "I hate Java" group on Orkut.com. It's a safe place to rant without being contradicted by apologists, toadies, people worried about their unwise career choices, or even facts.

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

ohanssen — Thu, 12 Feb 2004 15:24:19 +0000

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.

reviews of Eclipse?

ohanssen — Thu, 12 Feb 2004 14:47:22 +0000

I ask: Who (or what company) benefit from a division between Java and
Open Source communities?

And when mentioning Eclipse, dont forget the Apache project.

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

kunitz — Thu, 12 Feb 2004 11:41:00 +0000

I can't resist to comment.

First thing: Java is slow because linking and bytecode compiling is
done every time the JVM starts. With version 1.5 at least the core
libraries are "precompiled" in shared libs. Yes, it is true, Java
segfaults under heavy garbage collection load. There is some
progress however.

However I still like the language, you can code clean and fast in it
and the library interfaces are reasonable.

But there are a lot of obstacles for a free implementation of Java:

1) Java is a trademark.

It's a pity, that we have a programming language with a trademarked
name. So you can't write a Java compiler but you have to write a
compiler compatible with the Java(R) language (Java(R) and the
Java(R) logo are owned by Sun Microsystems.)

2) There is no Java standard

There is no consistent description of the Java language and
runtime system. It's quite not clear, what are the VM specific features
and what is the standard. That makes it very difficult to have an
user-acceptable open source implementation of Java. It's like the
Wine project, which has to reimplement the whole Windows system
including undocumented behaviour. It might be slow and the
products are expensive,but the ISO process results in quite
impressive and consistent documents, Sun doesn't have those for
Java.

3) Available source has a restrictive license.

Source code for java.* and javax.* classes is available in the J2SE
SDKs. But you can use it only for debugging purposes. The GNU
Classpath project recommends to remove the file with the zipped
source files and never to look at those source. The recommondation
is of course caused by the restrictive license conditions.

4) Sun doesn't want a successful free implementation of Java.

Maybe somebody should ask Jonathan Schwartz next time about it.
Sun regards Java as a proprietary technology which contributes to
little to the bottom line. They stopped the ISO standardization, they
are not contributing to Eclipse and they even "leverage" the brand
by renaming Linux in "Java desktop system". (Never mind that Linux
is a stronger brand than Java, but it is unfortunately not owned by
Sun Microsystems.)

5) Demand for free Java is low

Most Java developers are happy to use Sun's Java VM with Linux.
This fact of course reduces the demand for a solid and reasonable
Java implementation for Linux. From the Linux companies only Red
hat supports the gcj project. IBM has it's own open source Research
VM, but it is obviously licensing Java from Sun for the Power CPUs.

6) Sun lost the sense for revenue.

If Sun would aggressively support a free software implementation of
Java, they could sell an "enterprise" VM implementation including
support. Currently they earn nothing with the runtime environment
because they have to keep and increase the developer base, which
would be a non-issue with a reasonable free software
implementation.

This is all changeable, but it requires Sun managers to change the
perspective. But if this change happens, I'm quite sure, Sun will
shine again.

Just my 2 Euro-Cents.

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

hozelda — Tue, 10 Feb 2004 22:17:17 +0000

"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.

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

hozelda — Tue, 10 Feb 2004 18:52:18 +0000

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).

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

hozelda — Tue, 10 Feb 2004 17:48:54 +0000

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.

Java, hip-hip hurray!!!

XERC — Sat, 07 Feb 2004 00:40:57 +0000

Well, in IT, it's just what the managers find cool. If it's Java and if that's what they pay for, then the developers program Java, if it's Windows, then everybody is on Windows, etc. The real cool stuff is, what people do on their free time and what conserns Java, then one of my school mates said it very well:

" After this fu__ing Java cource is over, I will never touch this awful thing again: it's so slow, it's big, it's fuzzy(can't compile it for a self-soldered platform)."

By the way, I use C++ for all my hobby projects.

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

khim — Fri, 06 Feb 2004 23:40:16 +0000

Ghm. I'm developing Java software and use quite a few Java-based tool at my work. Under Linux, of course. I hate Java.

Why ? It's worse the Windows. It's that simple.

Bloatware. Why I need 10 time more memory to open file in JBuiler then in emacs ? And I'm not talking about "startup memory" - obviously all this bells and whistles need some memory. I'm talking about 530Mb vs 52Mb when all project files are loaded.
Slow. The same emacs can open session with all files in 10-15 sec on my system (and there are quite a few files). JBuilder needs 2-3 minutes to do the same.
Non-working garbage collector. Usually programs use 10 time more memory then needed. When memory limit is reached I do not get slow down as I expect out of "normal" GC when it tries to find memory in jiffy - I usually get crash instead.
Closed and buggy. I spend a lot of time trying to workaround known bugs in jvm, javac, etc. They are known, they are registered but I can not do anything to fix them. And that's not even counting cases where I can not understood - what goes on and can not trace it deep in source like I can with GTK+ or even GTK#.

BTW I use emacs for comparision exactly since it do use garbage collection, it do use bytecode - but it does not become total hog like Java tools.

And I have a lot of problem with Java even for server projects where no AWT, X and window managers are needed so do not talk about "KDE application with GNOME environment". I expect KDE application to work fine with GNOME btw - and while there are some glitches they do work on fixing them, not use it as excuse.

And that's that. I do not know who is to blame but the end result is total disaster: bloated, slow, closed and buggy thing. Used by a lot of people since there are a lot of marketig hype around it. Exactly like Windows. Only worse. May be GCJ and eclipse will fix that, I do not know (Java as language is pretty decent especially with generics added). But so far it's disaster.

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

gsc — Fri, 06 Feb 2004 21:13:38 +0000

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.

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

ballombe — Fri, 06 Feb 2004 16:59:40 +0000

That answer translate to "Java is the way to go".
Fine, it is the kind of answer I got in 1998.

It is still not sufficient to convince me.

About Java move since version 1.1, it look like subsequent versions
came with more and more free-software-hostile terms, and Java API above
1.1 is far from being well supported by free softwares.

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

cpm — Fri, 06 Feb 2004 16:53:49 +0000

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 ;-).

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

cpm — Fri, 06 Feb 2004 16:46:27 +0000

hey zakalwe;

Couple of things. I have been hoping for years that the "java thing" was just that. Me working with dated hardware, always behind the edge a jump or two software wise as well.

Just recently, the company I work for, purchased a "complete document management system" which incorporates a few technologies that use a Canon web interface that is a Java app.

Very recent.

On my machine, a linux box, fully patched and up-to-date on Mandrake 9.1, running J2SE 1.4.2, with and AMD 2800 and a gig of memory, I get a nice grey box that just sits there when I bring the Java app up.

With other boxes, of more or less 2003 vintage which do all other things quite well, I sometimes get a grey box, sometimes get the app interface, that "just sits there" after trying a few tasks, and has to be forced down.
If the box only has the default Win2K base java, it sort of works,

anyway, there are a few permutations, none of which are satisfactory.
And in the cases where a java app does work fine on say, my machine, that doesn't mean it will work fine on another.

This experience has been consistant for me since 1995. Slow, and unreliable. Perhaps in a fully homogenous environment, it will behave well if you have a lot of horsepower. But for us mortals, I don't know. I've just never seen it work well. And, I thought that the whole point, was to *not* be forced into a homogenous environment.

And I still don't like the license.

On the other hand, stuff spoked up with perl, php, tk/tcl, cgi, etcetera always seem to work, without regard to plaform, and perform reasonably.
And I like the licenses. Can't get "real-time" graphs that way, and a few other things, but at least you can get the work done.

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

rfunk — Fri, 06 Feb 2004 16:02:11 +0000

What, has the Java license changed lately to be open-source?

Or is there finally a free and *complete* version of the Java libraries,
so that kaffe and gcj are actually useful in the real world?

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

zakalwe — Fri, 06 Feb 2004 15:45:04 +0000

Wow, I see somebody is still living in 1998, or just enjoy spreading the FUD around.

If it's the first, then you should know that Java has moved on a little from version 1.1.

If it's the second, well, then there is no point arguing with you, just like there isn't any point arguing with Microsoft about linux.

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

cpm — Fri, 06 Feb 2004 15:18:04 +0000

Well,

The one great reason I haven't spent much time with Java is that I don't see
any great reason to spend any time with it.

I don't like the license,
I *really* don't like the performance.
I *really* don't like the way it hangs,
and so on.

I don't see the point, never have.

I work in a world with various Microsoft platforms,
a couple of versions of MacOS, including X,
and a more than just a few Linii (linuxes?)

And have yet to see any java app that functions as advertised.

I for one, wish it would just go away.

reviews of Eclipse?

biehl — Fri, 06 Feb 2004 10:03:45 +0000

Hi,

I'll have a go at your questions.

1) Not easy - the C/C++ editor and toolchain (CDT) http://www.eclipse.org/cdt/ is quite alpha-quality (my subjective feel)

2) Well, when the CDT matures - then this will in all likelyhood be a feature. The CDT is aiming for open integration of tools - and especially Redhat-hackers are pushing for autoconf/automake integration.

3) Yes - exactly as if you are used to the niceties of Xemacs.

4) As make is integrated it should be easy - you could also just run the script from a terminal or a button in eclipse and do a F5 (refresh).
- The eclipse way would be to write a small plugin for that - maybe then hook it to a key-combo (my colleagues tell me that it is very easy to implement)

5) GCJ is not integrated in Eclipse - i anticipate that when the CDT-builder infrastructure works, then someone will find out how to hook up the JAVA-editor to the make backend.
I dont know about the quality of GCJ compiled eclipse - but I'll be looking for it in Fedora core 2 ( http://fedora.redhat.com/participate/schedule/ )

6) Few - unless you are a JAVA-free software developer ( http://sourceforge.net/softwaremap/trove_list.php?form_cat=198 )

As I said Redhat seems to be pushing for integration of the usual FOSS tools and AFAIK have integrated some support for hacking GNOME libraries.

Hope this helps - all knowledge is from the CDT-dev mailinglist, which I read just out of curiosity.

-Anders

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

mcbridematt — Fri, 06 Feb 2004 06:31:49 +0000

I personally use NetBeans myself and I think it's great - 95% of everything I've coded for Jazilla has been done in NetBeans.

The SPL itself is of course - a modified MPL 1.0. And, I, for one, absolutely hate the MPL/SPL. Sun probably chose it to satisfy their lawyers (AFAIK the MPL and the SPL have trademark restrictions inbuilt, along with the Apache License).

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

bignose — Fri, 06 Feb 2004 03:41:35 +0000

> Tiemann also spoke of the divisiveness between the Java community and the
> open-source community, claiming that to be one reason Sun Microsystems
> Inc.'s NetBeans open-source development platform has not taken off and been
> accepted

There's also the trivial fact that the NetBeans license, SPL, is incompatible with the majority of free software.

The crazy thing is that the NetBeans FAQ acknowledges the problems of license incompatibility:

"Source Code (new files or modified files) contributed to the NetBeans repository must be contributed under the SPL. Why can't code be contributed under some other open source license?
It is highly desirable to have the entire NetBeans code base under a single license for simplicity and clarity of use. Separate licenses for contributions would require developers to track whatever specialized requirements flow from each license."
<http://www.netbeans.org/kb/faqs/license.html#FAQ_2>

Why they chose to release under a divisive, GPL-incompatible license in the first place is not explained.

reviews of Eclipse?

stevenj — Fri, 06 Feb 2004 02:19:05 +0000

We've been hearing a lot about Eclipse recently, but I found their website too buzzword-heavy to easily evaluate; it would be great if LWN could do a review of it.

In particular, if Tiemann is serious about using Eclipse to help bridge the gap between Java developers and the rest of the free-software/open-source community, I'd like to see a few questions answered, in no particular order:

Suppose I currently use make/automake, Emacs, gdb/ddd, etcetera for my project (say in C/C++ with various directories of source files, maybe for GNOME or KDE if it has a GUI). How easy is it to switch to Eclipse, and how would I benefit?
- (No, "integration" is not a benefit in itself; be more concrete.)
Free-software developers aren't like commercial developers: they distribute source, not just binaries. If I develop my program in Eclipse, how easy is it to distribute an autoconf'ed tarball that users can simply ./configure && make && make install on any GNU/Linux (and most Unix-like) systems?
- No, we don't want no stinkin' byte-codes.
If I'm using Eclipse, can I still work mainly from the command-line if I want? (e.g. from remote login)
What if I currently generate part of my sources with the help of Perl scripts, etcetera. This is easy with make; how about with Eclipse?
What is the status of using Eclipse with a completely free/open-source toolchain, e.g. gcc/gcj/classpath from top to bottom? Last I heard, Eclipse compiled with gcj was still alpha or pre-alpha quality, and that doesn't address the question of how easy it is to use gcc/gcj from Eclipse.
I gather that Eclipse by itself doesn't actually do much—it's just a "platform" for building IDE's. What are the current best-of-breed plugins to satisfy all the needs of the typical free-software developer?

Anyone else have any questions they'd like to ask? Is there a document somewhere I've missed that explains all this?