Re: Java/J2EE and the future..

Chris <[email protected]> writes:

> 
> On Tuesday 20 April 2004 7:04, Benj. Mako Hill wrote:
> 
> > It depends on where you are putting the emphasis in that sentence.
> > If you mean it's the best tool for writing *Free* Software, I doubt
> > that you are correct. If you mean it's the best tool for writing
> > Software for non-profits regardless of the effect on your users'
> > freedom, you might be correct as well.
> 
> Let me be more to the point:  All other Open Source tools for writing 
> large-scale, professional business software are entirely inadequate 
> compared to J2EE -- inadequate as in "not even an option."  As far as 
> freedom is concerned, this is really the same situation faced by RMS 
> and other GNU folks in the days before Linux and gcc.  They had to 
> use a proprietary Unix and C compiler as a crutch for a time because 
> it was the only workable option.  I feel the same is true of Java 
> today.

Yes. It's really all about creating the free 'enterprise software stack',
without 'tainted cards' in the middle of it. Enterprises should have an
interested in having control over all parts of their software 'backbone', and
not being depandant on the financial futures of their current software vendors.

There is a lot of effort going into making Kaffe, gcj, and other implementations
catch up with the JDK in terms of missing APIs, and the quelity of
implementation. In large, commonly used parts in enterprise applications, there
was a lot of progress in the last year, leading to successes like being able to
run OfBiz, tomcat, Jetty or eclipse on Kaffe (and other runtimes). The big
missing areas, as you can see on
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html are mostly the
graphics side of things, AWT and Swing, CORBA, sound and security. For security,
you can use GNU crypto, for sound Tritonus, for Swing SwingWT over SWT, and for
CORBA JacORB (I hope). Tritonus is already merged in into kaffe, SwingWT is on
my list of things to merge in when time permits it, same for GNU Crypto and
JacORB. Our AWT implementations will grow quite a bit over the next few months,
as some Kaffe developers are trying to merge in the gtk-based AWT from GNU
Classpath as well as the PocketLinux AWT implementations.

So it's not as bad as it seems, we are not too far from having a rather complete
1.4 free java platform out of the box in Kaffe, in 6-9 months, if we could
attract more enthousiastic developers. Hopefully, we'll have more than one
project offering such a platform by the time Kaffe gets there, so that you could
choose according to your needs between Kaffe, gcj, SableVM, IKVM or others.

> > My guess is that you are speaking in the terms of some sort of
> > compromise. As developers, we each have to choose the role that our
> > users freedom plays in the determination of the platform on which
> > we chooses to write software. Developers clearly make different
> > choices.
> 
> The choice to use Java today would only undermine users' freedom if 
> there were not Open Source implementations in the works.  As it 
> stands, the non-Free Java implementations are still free as in beer, 
> so there's no financial disadvantage during the wait.

There is the not-so-obvious disadvantage of locking yourself into the non-free
solution by depending on non-free code through out-of-spec use of APIs, or use
of runtime-specific APIs, like the sun.* packages. There is a lot of code out of
there that won't run on a free runtime because the developers didn't have a good
reason to come up with a better way of doing things than using an undocumented,
Sun-internal API. So, the longer it takes for you to switch, the larger the
chance that your developers get locked-in into the proprietary solution without
knowing it. 

That happened with OfBiz3, for example, which uses a component (CAROL), that
uses sun-internal classes,and therefore can not run on free runtimes. So it's
not only about 'can I run this on a free runtime' but also about 'will I be able
to run my future development on the free runtime'. Given that most software
tends to evolve, I think the latter question is more important, and the right
answer is to try to switch over sooner, rather than later.

> > 2) Write your software while expanding existing Free tools to
> > include the functionality of the non-free software; This would mean
> > either using Kaffe & GNU ClassPath instead of Sun J2EE or using
> > another language and tools;
> 
> Some Java software is already runnable with Kaffe + ClassPath (some of 
> the Apache project stuff, for instance).  This software is already in 
> Debian, which I think is cool.  There are already complete Open 
> Source J2EE implementations, JBoss and JOnAS, but they require Java 
> 1.4 and Kaffe/ClassPath are at 1.1 + partial 1.2.  I am, of course, 
> using the Open Source J2EE software instead of Sun's.

Yeah, Kaffe is somewhere between 1.1 and 1.4, depending on the API you care
about. It's 1.4-ish enough for quite a bit of Apache software, but there are
still things that need to be implemented, and bugs to be fixed before JBoss runs
well, for example. Having developers on board with a J2EE background would
certainly help a lot (hint, hint).

Jonas didn't run last time around I tried because of CAROL's dependency on some
undocumented sun.* API. OpenEJB breaks quite early since it's developers decided
that they needed to use reflection on the precise names on internal fields of
Sun's implementation to access information that wasn't exposed through some API.
When you implement something in a clean-room fashion, chances are you won't be
able to guess the unspecified bits right. The problem with most of the free J2EE
implementations I tried was that they have dependencies on the 'unspecified
bits'. So a few volunteers that could help out with identifying those bits, and
finding workarounds would be most welcome. Some experience using the free J2EE
solutions would be a plus [1] :)

> > Because (1) involves the least work up front, many developers will
> > choose this. However, I personally don't have confidence in my own
> > ability or stamina to hack on the Java ClassPath to choose (1) with
> > a good conscience -- I'm simply not confident in my own ability to
> > contribute to that project to the degree that it would ensure its
> > success and not willing to live with the consequences of non
> > succeeding.
> 
> Sadly, I don't yet have the skills needed to help either.  My thought 
> is that the Open Source community needs to get together, pool some 
> money, find some sponsors, and see to it that Kaffe/ClassPath are 
> brought up to Java 1.4 compliance sooner than later.

We're pooling together on GNU Classpath, the class library implementaion. There
are also efforts to foster more cooperation between different projects on
runtime components, like jits. I'm hoping to create a performant
mixed-mode-runtime by stacking kaffe over sablevm over gcj. That should enable
your apps to run with a native code core class library, in a state-of-the-art
interpreter, when the code grows hotter to switch over to a quick jitter and if
necessary to compile it down to native code with gcj again. Such cross-vm
integration work would need either an interested sponsor, or a willing hacker
wanting to tackle it.

> The difference in this case, of course, is that the proprietary 
> out-of-the-box toolkit is an open specification just waiting to be 
> re-implemented.


There is some legalese in the specs that's putting some people off, though, like
the 'must pass the TCK' requirement, without the TCK being actually freely
available, and it being contrary to the free-software developement model, where
you gradually achieve perfection, instead of dropping a binary and claiming it's
perfect :)

cheers,
dalibor topic

[1] Yeah, I know I sound like a HR ad for free java, but hey, if you want GNU
Classpath to become a useable platform for your field of endeavour, you need to
donate a little bit of your time and knowledge to make it get there (sooner).