Hi Bernd,
I just noticed your report regarding the regression after JDK-8273655. I'm
directing this communication to jdk-updates-dev now as it seems more
appropriate.
I assume with release notes you're referring to the Oracle 17.0.3 release
notes? This change, if you look closely at the
Hi Martin,
this makes sense. Thanks for doing the backport.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf Of
> Doerr, Martin
> Sent: Mittwoch, 16. Dezember 2020 14:39
> To: core-libs-dev ; jdk-updates-
> d...@openjdk.java.net
> Subject: [CAUTION] [11u]
Hi Volker,
since it's not yet pushed, I also went over the change and I like it. +1
One little style nit caught my eye, which you could correct before pushing: The
style of the if/else blocks in test/jdk/java/util/zip/DeflateIn_InflateOut.java
in lines 48/49 and 59/60 does not match the
Hi Alan,
> >> Looks okay to me too, except @SuppressWarnings("unused") looks
> strange,
> >> is that an Eclipse compiler warning name?
> > Yes, it comes from Eclipse, probably only used by its compiler. The private
> field EXIT_SYSERR doesn't seem to be used. Alternatively, I could comment it
>
Hi Alan,
> Looks okay to me too, except @SuppressWarnings("unused") looks strange,
> is that an Eclipse compiler warning name?
Yes, it comes from Eclipse, probably only used by its compiler. The private
field EXIT_SYSERR doesn't seem to be used. Alternatively, I could comment it
out? Or remove
nntag, 19. April 2020 18:32
> To: Langer, Christoph ; jigsaw-
> d...@openjdk.java.net
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: RFR (T): 8243117: Cleanups in Java code of module jdk.jlink
>
> Looks good to me, Christoph,
>
> JmodTask.java: Not sure what the co
Hi,
please help review this cleanup patch for the Java code in module jdk.jlink.
It's mostly automatic IDE cleanups of unused imports plus a few removals for
unused private methods, fields and annotations. I've also added some @Override
annotations where such were missing.
Bug:
; Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin
>
>
>
> On 2020-04-03 15:36, Langer, Christoph wrote:
> > Eventually I came up with this result and then I also asked myself the
> question whether the new complexity was worth the benefit. I answered
> myself wit
Thanks, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Donnerstag, 2. April 2020 23:05
> To: Langer, Christoph ; jigsaw-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin
>
>
Hi Mark,
> -Original Message-
> From: mark.reinh...@oracle.com
> Sent: Donnerstag, 2. April 2020 23:13
> To: Langer, Christoph
> Cc: jigsaw-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin
>
>
tory)
OK, I created an edition which doesn't change the formatting so that the added
code becomes more obvious:
http://cr.openjdk.java.net/~clanger/webrevs/8242039.1/
Does it look better?
Cheers
Christoph
>
> /Claes
>
>
> On 2020-04-02 17:01, Langer, Christoph wrote:
> >
Hi,
please review a small improvement for the jlink VersionPropsPlugin. The Plugin
modifies the bytecode of java/lang/VersionProps.class to replace the
initializion of certain vendor specific system properties with custom values.
This modification currently adds two bytecodes per constant, a
Thanks for the review, Alan.
I'll push it then.
Best regards
Christoph
> -Original Message-
> From: Alan Bateman
> Sent: Mittwoch, 1. April 2020 16:46
> To: Langer, Christoph ; Mandy Chung
> ; core-libs-dev@openjdk.java.net
> Cc: build-dev
> Subject: Re: RF
://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ?
Thanks
Christoph
From: Mandy Chung
Sent: Dienstag, 31. März 2020 19:34
To: Langer, Christoph ; core-libs-dev@openjdk.java.net
Cc: build-dev
Subject: Re: RFR (S): 8241947: Minor comment fixes for system property handling
On 3/31/20 7:56 AM, Langer, Christoph
Hi Magnus,
> From a build perspective this looks fine.
Thanks for the review.
> But it seems you are changing the interface for java.lang.System. Don't
> you need a CSR for that? Or is your claim that the interface was indeed
> changed by JDK-8197927, and it is a bug that the documentation was
Hi,
please review a small fix that updates two comments.
The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks
about handling of a property "vm.vendor" in VersionProps.java.template.
However, there is no property "vm.vendor", it must rather be "java.vendor". I
stumbled
> > By spec part you mean the "@throws SecurityException" sections? Do you
> think those should not have been part of the 11u/13u change? Should these
> be even rolled back?
> >
> The spec changes to NetPermission and the protected Socket constructor
> should not be in the update releases. If a
> >> One other thing on this. It looks like the spec changes that were part
> >> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> >> mistake. Is that part of the issue that you are trying to fix?
> > I can't find/access JDK-8218573 and I also struggle to find a changelist
> >
Hi Alan,
> On 23/03/2020 18:07, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport JDK-8223326 from jdk/jdk.
> >
> One other thing on this. It looks like the spec changes that were part
> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> mistake. Is that part of the issue
Hi Alan,
> -Original Message-
> From: jdk-updates-dev On
> Behalf Of Alan Bateman
> Sent: Montag, 23. März 2020 20:19
> To: Doerr, Martin ; core-libs-
> d...@openjdk.java.net; jdk-updates-...@openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
>
Hi Paul,
as Martin said, the original bug could not be opened by Oracle. I, however
changed the bug created by Martin to a Backport item. Doing it that way would
allow a "standard" backport of such type of issues while the original item that
was pushed to head can remain invisible. We
Hi Adam,
thanks for opening up the bug and reposting. Looks good to me
Cheers
Christoph
From: Adam Sotona
Sent: Mittwoch, 11. März 2020 11:32
To: Langer, Christoph
Cc: Lance Andersen ; Sean Mullan
; core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8230117 removing dead code from jar tool
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
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
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 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
>
> 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
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 Lance,
thanks, I’ve pushed it now: http://hg.openjdk.java.net/jdk/jdk/rev/c22b369d40b2
I’ll be out next week, so I’ll probably get to JDK-8225507 the week after.
Cheers
Christoph
From: Lance Andersen
Sent: Freitag, 21. Februar 2020 12:34
To: Langer, Christoph
Cc: nio-...@openjdk.java.net
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
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,
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:
Hi Matthias,
Looks good to me now.
Cheers
Christoph
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 18. Februar 2020 16:55
> To: Langer, Christoph ; core-libs-
> d...@openjdk.java.net; Alexey Semenyuk
> Subject: RE: 8238953: tools/jpackage tests do
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(
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,
> 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
//
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,
> 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
Hi,
Looks good to me
Cheers
Christoph
From: Lance Andersen
Sent: Montag, 13. Januar 2020 21:26
To: Alan Bateman
Cc: Jaikiran Pai ; Langer, Christoph
; nio-...@openjdk.java.net;
core-libs-dev@openjdk.java.net
Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider
Hi,
I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is
cheaper and accesses to the inodes map on a closed filesystem object should not
happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the
change looks fine.
Cheers
Christoph
> -Original
Hi Naoto,
The change looks good. Thanks for fixing this. We're seeing it regularly in our
test infrastructure where we're running Mac systems with German locale.
Best regards
Christoph
> -Original Message-
> From: i18n-dev On Behalf Of
> naoto.s...@oracle.com
> Sent: Montag, 6. Januar
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,
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
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 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
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...@
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 ;
>
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
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
; 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
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 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
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,
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 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.
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
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 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
+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 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
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
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
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,
> 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.
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
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
> 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.
&
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
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
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,
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
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 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
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
+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>;
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 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
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
> 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
. 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
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
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,
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,
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
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:
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 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
/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 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
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
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
1 - 100 of 427 matches
Mail list logo
