Jim Driscoll's Blog: J2EE Archives

Posted by driscoll on June 26, 2008 at 02:05 PM | Permalink | Comments (1)

The Mojarra Project is proud to announce the release of the JSF 2.0 EDR1 implementation.

"EDR" stands for Early Draft Review, so this is a very early snapshot of what we're doing with the new version of JSF. It should be of interest to anyone who'd like to see where JSF is headed in the months ahead.

You can download the new API, along with the implementation, from the Mojarra project download area. For the folks using the Glassfish Application Server, the new API will be available via the Glassfish Update Center later today... but remember that this is very early code, so don't update your production machines just yet. Release notes for the EDR1 release of Mojarra are also available.

The actual JSF 2.0 EDR1 specification is available from the JCP site.

For those who'd prefer a more example-laden description of some of the new JSF 2.0 features, please check out Ryan Lubke's blog - he's been blogging about the new 2.0 features since February - skip back a bit in his blog to Part 1, and start reading from there.

As always, we'd love to hear your feedback! The whole purpose of this release is to get feedback both on the API, as well as on the implementation of it, so feel free to leave comments either here, on our forum, or on the mailing lists - or you could even just file a bug, either on the implementation or the spec.

GlassFish, and Tainted Love

Posted by driscoll on July 19, 2005 at 10:19 AM | Permalink | Comments (19)

I recently had a very sincere person, who I have every reason to respect, tell me: "I thought about downloading your code, but I don't want to be tainted." He further went on to say "If you had a statement about that on your website, I'd feel better about it."

Frankly, I was a bit taken aback. Weren't we Open Source? Was this the leading edge of another Sun Evil Plot (tm)?

I was right next to Gier Magnussen at the time, so I turned to him and asked "Gier, what's Apache's tainting policy? We'll just copy that." Geir looked at me, somewhat bemused, and said: "We don't have one."

Now, this makes sense. Apache's an Open Source project, and Open Source projects don't generally worry about tainting. And up 'till now, neither have we. And neither should you. As a real, honest to goodness F/OSS codebase, you're no more tainted if you read our code than if you read JBoss' code, or Geronimo's code. Go ahead. Read it. You won't be tainted. You can't copy our stuff any more than you can copy JBoss' stuff, or Apache's stuff, without listening to the license, but honestly, this shouldn't effect you at all, any more than it effects you for any other project.

I thought about writing more, but I'm not even sure that this is necessary. Still concerned? I want to hear about it - tell me below.

Open Sourcing the Rest of App Server

Posted by driscoll on July 15, 2005 at 12:07 PM | Permalink | Comments (9)

As you know, we've open sourced Sun's AS PE (as Project GlassFish). Recently, some people have taken us to task on not doing the rest of it too. Leaving aside the "geez, are we ever going to not get flack" factor, I thought I'd post this...

In a recent article in Developer Pipeline, my boss got asked about opening the rest of it:

CRN: Will all editions of the application server be available under the CDDL? The version currently available is the platform edition.

SCHWARTZ: If Johnny has his druthers, yes. There's no reason for us to hold anything back. Open source doesn't mean free, as in no revenue.

Now, if you read closely, he didn't say yes. So don't go getting worked up over this. But here's the thing about my boss: Read his blog. Now, imagine this: he means everything he says. Sun is committed to Open Source.

Newest Concern on Sun's Open Source Strategy

Posted by driscoll on July 14, 2005 at 10:28 AM | Permalink | Comments (48)

In my last blog's comments, I had a couple of people raise the issue of joint copyright assignment. The subject was raised with the greatest respect and concern, and I'd like to thank the posters for giving me a chance to talk about it. There continues to be a lingering uneasiness about Sun's new foray into Open Source, so I'll probably be blogging on this and related subjects for the next few weeks.

Joint Copyright Assignment is a fairly standard practice that is being embraced by most major open source concerns. First let's explain how copyright works. As the creator of any peice of work, you by default own the copyright on it, and noone else does. Even if you give it under an existing license (like CDDL, or GPL, or ASL) to an organization, you continue to keep that license.

So far, so good. There's just one problem. Noone else has the copyright on the code you just made. Why can this be a problem? Well, there's a few ways. For one, you can never change the license again, without permission from every copyright holder, which in large projects, can be hundreds of people. Imagine your code worked that way - would anything useful ever get done? Do you beleive licenses are any more free of bugs than code? So, for example, to go to a GPL 3.0, CDDL 1.1, or APL 2.1, it would require to contact every single person and get their permission. One doesn't want to? You can't do it. Can't find one? You can't do it. Then there's the problem of what happens if you end up in court. Only the holder of copyright can usually perform legal operations on behalf of the covered code. If you don't hold copyright on the code, you've got a problem. There's a third issue that Sun faces, and that is that parts of AS PE (and thus GlassFish) find their way into the RI. And Sun's contractually obligated to give the RI to a whole host of companies, including such companies as BEA, and IBM. We aren't going to change that, and even if we could, we wouldn't want to, since that's good for the entire developement community.

And that doesn't even touch on patents, which most licenses don't discuss at all - though CDDL does. So, what's the solution here? Well, one solution is to put a copyright grant right into the license - ASL does this, for instance. But lawyers would make any QE manager proud, they're nervous beasts. They prefer to have a signed peice of paper that actually establishes beyond a reasonable doubt that the original author actually meant to assign copyright. Thus, the SCA is born for our organization, and other similar documents exist for others. It's not a scary document - go read it yourself.

There's been some suggestion that this is a uniquely Sun thing to do. It's not. Other highly regarded organizations do this, for much the same reasons mentioned above. The Apache Software Foundation has been requiring this for some time. The Free Software Foundation has required for as long as I can remember. I've also heard of a number of other groups doing it, but a cursory web search didn't find this information on their websites - they're often less transparent than us, so that's not a suprise.

Still concerned? Let's talk about it below.

One more time: CDDL is Open Source

Posted by driscoll on July 12, 2005 at 03:10 PM | Permalink | Comments (16)

In a recent article, both Marc Fleury of JBoss and Bill Roth of BEA are said to be telling the press that CDDL isn't Open Source. Drat, apparently neither of them read my blog.

So, one more time: CDDL is Open Source. Why can I say that with absolute confidence? Because Open Source is an servicemark that is owned by the OSI. They're essentially the Good Housekeeping Seal for licenses. BEA, JBoss and Sun all don't get to say what is and isn't an Open Source license: the OSI does.

Now, I'm a little disappointed that Bill didn't know this, but it's a bit understandable - BEA isn't exactly known as the Open Source company, though they've been doing stuff there that's interesting lately.

I am a little suprised about Marc, though. One hopes that he was misquoted, since the alternative is that he was trying to mislead people deliberately, or prehaps he just didn't know. I'm not sure which alternative is more disconcerting.

So which is it? What do you think?

Powered by
Movable Type 3.01D

java.net RSS Feeds