This was prompted by me trying to modularize another library that transitively dependeds on dns-java. I ran into an issue when importing this as an automatic module, caused by dnsjavacontaining classes in the default/unnamed package:
[WARNING] Can't extract module name from dnsjava-2.1.8.jar: lookup.class found in top-level directory (unnamed package not allowed in module)
These are removed in version 3.0.0
Upgrading dnsjava to 3.x
Although the readme mentions that a lot of things has changed, we seem to be in the clear since we're using such a small portion of the API (Lookup, Record and SRVRecord)
Upgrade to Java 9
Java 9 was released September 2017. It should not be a controversial requirement. Also, given the level of stability in this library, it would be safe to continue using v3.1.5 for users still on Java 8.
Dropping jsr305
The value of these annotations where minimal. A small price to pay for enabling modules. cc #33
This was prompted by me trying to modularize another library that transitively dependeds on
dns-java. I ran into an issue when importing this as an automatic module, caused bydnsjavacontaining classes in the default/unnamed package:These are removed in version 3.0.0
Upgrading dnsjava to 3.x
Although the readme mentions that a lot of things has changed, we seem to be in the clear since we're using such a small portion of the API (
Lookup,RecordandSRVRecord)Upgrade to Java 9
Java 9 was released September 2017. It should not be a controversial requirement. Also, given the level of stability in this library, it would be safe to continue using v3.1.5 for users still on Java 8.
Dropping jsr305
The value of these annotations where minimal. A small price to pay for enabling modules. cc #33
This PR should make #36 redundant