<div class="gmail_quote">On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll <span dir="ltr"><<a href="mailto:Jim.Driscoll@sun.com">Jim.Driscoll@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 5/24/09 7:18 PM, Dan Allen wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
It's a shame that this discussion is coming up after the spec is<br>
final though. If only there had been some group of people<br>
responsible for reviewing the spec before it went final to catch<br>
this sort of thing, some sort of Group of Experts....<br>
<br>
<br>
It's just amazing what happens once discussions are released out into<br>
the open, isn't it? You actually get participation.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So it's really too<br>
bad that collaboration started so late. But at the same time, exciting<br>
that it's finally happening. Frankly, I don't really care what "state"<br>
JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that<br>
JSF has and will continue to have. If we can't change something in 2.0,<br>
then we will change it in 2.1.<br>
</blockquote>
<br></div>
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.<br>
<br>
As a rule, Java does not ever, ever, make changes that break backward compatibility.<br>
<br>
Even when I really wish we would. (Java security policies spring to mind, for instance.)<br>
<br>
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).<br>
<br>
So, the changes you're proposing, moving the data fields around in the payload, will break compatibility, and will thus probably not happen.</blockquote><div><br>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)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Because we missed our window to change it before the spec went final.<br>
<br>
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?</blockquote>
<div><br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
The point is, we need the changes and the<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
discussions that lead up to them to happen and continue to happen.<br>
</blockquote>
<br></div>
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.<br>
<br>
This is why reviewing the spec when it goes through it's drafts is such a big deal.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Otherwise, as David so gracefully said in his IBM series, we are just a<br>
bunch of eggheads in an ivory tower.<br>
</blockquote>
<br></div>
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?</blockquote>
<div><br>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.<br>
<br>But if the rule is that it can never change, so be it. It doesn't necessarily mean it makes good sense.<br><br>-Dan</div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>
<br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://in.relation.to/Bloggers/Dan">http://in.relationto/Bloggers/Dan</a><br>
<br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>from my email. If you contact me, but don't hear back for more than a week,<br>
it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>you feel that it did not reach my attention.<br>