RFR v4 - 8027634: Support @argfiles for java command-line tool
Kumar Srinivasan
kumar.x.srinivasan at oracle.com
Thu Aug 13 16:38:09 UTC 2015
Henry,
<trimmed the cc: list>
I am still not complete, but here are some more comments and specifics.
args.c
1.
-static int firstAppArgIndex = -1;
+#define NOT_FOUND -1;
+static int firstAppArgIndex = NOT_FOUND;
2.
// Any @argument comes in here is an argument as is.
// Expansion should had done before checkArg called.
I think you are trying to say
// All arguments arrive here must be a launcher argument,
// ie. by now, all argfile expansions must have been performed.
3. void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
// No expansion for relaunch
The launcher might re-exec itself, this might happen under certain
circumstances on *nix, is the above logic to prevent subsequent
expansion on relaunch ? However when a re-exec occurs, the
expanded args will be sent to the second invocation of the launcher.
So what does "relaunch" mean ? in your comment ?
ArgFileSyntax.java:
usage of ArrayList vs. Arrays will simplify things.
// arg file content, expected options
static String[] testCaseArrays[][] = {
{ // empty file
{}, {}
},
...
public List<List<List<String>>> loadCases() {
List<List<List<String>>> rv = new ArrayList<>();
for (String[][] testCaseArray : testCaseArrays) {
List<List<String>> testCase = new ArrayList<>(2);
testCase.add(Arrays.asList(testCaseArray[0]));
testCase.add(Arrays.asList(testCaseArray[1]));
rv.add(testCase);
}
// long lines
.....
@Test
public void testSyntax() throws IOException {
List<List<List<String>>> allCases = loadCases();
for (List<List<String>> testCase : allCases) {
verifyParsing(testCase.get(0), testCase.get(1));
}
}
ArgsFileTest.java:
use case coverage looks great, still haven't finished with this
yet.
Kumar
>> On Aug 12, 2015, at 7:55 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>>
>> Henry,
>>
>> Generally looks good here are some comments, on my initial
>> pass, I am not fully done with args.c I will look at this some
>> more later today or tomorrow.
>>
>> 4.)
>> expectingNoDash is expectingMain right ? if so I would rename it so.
>>
> Not really, it is expecting a argument without dash, such as -cp or -classpath.
>
>>
>> TestHelper.java:
>>
>> Why add findInOutput method ? this seems to be identical
>> to "matches" at line 606, which does exactly that.
>>
> To return a string, this is used when trying to match a pattern and get information from that line, I used to get the starting index for an argument in verifyOptions.
>
> Guess I can remove that now as each use of verifyOptions all starts from 1.
>
>> ArgFileSyntax.java
>> Nice, but I think the creation and storage of test case can be simplified,
>> basically loadCases(), also please avoid Xbootclasspath. The trouble
>> with these tests which operate loops, are very painful to debug
>> and isolate a failing case, on the night before GA.
>>
> I wrote that because I start with testng as a DataProvider, we can change that.
>
>> Can we do something like this.....
>>
>> Map<String, List<String>> tests = new ArrayList<>();
>> tests.put("testing quotes", Array.asList({{...}, {....}});
>> tests.add("no recurse expansion", Array.asList({{...}, {....}});
>>
>> The execute each test, with a description of what the test is doing.
>> This way if a test fails its easy to zero in on the failing test.
>>
> verifyOutput will print out what line is not matching, so it’s pretty easy to identify which case failed.
>
> Cheers,
> Henry
>
More information about the core-libs-dev
mailing list