I have created a CSR, https://bugs.openjdk.java.net/browse/JDK-8233722 <https://bugs.openjdk.java.net/browse/JDK-8233722>, to address the EOF issue. The CSR has been approved.
Unless I hear any last minute reservations, I will move forward with the update to the JAR spec. Best Lance > On Nov 4, 2019, at 1:38 AM, Philipp Kunz <philipp.k...@paratix.ch> wrote: > > Hi Max, > Even if it was easy to implement, I don't think we actually would want > it. Hopefully not put too much to the point, it sound like last century > operating with punch cards. The discussed portion of the specification > refers to "EOF character (code 26)" and also I am not talking about an > end of a file or input stream. Nowadays I don't see fit. However easy > or difficult to implement, in either case, I'd opt for removing that > sentence about EOF characters in manifests. > I doubt that changing the reading of manifests, particularly at their > ends, is a promising prospect at the moment. I tried to make this point > already with references [3] through [14] in the previous mail below and > I added one new reference [1] of that sort. It would be easy to > implement only if it was not for compatibility, I figure. If a > consensus or an agreement can be found for removing the discussed > sentence from the specification we are kind of lucky that the code does > not have to be changed. No way I'd want to jump to conclusions here but > changing the specification around the EOF character only and not the > code is possible without waiting for the other issues related to > parsing an insufficiently terminated last line of a manifest which have > been stuck for a while now. > Regards,Philipp > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html > > On Mon, 2019-10-14 at 09:41 +0800, Weijun Wang wrote: >> Hi Philipp, >> Although I also think this feature might be useless, I feel hesitated >> to just remove it. How about implement it and let it stay useless? I >> assume this will not break any existing test or app if no one is >> actually using the character. Hopefully it's easy to implement. >> On the other hand, if there is really a EOF char at the end, there >> will be a behavior change. If that EOF is at the end an attribute >> line, that line is ignored now, and it should be visible after the >> change and this looks like a good thing. If that EOF is after a >> newline, it will be useless anyway. >> Also, my understanding is that hash/signature in a signed jar file >> are calculated on raw bytes and old signed jars can still be >> verified. We should take care to use the original raw bytes and not >> the result of Manifest::write, but I think your previous fixes in >> this area had already handled this correctly. >> Just my $0.02. >> Thanks,Max >>> On Oct 11, 2019, at 2:11 PM, Philipp Kunz <philipp.k...@paratix.ch> >>> wrote: >>> Hi, >>> The Jar File Specification [1] states that, >>>> If the last character of the file is an EOF character (code 26), >>>> the >>> EOF is treated as whitespace. Two newlines are appended (one >>> foreditors that don't put a newline at the end of the last line, >>> and oneso that the grammar doesn't have to special-case the last >>> entry, whichmay not have a blank line after it). >>> But I can't see that this is actually the case. See the attached >>> simpletest that indicates that this statement is not implemented. >>> See also potentially remotely related bugs [2] and [3] which both >>> referin my opinion to EOF as the end of the byte stream as opposed >>> to theEOF character 26. >>> After nobody has fixed this point inside of many years I tend to >>> assumethat it is not at all necessary or useful. However, I cannot >>> understandthe intention behind it or how that statement got there >>> in the firstplace and hence might not be aware of the full context. >>> Considering the activity about the last line of a manifest >>> notterminated by a line break resulting in that line ignored >>> unexpectedly (see [3] through [14]) I doubt that it is promising to >>> attempt toimplement the EOF according to the specs. >>> Instead I'd rather like to propose to update the specification >>> byremoving the quoted statement. >>> I'm not sure if the specification [1] has changed since 13 or where >>> themost up to date one is. >>> Regards,Philipp >>> >>> >>> [1] >>> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files >>> >>> EOF-related:[2] https://bugs.openjdk.java.net/browse/JDK-7148584 >>> [3] https://bugs.openjdk.java.net/browse/JDK-4639129 >>> >>> Last line break required or missing related:[4] >>> https://bugs.openjdk.java.net/browse/JDK-4274235 >>> [5] https://bugs.openjdk.java.net/browse/JDK-4894998 >>> [6] https://bugs.openjdk.java.net/browse/JDK-4333854 >>> [7] https://bugs.openjdk.java.net/browse/JDK-6594305 >>> [8] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html >>> [9] https://bugs.openjdk.java.net/browse/JDK-4489716 >>> [10] https://bugs.openjdk.java.net/browse/JDK-4639129 >>> [11] https://bugs.openjdk.java.net/browse/JDK-4625822 >>> [12] >>> https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf >>> [13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249 >>> [14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235 >>> >>> <20191011-manifest-eof.patch> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
