Hi Philipp, Thank you for looking into this issue and proposing a fix. I ran the JCK and encountered 9 failures similar to the JavaClassPathTest failure. The JCK tests that I looked at did not validate all of the attributes which is one of the reasons this was not caught earlier
Given the fact that this code dates back to JDK 1.1/2 and with this fix, an Exception is now encountered I am reluctant to integrate the patch as is into the JDK as I think there is a compatibility risk that I am not comfortable with. I believe the best course of action is to look to develop additional tests in this area and we look to further clarify the JAR specification. Best Lance > On Feb 15, 2019, at 4:30 PM, Philipp Kunz <philipp.k...@paratix.ch> wrote: > > Hi, > > Manifest parsing an input stream given to the constructor or the read > method ignores the contents of the last line unless terminated with a > line break. > > In course of my attempt to fix 8217375, I found that Manifest ignores > the last line when not terminated with a line break whereas > ManifestDigester throws an exception. > Without ManifestDigester's different behavior, I'd have opted for > parsing the last line also without a line break (or the last line being > empty). > But ManifestDigester cannot easily be changed that way, too, because > the line breaks are part of the digested manifest portions. > I don't think Manifest should accept any manifests that cannot later as > well be signed and should therefore raise an error when there is no > line break at the end of a manifest. > Adding a new error condition adds potential for compatibility issues. > On the other hand, I don't think the last 'ill'-terminated line should > really be ignored silently. > A good example how things can go wrong this way is > JavaClassPathTest.java. It uses a one-line manifest without a trailing > line break and m1.jar does not contain the expected Class-Path entry. > In the long term the best option would probably be to re-unite > Manifest's and ManifestDigester's parsing-related code the biggest > challenge of which is not to change digests and thereby break existing > jar signatures. > > Attached is a patch with a proposed fix. > > The bug number in > test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java is > from another bug that lead me to it. If someone creates another bug it > can be replaced. I haven't found an existing issue that matches. > In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java is > a test case testJARManifestClassPathAttribute/testClassPathAttribute > which I have no clue how this should really work. As far as I can tell > the test is and was wrong but nevertheless passes. > > Is there a chance to find a sponsor for fixing this? > > Regards, > Philipp<NoLineBreakAtEndOfManifestFile.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>
