Community
Participate
Working Groups
FYI, the org.eclipse.ecf.provider.dnssd (1.2.100.v20160823-2221) bundle in the Oxygen M6 repository contains a reference to org.xbill 2.0.8, which has been added to Orbit ages ago (with CQ 4551) and which receives some complaints by jdeps: org.xbill.dns_2.0.8.v201112050911.jar -> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/lib/rt.jar org.xbill.DNS.spi.DNSJavaNameServiceDescriptor (org.xbill.dns_2.0.8.v201112050911.jar) -> sun.net.spi.nameservice.NameService JDK internal API (rt.jar) -> sun.net.spi.nameservice.NameServiceDescriptor JDK internal API (rt.jar) Not sure whether this is a code path actually exercised by org.eclipse.ecf.provider.dnssd, though. FWIW, the latest version (2.1.8) from [1] still elicits the same warning. [1] <http://www.dnsjava.org/download/>
Thanks Andreas for the report. We've contacted the dnsjava folks about fixing this upstream, but I doubt it's likely to happen before our 'final' ECF release for Oxygen, which will happen at the beginning of May. So, for Oxygen I think we are simply going to release with the dnsjava version we have, and plan for an update (or perhaps removal) sometime during the summer to fully support java 9.
(In reply to Andreas Sewe from comment #0) > FYI, the org.eclipse.ecf.provider.dnssd (1.2.100.v20160823-2221) bundle in > the Oxygen M6 repository contains a reference to org.xbill 2.0.8, which has > been added to Orbit ages ago (with CQ 4551) and which receives some > complaints by jdeps: > > org.xbill.dns_2.0.8.v201112050911.jar -> > /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/lib/rt. > jar > org.xbill.DNS.spi.DNSJavaNameServiceDescriptor > (org.xbill.dns_2.0.8.v201112050911.jar) > -> sun.net.spi.nameservice.NameService JDK internal API > (rt.jar) > -> sun.net.spi.nameservice.NameServiceDescriptor JDK internal API > (rt.jar) What are the complaints from jdeps? Can they be ignored with property setting, cmd line argument, etc? I'm imagining that it's something like accessing non java* (api) classes, but I also expect this is not completely uncommon for libraries that have existed for some time. In any event, details would be appreciated.
