Thank you BJ, Supposing I hadn't any classes from optional packages in my signatures then, is the rest of the approach acceptable? Or is it more desirous to do a check if the class exists before continuing, rather than trying to catch an exception?
Thanks, Dan. On 20 Mar 2014, at 15:25, BJ Hargrave wrote: > 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
