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 <[EMAIL PROTECTED]> wrote: > Don Brown wrote: > > On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
