On 01/11/2007, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
>
> On Thursday 01 November 2007 11:48, Stuart McCulloch wrote:
> > also, I think the main cause of non-compatible frameworks getting out
> would
> > be due to lack of TCK tests - so when areas of the spec are clarified
> TCK
> > tests should be updated / added to.
>
> I was more thinking of stuff like;
>
> Constructed example; If spec says that Constants.SERVICE_VENDOR =
> services.vendor, but the Jar file that all frameworks has been using has;
>
> public interface Constants
> {
> :
> String SERVICE_VENDOR = "service.vendor";
> :
> }
>
> Some people will code against the Constants class, but there are those who
> take the String value as-is, and there could be valid reasons to do so.
>
> Didier's recently reported bug (573) in Javadoc is a close call on this
> topic,
> and I jut got curious.
still think a lot depends on the situation; we can't really protect against
all the possible
programmer typos when people use hard-coded String values in their code
instead of
the constants - I guess I'm just missing the value of declaring a decision
up-front...
although a framework could have a mode where it looks for fuzzy matches and
report
possible typos of the various framework constants - that could be an
interesting option
Cheers
> --
> Niclas Hedhman, Software Developer
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
>
--
Cheers, Stuart
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
