Hi Vyom,
So if I understand well, the class level API documentation allowed
for the colon to be either omitted or present:
121 * <p>
122 * The colon separator need not be present if the request headers
list is empty.
but the getActions() javadoc indicated that the colon would be
omitted if there were no headers:
219 * There is no white space in the returned String. If
header-names is empty
220 * then the colon separator will not be present.
However, the JDK implementation used to always include the
colon, in contradiction to lines #219-220.
We tried to bring the implementation in conformance to line
#219-220, but this caused failures in serialization tests
(see JDK-8161291 [2]) - so we reverted to always include
the colon for the sake of interoperability and serial-compatibility
with previous releases.
Now this fix (8163482) is just to alter the spec of getActions(),
lines #219-220 to match the spec at line #122 and acknowledge
the existing behavior.
Did I get it right?
best regards,
-- daniel
On 06/10/16 08:31, Vyom Tewari wrote:
Hi All,
Please find the spec change for below issue.
BugId : https://bugs.openjdk.java.net/browse/JDK-8163482
Webrev :
http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html
<http://cr.openjdk.java.net/%7Evtewari/8163482/webrev0.0/index.html>
The reason of this change is a side effect of a recent past fix [1]
changed the behavior of URLPermission to omit the colon separator when
the request headers list is empty (the spec allows this). However some
previously existing tests started failing [2] because of that.
As the spec allows the colon separator to be always present, whether
the request list is empty or not. For the sake of backward compatibility
with existing code that might expect getActions() to always return a
string containing a colon we chooses the conservative approach and
continue to add the colon separator in all cases.
[1] https://bugs.openjdk.java.net/browse/JDK-8114860
[2] https://bugs.openjdk.java.net/browse/JDK-8161291
Note: i will file a CCC for this spec change.
Thanks,
Vyom
