struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: StrutsStatics...
Date Thu, 21 Feb 2008 22:09:25 GMT
Moving to API compat thread.

Don Brown wrote:
> I do agree we need to be much better about how much of our API we
> expose to developers, but I think the question of public vs private
> API goes beyond the Java semantics and into what a typical Struts user
> will encounter.   Unless you are a plugin or framework developer, it
> would be very rare for you to be creating configuration objects, so
> yes, while these are technically public, I'd certainly call them more
> private than, say, the Action interface.
> The other example you mention, changing the names of interceptors and
> results, is easily rectified by re-adding them under their old names
> side-by-side the new ones.  I agree this is a change that should have
> been done better.
> So the bottom line is what changes can you do when?  As I understand
> the Struts policy, there can be internal changes between minor
> releases as they are generally viewed as "mostly"
> backwards-compatible.  Therefore, I just don't enough justification
> for the statement that 2.1 changes are "completely incompatible",
> especially from the standpoint of a Struts application developer.
> Don
> On 2/22/08, Brian Pontarelli <> wrote:
>> Don Brown wrote:
>>  > On 2/22/08, Brian Pontarelli <> wrote:
>>  >
>>  >>  Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
>>  >>  change is minor in comparison.
>>  >>
>>  >
>>  > I disagree with that statement.  For Struts 2 users, the changes are
>>  > only minor.  I think you feel them more because you are working on
>>  > plugins that dig deep into the Struts 2 and XWork 2 code, and yes, the
>>  > internals have changed quite a bit.  I'd say the biggest change, from
>>  > a user standpoint, was not allowing JSP EL expressions in JSP tags,
>>  > and that was first done in 2.0.10.
>>  >
>> I'm pretty sure applications will break. Just look at the changes made
>>  to the names of interceptors, results, etc. Plus, I've got to argue this
>>  point because those APIs that I was using as a plugin developer or in
>>  other similar cases are public APIs. This is very different than
>>  internal APIs. If you are going to make something public, you need to
>>  ensure compatibility because if it is public, people will use it.
>>  I have a good antidote about this. The folks over at Spring had an API
>>  that was public and returned the current proxy (for AOP). They
>>  documented it saying something like, "don't use this even though it is
>>  public." Well, sure enough, a number of people used it and the method
>>  changed a few times and broke a few times over the years. Each release
>>  they did there would be a bug submitted to fix that method and each time
>>  the Spring folks would say, "don't use that method," and after some
>>  moaning and groaning would eventually fix the method.
>>  The moral of the story: if it is public, people will use it and if you
>>  break it, people will complain.
>>  -bp
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail:
>>  For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message