If the types in the optional package are used directly in your api signatures, the optional package is not optional. Your package has a uses constraint on that package which the JVM will need access to to load and verify your type.
Optional packages are more for: I'd like to log if the log package is present. But the log package does not appear in your API. That is, you have an implementation dependency on log not an API signature dependency on log. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Daniel McGreal <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2014/03/20 11:16 Subject: [osgi-dev] Handling Optional Dependencies Sent by: [email protected] Hi Osgi Developers, For the first time I have come up against a wish to implement an optional dependency. Specifically, I have an 'api' bundle with an interface which has a method that takes a String, which is actually some XML. I don't want to force a dependency on a specific XML parser but I would like to provide some helper methods for callers using JDOM (basically, that's ourselves!) along with this bundle. A whim leads me to investigate having an optional dependency on JDOM in the API bundle instead of creating a new bundle just for this utility. My question is, essentially, are there any examples of what this community considers best practice when dealing with the optional dependency at runtime? For example, one of the methods looks like this: private static Document buildXmlFromString(String strMsg) throws JDOMException, IOException { InputStream is = new ByteArrayInputStream(strMsg.getBytes()); SAXBuilder builder = new SAXBuilder(); return builder.build(is); } My naïvety leads me to implement a best guess at making JDOM optional for this method by private static Document buildXmlFromString(String strMsg) throws JDOMException, IOException { InputStream is = new ByteArrayInputStream(strMsg.getBytes()); try{ SAXBuilder builder = new SAXBuilder(); return builder.build(is); }catch(NoClassDefFoundError ncdfe){ throw new JdomUnavailableException(); } } private static class JdomUnavailableException extends UnsupportedOperationException {} Is this an OK approach? Are there intricacies around method signatures (e.g. the JDOMException above) or anything I should be aware of? Many thanks, Dan. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
