, naoto.s...@oracle.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
> 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.
>
&
ot; -> "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:
> >
/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
; 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
&
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 special
ed this correctly.
> Just 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
>
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
an
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
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 attri
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
7 +, Seá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
> >
ml
[2]
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 ne
o discussions on the other.
> It would be best for your 2nd patch to create the jar via the test.
> You could save a byte array containing the contents of the jar and
> have the test write them out as part of the set up
>
> Best
> Lance
>
> > On Feb 10, 2020, at 2:1
lt locale is.
> 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.open
his itself 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 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 as
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
+++ b/src/java.base/share/classes
ere 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 loc
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
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 some
is 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
> >
>
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:
> > T
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 th
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
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, Phi
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 conta
n functional 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
>
>
&
and 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
>
>
> Than
ll 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 wrot
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');
>
>
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 to
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
> >
> >
> >
>
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
g 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.
>
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
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
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 candidat
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 impl
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
patch 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 mani
is going to take some further discussion/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
> > decis
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 iteration
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 a.
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
ManifestDig
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 sho
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 @@
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 a
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
> >
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, Jonath
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
written 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 a
full 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 rep
,
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
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
wrote:
src/java.base/share/classes/jav
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 at
?
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
yte[] 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());
---
}
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 62
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
attached.
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 excep
value != null) {
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(buffe
ve -bcc-ed security-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
e
been written 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 ma
64 matches
Mail list logo