Thank you Peter, On 20 Mar 2014, at 15:47, Peter Kriens wrote:
> Your code looks ok since the Java VM must not throw the error until you > actually get to the place where the error would be visible. I am a bit > worried about the JDOMException, I do not know what the VM's behavior is for > Exceptions. If this is eagerly reported or only at the throws clause. > However, just throw Exception and that problem is solved. Understood. > So I do not see anything wrong with this except that it seems wrong to > provide a function that might not be available ... (Reminds me of M$ Word, > all those menu entries that looked ok until you clicked them ...). I am not > sure if this is just a demo example but it sounds that you hardly save the > user any code, on the contrary, you give him a headache because he now must > think about the implications of the optionality. However, that is of course > outside the technical problem. Indeed, a demo example, though I appreciate the comment. Many thanks, Dan. > > Kind regards, > > Peter Kriens > > > > > On 20 mrt. 2014, at 16:15, Daniel McGreal <[email protected]> wrote: > >> 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
