DNS JNDI provider

Fri Feb 15 06:04:00 GMT 2002

Andrew Haley <aph@cambridge.redhat.com> writes:
> Pete Chown writes: 
> > I've made a fair amount of progress on this and I should have 
> > something that you can have a look at soon. I have a couple of 
> > questions, though, about code which is going into gcc: 
> > 
> > 1. Sun's implementation of this provider uses a class which is under 
> > the com.sun hierarchy. For example Sun's documentation talks 
> > about the java.naming.factory.initial property as follows: 
> > 
> > > This property is used to select the DNS service provider as the 
> > > initial context. It is not used by the provider itself. It 
> > > specifies the class name of the initial context factory for the 
> > > provider, and may be set as in the following example: 
> > > 
> > > env.put(Context.INITIAL_CONTEXT_FACTORY, 
> > > "com.sun.jndi.dns.DnsContextFactory"); 
> > 
> > I find this rather odd because I thought the idea was that com.sun 
> > packages were "private" rather than being part of the published 
> > Java API. At present there are no com.sun packages in gcj CVS 
> > (unless I'm looking in the wrong place). This would seem to fit 
> > with the idea that com.sun packages are private. 
> > 
> > The problem this creates is that to make my JNDI provider a 
> > drop-in replacement for Sun's I would need to put it under 
> > com.sun. This seems like a bad idea for trademark reasons if 
> > nothing else. 
>> Interesting. It's very hard to know what to suggest in this case. 
>> Perhaps all we should do is produce a special error message from the 
> compiler. 

Nah. We have the same problem with javamail.
You just have to break compatability. If programmers are sensible
they will always pick strings names for implementation classes from
some property file.
Nic Ferrier