Re: Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs

Moved this thread from discussions mailing list[1] to here. Comments inline. On 11/12/17 7:55 PM, Alan Bateman wrote: On 11/12/2017 14:06, Jaikiran Pai wrote: : So a few related questions that I have are:     1. Is this inconsistency an expected behaviour or is this a bug?     2

Re: Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs

On 11/12/17 9:43 PM, Alan Bateman wrote: On 11/12/2017 15:46, Jaikiran Pai wrote: Thanks Alan. Given that the cache itself is being planned to be eventually removed, that answers the main part of my question and I can workaround this issue in a couple of ways (disabling the cache using

Re: [PATCH] JDK-8159797 Throw a right IllegalArgumentException from the bytecode generated by Method/ConstructorAccessor

would like more reviews, especially the part where this introduces an additional "aload" instruction. -Jaikiran Mandy On 5/10/18 8:21 PM, Jaikiran Pai wrote: Any reviews/sponsors please? -Jaikiran On 03/05/18 6:24 PM, Jaikiran Pai wrote: Hi, This mail contains a poten

Re: RFR: 8201274: Launch Single-File Source-Code Programs

Not a reviewer, but a minor comment: src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java +private Path getFile(String[] args) throws Fault { +if (!Files.exists(file)) { +// should not happen when invoked from launcher +throw new

Re: RFR: 8201274: Launch Single-File Source-Code Programs

Just gave the patch a try by locally building it. Works great! :) A minor comment- the java usage/help text shows this: Usage: java [options] [args...]    (to execute a class)    or  java [options] -jar [args...]    (to execute a jar file)    or  java [options] -m [/]

Re: [PATCH] JDK-8159797 Throw a right IllegalArgumentException from the bytecode generated by Method/ConstructorAccessor

Any reviews/sponsors please? -Jaikiran On 03/05/18 6:24 PM, Jaikiran Pai wrote: Hi, This mail contains a potential patch to the issue[1] that I had reported a couple of years back. The issue is still valid and reproducible with latest upstream JDK. In brief, if a certain code has

[PATCH] JDK-8159797 Throw a right IllegalArgumentException from the bytecode generated by Method/ConstructorAccessor

iran # HG changeset patch # User Jaikiran Pai <jaikiran@gmail.com> # Date 1525350350 -19800 # Thu May 03 17:55:50 2018 +0530 # Node ID 2b535248cf02d90f6fea1c89150a277f16954c04 # Parent 7379e6f906aeb6e69ed8eccda9de285e606ab1ff JDK-8159797 Prevent NPE from the generated Method/Construc

[PATCH] JDK-8159797 Throw a right IllegalArgumentException from the bytecode generated by Method/ConstructorAccessor

iran # HG changeset patch # User Jaikiran Pai <jaikiran@gmail.com> # Date 1525350350 -19800 # Thu May 03 17:55:50 2018 +0530 # Node ID 2b535248cf02d90f6fea1c89150a277f16954c04 # Parent 7379e6f906aeb6e69ed8eccda9de285e606ab1ff JDK-8159797 Prevent NPE from the generated Method/Construc

Re: Arrays.asList returned List - Its modifying/write-through semantics

ne for > List.removeIf() here [2]. > > [2] https://bugs.openjdk.java.net/browse/JDK-8023339 I looked at that commit and yes, a similar @throws explaining the UnsupportedOperationException will be helpful. -Jai > > With kind regards, > Ivan > > > On 8/14/18 10:58 PM, Jaikiran Pai wrot

Re: Arrays.asList returned List - Its modifying/write-through semantics

Hi Ivan, On 15/08/18 4:27 PM, Jaikiran Pai wrote: > Hi Ivan, > > > On 15/08/18 1:20 PM, Ivan Gerasimov wrote: >> Hi Jaikiran! >> >> The first part (the documentation clarification) was requested some >> time ago [1], so it may be eventually fixed. >> &

Arrays.asList returned List - Its modifying/write-through semantics

Consider the following code: import java.util.Arrays; import java.util.List; public class ArraysAsListTest {     public static void main(final String[] args) throws Exception {         final List someList = Arrays.asList(new String[] {"a"});         System.out.println("Removed? " +

Re: Arrays.asList returned List - Its modifying/write-through semantics

Thank you Roger and Stuart for the detailed reply. Comments inline. On 17/08/18 7:27 AM, Stuart Marks wrote: >   > > Note that while this is changing javadoc and doc comments the task is > quite a bit more rigorous than merely updating documentation. The > javadoc for public Java SE APIs is a

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Anyone willing to help review the patch, please? -Jaikiran On 20/08/18 5:56 PM, Jaikiran Pai wrote: > Hello everyone, > > I'm requesting a review of a documentation change which was discussed in > a recent thread[1][2]. Here's an initial proposed draft, for a better >

[PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Hello everyone, I'm requesting a review of a documentation change which was discussed in a recent thread[1][2]. Here's an initial proposed draft, for a better documentation of Arrays.asList method:     /** * Returns a fixed-size list backed by the specified array. The passed * array is

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

I agree with Chris. Unlike the connection failure error messages where the IP/port being part of the error message did add value, I don't think including the "path" to the jar (something like /opt/private/foo/bar/helloworld.jar) in case of MANIFEST parsing errors is really necessary. I think, just

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Hello Bernd, Thank you for the review and sorry about the delayed response. Comments inline. On 29/08/18 4:26 PM, Bernd Eckenfels wrote: > Hello, > > Not an Reviewer But just wanted to give a short Feedback: I like the > new Version it is really helpful.  > > However I wonder if the usage

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

List#of() */ -Jaikiran # HG changeset patch # User Jaikiran Pai # Date 1535208403 -19800 # Sat Aug 25 20:16:43 2018 +0530 # Node ID e4d5e71a20f7c80196f211f62440d3cccb69e8f3 # Parent a716460217ed180972b568e28cf332e37e07a3ae JDK-7033681 Improve the javadoc of Arrays#toList() diff --git

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Any other reviews? I'm not a committer, so I'll also need someone to help sponsor this patch. -Jaikiran On 06/09/18 7:39 PM, Jaikiran Pai wrote: > On 06/09/18 1:24 PM, Bernd Eckenfels wrote: >> Yes you are right @apinote is aproperiate section (was confusing it with >> implnot

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Hi Matthias, I am not a reviewer and neither do I have enough knowledge about whether jar/file _names_ are considered security sensitive. However, the patch that's proposed for this change, prints the file _path_ (and not just the name). That I believe is security sensitive. -Jaikiran On

Re: InetAddress.getByName/getAllByName for empty host string

wrote: Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what

InetAddress.getByName/getAllByName for empty host string

The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention

Re: InetAddress.getByName/getAllByName for empty host string

On 20/04/18 11:24 AM, Alan Bateman wrote: On 20/04/2018 05:37, Jaikiran Pai wrote:  I'm in the process of creating the patch and will send it out to this list soon. Best to send it to the net-dev list as this is where the java.net API is mostly maintained. Will do. Thank you. -Jaikiran

Re: InetAddress.getByName/getAllByName for empty host string

Hi Chris, On 16/04/18 9:33 PM, Chris Hegarty wrote: Jaikiran, On 13/04/18 16:29, Jaikiran Pai wrote: Hi Chris, Thank you creating that JIRA. If the fix involves just updating the javadoc, is this something that youwould like me to contribute as a patch? I have a signed and approved OCA

[PATCH] JDK-8211765 - JarFile constructor throws undocumented exception

wrote: >> On 5 Oct 2018, at 12:08, Jaikiran Pai wrote: >> >>> I don't have access to create an issue for this in OpenJDK JIRA, so I'll >>> go ahead and create one at bugs.java.com. >>> >> I just submitted the report. Internal review id 9057522

Re: Filesystem case sensitive check and java.io.File#equals

Thanks for the clarification, Alan. -Jaikiran On Thursday, November 8, 2018, Alan Bateman wrote: > On 08/11/2018 12:59, Jaikiran Pai wrote: >> >> A slightly related question - I used the example that Roger showed and >> it mostly worked. However, Fi

Re: Filesystem case sensitive check and java.io.File#equals

// supply a directory to test a > particular file system >     Path path1 = Files.createTempFile(dir, "MixedCase", ""); >     Path path2 = > Path.of(path1.toString().toLowerCase(Locale.US)); >     return Files.isSameFile(path1, path2); > > or sim

Filesystem case sensitive check and java.io.File#equals

In one of the projects that I'm involved in, we do a bunch of file operations which sometimes need to check if a particular filesystem is case sensitive. I was thinking of using java.io.File#equals since its javadoc states: /** * Tests this abstract pathname for equality with the given

Re: Filesystem case sensitive check and java.io.File#equals

Hi Alan, On 07/11/18 7:15 PM, Alan Bateman wrote: > On 07/11/2018 13:13, Jaikiran Pai wrote: >> : >> >> >> My impression, based on that javadoc, was that the implementation of >> that API will use the underlying _filesystem_ to decide whether or not >> its

Re: Filesystem case sensitive check and java.io.File#equals

Files.createTempFile(dir, "MixedCase", ""); >     Path path2 = > Path.of(path1.toString().toLowerCase(Locale.US)); >     return Files.isSameFile(path1, path2); > > or similar... > > Roger > > On 11/07/2018 09:27 AM, Jaikiran Pai wrote: >> Hi Alan, &

Re: JarFile constructor throws undocumented exception (only) on Windows OS

core-libs-dev@openjdk.java.net > *Betreff:* Re: JarFile constructor throws undocumented exception > (only) on Windows OS >   > Just for reference - this came up while debugging an issue, that one of > our users of Apache Ant project raised here > https://bz.apache.org/bugzilla/show_bug.cg

Re: JarFile constructor throws undocumented exception (only) on Windows OS

Just for reference - this came up while debugging an issue, that one of our users of Apache Ant project raised here https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8 -Jaikiran On 04/10/18 3:06 PM, Jaikiran Pai wrote: > Please consider the following trivial code: > > import java

Re: JarFile constructor throws undocumented exception (only) on Windows OS

Hello Alan, On 05/10/18 4:15 PM, Alan Bateman wrote: > On 04/10/2018 10:36, Jaikiran Pai wrote: >> : >> >> >> The javadoc of JarFile constructor(s) mentions that: >> >>   * @throws IOException if an I/O error has occurred >> >> Given that th

Re: JarFile constructor throws undocumented exception (only) on Windows OS

> I don't have access to create an issue for this in OpenJDK JIRA, so I'll > go ahead and create one at bugs.java.com. > I just submitted the report. Internal review id 9057522 has been assigned to the issue. -Jaikiran

JarFile constructor throws undocumented exception (only) on Windows OS

ion to wrap that into a IOException? Something like: # HG changeset patch # User Jaikiran Pai # Date 1538645309 -19800 #  Thu Oct 04 14:58:29 2018 +0530 # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e # Parent  8705c6d536c5c197d0210acccf145ebc48f90227 Wrap and throw an IOException whe

Re: [PATCH] JDK-8211765 - JarFile constructor throws undocumented exception

Thank you Sherman. -Jaikiran On 05/10/18 9:59 PM, Xueming Shen wrote: > Hi Jaikiran, > > "wrap to throw a IOE" appears good. I will sponsor this patch. > > Thanks! > -Sherman > > On 10/5/18, 8:31 AM, Jaikiran Pai wrote: >> Thank you Chris. >&g

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

On 21/09/18 1:04 AM, Stuart Marks wrote: > > > Since you mentioned it I'll proceed with "Jaikiran Pai > " since that looks a bit more "official". Sounds fine to me and yes it indeed is a bit more official one. Thank you. -Jaikiran

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

e listed your email > address in the Contributed-by line of the changeset comment. Thank you. More of a FYI and if it matters from a process point of view - in a couple of my earlier contributions, the sponsors have used the "Contributed-by" line to be "Jaikiran Pai " like here h

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Hello Stuart, Thank you very much for your help in sponsoring this as well as the detailed reviews and suggestions. -Jaikiran On Thursday, September 27, 2018, Stuart Marks wrote: > Hi, I just wanted to mention that I pushed the changeset for this bug: > >

Multi-release jar file - Should the "Multi-Release" mainfest attribute have a specific value?

Hi, The Multi-Release JarFile support JEP[1] notes that the jar file is expected to contain a main attribute: Multi-Release: true The JarFile javadoc[1] on the other hand makes no mention of the value for such an attribute and just mentions that the Multi-Release main attribute needs to be

Re: jar --verify operation mode checking mrjar validity

(resending using the email id I'm subscribed by, in this list) On 02/12/18 3:43 PM, Alan Bateman wrote: > On 01/12/2018 08:45, Christian Stein wrote: >> Hi, >> >> jar --create (and --update) perform type API validation checks when >> used in >> combination with --release option. This detects

Re: jar --verify operation mode checking mrjar validity

On 02/12/18 3:43 PM, Alan Bateman wrote: > On 01/12/2018 08:45, Christian Stein wrote: >> Hi, >> >> jar --create (and --update) perform type API validation checks when >> used in >> combination with --release option. This detects invalid "version >> overlays" >> at package time, where the API

Re: Source file launcher - Handling of pre-compiled classes of the source file

Thank you Jon. -Jaikiran On 15/09/18 10:34 PM, Jonathan Gibbons wrote: > Jaikiran, > > This issue is on our radar; there is no need for any additional action > on your part at this point. > > -- Jon > > > On 9/14/18 7:50 PM, Jaikiran Pai wrote: >> Hello Pe

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

by which the list will be backed >> * @return a list view of the specified array >> * @see List#of() > > OK. We probably don't need the @see for List.of if there's a reference > to the "unmodifiable lists" section above. Done. "@see List#of()" i

Re: Source file launcher - Handling of pre-compiled classes of the source file

Hello Peter, On 14/09/18 1:03 PM, Peter Levart wrote: > > The check for main class is performed after compilation (which > actually produces the main class name). > > I think it would be possible to check for all classes compiled from > the source file after compilation without to much

Source file launcher - Handling of pre-compiled classes of the source file

Please consider this trivial code C.java: public class C {     public static void main(String[] args) throws Exception {         System.out.println("main() execution started");     } } > ls C.java Similar to a previous discussion[1] while doing random testing, I ended up compiling C.java

Re: Multi-release jar file - Should the "Multi-Release" mainfest attribute have a specific value?

Thank you Alan. -Jaikiran On 23/01/19 8:09 PM, Alan Bateman wrote: > On 23/01/2019 14:27, Jaikiran Pai wrote: >> Hi, >> >> The Multi-Release JarFile support JEP[1] notes that the jar file is >> expected to contain a main attribute: >> >> Multi-Re

Re: Inputs on patch for JDK-8225763?

Hello Alan, On 27/06/19 4:22 PM, Alan Bateman wrote: > On 27/06/2019 11:16, Remi Forax wrote: >> Is a boolean isEnded that records if end() was already called is not >> enough ? >> > I'm sure Jaikiran will create tests that cover the different > combinations of overriding end and close. It might

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hello Lance, On 12/07/19 5:53 AM, Lance Andersen wrote: > Hi Jaikiran, >> I have now updated the javadoc of end() to be closer to the javadoc >> of close(). >> >> > > Its better but end() should include the wording  > > > This method should be called when the compressor is no longer needed.

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hello Peter, On 13/07/19 2:50 PM, Peter Levart wrote: > Hi Jaikiran, > > On 7/12/19 9:07 AM, Jaikiran Pai wrote: >> The new updated webrev is at >> http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/ > > > I don't know if there are any custom subclasses

RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Can I please get a review and a sponsor for the patch that implements the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763 ? There has been a recent discussion about this change in the core-libs-dev mailing list here[1]. The latest version of the patch for this change is now

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

Hello Lance, On 08/07/19 11:16 PM, Lance Andersen wrote: > Hi Jaikiran, > > Thank you for your efforts here. > >> On Jul 6, 2019, at 9:59 AM, Jaikiran Pai > <mailto:jai.forums2...@gmail.com>> wrote: >> >>> >>>  - Idempotency >>&g

Inputs on patch for JDK-8225763?

I am looking to contribute a patch for the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself looks relatively straightforward to me and here's what I plan to do: 1. Have both java.util.zip.Inflater and java.util.zip.Deflater start implementing the

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

Hello Stuart, Thank you for the detailed response. Comments inline. On 28/06/19 2:48 AM, Stuart Marks wrote: > On 6/26/19 9:28 PM, Jaikiran Pai wrote: >> I am looking to contribute a patch for the enhancement noted in >> https://bugs.openjdk.java.net/browse/JDK-8225763. Th

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

On 29/06/19 4:31 PM, Jaikiran Pai wrote: > Hello Stuart, > > Thank you for the detailed response. Comments inline. > > On 28/06/19 2:48 AM, Stuart Marks wrote: >> On 6/26/19 9:28 PM, Jaikiran Pai wrote: >>> I am looking to contribute a patch for the

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

p that array too. If this isn't the right time/patch to do it, please do let me know and I'll take that up separately. Thank you very much for your inputs so far. [1] http://cr.openjdk.java.net/~jpai/webrev/8225763/1/webrev/index.html P.S: I can start a new official RFR thread in this mailing

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

Hello Lance, On 03/07/19 11:27 PM, Lance Andersen wrote: >  Just a thought below to consider or ignore ;-)  >> On Jul 2, 2019, at 11:27 PM, Stuart Marks > > wrote: >> >> Hi Jaikiran, >> >> OK, good analysis. Rather a lot of issues for what seems like a >> simple

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

ImplSpec, I am not sure the initial wording for end() > and close() really need to differ: > > end(): > > Closes the decompressor and discards any unprocessed input. > > close(): > > Releases resources held by this decompressor and discards any > unpr

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hello Lance, On 10/07/19 2:25 AM, Lance Andersen wrote: > ——— > @implSpec This method is a no-op if this compressor has already > 886 * been previously closed, > > > > Please remove “already” in both the close() and end() methods. Done. >  I believe the preference is the @implSpec and its

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

On 09/07/19 8:44 PM, David Lloyd wrote: > On Tue, Jul 9, 2019 at 8:19 AM Jaikiran Pai wrote: >> - In addition, I have sneaked in an unrelated change in this patch, into >> the Deflater.end() method: >> >> public void end() { >> synchronized (

Re: ZipFileSystem and the impact of JDK-8031748 on ordering of MANIFEST files in the created jars

Adding core-libs-dev, since this also involves java.util.jar APIs. -Jaikiran On 14/11/19 8:47 PM, Jaikiran Pai wrote: > Please consider the code listed at the end of this mail. What it does is > uses ZipFileSystem to create 2 jar files with identical content. foo.jar > and bar.

Re: ZipFileSystem and the impact of JDK-8031748 on ordering of MANIFEST files in the created jars

Hello Lance, On 14/11/19 9:35 PM, Lance Andersen wrote: > ... > > There is an existing Zip FS enhancement > request, https://bugs.openjdk.java.net/browse/JDK-8211917.  Thank you, I hadn't noticed this one before sending this mail. I'll keep a watch on this one. -Jaikiran

Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

Imagine 2 jar files. One called helloworld.jar which contains just a single org.myapp.HelloWorld class which prints to System.out from its main method. The other jar called manifest-cp-test.jar. This manifest-cp-test.jar contains (only a) META-INF/MANIFEST.MF with the following content:

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

FWIW - this was reported by one of Quarkus project users here https://github.com/quarkusio/quarkus/issues/5359 -Jaikiran On 18/11/19 8:31 PM, Jaikiran Pai wrote: > Imagine 2 jar files. One called helloworld.jar which contains just a > single org.myapp.HelloWorld class which prints to Syst

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

Hello Alan, On 18/11/19 9:17 PM, Alan Bateman wrote: > On 18/11/2019 15:03, Jaikiran Pai wrote: >> FWIW - this was reported by one of Quarkus project users here >> https://github.com/quarkusio/quarkus/issues/5359 >> > BTW: Do you know if this is a mistake in t

java.lang.System's comment about initializeSystemClass

The java.lang.System has this code comment[1] which states: " /* Register the natives via the static initializer. * * VM will invoke the initializeSystemClass method to complete * the initialization for this class separated from clinit. * Note that to use properties set by

Re: java.lang.System's comment about initializeSystemClass

On 18/10/19 12:39 PM, Alan Bateman wrote: > On 18/10/2019 08:03, Jaikiran Pai wrote: >> >> However, I can't find that "initializeSystemClass" method anywhere in >> that class or any other class in the JDK code. Is that comment still >> relevant or am I l

Re: java.lang.System's comment about initializeSystemClass

On 18/10/19 4:51 PM, Alan Bateman wrote: > On 18/10/2019 08:12, Jaikiran Pai wrote: >> : >> Thank you Alan. Should I create a JBS issue to track and have this >> changed? >> > Yes, go ahead, we just missed updating this comment in JDK 9. Done - https://bugs.openj

RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Can I please get a review and a sponsor for a potential fix for JDK-8232879[1]? The patch is available as a webrev at [2]. What's happening in there is that the jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the one arg write(byte b) method and calling the super.write(b) and

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Thank you Lance. -Jaikiran On 24/10/19 1:17 AM, Lance Andersen wrote: > Hi Jaikiran, > > I will take a look and once we are good with the review, I can sponsor it. > > Best > Lance >> On Oct 23, 2019, at 7:24 AM, Jaikiran Pai > <mailto:jai.forums2...@gmail.com&g

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Hello Christoph, Thank you for the very detailed review. Comments inline. On 24/10/19 3:00 AM, Langer, Christoph wrote: > > For the path to the test file, you could simply do: final Path jarPath = > Paths.get("zipfs-crc-test.jar"); > The test is run in the scratch directory of jtreg, so no

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Thank you for the review, Lance. On 26/10/19 4:25 AM, Lance Andersen wrote: > > The change to Zip FS looks good.  I re-worked the test so that it also > runs against ZipFile (which uses the CEN vs the LOC) and Zip FS in > addition to ZipInputStream for extra coverage. > > The webrev can be found

Re: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...")

Thank you all for the real quick fix for these 2 issues. In the context of Quarkus project, trying to get a decent workaround to get past these issues across all prominent Java versions (and OS) was starting to get a bit out of hand. But with this fixed consistently within in the JDK now, it's

Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

, Jaikiran Pai wrote: > > Hello Lance, > > On 05/02/20 3:13 am, Lance Andersen wrote: >> Hi Jaikiran, >> >> Thank you again for tackling this feature request. >> >> Overall, I think this looks OK. >> >> In ZipFileSystem.java, I would reverse th

Re: DriverManager.isDriverAllowed has an unintentional side-effect?

Hello Lance, On 11/02/20 2:05 am, Lance Andersen wrote: > Hi Jaikiran > > >> >> Should this check in the isDriverAllowed, instead use "false" and not >> trigger the intialization of the class? > > As I mentioned above, this dates back to the very early days of JDBC > and JDK 1.2.  Any changes in

Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hello Lance, On 28/02/20 2:41 am, Lance Andersen wrote: > Hi Christoph, > > I have cleaned up, re-vamped and added more coverage to the test.  As > part of this I started to lay the foundation for removing some of the > duplicate code as part of continued clean up and enhanced coverage > going

Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

On 03/03/20 12:45 pm, Langer, Christoph wrote: > Unfortunately I don't get the mails from Martin ☹ Same for me. They always end up in spam folder which I usually check once a month. I see that there's already https://bugs.openjdk.java.net/browse/JDK-8213225 which seems to be the same issue.

Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hello Lance, On 05/02/20 3:13 am, Lance Andersen wrote: > Hi Jaikiran, > > Thank you again for tackling this feature request. > > Overall, I think this looks OK. > > In ZipFileSystem.java, I would reverse the if statement given a > MANiFEST.MF present is going to be the exception vs the norm.  

Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hello Lance, On 15/02/20 2:27 am, Lance Andersen wrote: > Hi Jaikiran, > > I think the changes to ZipFileSystem are OK. > > The test overall is good.  I am going to streamline it a bit and > remove the long lines (we try to keep lines to around 80 characters). > I'll keep that in mind for future

Re: DriverManager.isDriverAllowed has an unintentional side-effect?

Hello Lance, On 13/02/20 12:22 am, Lance Andersen wrote: > Hi Jaikiran > >> On Feb 10, 2020, at 10:05 PM, Jaikiran Pai > <mailto:jai.forums2...@gmail.com>> wrote: >> >> Hello Lance, >> >> On 11/02/20 2:05 am, Lance Andersen wrote: >

DriverManager.isDriverAllowed has an unintentional side-effect?

Right now within the implementation of APIs in java.sql.DriverManager there are classloader checks to ensure whether the caller is allowed access to registered drivers. For example the getDriver(String url) API[1] calls the isDriverAllowed (private) method[2] to check if the registered driver is

RFR 7143743: (zipfs) Potential memory leak with zip provider

Can I please get a review and a sponsor for a patch which fixes JDK-7143743[1]? The patch is hosted as a webrev at [2]. As noted in the JBS issue, the ZipFileSystem, even after being closed can end up holding on to large amounts of memory. The root of the issue is the "inodes" map which is

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

Hello Alan, On 11/01/20 3:37 pm, Alan Bateman wrote: > On 11/01/2020 09:51, Jaikiran Pai wrote: >> : >> >> The commit here fixes that issue by simply clearing the "inodes" map in >> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage >&

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

Thank you Lance. -Jaikiran On 12/01/20 2:26 am, Lance Andersen wrote: > I am happy to sponsor this next week after providing time for > additional review feedback and also sanity check it via Mach5 > > Best > Lance > >> On Jan 11, 2020, at 5:24 AM, Jaikiran Pai > <m

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

ensureOpen()). Other than that, the > change looks fine. > > Cheers > Christoph > >> -Original Message----- >> From: nio-dev On Behalf Of Jaikiran >> Pai >> Sent: Samstag, 11. Januar 2020 11:24 >> To: Alan Bateman ; nio-...@openjdk.java.net >

Re: RFR 7143743: (zipfs) Potential memory leak with zip provider

Looks fine Lance. I forgot about the copyright year, thank you for taking care of that one too. -Jaikiran On 14/01/20 1:56 am, Lance Andersen wrote: > > >> On Jan 13, 2020, at 1:53 PM, Alan Bateman > <mailto:alan.bate...@oracle.com>> wrote: >> >> On

RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

Can I please get a review and a sponsor for this patch which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-8244706? The commit here sets the `OS` header flag to `255` (which represents `unknown`) as noted in [1]. A new test has been included in this commit to verify the

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v3]

k/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Improve the comment for the OS_UNKNOWN field - Changes: - all: https://git.openjdk.java.net/

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4]

k/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Remove unintended file commit - Changes: - all: https://git.openjdk.java.net/

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4]

On Sun, 13 Sep 2020 02:22:54 GMT, Jaikiran Pai wrote: >> Hi Jaikiran, >> >> The change seems fine an inline with the RFC. I can sponsor this once we >> have another review. >> >> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tie

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v2]

k/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request conta

Re: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2]

On Tue, 15 Sep 2020 15:33:51 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove "final" > > Hi Jaikiran, > > This is not an are

Re: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2]

On Tue, 15 Sep 2020 15:29:44 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove "final" > > src/java.base/share/classes/java/util/jar/JarFile.java line

Re: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2]

On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote: > As for this: > >> As long as the input stream close() method is idem potent this should be >> safe, and AFAICS that is the case for the two >> input stream subclasses that can be returned by ZipFile::getInput

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: >> Can I please get a review and a sponsor for this patch which fixes the issue >> reported in >> https://bugs.openjdk.java.net/browse/JDK-8244706? >> The commit here sets the `OS` header flag to `255` (which represents >> `unknown`) as

Re: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException

On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for a fix for > https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar > happens to be very large (such

RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException

Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes`

Re: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException

ws, before initiating any /integrate command. -Jaikiran On 23/09/20 10:21 pm, Brent Christian wrote: > On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote: > >>> Can I please get a review and a sponsor for a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8242882?

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4]

On Tue, 15 Sep 2020 16:54:29 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove unintended file commit > > Thank you for making the changes that Brent and I

Integrated: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

On Fri, 11 Sep 2020 14:17:45 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for this patch which fixes the issue > reported in > https://bugs.openjdk.java.net/browse/JDK-8244706? > The commit here sets the `OS` header flag to `255` (which represents > `unk

RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Could I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8240148? The patch is available as a webrev at https://cr.openjdk.java.net/~jpai/webrev/8240148/1/ The patch updates the ScheduledThreadPoolExecutor.execute(Runnable) to wrap the user passed Runnable

  1   2   3   4   5   6   >