On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll
<Jim.Driscoll@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.
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