Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

t; So that is the work that would need to be done to support this > change. > The question then will be if the benefit of this change (seen only > outside of running code) outweighs the risk of changing behavior that > has not been an issue for 20+ years. It seems unlikely that a strong > enough case

RFR: JDK-8243454 - Redundant code for executable jar file manifests except SplashScreen-Image

/UnicodeTest.javacp JTwork/scratch/UnicodeTest.jar test/jdk/tools/launcher/ Regards,Philipp [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064190.html[2 ] https://bugs.openjdk.java.net/browse/JDK-8243454 On Sat, 2020-01-04 at 11:00 +0100, Philipp Kunz wrote: > Hi, > When I tried to i

Re: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

t; -> "2019, 2020," > Otherwise, it looks good. > Naoto > On 4/14/20 9:26 AM, Philipp Kunz wrote: > > Hi Naoto, > > I agree, see attached patch. > > Regards,Philipp > > > > On Thu, 2020-03-26 at 14:14 -0700, naoto.s...@oracle.com wrote: > > >

Re: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

> Maybe you would want to put it similar to > open/test/micro/org/openjdk/bench/java/util/regex/PatternBench.java > > Minor suggestion: I would rather rename "getGraphemeType()" to just > "getType()", as it is simply retrieving the character type. > &

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

acle.com wrote: > Hi Philipp, > Sorry for the delay. > On 3/25/20 11:52 AM, Philipp Kunz wrote: > > Hi Naoto, > > See another patch attached with Locale.ROOT for the BreakIterator. > > I will be glad to hear of any feedback. > > I wonder how your change affects the pe

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

e here by definition, though the > implementation is the same. > Naoto > On 3/21/20 5:19 AM, Philipp Kunz wrote: > > Hi Naoto and everyone, > > There are almost as many occurrences of Locale.ROOT as Locale.US > > which made me wonder which one is more appropriately

RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size

Hi, Any opinions on the attached patch or someone tempted to sponsor it? Regards, Philipp diff -r 84215fa115fc src/java.base/share/classes/java/util/regex/Grapheme.java --- a/src/java.base/share/classes/java/util/regex/Grapheme.java Fri Mar 20 17:37:52 2020 -0700 +++

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Naoto and everyone, There are almost as many occurrences of Locale.ROOT as Locale.US which made me wonder which one is more appropriately locale-independent and which is probably another topic and not actually relevant here because BreakIterator.getCharacterInstance is locale-agnostic as far

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

tself can be improved, but I am not so keen on > modifying Grapheme/Pattern code at this time, so using BreakIterator > (with Locale.US) is more preferred solution to me. > Naoto > [1] https://unicode.org/reports/tr29/ > > > On 3/10/20 12:11 AM, Philipp Kunz wrote: > > Hi N

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

gt; Naoto > On 2/10/20 1:22 PM, Lance Andersen wrote: > > Hi all, > > Here is a webrev for the patch that Philipp is proposing which will > > make it easier to review: > > http://cr.openjdk.java.net/~lancea/6202130/webrev.00 < > > http://cr.openjdk.java.net/~l

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/064149.html On Thu, 2019-12-26 at 17:50 +0100, Philipp Kunz wrote: Hi, The specification says, a line break in a manifest can occur before or after a Unicode character encoded in UTF-8. ... value: SPACE *otherchar newline

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

eán Coffey wrote: > Hi Philipp, > > On 17/01/2020 12:40, Philipp Kunz wrote: > > Hi Sean, > > > > Nice patch. I wonder why permissions should be preserved only in > > zip > > files. Jar files also are zip files, according to the jar file > > specs, &

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

Hi Sean, Nice patch. I wonder why permissions should be preserved only in zip files. Jar files also are zip files, according to the jar file specs, and hence, shouldn't jar files benefit of preserving permissions, too? The file name extension is most often zip for zip files and jar for jar files

Test Unicode support for "SplashScreen-Image" manifest attribute and potential clean up of some c code

Hi, When I tried to improve Unicode support in JAR manifests in [1], independent of what will happen with that, I found that there are not only Manifest and Attributes classes parsing manifests but also some c code which parses "SplashScreen-Image" attribute and also used to parse some other

Note about Manifest Header Names starting with "From"

Hi, The Jar File Specification [1] states that, > Note: To prevent mangling of files sent via straight e-mail, > no header will start with the four letters "From". But I can't see that this is actually the case. After nobody has fixed this point inside of many years I tend to assume that it is

6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi, The specification says, a line break in a manifest can occur beforeor after a Unicode character encoded in UTF-8. >...> value: SPACE *otherchar newline *continuation> continuation: SPACE *otherchar newline>...> otherchar: any UTF-8 character except NUL, CR

Re: Jar manifest and EOF character (code 26)

ust my $0.02. > Thanks,Max > > On Oct 11, 2019, at 2:11 PM, Philipp Kunz > > 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 w

Jar manifest and EOF

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 for editors that don't put a newline at the end of the last line, and one so that the grammar doesn't have to

Re: Manifest ignores last line if not terminated by line break

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 > me

Re: Faulty Null-Check Suspected in ToolProvider

Hi Jon, All right, let's not document flushing behavior then. It's probably really not important enough. So we're back to the null-checks?For that see patch of https://mail.openjdk.java.net/pipermail/core-libs-dev/2019 -February/058576.html Regards,Philipp On Sat, 2019-02-16 at 17:05 -0800,

Re: Faulty Null-Check Suspected in ToolProvider

Hi Jon, On Sat, 2019-02-16 at 13:44 -0800, Jonathan Gibbons wrote: > On 2/16/19 12:20 AM, Philipp Kunz wrote: > > I'm also wondering about the call to flush in run(PrintStream out, > > PrintStream err, String... args). It looks like the intention was > > to > > flu

Re: Faulty Null-Check Suspected in ToolProvider

Hi again, I figured out and err deserve a null-check test as well. See patch. I'm wondering, if or how a similar check could be applied as well to ToolProvider.run(PrintWriter, PrintWriter, String...) which currently is implemented (hopefully) by each tool having to repeat the null-checks. I'm

Re: Faulty Null-Check Suspected in ToolProvider

diff -r 7c17199fa37d src/java.base/share/classes/java/util/spi/ToolProvider.java --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Fri Feb 15 08:21:08 2019 -0500 +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat Feb 16 00:57:54 2019 +0100 @@ -126,8 +126,9 @@

Faulty Null-Check Suspected in ToolProvider

Hi, There has always been an implicit null-check for args by the for loop attempting to iterate but the check seems to be intended and wrong for the elements. See attached patch. >From the comment to args, "the command-line arguments for the tool", I guess it makes sense to conclude that these

Manifest ignores last line if not terminated by line break

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

Missing Blank Line Suspected in jar.html

Hi, https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#per-entry-att ributes shows an example manifest Manifest-Version: 1.0 Created-By: 1.8 (Oracle Inc.) Sealed: true Name: foo/bar/ Sealed: false with the explanation It means that all the packages archived in

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

The class comment to Attributes says> > This map and its views have a predictable iteration order, namely the> order that keys were inserted into the map, as with {@link LinkedHashMap}.> Considering above statement, are two Attributes equal if they contain the same mappings in a different

Re: Manifest copy constructor does not deeply copy individual section Attributes

ussion/input as this has > > been documented for sometime as a shallow copy. > > > > If there is a consensus  to move this forward, it will also require > > a CSR.   I can help with that and sponsoring the updates,  if the > > decision is to go ahead with the propose

Re: Manifest copy constructor does not deeply copy individual section Attributes

in the previous message, I continued and attached another patch for a deep copy approach. There might still be some reason not to deeply copy manifests which I don't intend to forestall. Philipp On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote: > Hi, > > Creating a new manifest as a

Manifest copy constructor does not deeply copy individual section Attributes

Hi, Creating a new manifest as a copy from an existing one using the copy constructor assigns the new manifest individual sections entries map the same values which are references to attributes as the original rather than copying them as well deeply resulting in two manifests pointing to the same

Clarification in Attributes equal

Hi, In the JavaDoc comment for java.util.jar.Attributes#equals on line 269 it says: [...] Returns true if the given object is also an instance of Attributes [...] but that is not actually true. Passing a LinkedHashMap results also in true returned given equal content of both maps. Comment and

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

Better late than too late: Would it be an option to catch the exception in JarFile.getManifestFromReference and throw another one with the name and the caught exception as a cause? Because this is the only code that calls that particular constructor that I know of. JarVerifier could be a

[RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful construction with read and will be used by subsequent

[PATCH] for error message not containing file name of jar with bad manifest

Hi, I suspect that the filename of a jar never gets into the error message because the only place Manifest.jarFilename is assigned is in Manifest.Manifest(JarVerifier,InputStream,String) only after a successful call to Manifest.read by which the manifest is already fully read and parsed and after

Re: Wrong statement suspected in jar.html

to spec of Manifest, the "header" is called the main > attributes and all the others manifest entries. > > And yes, this is the correct mail list to talk about this issue. I > also have no idea where the source of that tooldoc is. Someone on the > list should know. > &g

Wrong statement suspected in jar.html

Hi, https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature-val idation says: When the jar tool is used to add files, the manifest file is changed (s ections are added to it for the new files), but the signature file is n ot. It appears to me that using the jar tool to add files to

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

New patch attached. Philipp On Wed, 2018-12-19 at 09:44 -0500, Roger Riggs wrote: > Hi, > > > >     On 12/18/2018 06:00 PM, Philipp Kunz >   wrote: > > > > >    > >   Hi Roger > >    > > > >    >

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

now with assertThrows. Find a new patch attached. On Tue, 2018-12-18 at 13:38 -0800, Martin Buchholz wrote: > On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen .com> > wrote: > > > > > Is there a reason you did not use > > > > @Test(expectedExceptions = IOException.class) > > > > It just seems

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Thanks. Find a new patch attached. On Mon, 2018-12-17 at 12:12 -0500, Roger Riggs wrote: > Hi Philipp, > > > > Manifest.java: > > > >  - Line 258: creating a new array for two characters on each call > isn't as efficient as: > >     out.write('\r');  > >    

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

to resolve the deprecation and hence I figure it might be good enough if the result is at least as good as the previous version. Does that convince or make any sense? Find another patch attached. On Mon, 2018-12-17 at 08:06 +0100, Claes Redestad wrote: > On 2018-12-17 07:42, Philipp Kunz wrote: &g

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

nd SIGNATURE_VERSION > should use "#". > > * {@link Attributes.Name#MANIFEST_VERSION} or > > * {@link Attributes.Name#SIGNATURE_VERSION} must be set in removed it again because it applies more to bug 8196371 or 6910466 > > > Thanks, R

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

l improvement (multi- > byte) > and fix the deprecation as a side effect. > > Thanks for digging through the issues and the explanations; > it will take a bit of study to unravel and understand everything in > this  > changeset. > > Regards, Roger > > > On 12/01/20

RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Find the proposed patch attached. Some comments and explanations, here: There is a quite interesting implementation in Manifest and Attributes worth quite some explanation. The way it used to work before was: 1. put manifest header name, colon and space into a StringBuffer -> the buffer now

Re: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Please find another revised and updated patch attached. On Sun, 2018-10-21 at 15:10 -0700, Martin Buchholz wrote: > I only took a quick look. > Looks good, but here's a nitpick - capitalize javadoc that begins > with "returns" > On Fri, Oct 19, 2018 at 1:27 AM, Philipp

Re: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Hi Martin and everyone, You were absolutely right to object "utf". Please find a revised and updated patch attached. Regards, Philipp On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > "utf8" is a thing.  "utf" is not. > > On Thu, Oct 4, 2

Review Request: 6443578: Continuation lines in JAR manifests do not follow RFC-822

Hi, Attached is a patch with a proposal to fix bug 6443578 about Manifest inserting line breaks in between bytes of characters encoded in utf-8 with more than one byte and a test for it. The Issue The current Manifest implementation places line breaks for breaking and continuing values onto

Re: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Thanks to Martin's hint, I revised the test to use UTF-8 consistently and not utf. Philipp On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > "utf8" is a thing.  "utf" is not. > > On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz h> wrote: > > Thanks

Re: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

it might be preferred to use "utf8" directly in the test > instead of current "utf" > > -sherman > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > In short, bug 6202130 is about removal of comments in Attributes > > like > > > >

Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

ing before. In the main code, the patch only removes a few comments and does not change actual code. It all has been working before and now we know. Philipp https://bugs.openjdk.java.net/browse/JDK-6202130 On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > Hi, > > There are s

Patch for 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Hi, There are some comments in the source code like this: > XXX Need to handle UTF8 values and break up lines longer than 72 bytes in Attributes.java on lines 299, 327, and 370. Bug 6202130 also suggests to add a test to show that the character set is fully supported before actually removing

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests / interesting impl and use of deprecated code

byte[] vb = value.getBytes("UTF8"); value = new String(vb, 0, 0, vb.length); } buffer.append(value); Manifest.make72Safe(buffer); buffer.append("\r\n"); out.writeBytes(buffer.toString(

Question/discussion how to resolve 8196371, 4271239, 4935610, and 6910466 about missing manifest version in Attributes#writeMain

Hi, Bugs 8196371, 4271239, 4935610, and 6910466 all are about manifests with no version. Which approach would be preferable? 0) leave the impl as is - close with resolution won't fix 1) assume a version automatically if not explicitly set (suggested in 6910466 and 4271239) 2) throw an

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

Hi Brain and Roger, Thank you very much for your hint about submitting patches. In the meantime I got feeback [1] from Xueming Shen and I sent two (much) smaller portions [2] and [3] which makes [5] now obsolete. I saw through my own messages again and found them having the patches

Re: RFR for 6443578: Continuation lines in JAR manifests do not follow RFC-822

} buffer.append(value); Manifest.make72Safe(buffer); buffer.append("\r\n"); out.writeBytes(buffer.toString()); - sherman On 5/1/18, 10:21 PM, Philipp Kunz wrote: Hi, Recently, I tried to fix only bug 6202130 with

Re: RFR for 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

value.getBytes("UTF8"); value = new String(vb, 0, 0, vb.length); } buffer.append(value); Manifest.make72Safe(buffer); buffer.append("\r\n"); out.writeBytes(buffer.toString());

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

? Regards, Philipp On 02.05.2018 07:21, Philipp Kunz wrote: Hi, Recently, I tried to fix only bug 6202130 with the intention to fix bug 6443578 later with the intention to get some opportunity for feedback, but haven't got any, and propose now a fix for both together which in my opinion makes

JDK-6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars

Hi, I tried to fix bug 6202130 about manifest utf support and come up now with a test as suggested in the bug's comments that shows that utf charset actually works before removing the comments from the code. When I wanted to remove the XXX comments about utf it occurred to me that version

Re: Cannot add attribute into main attributes of a jar if there is no version

duplicate of https://bugs.openjdk.java.net/browse/JDK-6910466? On 30.01.2018 02:44, Weijun Wang wrote: On Jan 30, 2018, at 8:57 AM, mandy chung wrote: On 1/29/18 4:22 PM, Weijun Wang wrote: Ping again. On Jan 22, 2018, at 1:12 PM, Weijun Wang

Re: JDK-6372077: JarFile.getManifest() should handle manifest attribute names up to 70 bytes

, I'm tending to agree with the suggestion about line length interpretation. To meet OpenJDK IP requirements, please attach the .patch file or include it in the body of the message. Thanks, Roger On 12/18/2017 11:17 PM, Philipp Kunz wrote: Hi Roger, My suggested and also preferred approach

Re: JDK-6372077: JarFile.getManifest() should handle manifest attribute names up to 70 bytes

understand the ramifications of the change you propose. It seems there is a difficult/unresolvable conflict in the specifications between the line length requirements and the header specs. Regards, Roger On 11/21/2017 1:18 AM, Philipp Kunz wrote: Hi everyone, I haven't got any reply now

RFR JDK-6372077: Manifest should handle manifest attribute names up to 70 bytes

itten down in either the preceding mails included below or as comments in the patch. I'd be glad to get any kind of feedback and am looking forward to closing another bug. Regards, Philipp On 21.11.2017 07:18, Philipp Kunz wrote: Hi everyone, I haven't got any reply now for around three wee

Re: JDK-6372077: JarFile.getManifest() should handle manifest attribute names up to 70 bytes

confusingly in my last email. As far as I understood, I should first get a sponsor. In any case, is there any suggestion for how to proceed? Regards, Philipp On 03.11.2017 00:04, Philipp Kunz wrote: Hi Sean and Max and all others, Thank you Sean for the hint about the right mailing list

JDK-6372077: JarFile.getManifest() should handle manifest attribute name 70 bytes

dev (where this was originally posted). --Sean On 10/2/17 1:24 PM, Philipp Kunz wrote: Hi, While fixing JDK-6695402 I came across other related bugs to manifests such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, and JDK-6443578 which all relate to manifest reading and writing. Somewh