[rfc][icedtea-web] add switch to trim main-class attribute
Andrew Azores
aazores at redhat.com
Wed Nov 25 15:54:09 UTC 2015
On 23/11/15 09:58 AM, Jiri Vanek wrote:
> 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.
>
OK, no more objections from me.
--
Thanks,
Andrew Azores
More information about the distro-pkg-dev
mailing list