You'd still have to recompile all code to take advantage of that.
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45139
This does speak to a design pattern that we did not use in JSF,
but probably should have: avoid defining public final constants;
if at all possible, turn them into methods or non-constants, e.g.,
something like:
public static final char SEPARATOR_CHAR = getSeparatorChar();
private static final char getSeparatorChar() { return ':'; }
... would have been a more flexible approach. Ah well...
-- Adam
On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> > This was specifically discussed on the EG; a problem
> > is that NamingContainer.SEPARATOR_CHAR is a static String
> > constant, so there's no way to introduce an API to set it
> > without breaking backwards compatibility - any code that
> > referred to SEPARATOR_CHAR would have to be changed
> > to point at a new API, or break.
>
> What about:
>
> public interface NamingContainer
> {
> public static final char SEPARATOR_CHAR =
> System.getProperty("javax.faces.SEPARATOR_CHAR", ":").charAt(0);
> }
>
> Then to override the value, you just have to provide a value for the system
> property javax.faces.SEPARATOR_CHAR, for example:
>
> -Djavax.faces.SEPARATOR_CHAR=!
>
> --
> Colin Sharples
>
>
> CAUTION - This message may contain privileged and confidential information
> intended only for the use of the addressee named above. If you are not the
> intended recipient of this message you are hereby notified that any use,
> dissemination, distribution or reproduction of this message is prohibited.
> If you have received this message in error please notify Bank of New Zealand
> immediately. Any views expressed in this message are those of the individual
> sender and may not necessarily reflect the views of Bank of New Zealand.
>
