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

[Jiri Vanek]

On 11/06/2015 10:35 PM, Jacob Wisor wrote:
> On 11/06/2015 at 03:41 PM Jiri Vanek wrote:
>> Hello!
>>
>>
>> I'm bugged at elast once per month  last half a year  "oracle can parse this
>> jnlp, itw can not". The cause is always same - white char on start or end of
>> amin-class attribute value.
>>
>> This patch is for head, and is adding warning when white-char is there and is
>> adding new Xtrimmainclass javaws switch, which will allow trimming (if there si
>> whitechat).
>>
>> I would like to backport to 1.6 the refactoring of Parser to allow print this
>> warning also there (so no new switch for 1.6)
>>
>>
>> I recall several discussions about triming by default, and the resutl was always
>> no. If mood changes I'm 60:40 ok to change this for head.
>>
>> Thoughts?
>
> Let me get this straight; are people complaining because of white spaces *in* fully qualified class names (like fully.qual ifi ed.class. Name) or because of *leading* and *trailing* white spaces (      fully.qualified.class.Name  )?

YES!  Only leading and trailing  whitesapces  before and after value of mian-class attribute.
> Or, is it about the "Main-Class" attribute name? Could you please give some examples?
no!

main-class="some.class" => String "some.class" will be used in ITW (now identical  "some.class" is)
main-class="so me.cl ass" => String "some.class" will be used in ITW (now identical "so me.cla ss" is)
main-class="   some.class" => String "some.class" will be used in ITW (now  "  some.class" is)
main-class=" some.class    " => String "some.class" will be used in ITW (now " some.class    " is)
main-class="some.class " => String "some.class" will be used in ITW (now "some.class " is)
main-class="  so me.cl ass " => String "so me.cla ss" will be used in ITW (now " so me.cla ss " is)


>
> If this is only about leading and trailing white spaces on the value then I'm all for it, even for doing it by default, without any new command-line options. But if this is about white spaces in fully qualified class names then I'm all against it. Simply because it violates the JNLP specification. And no, I do not care if other implementations let this slip through or boast themselves falsely of being "fault tolerant". Violating the specification has nothing to do with "fault tolerance". It's just mere stupidity and disregard for rules and standards (either by implementers or authors). The reason why this is unacceptable is because if we once follow down that path we could as well start accepting class names
> and identifiers starting with digit or operator characters, which would lead effectively to a total indistinguishable mess. There are good reasons for not doing either.

I 100% agree.

I did not foud any record of that discussion I recalled ("I recall several discussions about triming by default, and the resutl was always no. ").

So whats pros and cons?

AFAIk some unicode white characters are allowed in class names

MAybe follow- http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8 ?

Maybe remove al leading characters, for which Character.isJavaIdentifierStart returns true? and remove all trailing chars for which  Character.isJavaIdentifierPart returns false? And hope it will not chnage in future specifications to much?



To your last sentence - I definitly have no intentions to remove ay charactes inside the class name vlaue.


Tahnx!

>
> Regards,
>
> Jacob
>
> p.s.: Please use String.trim() for trimming instead of regex.

I did:)

The regex is there to  print warning and avoid iffing of varius cases of whiespaces or avoid iffing of char.isWhitespace on various places....
Then trim is used to do the job.