The package name is unfortunate. It has been like that for 20+ years, which is why I'm probably not going to change it until it breaks.

As for Record, this is really awful. Putting such a generic new name into java.lang will break sources for hundreds of projects. I'll keep this in mind for v4 if the JDK sticks with it into an LTS version. However, I hope they'll reconsider and use a different package or name.

Regarding the "records" extension: Maybe I am missing something, but I do not see a big problem at the moment. It is not forbidden to use a name of a class, interface, enum or exception of java.lang package in any other package. One still can reference the java.lang item by using the package prefix if needed. Additionally, the java.lang.Record class will only be rarely directly used. Only if one imports the dnsjava classes via a wildcard import problems will occur, but this is a bad practice anyway. A problem could occur due to the new "record" keyword, as the code frequently uses "record" as an identifier. However, the specification tells that it is not a real keyword like "class", but a "restricted" identifier with a special meaning in some contexts. So in respect of the records, I am confident that no big changes need to be made.

Okay, after adding import org.xbill.DNS.Record; manually I can use it like in previous Java versions. I’m a bit spoiled by my IDE, it didn’t offer adding the import as usual but instead complained about the method missing in java.lang.Record. Maybe I should file a request for improvement there.

I'm closing this in favor of @demonti's explanation, the big changes this would cause inside the library and for consumers, as wells as Java 14's release notes: https://bugs.openjdk.java.net/browse/JDK-8236439