Slashdot Mirror
Sun Works With Apache Software Foundation
The Jakarta group had raised some concerns over the proposed Java Specification Participation Agreement. After some hemming and hawing, it appears that the Java Community Process chair (Sun) has agreed with the ASF's concerns - but IANAL ? . If you have more info, paste it below.
Jakarta's Tomcat was threatened, and, from someone who works in the J2EE market, that woulda been baaaaad. Tomcat is great for prototyping and working at from home (trust me, you don't want to lug Weblogic or Websphere onto your home machine).
With Apache representing such a massive (and impressive, they are certainly a great example of success)number of internet/intranet servers out there, I'm not suprised Sun takes them seriously, they probably represent one of the strongest areas of java development currently.
I would truly love Sun to take java *implementation* a little more seriously, they seem to put a lot of work into API designs and the legal situation of java, but don't seem that commited to providing a stable and simple to install environment for developers and users.
The number one bug bear I have repeatedly hit with java is convincing users that it is worth the trouble to get the 'right' implementation installed on a given machine to allow the required functionality to work, and this can sometimes be hit and miss, which is a big problem.
I would love to see Sun dedicate perhaps 6 months to working with other implementers to get java working smoothly and seemlessly on a wide range of hardware and operating systems, as it just doesn't seem to yet.
I know that microsoft has thrown a lot of hurdles in the way of java, however it's not just windows where there seem to be problems. It is just too hard to get users to get their execution environment 'right' to use.
I think this situation will limit java to vertical apps and server use until it is addressed, as these are the only situations where the extra time to get it working is acceptable.
It really looks like Sun went above and beyond the call of duty here. I doubt Apache expected them to use $3 million of their own money to help fix this, but they did it anyway because it turned out that that was the only way to fix issue #4 on their list. Pretty cool. Chalk up one Open Source Brownie Point for Sun.
I figured this would happen eventually. It seems all Web Server software (other an IIS of course) will merge to become an Application Server. Well, not as much merge but mature.
This happened last year with the relase of ColdFusion Server 5.0 which had a built in J2EE Aplication Server. This gave ColdFusion programmers the platform to incorporate Java into their CF apps (but if they were smart they'd use it as a springboard to merge all apps over to Java).
This will probably be a big step forward for Apache and I'm interested to see whats cranked out.
Almost all installers now provide a way to wrap the java application in such a way that this is abstracted from end users...
; .
Also, if you don't use an installer, you should provide an application specific start method (shell script, makefile when developing, or batch file) that wraps the basic classpath with your specific application's classpath.
My classpath:
CLASSPATH=$(JAVA_HOME)/jre/lib/rt.jar
Is it just me, or is the java icon they're using a styrofoam cup of coffee with cigarette butts floating in it? If so, it's cool (even though it was copped from a perl jounal a while back). If not, what the hell is that floating in there?
There's one detail that I notice and it may be very important. They list at the end of the document a set of JSRs that they are committed ("at a minimum") to changing to meet Apache's requirements. Can you see which one is missing?
JSR 151, Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification is not in the list. That's the one that JBoss really needs (or JSR 58 for J2EE 1.3) access to testing on and a guarantee that Sun isn't going to go after them for implementing an open source version of their specification.
Now I could be overreacting, it could be that they left 151 out of the list because it is still open and they intend to get to it for that reason, but if that was the case you would expect to see 58 in the list. I'm hoping this is more oversight than an actual attempt to continue the foolishness with JBoss.
Sigs are for people who started using the net _after_ '86.
...and you don't think that eventually Mono will have to do the same monkey tricks that Apache has to do now with Microsoft? All MS has to do is make a key piece of functionality proprietary and not disclose it to Mono, and they have many legal layers they can wrap it under, just like with Samba and Kerberos. Will ActiveState release Perl.net for non-Win32 systems? Will the (crazy?) people who put out Cobol.net do the same? Will MS allow some of the libs used by .Net to be made hostable from non-Win32 systems?
That is regrettable because an open source Java equivalent of ECMA C# would have been available years ago if only a standard equivalent to ECMA C# had been created for Java.
It wouldn't have even taken that much for there to be a Free Software version of Java. Because Sun released Java under there horrible shared source-like license, Kaffe had a whole world of trouble preventing IP pollution.
It's really ashame.
int func(int a);
func((b += 3, b));
The draft of the JSPA submitted for community review would permit the TCK to be so licensed, but not the RI.
That's news to me, when we moved into the public review period for JSR80 (javax.usb), the JCP PMO suggested that we host the RI, licensed under the Common Public License, on our own server.
We have written and circulated a change to the draft JSPA that would permit the RI to be so licensed.
Well that's good news. I thought it was already ok! Guess that's why IANAL.
We run Tomcat 4.0.3 in production, and have found it to be more than adequate. Like most Open Source tools, it's growing into larger and larger roles.
He that breaks a thing to find out what it is has left the path of wisdom.
-- J.R.R. Tolkien
1) Java is not going away. It has a lot of momentum, a number of mature implementations and competing implementations. While .NET will be successful the two are assured of uneasy coexistance for the forseeable future.
.NET platform and as such is in no way comparable to the level of open specification present in the JCP.
2) The specification process for the Java platform is public, includes vendors of competing implementations and gives them an equal vote. MSFT will do all that when hell freezes over, pigs fly and user error is a thing of the past.
3) Don't believe the ECMA C# hype. That is only a small part of the
4) Furthermore, anyone who believes that MSFT is going to play nice needs to take a refresher course on recent history. A vendor with dominent market share has nothing to benefit from high levels of interoperability. The internet alone set MSFT back substantially in continued and extended market domination.
This is a step in the right direction. Apache made a stance and stood their ground. Sun gets sick of everyone's complaints - so they listen (plus I wouldn't mess with Apache).
Now that Sun-Apache is better (not perfect), can Sun PLEASE solve the issue with JBoss. They are not as big as Apache, yet, but the certification of an open source implementation of J2EE is very important.
It is not over yet, I think this is very promising, but until Sun 'really' decides where they stand on OSS, Java will continue to get hurt.
~the keyboard is mightier than the pen.
Well, it looks like 3-4 severely coffee logged butts huddled together to me. When I zoomed into it even at 200% it looked like just a blob (maybe a marshmallow).
Apache's rep,
Jason Hunter
Of course, the orignal Java USB API was/is LGPL'd (jusb.sourceforge.net). But the terms of the various JCP agreements prevent JCP processes from working with such an effort (even for expert group membership, much less the other issues). The jUSB effort predated JSR-80 by over a year. See the FAQ entry on that topic (at the jUSB site).
If IBM is going to mention their javax.usb API as an example of OSS and Java, I think it's worth highlighting that there's a very strong argument to be made that Sun permitted that OSS license to preclude a Free Software effort taking hold. Notice that even the Apache effort was having a hard time getting accepted as an OSS/JCP process ... this USB example shows that Sun is clearly willing to bend its process quite a lot to prevent Free Software from gaining headway.
Now if Sun were willing to let (a) the Reference Implementation (RI) and (b) the Test Compatibility Kit (TCK) be Free Software, and (c) structure the JCP so that Free Software contributors can fully/Freely contribute to the spec, as opposed to needing to license themselves to Sun at zero cost ...
then I could agree that there's been some real progress.
Until then, all I see happening is that Sun continues to be opposed to a true "Community Process" because it's excluding the Free Software community.