Rams wrote:
>Sorry if this is a dumb question... But lacking sun.misc.Service will not
>preclude those VMs from making use of my library? It will only keep them
>from being able to compile the SPI source itself, no?
Short answer: Maybe.
Long answer: It depends on exactly how Sun has implemented sun.misc.Service
in its JDK 1.6/6.0 release. If it's done by forwarding calls to
java.util.Service, then your old code will still work.
If there is no sun.misc.Service at all, then your compiled code that refers
to sun.misc.Service will fail. And it will fail at runtime, not just when
compiling the SPI source. It will fail with a NoClassDefFoundError, which
you should read the Java-docs of.
To discover what will happen on 1.6/6.0, I suggest looking at the source or
the classes included in 1.6/6.0. Since it's beta-quality, what you see now
may change.
In any case, Sun has every right and privilege to NOT provide
sun.misc.Service, so I suggest preparing yourself. The simplest way to do
that is to use reflection. See any Java tutorial on reflection for details.
>Otherwise, wouldn't javax.naming.spi be broken on any VM that does not
>have sun.misc.Service?
An implementation may change as long as its public API remains the same
(see the Java Language spec on "Binary Compatibility"). Just because
javax.naming.spi uses sun.misc.Service now doesn't mean it's forever
required to do so.
Since you're looking at the implementation for javax.naming.spi under a JDK
before 1.6/6.0, you can't assume that the implementation is unchanged in
1.6/6.0. As long as Sun is consistent throughout any given JDK release,
they can do anything they want in the implementation of a given API.
Some classes other than in javax.naming also use sun.misc.Service, but they
do so in a way that only affects the implementation, not the public API.
For example, see the 1.4 source for:
java.net.InetAddress
java.nio.channels.spi.SelectorProvider
java.nio.charset.Charset
>As long as people are able to use >apps built on it and develop code that
>plugs into it, that's all I really care about at the moment.
Then use sun.misc.Service, but isolate it into a single adapter class that
your classes call on to use the SPI facilities.
That is, there should be only ONE place in your code that refers directly
to sun.misc.Service. Everything else that wants to use the SPI facilities
musc call your one adapter class. Then you only have to change, improve,
add reflection to, or do whatever else in only ONE class, no matter what
Sun does in the future.
This is exactly how I approached my own use of sun.misc.Service. And I was
testing that code today, which worked fine on 1.3.1 thru 1.5.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
