9:18 a.m.
On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
On 5/24/09 7:18 PM, Dan Allen wrote:
>
>
> It's a shame that this discussion is coming up after the spec is
> final though. If only there had been some group of people
> responsible for reviewing the spec before it went final to catch
> this sort of thing, some sort of Group of Experts....
>
>
> It's just amazing what happens once discussions are released out into
> the open, isn't it? You actually get participation.
>
So it's really too
> bad that collaboration started so late. But at the same time, exciting
> that it's finally happening. Frankly, I don't really care what
"state"
> JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that
> JSF has and will continue to have. If we can't change something in 2.0,
> then we will change it in 2.1.
>
Actually, that's not entirely true, and it's a point that has to be made,
so everyone understands why it's such a big deal that the spec is final.
As a rule, Java does not ever, ever, make changes that break backward
compatibility.
Even when I really wish we would. (Java security policies spring to mind,
for instance.)
The examples where backward compatibility was violated are small in number,
and usually involve things that are horribly broken by design, with no way
to fix it (like Thread.stop).
So, the changes you're proposing, moving the data fields around in the
payload, will break compatibility, and will thus probably not happen.
I understand the policy. And I can also say that many, many people think
that it is a naive stance because the world changes and thus APIs need to
adapt. Of course there are people that never want it to change. But that
ignores all those pleas from people who do want it to change. So, it should
change when it makes sense (i.e., strong use cases, etc)
Because we missed our window to change it before the spec went
final.
Now, that policy respecting backward compatibility may change, but please
keep in mind why it's there: because enterprises expect that out of their
APIs. The backward incompatible changes that Microsoft makes every few
years, though necessitated by bad design choices, has hurt their enterprise
adoption noticeably. ASP.net, anyone?
Um, .NET is killing us. So obviously it doesn't hurt adoption that badly. By
no means am I saying to follow MS, I'm just pointing out that it somehow
doesn't phase the adoption.
The point is, we need the changes and the
> discussions that lead up to them to happen and continue to happen.
>
Yes, but the ability to make those changes become more constrained once the
spec goes final. So it's a big deal that we didn't catch this before it
did.
This is why reviewing the spec when it goes through it's drafts is such a
big deal.
Otherwise, as David so gracefully said in his IBM series, we are just a
> bunch of eggheads in an ivory tower.
>
API stability isn't for eggheads. In fact, in my experience, it's the
suits who want API stability. Eggheads and gearheads (academics and geeks)
tend to like fiddling with APIs. That fiddling makes the suits, for whom
every API change means expense costs, more than a little crazy. Or has your
experience been different?
The reality is, and the reality coming out of my experience, is that this
argument completely ignores that fact that there are defacto standards.
Facelets is a defacto standard and we are most definitely breaking that
standard as we move into JSF 2.0. If people think that APIs will never ever
change, they are just not being reasonable. I think that APIs should never
change without good reason. People that refactor just to try something new
are hurting a lot of people. People that refactor because others are begging
them to reduce pain or want to grow and mature the library are following
sound judgement.
But if the rule is that it can never change, so be it. It doesn't
necessarily mean it makes good sense.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.