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.
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?
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
Apache's rep,
Jason Hunter
The JBoss team can afford to get the certification (and have sponsors who were willing to pay for this, and told SUN about it). The problem is that to get certified you need to agree to Sun legal documents that disallows the distribution of source code for J2EE certified products. Hence no Open Source J2EE implementation can be certified. This is the reason Lutris for example chose to close the source for their J2EE implementation. For them it was more important to get certified than to support Open Source development. For the JBoss team the opposite is the case. We will not close the source base just so that we can get a "J2EE Certified" sticker for the product.