JDK-8072376 : LangTools: Investigate versioning impact on all langtools and nashorn (source, tests, etc.)
  • Type: Sub-task
  • Component: tools
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2015-02-03
  • Updated: 2015-02-20
  • Resolved: 2015-02-20
Description
javac provides its own version number which mimics the format of the platform version string.  (There is a regression test which confirms this.) The tools team needs to determine how closely javac���s version should conform to java.version and make changes as necessary.  Also, javadoc, javah, javap, and possibly other tools in the langtools repository support a ���-version��� option. They may require some adjustments.
Comments
In conclusion: besides some minor adjustments to the version string of the tool itself and some adjustments to JTREG there is no big impact on nashorn and langtools tools.
20-02-2015
As far as Nashorn is concerned: I'm admittedly confused about the right way to interpret the scope of this issue, but I'll answer for both interpretations: - If the goal of this issue is to have all tools report a single, consistent version number, then we need to update Nashorn's version reporting. (FWIW, Nashorn currently reports "0.1" as its version with "-version". That's quite meaningless.) - OTOH, if the goal is to ensure that Nashorn is not sensitive to whatever javac or java report about themselves, then we're good (as Nashorn is not sensitive to the reported version numbers).
19-02-2015
Should we use javac -source 9 -target 9 instead of 1.9?
19-02-2015
Re: the tools team needs to determine .... In times past, javac reported the version string from the underlying platform as its own version string. That was OK when javac was inherently and only part of the platform, and before it because practical/reasonable to build a separate "javac.jar" file. When javac started using its own version string, it seemed sensible that the informal spec should be when javac is accessed via the platform, the version string should "closely resemble" that of the underlying platform. I see no reason to change that policy now. If the format of the version string for the platform is changing, so too should the format of the string displayed by javac. The makefiles should be updated accordingly, and any tests fixed as needed.
10-02-2015
By simulating a version change by changing the version from 1.9.0 -> 9.0.0 I find these langtools tests to fail: 1. langtools/test/tools/javac/options/modes/SourceTargetTest.java, this is because changing the version string seems to have changed the java.vm.specification.version=1.9, this may very well be a build issue regardless maybe this test needs minor adjustments. 2. langtools/test/tools/javac/processing/model/ TestSourceVersion.java similarly directly unrelated to the version change setting the above changed such that javax.lang.model.SourceVersion.version return RELEASE_9, might need some adjustments, as well. Thus besides these small nits nothing major was encountered.
10-02-2015