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.
add another point to apache's scorecard!
'Go for the eyes, Boo, go for the eyes, aaarrrrrrrr!' -- Minsc
-davidu
# Hack the planet, it's important.
This endangers their java environment partnership with Apple.
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.
OS X runs Apache btw...
This kinda nonsense is ridiculous. Java and all related technology would be much better handled as an open industry project rather than by an arrogant corporation that hasn't quite realized yet that proprietary is going the way of the dino. So it doesn't fit their current cost structure. Boo hoo! Restructure the company how 'bout.
I'm glad to hear this! It would be very nice to get more help from Sun on a Open Source Servlet Container. Mad props to Sun for getting their hands dirty. ;)
<crickets>
</crickets>
Okay, never mind then. Bastards.
Carousel is a lie!
Take note: *this* is how software development is done.
Maybe some college classes would help?
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.
Open office is still open, and better than SO6 for the same reasons mozilla is better'n netscape 6.
And for the same reason netbeans is better'b forte for java, although I hear the Enterprise stuff in FFJ is nice.
Open Source Identity Management: FreeIPA.org
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.
well... at least their trousers fit properly when filled with hot grits.
they'll leave the humming to natalie portman, while she's down there...
and if they only had a beowulf cluster of these...
sigh... its friday, cut me some slack..
... hi bingo
The mechanisms at work here are essentially the same as with Microsoft Windows or Microsoft VisualBasic: in the absence of multiple implementors, people will just keep adding functionality to the single codebase and ship the stuff. There is no pressure on Sun to keep things small, manageable, and independently implementable. And since Sun's Java implementation is not Open Source (although you can get the source with lots of restrictions under some legal agreement or other), it still gets controlled by just one company. The overall effect is also the same as with Microsoft: either you follow Sun wherever they go, or you are out of luck.
It's a shame that it had to come to this. I think, on balance, once Mono and similar projects have matured enough, ECMA C# (but not Microsoft C#/.NET) is going to be the better long-term choice for people interested in Java-like languages. I expect that's going to be less than a year. 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. And I think Sun would be doing better in the long run as well if that had come to pass--Microsoft may be able to get away with this sort of thing for decades, but I doubt Sun will.
...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.
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
Please explain -
What happens in three years if Sun decides to discontinue the program? This smells of Sun "buying time" so that everyone will quit complaining. I am glad Sun is accomodating OSS, but I do not see a long term solution to the problem in Sun's proposal.
Greg
To a shark, you are just another food choice...
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.
Jakata group?
Moved away from the coffee theme, an onto another one? (No, I don't expect most of you to know what Jakata 'is', let alone where it is, or whose capital city it is.)
Interesting.
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.
err..they already have done this right ? Winforms libs are already proprietary to win32. and they're too big for anyone to implement on *nix. .NET on *nix i can write my code for that subset. As long as the subset compiles on win32 (or the CLR runs) i've achieved portability. .NET involves SOAP to abstract the GUI anyway, it doesnt really matter. .NET (make it proprietary while still keeping ECMA happy) with the ECMA subset of C#/.NET . But i can definitely see Sun doing it with Java -- theres no oversight commitee to bash Sun over the head if it decides to completely close java.
The thing is that it doesnt matter. if i have a subset of
Unless there is some really critical block of code that's winforms specific in general the subset is all that matters. the GUI stuff will have to be rewritten but since
i cant see how M$ could do this with
With Mono it seems that there will be a Free Software implementation of .NET.
It's a shame that there is no Free Software implementation of Java2.
But the situation of both can change. For the moment I stick to plain old Unix and C...
echo -n blabla | md5sum | cut -b 1-5
So they can make people pay for Apache as well :)
It looks like a rapidly dissolving marshmallow to me too (don't know how you get cigarette butts from it) - maybe it's like one of those magic eye pictures - some people can see the marshmallow and some people can't. :o)
Video Game cheats, hints a
free software and quality software don't go together and Java is quality software
oh man thats funny.
you just made my day.
Troll? It's the funniest message I've read on this thread. Can't you people recognise a joke without the canned laughs?
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).
No. The reason is is that Sun set out to create a single, universal, platform-independent language and runtime environment. Mono and .NET, however, each have a much more modest goal: provide a Java-like language with a few libraries that work on different platforms and provide easy ways for people to use their platform-specific stuff. C# doesn't aim as high as Java: C# is just a Java-like language to replace C++, with a few portable libraries.
In different words, Apache has to care about Sun stuff like J2EE because Sun has made Java an all-or-nothing proposition; if they don't support all the latest Sun APIs, they aren't Java compliant. There is no such pressure on Mono.
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.
1) M$ controls the "spec" ...
.NET is today? Where will M$ be by then?
2) M$ has mastered the art of moving target APIs (embrace,extend,extinguish)
3) M$
It took three years (more?) to get the Linux port of Java up to the same level as the windows version, and Blackdown had Sun's source code. How long will it take for Mono to get to where
[offtopic] I use mozilla every day and it is very nice, but rewriting a web browser takes three years no matter who does it. For me, mozilla is important, but most people just don't care anymore.
Please don't play Microsoft's game: lead, don't follow.
At least Sun is trying to have a clue. Right now, they are certainly not The Enemy(tm).
Actually I think this is a major point down the road of Java becoming progressively less proprietary. Even before the changes to deal with Apache's concerns, the new legal documents were much better than the old ones - licensing of tests was separated from licensing of Sun's implementation for the first time.
Now those legal documents are even better still. Apache's position paper provoked support from many other members of the Java community and the result was that Sun clearly & visibly gave way. Now those people who defend Java against Microsoft technologies have a public example to give of Sun being forced to listen to the community.
Unlike the moderators who seem to have suffered a major sense of humour failure, I found your comment amusing.
Judging by what I can see at www.m-w.com, I think that Americans actually do say "hemming and hawing" - another one of those peculiar quirks in their dialect of English. I suspect you were moderated down by Americans, too bad.
More coverage at open-source java news.
Rich
Those changes don't address the fundamental problem with Java: developing a compliant implementation from scratch is a huge undertaking and Sun controls the one-and-only implementation. It's questionable whether Sun's specifications are even good enough to write an implementation from scratch. Java may be a little less proprietary now than a couple of years ago, but that just isn't enough.