Its on my list, just have not time to look at it > On Feb 22, 2019, at 6:16 AM, Philipp Kunz <philipp.k...@paratix.ch> wrote: > > Hi, > > Without any impatience, but may I ask if someone has read the previous > message or if there is any opinion about it? > > Regards, > Philipp > > On Fri, 2019-02-15 at 22:30 +0100, Philipp Kunz 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
<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>
