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

[Jacob Wisor]

On 11/07/2015 at 09:25 AM Jiri Vanek wrote:
> 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)

Should get accepted.

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

Must NOT get accepted.

> main-class="   some.class" => String "some.class" will be used in ITW (now  "
> some.class" is)

Should get accepted.

> main-class=" some.class    " => String "some.class" will be used in ITW (now "
> some.class    " is)

Should get accepted.

> main-class="some.class " => String "some.class" will be used in ITW (now
> "some.class " is)

Should get accepted.

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

Must NOT get accepted.

>> 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. ").

I do not recall this discussion nor I recall having referred to it either. So, I 
am confused why you are addressing this to me.

> So whats pros and cons?
>
> AFAIk some unicode white characters are allowed in class names

Well, white spaces are white spaces. They have been clearly defined. White 
spaces beyond the \u0020 Unicode code point do not exist. Period. But there are 
other Unicode code points beyond \u0020 which are not accepted either.

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

Ahem yeah..., this is *exactly* what this is about.

> Maybe remove al leading characters, for which Character.isJavaIdentifierStart
> returns true?

No, characters for which isJavaIdentifierStart() returns true should be accepted 
and kept untouched. Please read below.

> and remove all trailing chars for which Character.isJavaIdentifierPart returns false?

No. If isJavaIdentifierPart() returns false on *any* character of the value, 
except for leading and trailing white spaces, the class name should be rejected. 
Period. If you start removing or ignoring characters which are not part of a 
Java identifier, you inherently start accepting invalid Java identifiers, 
regardless of the position (leading, inside, or trailing) of characters for 
which isJavaIdentifierPart() returns false. Again, I am not talking here about 
trailing and leading white spaces because they should get removed before 
processing by isJavaIdentifierStart() and isJavaIdentifierPart().

And hope it will not chnage in
> future specifications to much?

Well, isJavaIdentifierStart() and isJavaIdentifierPart() *are* part of the Java 
Language Specification (even though they are implementations, which admittedly 
is a wired thing to do for a specification), so I do not think they are going to 
change much. And as such, even if they change, their sole purpose is to check 
for valid Java identifiers, hence developers using these methods to test for 
valid Java identifiers should be future safe.

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

Right, so anything with white spaces inside must get rejected.

Regards,

Jacob