> Overall, introducing a local variable is more-or-less reasonable even if it's
> used only once. One point is that somebody might come along and "clean
> up" the
> code and inline local variables and reintroduce the problem. Another point is
> that, hypothetically, if in the future Eclipse is
Hi,
I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did
not apply cleanly in the imports section of
src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so I
had to resolve this part manually. I also updated the copyright year. Please
check.
> -Original Message-
> From: Daniel Fuchs
> Sent: Donnerstag, 9. Mai 2019 17:24
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
&g
Hi Alan,
Thank you for your comments. Here comes the next update... increasing the
turnaround time a little bit
http://cr.openjdk.java.net/~clanger/webrevs/8213031.10/
> Thanks. I think you've addressed most of my points. The only thing that
> isn't clear is the group owner as I thought we
Hi Lance,
thanks for the quick turnaround. I tried to address your findings. Please find
the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/876.3/
> o FindEND()
> • I know that endsub and comlen fields are not currently used by Zip FS but
> given they are valid fields in the
again from a compiler/spec perspective and make
the according modifications?
Thanks
Christoph
> -Original Message-
> From: David Holmes
> Sent: Mittwoch, 15. Mai 2019 00:05
> To: Langer, Christoph ; Daniel Fuchs
> ; core-libs-dev d...@openjdk.java.net>; net-d
Hi Lance,
> Thank you for taking this on.
Thank you for reviewing! Unfortunately you didn't look at my latest edition...
(http://cr.openjdk.java.net/~clanger/webrevs/876.2/)
In v2 I took back the modification of the hierarchy of classes IndexNode and
Entry so it should be a bit easier to
Hi Daniel,
> > unfortunately, your proposed solution does not work with javac. I get this
> in the build:
>
> Oh darn. I should have double checked.
> Can we at least reduce the scope of the @SuppressedWarnings by
> introducing a private method that just has the return call?
Sure, what about
> -Original Message-
> From: core-libs-dev On Behalf
> Of Alan Bateman
> Sent: Mittwoch, 1. Mai 2019 08:17
> To: Joe Darcy ; nio-dev d...@openjdk.java.net>
> Cc: core-libs-dev
> Subject: Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
> example with map factory methods
current version here: http://cr.openjdk.java.net/~clanger/webrevs/876.1/
Now it passes all testing.
Thank you
Christoph
From: Langer, Christoph
Sent: Freitag, 26. April 2019 17:37
To: core-libs-dev ; nio-dev
; Alan Bateman ; Lance
Andersen
Subject: RE: RFR: 876: (zipfs) Refactoring
Hi,
please review a small change that I'd like to see in OpenJDK to get rid of
compilation errors in the Eclipse IDE.
It seems the root cause for the compilation errors is that javac would
sometimes widen capture variables and is hence able to compile the places that
I touch here. The EC4J
Thank you, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Freitag, 26. April 2019 14:44
> To: Langer, Christoph ; core-libs-
> d...@openjdk.java.net; nio-...@openjdk.java.net
> Subject: Re: RFR (S): 8223015: Cleanups for zipfs tests
>
> Looks good
Hi,
please help reviewing these cleanups to the zipfs tests. In detail:
- Fix warnings in test/jdk/jdk/nio/zipfs/Demo.java (not a real testcase but
Demo coding)
- change some calls of Runtime.version().major() to Runtime.version().feature()
(the former is deprecated)
- change occurences of new
into
a subfolder. So I'll move MultiReleaseJarTest to the subfolder instead of
moving JFSTester.
OK for you if I push this without another webrev next week?
Best regards
Christoph
From: Lance Andersen
Sent: Freitag, 26. April 2019 18:26
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; nio
Great, thank you. This one is a bit larger and will probably need a few
iterations…
From: Lance Andersen
Sent: Freitag, 26. April 2019 18:45
To: Langer, Christoph
Cc: core-libs-dev ; nio-dev
; Alan Bateman
Subject: Re: RFR: 876: (zipfs) Refactoring and cleanups to prepare for
JDK
Hi Lance,
ok, then I’ll remove the commented printf in ZipFSTester altogether. In case
anybody debugs this again, he or she will probably add their own printfs anyway.
Have a nice weekend, too
/Christoph
From: Lance Andersen
Sent: Freitag, 26. April 2019 18:54
To: Langer, Christoph
Cc
Hi Naoto,
thanks for providing a fix so quickly.
The change looks good to me. But I would say the assertion in
CalendarDataUtility in line 266 is pointless now, isn't it?
Best regards
Christoph
> -Original Message-
> From: i18n-dev On Behalf Of
> naoto.s...@oracle.com
> Sent:
Thanks Naoto.
I'll hold back the push (in JDK13) until JDK-8226876 is in.
/Christoph
> -Original Message-
> From: naoto.s...@oracle.com
> Sent: Donnerstag, 27. Juni 2019 18:03
> To: Langer, Christoph ; i18n-
> d...@openjdk.java.net; Java Core Libs
> Cc: Ying Zhou
&g
> > The change looks good to me. But I would say the assertion in
> CalendarDataUtility in line 266 is pointless now, isn't it?
>
> Yes, but would not hurt leaving it. It would catch error if yet another
> case is installed (and it forgot to provide a default value) in the
> switch statement. So
Sounds great. Thank you.
> -Original Message-
> From: naoto.s...@oracle.com
> Sent: Donnerstag, 27. Juni 2019 23:16
> To: Langer, Christoph ; i18n-
> d...@openjdk.java.net; core-libs-dev
> Subject: Re: [13] RFR: 8226876: Assertion in
> sun/util/locale/provide
Hi,
next try, here we go again...
I'd like to backport "JDK-8211122: Reduce the number of internal classes made
accessible to jdk.unsupported". The main reason for backporting this item is
that it'll ease further backports which base on that changeset (e.g.
JDK-8216039). The patch is quite
Hi Thomas,
I looked at this.
One thing that catches my eye immediately: exeCallerAccessTest.c, line 149:
Looks like this #error would always fire on Windows. So the test wouldn’t
compile there…? Or am I wrong?
Furthermore, if we do this new thread dance only on AIX, shouldn’t all the
extra
Hi Lance,
> Overall, I think the changes look good.
Thanks for looking at this.
> Was there a reason that you did not leave the multi-release 9 test as is when
> you added the 10 test?
Well, since I wanted to use this test as blueprint to provoke the jarfs issue,
I had a closer look to it. I
Hi,
during work on JDK-8221880 I spotted some opportunity for cleanup in Windows
resource files and their handling in the build.
The naming of variables used for customizing resource properties in the build
system should be aligned between hotspot and JDK. This should be carefully
reviewed by
Thanks, Erik.
I already checked and will check carefully once again before pushing.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 9. April 2019 15:22
> To: Langer, Christoph ; build-
> d...@openjdk.java.net; hotspot-...@openjdk.java.net
change as is after running some further tests.
Thanks
Christoph
From: Lance Andersen
Sent: Dienstag, 23. April 2019 12:49
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8222440: (zipfs) JarFileSystem does not correctly handle
versioned entries if no root entry is present
Hi Claes,
will you open a bug for this?
Thanks
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Lennart Börjeson
> Sent: Dienstag, 16. April 2019 09:05
> To: Claes Redestad
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: ZipFileSystem performance regression
>
>
://cr.openjdk.java.net/~clanger/webrevs/876.1/
The jtreg tests for zipfs are all passing.
Thanks
Christoph
From: Langer, Christoph
Sent: Donnerstag, 11. April 2019 16:06
To: core-libs-dev ; nio-dev
; Alan Bateman ; Lance
Andersen
Subject: RFR: 876: (zipfs) Refactoring and cleanups to prepare
Hi,
Please, first of all, review a little test fix. Java level assertions should be
enabled in test java/util/Locale/LocaleProvidersRun.java. It was (probably
inadvertently) removed by refactoring the test with JDK-8210403 (Refactor
java.util.Locale:i18n shell tests to plain java tests).
Hi Matthias,
this seems fine to me. The change in NetworkInterface.c is correct, too.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 25. Juli 2019 15:45
> To: Doerr, Martin ; 'hotspot-
> d...@openjdk.java.net' ;
Hi,
please review the backport for JDK-8229773: Resolve permissions for code source
URLs lazily to OpenJDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/
Original Change:
/objections from anybody else. If I
don't get further feedback I'm going to push this within the next 2-3 days:
http://cr.openjdk.java.net/~clanger/webrevs/8213031.17/
Thank you,
Christoph
From: Langer, Christoph
Sent: Mittwoch, 5. Juni 2019 16:45
To: Alan Bateman ; Lance Andersen
Cc: nio-dev
Hi Lance,
this looks good to me.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Lance Andersen
> Sent: Dienstag, 6. August 2019 22:32
> To: core-libs-dev
> Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries
>
> Hi
>
> Please
Hi Matthias,
looks good, thanks for doing this.
How far are we then from enabling "warnings as errors" on AIX? :P
Best regards
Christoph
From: awt-dev On Behalf Of Baesken, Matthias
Sent: Dienstag, 16. Juli 2019 17:04
To: Java Core Libs ; nio-...@openjdk.java.net;
Hi Ogata,
this seems to make sense. So, +1 from my end.
Can you please add a space after "if" in line "734
if(langReflectAccess == null) {"?
Thanks
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Kazunori Ogata
> Sent: Mittwoch, 17. Juli 2019 08:49
Thanks for the review, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 18. September 2019 19:16
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: core-libs-dev
> Subject: Re: [11u] RFR 8229773: Resolve permissions for code
+1
You'll have to update the copyright years in the jni_util files.
Cheers
Christoph
> -Original Message-
> From: David Holmes
> Sent: Mittwoch, 30. Oktober 2019 05:29
> To: Alexey Ivanov ; core-libs d...@openjdk.java.net>; hotspot-runtime d...@openjdk.java.net>;
Sure. Thanks, Alexey.
> -Original Message-
> From: Alexey Ivanov
> Sent: Mittwoch, 30. Oktober 2019 14:22
> To: Langer, Christoph ; David Holmes
> ; core-libs ;
> hotspot-runtime
> Cc: Claes Redestad
> Subject: Re: RFR JDK-8232724: Remove
Hi Volker,
good catch in ZipFileSystem The fix is the right thing to do.
I have a few remarks to the test, though:
Line 52, initialization of the File object: I think you should just do Path
zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework,
it's running in its
Hi,
can I please get reviews for this cleanup change in zipfs.
Bug: https://bugs.openjdk.java.net/browse/JDK-8234089
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.0/
I figured that JarFileSystemProvider is completely obsolete (please correct me
if I'm wrong) and the reasons for
Hi,
please review this cleanup change regarding function "canonicalize" of libjava.
Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
The goal is to cleanup how this function is defined and used. One thing is,
that there was
ctionality and added explicit comments
as well as augmenting MultiReleaseJarTest.java a little bit to test that
"multi-release" is ignored in the right places.
This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.1/
Best regards
Christoph
From: Langer, Christoph
Sen
Hi Gerard,
generally it looks like a nice cleanup.
I've got a patch prepared though, which I was planning on posting tomorrow. It
is about cleanup for the canonicalize function in libjava. I wanted to use
jdk_util.h for the function prototype. I had not yet filed a bug but here is
what I
2019 17:38
To: Volker Simonis
Cc: Langer, Christoph ; Simonis, Volker
; core-libs-dev@openjdk.java.net
Subject: Re: RFR(XS): 8234011: (zipfs) Memory leak in
ZipFileSystem.releaseDeflater()
On Nov 14, 2019, at 11:27 AM, Volker Simonis
mailto:simon...@amazon.com>> wrote:
On 14.11.19 16:27,
Hi Lance,
thanks for reviewing. I've addressed your points:
> I would suggesting moving the code added to the constructor for checking
> the releaseVersion/multi-release properties to a method and grouping it
> with the other methods added for supporting MR jars around line 1396.
> (keeps it
> I plan to review this change. We also need to figure out how to remove
> the dependency on this function from the JPLIS agent as that should not
> be there.
Agree. I'd hope, however, that this can be done with a different change (unless
you have an idea for a very simple, straightforward way
other reviews (e.g. Gerard?)
Thanks & Best regards
Christoph
>
> Thanks,
> David
>
> On 15/11/2019 1:37 am, Langer, Christoph wrote:
> > Hi,
> >
> > please review this cleanup change regarding function "canonicalize" of
> libjava.
&
support?
Best regards
Christoph
> -Original Message-
> From: Thorsten Schöning
> Sent: Montag, 18. November 2019 14:09
> To: core-libs-dev@openjdk.java.net
> Cc: Langer, Christoph ; hotspot-runtime-
> d...@openjdk.java.net; gerard ziemski
> Subject: Re: RFR: 8
Hi Volker,
> > Please remove the "import java.nio.file.Files;" statement before pushing.
> >
>
> It's needed for "Files.deleteIfExists(zipFile)" in the finally block..
Oops, you're right. It popped up in my IDE because I tested what happened when
the file remained in the directory and
Hi Volker,
Looks awesome now
Please remove the "import java.nio.file.Files;" statement before pushing.
Cheers
Christoph
> -Original Message-
> From: Volker Simonis
> Sent: Freitag, 15. November 2019 12:30
> To: Langer, Christoph ; Volker Simonis
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 21. November 2019 14:19
> To: Alan Bateman ; core-libs-
> d...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function between
Hi Alan,
thanks for the review. I'll push it then after running through jdk-submit.
/Christoph
> -Original Message-
> From: Alan Bateman
> Sent: Donnerstag, 21. November 2019 09:51
> To: Langer, Christoph ; core-libs-
> d...@openjdk.java.net; hotspot-runtime-...@o
+1
> -Original Message-
> From: core-libs-dev On Behalf
> Of Roger Riggs
> Sent: Mittwoch, 20. November 2019 16:08
> To: core-libs-dev@openjdk.java.net
> Subject: Re: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
>
> Hi Matthias,
>
> Good to see the switch to strtok_r.
>
Hi Lance,
thanks again. Makes sense to keep comments consistent. So this is what I’m
going to push tomorrow: http://cr.openjdk.java.net/~clanger/webrevs/8234089.5/
Cheers
Christoph
From: Lance Andersen
Sent: Mittwoch, 20. November 2019 19:02
Cc: Langer, Christoph ; nio-dev
; core-libs-dev
Hi,
I'm currently looking into native debug symbols support for Windows.
The OpenJDK build system supports these two configure flags
--with-native-debug-symbols= (among a few other options
which I don't want to discuss here).
So, the name implies that for "internal", debug symbols should be
_util_md.h by including io_util.h.
http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/
Cheers
Christoph
> -Original Message-
> From: David Holmes
> Sent: Dienstag, 3. Dezember 2019 03:13
> To: Langer, Christoph ; Alan Bateman
> ; gerard ziemski
> Cc: core-libs-dev@openjdk.ja
Hi Arno,
+1
I'll push it for you.
Cheers
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Mandy Chung
> Sent: Mittwoch, 4. Dezember 2019 00:39
> To: Zeller, Arno
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: RFR(XS): 8234696:
>
Hi Martin,
thanks for looking into this and coming up with this patch. The test failures
were quite annoying
In hotspot, there is coding to define a macro "ATTRIBUTE_ALIGNED(x)". I'd
rather like to see that we define such a macro in the JDK code as well and use
it. I think it would make the
nal Message-
> From: Erik Joelsson
> Sent: Mittwoch, 4. Dezember 2019 15:46
> To: Bob Vandette
> Cc: Langer, Christoph ; build-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; hotspot-dev
> developers
> Subject: Re: native debug symbols support on Windows
>
Hi,
please review this import statements cleanup for
src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/WinMsiBundler.java.
I stumbled over an issue when I imported the jpackage project into Eclipse.
Due to importing both, static
e] Cleanup imports in
> WinMsiBundler.java
>
> looks good - thank you.
>
> /Andy
>
> On 12/11/2019 5:02 AM, Langer, Christoph wrote:
> > Hi,
> >
> > please review this import statements cleanup for
> src/jdk.incubator.jpackage/windows/classes/jdk/incuba
Hi Gerard,
this looks good.
Cheers
Christoph
> -Original Message-
> From: gerard ziemski
> Sent: Samstag, 7. Dezember 2019 14:34
> To: hotspot-dev developers ; core-libs-
> d...@openjdk.java.net; Claes Redestad ;
> Mandy Chung ; David Holmes
> ; Sergey Bylokhov
Hi David,
I prepared an updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/
> src/java.base/windows/native/libjava/canonicalize_md.c
>
> +// We can't include jdk_util.h here because the file is used in Oracle
> in another context
> +// #include "jdk_util.h"
>
> Seems to me
Thanks, David.
I'll run the final change once again through jdk-submit befor pushing.
Alan, Dan, may I consider this reviewed by either of you?
Thanks
Christoph
> -Original Message-
> From: David Holmes
> Sent: Freitag, 6. Dezember 2019 08:02
> To: Langer, Christoph ;
>
Thanks, Alan.
Then I'll push it now. A final jdk-submit run succeeded
(mach5-one-clanger-JDK-8234185-4-20191206-0819-7283662).
> -Original Message-
> From: Alan Bateman
> Sent: Freitag, 6. Dezember 2019 13:17
> To: Langer, Christoph ; David Holmes
> ; daniel.daughe...@
Hi Martin,
ok, you are the author – so I won’t insist.
Best regards
Christoph
From: Doerr, Martin
Sent: Freitag, 6. Dezember 2019 12:22
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; security-dev
; Lindenmaier, Goetz
; Thomas Stüfe
Subject: RE: RFR(S): 8220348: [ntintel
mber 2019 23:52
> To: Langer, Christoph
> Cc: core-libs-dev@openjdk.java.net; hotspot-runtime-
> d...@openjdk.java.net; Alan Bateman ; gerard
> ziemski
> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava, hotspot and libinstrument
>
> Hi
Hi Lance,
I looked at this patch as well and it seems good to me.
Cheers
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Lance Andersen
> Sent: Freitag, 25. Oktober 2019 20:42
> To: Alan Bateman
> Cc: core-libs-dev
> Subject: Re: RFR 8231451:
Hi Lance,
thanks for reworking the test. That definitely improves coverage.
The comment for the test method (line 56/57) could be improved like: "Verify
all write methods of an OutputStream that can be used to write to an entry of
Zip Filesystem by exercising all of them when creating an
Hi,
this item is really on the edge between core-libs and hotspot. So I'm
including both lists now.
The canonicalize() method is implemented in libjava, for both Unix and Windows.
For Unix, it is used from hotspot, libjava (the file system implementations)
and libinstrument. But for Windows,
. Oktober 2019 20:21
> To: Langer, Christoph ; Alan Bateman
> ; hotspot-runtime-...@openjdk.java.net; Java
> Core Libs
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
>
> Hi Christoph,
>
> The changes look good.
>
> I agree that other
> I would like to review this change. Would you mind holding off for a few
> days until I can find time?
OK, sure. Then I'll wait for you.
Cheers
Christoph
Hi Alexey,
> Please review the following fix which removes indirection in calling
> JNU_NewStringPlatform via NewStringPlatform.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8232724
> webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/
>
> It is a follow-up fix to JDK-8232624
ober 2019 15:33
> To: Langer, Christoph ; hotspot-runtime-
> d...@openjdk.java.net; Java Core Libs
> Cc: Schmelter, Ralf
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
>
> On 23/10/2019 14:26, Langer, Christoph wrote:
> > Hi Alan,
> >
&g
Hi Alan,
> I have this on my list to look at. I think we'll need to figure out a
> path to separate the usages (the JPLIS agent usage is technical debt, we
> should have addressed that issue a long time ago).
I agree that it's a good thing to explore how the different usages of calls to
Hi,
I've picked up Ralf's patch and cleaned it up a little bit. But apart from some
comment changes it should be the same as his original version. So, what happens
is that the windows 'canonicalize" function will only delegate to
'wcanonicalize' from now on. Furthermore,
Hi Jaikiran,
thanks for proposing this patch. I just had a look and think the fix in
ZipFileSystem.java is the right thing to do.
As for the test: That could be simplified a bit.
For the path to the test file, you could simply do: final Path jarPath =
Paths.get("zipfs-crc-test.jar");
The test
s good to me.
> I'd recommend to run the jdk_instrument and vmTestbase_nsk_jvmti tests.
> Also, it can be safe to run:
> open/test/hotspot/jtreg/serviceability/jvmti
> open/test/hotspot/jtreg/runtime/cds/appcds
> open/test/hotspot/jtreg/runtime/BootClassAppendProp
>
> Thanks,
Hi Lance,
I’ve taken care of ModulesInCustomFileSystem then, too.
Updated webrev in place…
Cheers
Christoph
From: Lance Andersen
Sent: Dienstag, 19. November 2019 23:42
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; nio-dev
Subject: Re: RFR: 8234089: (zipfs) Remove classes
Hi Alan,
makes sense. I’ve updated the patch:
http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/
Best regards
Christoph
From: Alan Bateman
Sent: Mittwoch, 20. November 2019 09:33
To: Langer, Christoph ; Lance Andersen
Cc: nio-dev ; core-libs-dev@openjdk.java.net
Subject: Re: RFR
Holmes
> Sent: Montag, 25. November 2019 01:02
> To: Langer, Christoph ; Alan Bateman
> ; gerard ziemski
> Cc: core-libs-dev@openjdk.java.net; hotspot-runtime-
> d...@openjdk.java.net
> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava
Hi Matthias,
overall this looks good to me.
The only change to src/java.base/share/native/libjli/jli_util.c is the
copyrights, so I guess this should be omitted...
Cheers
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Baesken, Matthias
> Sent: Mittwoch, 27.
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; nio-dev
Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
JarFileSystem
Hi Christoph,
Something else that should probably be done as part of this proposed change is
to clean up tests such as NodeCostDumpUtil.java
Hi Lance,
> If you look at MultiReleaseJarTest.java, it explicitly references JAR FS in a
> comment. Same for JFSTester.java in the @Summary. These should
> definitely be updated. There are comments
> in ModulesInCustomFileSystem.java as well.
Ok, agreed for MultiReleaseJarTest and JFSTester.
; Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; security-dev
; Lindenmaier, Goetz
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
Hi Thomas and Christoph,
thanks for the reviews.
Other code in java.security.jgss also uses these #defined checks:
src
Hi Adam, Lance,
as you've already figured out, attachments sent out to the mailing list will be
removed. So it's important to generate webrevs and link to it or, for smaller
patches, inline it.
Also, the RFR subject is missing a bug ID. From the URL to the webrev I take
the bug ID is
Hi Vipin,
I'm forwarding this to net-dev where it should be reviewed.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Vipin Mv1
> Sent: Dienstag, 3. März 2020 11:54
> To: core-libs-dev@openjdk.java.net
> Subject: RFR 8129841 Update comment for
>
Hi Vipin,
it's a really tiny thing but here you go:
https://bugs.openjdk.java.net/browse/JDK-8240524
In the change you'll also need to update the copyright year.
Maybe you find other places in these tests you want to update?
Best regards
Christoph
> -Original Message-
> From:
Hi Lance,
Thanks for addressing my points. Here my answer to those things which weren't
in full agreement yet:
> I dislike a bit the fact that we introduce a new testng subfolder in
> test/jdk/nio/zipfs. Wouldn’t it be possible to consolidate in the current test
> folder?
>
> I am trying to
you though, when sponsoring, no need for new webrev.
Can I have a second review, please?
Thanks
Christoph
From: Vipin Sharma
Sent: Donnerstag, 5. März 2020 18:27
To: Langer, Christoph ; core-libs-dev@openjdk.java.net
Subject: RFR 8240524: Removed warnings from test classes
Hi All,
Please rev
Hi Lance,
The revised webrev is at
http://cr.openjdk.java.net/~lancea/8211917/webrev.02/index.html
This looks good to me now. Ship it
Cheers
Christoph
> 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/JD
As far as another reviewer is needed - looks good to me, too
/Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Thomas Stüfe
> Sent: Donnerstag, 6. Februar 2020 07:49
> To: Patrick Zhang OS
> Cc: core-libs-dev
> Subject: Re: RFR: JDK-8238380:
Hi Erik,
> Does anyone have an opinion on this?
Yep, first of all, thanks for doing this work. Sorry for not replying earlier
but FOSDEM/openjdkcw has kept us a bit busy. We're in the process of testing
your change in the reported cases where behavior is broken and shall supply you
with
//
JDK_IMAGE_DIR=$PWD/images/jdk-bundle/jdk-15.jdk/Contents/Home
(e.g. use relative paths inside the build directory)
Thanks
Christoph
> -Original Message-
> From: Magnus Ihse Bursie
> Sent: Mittwoch, 5. Februar 2020 10:54
> To: Erik Joelsson ; core-libs-dev
Hi Erik,
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.02/
>
> On 2020-02-05 02:17, Langer, Christoph wrote:
> > Hi,
> >
> > we've tested the patch and all reported failure scenarios we're aware of
> are
Hi Matthias,
you could improve the patch a bit by starting TKit:: isUbuntu() with
if (!isLinux()) {
return false;
}
And then, in PackageType, you could simply do:
private final static Set DISABLED_PACKAGERS = Optional.ofNullable(
Hi,
please review this cleanup change to remove the ExistingChannelCloser facility
in zipfs.
Some technical details about why this existed can be found in this mailing list
thread, where Sherman explained its original purpose:
for JDK-8225507 to overhaul exception handling in close()().
Cheers
Christoph
From: Lance Andersen
Sent: Donnerstag, 20. Februar 2020 20:00
To: Langer, Christoph
Cc: nio-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Subject: Re: RFR 8239556: (zipfs) remove ExistingChannelCloser facility
Hi Matthias,
I think this is good.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 20. Februar 2020 14:15
> To: core-libs-dev@openjdk.java.net
> Subject: [CAUTION] RFR [XS]: 8238947: tools/jpackage tests fail with
301 - 400 of 427 matches
Mail list logo
