struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <>
Subject Re: StrutsStatics...
Date Thu, 21 Feb 2008 22:03:09 GMT
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.


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:

View raw message