[rfc][icedtea-web] add switch to trim main-class attribute

[Jiri Vanek]

On 11/20/2015 02:42 PM, Andrew Azores wrote:
> On 20/11/15 02:32 AM, Jiri Vanek wrote:
>> On 11/19/2015 07:12 PM, Jacob Wisor wrote:
>>> Hello guys!
>>>
>>> Although I did not take a look at the patch, I just wanted to comment
>>> on Andrews post before I have
>>> more time to actually review the patch.
>>>
>>> On 11/19/2015 at 04:59 PM Andrew Azores wrote:
>>>> What about this comment which Jacob made earlier?
>>>>
>>>>> Hence, the compiler accepts this in statements:
>>>>>
>>>>> javax.
>>>>>   imageio . stream    .
>>>>> FileImageInputStream
>>>>>
>>>>> So I guess, IcedTea-Web should accept white spaces around valid
>>>>> identifiers
>>>>> and/or the dot
>>>>> characters too, wherever it handles Java identifiers, package or fully
>>>>> qualified class names.
>>>>
>>>> Is this also valid for fully qualified main classes in JNLP files? If
>>>> so then it
>>>> looks to me like this patch doesn't implement this, unless
>>>> Character.isJavaIdentifierPart is allowing whitespace characters?
>>>
>>> No, Character.isJavaIdentifierPart() does not accept white spaces. If
>>> it did it would make stuff
>>> completely indistinguishable. White spaces are token terminators for
>>> the syntax verifier. Please
>>> read the documentation carefully. ;-)
>>>
>>> However, Character.isJavaIdentifierPart() does ignore some code points
>>> which are not actually
>>> allowed in identifiers because it calls
>>> Character.isIdentifierIgnorable(). But, even
>>> Character.isIdentifierIgnorable() explicitly does not accept white
>>> spaces, which is correct. White
>>> spaces /in/ identifiers are not allowed, hence identifiers surrounded
>>> by white spaces is not the
>>> same thing as white spaces /in/ identifiers. In fact, a fully
>>> qualified name in the semantics of the
>>> compiler is composed of multiple identifiers which may be delimited by
>>> white spaces and dots. And,
>>> to anyone with funny ideas; empty identifiers do not exist, hence
>>> "some..Class" is not accepted.
>>>
>>>> Either way, I'd like to see a test case for the example Jacob gave,
>>>> where there
>>>> are whitespaces but they do not break any "words" in the fully
>>>> qualified name,
>>>> they just are placed around dots.
>>>
>>> Yep, this is probably a good thing to do.
>>
>> The test I included is not enough?
>>
>>    @Test(expected = ParseException.class)
>> +    public void testSpacesInsidePersistedMainClassApplication() throws
>> Exception {
>> +        String data = "<?xml version=\"1.0\"?>\n"
>> +                + "<jnlp codebase=\"http://someNotExistingUrl.com\"  >\n"
>> +                + "<application-desc main-class=\"\nsom e.main
>> .class\t\">\n"
>>
>>
>>
>> Thanx!
>>
>>   J.
>
> No, we're talking about a test where the main-class looks something like "some\n\t.\tpackage .
> name\n.Klass" - the whitespace markers only appear surrounding the dots, never breaking up a word.
>

Here you go!
Behaves as expected....

tyvm!

J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: trimMainClass3.patch
Type: text/x-patch
Size: 16257 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20151123/d775b9c0/trimMainClass3.patch>