Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Steven Simpson <ss@my.domain.invalid>
Newsgroups: comp.lang.java.programmer
Subject: OpenJDK 9 options claiming extra arguments
Date: Sat, 14 Oct 2017 18:16:02 +0100
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <ibt9be-ud6.ln1@s.simpson148.btinternet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="a2df6df3a2efe538adc07dfd093032f0"; logging-data="2971"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hSatlyGBo+bIDyDAVrB8d3XPRvEkBUzU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
Content-Language: en-GB
X-Mozilla-News-Host: news://localhost
Cancel-Lock: sha1:SdyvkAJwwp/vD8ZXVSwIuU0F864=
Xref: csiph.com comp.lang.java.programmer:37572

Hello,

I've installed openjdk-9-jdk (which reports as [javac 9-Ubuntu]) on a 
new Kubuntu 17.04 machine, and started running some of my scripts on 
it.  In particular, I have a Java program that extends the default 
compiler by invoking it through javax.tools, and augmenting components 
like the JavaFileManager.  It also takes some additional options, so it 
submits all command-line arguments to several OptionCheckers 
(representing the various subsystems) to determine how many additional 
arguments are consumed by an option.  OptionChecker's sole method 
returns the number of additional arguments it consumes, or -1 if the 
option is not recognized, so -d should return 1, -implicit:class should 
return 0, and this still seems to be the defined behaviour:

<https://docs.oracle.com/javase/9/docs/api/javax/tools/OptionChecker.html#isSupportedOption-java.lang.String->

<https://docs.oracle.com/javase/8/docs/api/javax/tools/OptionChecker.html#isSupportedOption-java.lang.String->

I'm finding that some options that previously claimed 0 now claim 1.  
This means that, for example, "-implicit:class -d classes" is being 
split into "-implicit:class -d" and "classes" - the latter is then 
misinterpreted as a source file.

So far, -implicit:class, -Xlink:unchecked and -Xlink:options are all 
doing this.  "javac" with no arguments reports:

   -implicit:{none,class}
         Specify whether or not to generate class files for implicitly referenced files

...and javac -X reports:

   -Xlint:<key>(,<key>)*
         Warnings to enable or disable, separated by comma.
         Precede a key by - to disable the specified warning.

So they don't appear to have gained any parameters, and present no 
problems when running javac directly.  If I print out the options that 
claim at least one argument, I get:

-Xlint:-options claims 1     *******
-source claims 1
-target claims 1
-implicit:class claims 1     *******
-d claims 1
-cp claims 1
-processorpath claims 1
-s claims 1
-sourcepath claims 1
-profile:public claims 1
-profile:default claims 1
-packages:provided claims 1
-packages:used claims 1
-list:sources:3 claims 4
-list:classes:1 claims 2

The marked lines shouldn't be there, and aren't present on a host 
running [openjdk version "1.8.0_131"].  The tar from Oracle (reporting 
simply as [javac 9]) behaves the same.

(To get round the problem, I'm doubling up the options, so the first 
consumes the second, otherwise -source and -d above would disappear.  In 
the long run, I'm anticipating that it's only arguments using colons 
that cause a problem, so I'm overriding what the OptionChecker reports.)

Anyone else seeing this?

Cheers,

Steven