>> I’ve put up a new webrev that addresses the issue of having spaces before >> (and after) the value “true” in the Multi-Release attribute. >> > > Is some or all of that really necessary? since the we can specify domain of > values.
I think it is. The spec states that one can have an arbitrary amount of leading/trailing spaces in the value part of the attribute. Apparently attribute values could also have “hidden” characters such as vertical tab or nak for example. I wish the spec was tighter here. I’m merely stating the the domain can be “ *TRUE *” for upper/lower case letters. > > For example, the Sealed attribute can take on a value of “true” or “false” > (case ignored), but there is no white space trimming. Well then “Sealed: true” won’t work, but the spec says it should work. I am fine without doing this nonsense, but I think we need to change the spec to make it correct. We could change the definition of "otherchar” to something like this otherchar:=ALPHA EXTALPHANUM* ALPHA:=[A-Z | a-z | _] EXTALPHANUM:=[ALPHA | 0-9 | SPACE] Even this will still allow trailing spaces, so after matching TRUE we’d need to make sure the next char is SPACE, \r, or \n. Other ideas? > > Paul. > >>> Hi, >>> Please review this simple fix to require that the jar manifest >>> Multi-Release attribute has a value of “true" in order to be effective, >>> i.e. to assert the jar is a multi-release jar. >>> issue: https://bugs.openjdk.java.net/browse/JDK-8153213 >>> <https://bugs.openjdk.java.net/browse/JDK-8153213> >>> webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html >>> <http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html> >>> Thanks >>> Steve >
