3

I have a standalone project based on Java-9 with a single class Main.java on which I was experimenting with the jdeprscan tool pivoted over the Java SE release, when I ran the same using release 9 on my project there were no logs(assuming that being the expected behaviour) in the console:

➜  standalone git:(master) ✗ jdeprscan --release 9 .
Directory .:

meaning there were no deprecated APIs used by the code which seemed just to me.

Then I tried the same with release 8, though I didn't get any Deprecated logs again but the console displayed certain warnings for the project :

➜  standalone git:(master) ✗ jdeprscan --release 8 .
warning: unknown enum constant javax.jws.WebParam.Mode.IN
warning: unknown enum constant javax.jws.soap.SOAPBinding.Use.LITERAL
warning: unknown enum constant javax.annotation.Resource.AuthenticationType.CONTAINER

Q: Why are there warning with the release version 8 and not with version 9? To add to the details here for e.g. in JavaSE8 WebParam.Mode.IN is not marked as deprecated either.

Q: Why do I get these warnings even in the first place when my code isn't involved with any of these enum constants?

Edit: I was giving this a try with JDK10(GA release) and JDK11(EA), and what I could update here is that the only warning left over is

warning: unknown enum constant javax.jws.soap.SOAPBinding.Use.LITERAL

the other two has subsided.

Naman
  • 27,789
  • 26
  • 218
  • 353

2 Answers2

4

Thanks for trying out the jdeprscan tool.

This is a bug in jdeprscan or in the underlying tooling mechanism. The first thing jdeprscan does is to run through all the classes in the JDK to find out what's been deprecated. Given the --release option, it uses some internal javac tables that contain a representation of the class library that was present as of that release, in this case JDK 8. I haven't debugged this yet, but I suspect something elsewhere in the JDK is referencing these particular enum constants, and jdeprscan is trying to look them up in order to see whether they're deprecated.

However, these are defined in the javax.xml.ws and javax.xml.ws.annotation modules, which aren't part of the default set of root modules, thus a normal lookup won't find them. That's probably why the warnings are issued. (Note that the javax.xml.ws and javax.xml.ws.annotation modules are themselves deprecated, but I don't think that has anything to do with this issue.)

I've filed JDK-8187155 to track this issue. I don't think this should affect the operation of jdeprscan except to add noise. But please follow up if this causes additional issues.

(Also note that your code uses a JDK 9 API List.of which means that it's a JDK 9 class file. jdeprscan should probably issue a warning if you ask it to scan a JDK 9 class but provide the --release 8 option. It might also be a bug that it doesn't issue such a warning.)

Stuart Marks
  • 127,867
  • 37
  • 205
  • 259
  • Related to the part ***jdeprscan should probably issue a warning if you ask it to scan a JDK 9 class but provide the --release 8 option***, is there any place this is also being tracked? – Naman Mar 28 '18 at 04:18
  • 1
    @nullpointer I added a note to that same bug report. It'll quite likely end up being a separate issue, but it's quite unclear what should happen in this case anyway. – Stuart Marks Mar 28 '18 at 05:31
0

Java 9 has done a major re-packaging of the standard libraries. That means that when you create a small application the number of dependent libraries is much smaller than the corresponding requirement in Java 8. The answer to your second question is that some transitive dependency of your application uses annotations in those packages for which you get warnings.

Similarly, for the first question, because you are not explicitly listing all of the jars that contain those annotation classes, the dependency scanner is unable to find the definitions. The warning has nothing to do with deprecation; it states that jdeprscan is unable to find definitions in classes that were not provided.

Bob Dalgleish
  • 8,167
  • 4
  • 32
  • 42
  • The only dependent module for the project is [`java.base`](https://github.com/namannigam/Jigsaw/blob/master/standalone/src/standalone/module-info.java). Even if I would remove that, the warning holds. ***number of dependent libraries is much smaller than the corresponding requirement in Java 8*** I didn't get this in terms of `jdeprscan`. As the doc linked says **use the jdeprscan tool as a static analysis tool that scans a jar file (or some other aggregation of class files) for uses of deprecated API elements.** and I am not sure why any other warning is not displayed. – Naman Sep 04 '17 at 16:29