Re: MessageContext and final static strings

2003-01-09 Thread James M Snell
quot; <[EMAIL PROTECTED]> cc bcc Subject Re: MessageContext and final static strings the eclipse doc says that "Making an API field final breaks compatibility with pre-existing binaries that attempt to assign new values to the field.". assuming nobody tried to do this, I think making th

Re: MessageContext and final static strings

2003-01-08 Thread Steve Loughran
the eclipse doc says that "Making an API field final breaks compatibility with pre-existing binaries that attempt to assign new values to the field.". assuming nobody tried to do this, I think making the fields final should be OK. on a related topic, any reason why these bunnies in JWSHandler are

RE: MessageContext and final static strings

2003-01-08 Thread James M Snell
]> 01/08/2003 07:29 AM Please respond to axis-dev To "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc bcc Subject RE: MessageContext and final static strings Make 'em final. How would it break anyone? Do we think that someone is overriding the property na

RE: MessageContext and final static strings

2003-01-08 Thread Tom Jordahl
Make 'em final. How would it break anyone? Do we think that someone is overriding the property names in MessageContext? -- Tom Jordahl Macromedia Server Development -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 3:38 AM To: axis-

Re: MessageContext and final static strings

2003-01-07 Thread Steve Loughran
- Original Message - From: "James M Snell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 07, 2003 17:06 Subject: Re: MessageContext and final static strings > Oy ve. I highly doubt changing them to final will break anything, but it &g

Re: MessageContext and final static strings

2003-01-07 Thread James M Snell
Oy ve. I highly doubt changing them to final will break anything, but it is a risk. I'd say don't change them but I'd add the statement that these really should have been final from the beginning. But I'll vote +0 on it unless we find that it really does break existing code. As for the secon