Hi Arno yes I think so ; the NFS issue seems to appear on Linux quite often ,
noticed it a number of times in our nightly tests .
Best regards, Matthias
-Original Message-
From: Zeller, Arno
Sent: Montag, 10. August 2020 14:58
To: Brian Burkhalter
Cc: core-libs-dev ; Baesken
>The only reason why a 0 was observed, was because the cgroup interface
>files were missing and the old code mapped that to a 0. That's no
>longer the case and, thus, it seems it would make the code clearer if
>it wouldn't be there any more.
>
>I don't feel strongly about this, though, and can
Hi Alan, I do not have such a test case .
Is there one for the change 8230613 ?
The only call to Punycode.encode in IDN.java is below and the coding intends
to catch java.text.ParseException from Punycode.encode
and then throws an IllegalArgumentException . I see nothing regarding
Hello, recent change
https://hg.openjdk.java.net/jdk/jdk/rev/9e70cd55ae08
8230613: Better ASCII conversions
Adjusted one place in file Punycode.java to throw the declared
ParseException in
public static StringBuffer encode(StringBuffer src, boolean[] caseFlags)
throws
So the check you want to clean up does no harm, and might handle "strange"
cases - why not keep it?
Best regards, Matthias
-Original Message-
From: Severin Gehwolf
Sent: Mittwoch, 15. Juli 2020 11:47
To: core-libs-dev ; serviceability-dev
Cc: Baesken, Matthias ;
Hi , thanks for the reviews !
Best regards, Matthias
>Look good to me.
>
>Bob.
Message-
From: Bob Vandette
Sent: Freitag, 12. Juni 2020 15:02
To: Baesken, Matthias
Cc: daniil.x.ti...@oracle.com
Subject: Re: getCpuLoad() / getSystemCpuLoad() returns -1 on linux when some
offline cpus are present and cpusets.effective_cpus is not available
I looks like there are two
. Mai 2020 08:20
To: Baesken, Matthias
Cc: core-libs-dev ; Doerr, Martin
Subject: Re: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows
32bit
You have enough reviews now, but thanks for fixing this.
..Thomas
On Thu, Apr 30, 2020 at 4:15 PM Baesken, Matthias
mailto:matthias.baes
Hello, please look into this small fix for a link error we faced on Windows
32bit.
Currently we run into this link error :
jpackageapplauncher
* For target
support_native_jdk.incubator.jpackage_jpackageapplauncher_BUILD_JPACKAGE_APPLAUNCHEREXE_link:
LINK : fatal error LNK1561: entry point must
Hello, please review this small fix for the windows 32bit build .
Currently we run into this compile error on Windows :
./src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp(123):
error C2220: warning treated as error - no 'object' file generated
Hi Alan,
>Tests should never modify the "JDK under test".
That was my assumption too.
>It should be possible to
>test a JDK that is on a read-only file system for example. There are a
>small number of tests that need edit configuration files and they are
>supposed to replicate the JDK to
Hello, we noticed the following issue in
tools/jpackage/share/RuntimePackageTest.java .
See also https://bugs.openjdk.java.net/browse/JDK-8241415 .
When running a whole jdk jtreg test suite we see failures of the the
tools/jpackage/share/RuntimePackageTest.java test.
Failures are like this :
Hi Severin, looks good to me too .
Best regards, Matthias
> Hi,
>
> I still need a *R*eview for this. Any takers?
>
> Thanks,
> Severin
>
> On Fri, 2020-02-28 at 14:52 +0100, Severin Gehwolf wrote:
> > Hi Bob,
> >
> > On Thu, 2020-02-27 at 15:04 -0500, Bob Vandette wrote:
> > > The updates
Hi Severin, makes sense !
Maybe you could adjust the comment and add a bit of info about this .
I do not need to see a new webrev .
Best regards, Matthias
>
> What you are seeing here is a hybrid system[1]. My workstation is
> hybrid as well. Legacy and hybrid systems are being detected as
Hi Severin, 8239559/02 looks generally good .
However I wonder about this :
I have a SLES15 aarch64 system with these settings :
more /proc/cgroups
#subsys_namehierarchy num_cgroups enabled
cpuset 6 1 1
cpu 8 1 1
cpuacct 8 1 1
blkio
Hi, regarding RHEL 6 this webpage says it is not supported, only on RHEL 7
+ .
https://access.redhat.com/solutions/1378023
Regarding SUSE Linux (SLES) we run docker on SLES12 and higher ( I don't
think docker is supported on SLES11 but not 100% sure ).
Best regards, Matthias
>
Hi Severin, I'll put your patch into our internal build/test queue .
Additionally I can confirm that the error I reported last week when running
jtreg tests :
>
> > ./jtregojdk.sh tools/jpackage
>
>
> java.lang.InternalError: java.lang.reflect.InvocationTargetException
>
Hello, please review this small change adjusting the minimal rpmbuild version
of tools/jpackage tests .
Currently the tools/jpackage tests, for example
jdk/test/jdk/tools/jpackage/linux/AppCategoryTest.java fail on older distros
with rpmbuild tools < 4.10 .
This can be seen on Suse Linux
Buchholz
mailto:marti...@google.com>> wrote:
Thanks for doing this. Looks good to me.
I would probably create a tiny helper function to encapsulate the error
throw.
On Tue, Feb 18, 2020 at 7:03 AM Baesken, Matthias
mailto:matthias.baes...@sap.com>>
wrote:
> Hello, please rev
h wrote:
> > Hi Matthias,
> >
> > Looks good to me now.
> >
> > Cheers
> > Christoph
> >
> >> -Original Message-
> >> From: Baesken, Matthias
> >> Sent: Dienstag, 18. Februar 2020 16:55
> >> To: Langer, Christoph
regards
> Christoph
>
> > -Original Message-
> > From: core-libs-dev On Behalf
> > Of Baesken, Matthias
> > Sent: Dienstag, 18. Februar 2020 09:14
> > To: core-libs-dev@openjdk.java.net; Alexey Semenyuk
> >
> > Subject: [CAUTION] RE:
Hello, please review this change to Deflater.c .
When running the jtreg test java/util/zip/DeInflate.java , we currently have
errors on SLES 15.1 s390x when using the system zlib (1.2.11), while the
bundled zlib (of OpenJDK) seems to be okay.
What's worse, the error messages are not very
Ping ... are you fine with the latest version ?
Best Regards, Matthias
>
> Hi Alexey , I like your idea to do the handling in
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java .
>
> New webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.1/
>
>
>
> Best
Btw one small comment, I wonder why you have own functions for finding out
the platform (e.g. in TKit) , maybe jdk.test.lib.Platform should be reused
like in a lot of other jtreg tests ?
Example :
28import jdk.test.lib.Platform;
43public class DynLibsTest {
44
45public void
Hi Alexey , I like your idea to do the handling in
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java .
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8238953.1/
Best regards, Matthias
> Date: Thu, 13 Feb 2020 08:06:44 -0800
> From: Alexey Semenyuk
> To:
Hello, please review this small test related change .
Currently (most of the) tools/jpackage tests do not work on Ubuntu Linux .
Reason is that the rpm parts of the jpackage tests do not pass on this distro
.
The rpm tests can be disabled by this property :
> >
> > Do you expect those
(e.g. to 4.10+ ) ?
Best Regards, Matthias
>
> Hi Matthias,
>
> I confirm jpackage works with rpmbuild v4.11.3.
>
> - Alexey
>
> On 2/11/2020 4:15 AM, Baesken, Matthias wrote:
> > Hi Alexey, with rpmbuild 4.4 on SLES11 we get the additional output
&g
tools/jpackage tests fail .
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 11. Februar 2020 13:15
> To: core-libs-dev@openjdk.java.net; 'alexey.semen...@oracle.com'
>
> Subject: RE: tools/jpackage/linux - tests (from
> Message-ID: <0e495cc2-000f-ee46-f0ac-b2f08b084...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Matthias,
>
> On 2/7/2020 12:17 AM, Baesken, Matthias wrote:
> > Hello, I started to look a bit into the tools/jpackage/linux - tests
Hello, I started to look a bit into the tools/jpackage/linux - tests (from
8212780).
So far I noticed the following issues , maybe someone could comment on them ?
rpm/rpmbuild version requirements
--
We still have some older Suse Linux
Hi Erik, I did not notice slowdowns in our night makes .
Looking at a specific test machine I use (x86_64, build JOBS hardwired set
to 12 ) I get around 6 minutes build time with and without the feature .
( but you have to take into account that the link-time section-gc on
;
> On 2020-01-14 06:07, Baesken, Matthias wrote:
> > Hello, the following change enables the link-time section-gc for linux .
> >
> > gcc and ld support enabling "garbage collection" of unused input sections.
> > This can be used to eliminate unused coding
Hello David,
Here is a change that adjusts the naming of
Java_jdk_internal_reflect_Reflection_getCallerClass -
With this change, I checked the output of LD_DEBUG=libs java Test ,
and the error I observed before is gone .
Bug/webrev :
Hi David, thanks for clarification .
Guess we can just remove the __ now and avoid one lookup.
I'll open a bug for this .
Best regards, Matthias
> On 18/12/2019 10:43 pm, David Holmes wrote:
> > On 18/12/2019 7:43 pm, Baesken, Matthias wrote:
> >> Hello, I rec
Hello, I recently worked a bit with the "verbose debugging information"
output about operations of the dynamic linker (to sort out some lib loading
issues) .
See
https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html
http://man7.org/linux/man-pages/man8/ld.so.8.html
Thanks for the reviews .
jdk-submit is fine so there should be no issues .
Best regards, Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Donnerstag, 28. November 2019 13:33
> To: Baesken, Matthias ; Langer, Christoph
> ; core-libs-dev@openjdk.java.net
>
Thanks for the review . I'll adjust the COPYRIGHT .
Will push this as XS in case of no objections.
Best regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 28. November 2019 11:35
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.jav
Hello, I missed the reference from windows only code to JLI_MemRealloc , new
webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.1/
Best regards, Matthias
Hello, please review this small change .
It removed unneeded functions from libjli (shown by link-time-gc) .
libjli
Hello, please review this small change .
It removed unneeded functions from libjli (shown by link-time-gc) .
libjli contains a few functions that are shown as unused when applying
link-time-gc .
Those functions fall into 2 categories :
- totally unused/uncalled functions (can be deleted )
Hi Martin ,
> Hi Matthias and Erik,
>
> I also think this is an interesting option.
>
> I like the idea to generate smaller libraries. In addition to that, I could
> also
> imagine building with -Os (size optimized) by default and only select -O3 for
> performance critical files (e.g. C2's
ssume
> that makes the build quite chatty.
>
> /Erik
>
> On 2019-11-21 00:54, Baesken, Matthias wrote:
> > Hello,
> >
> > gcc and ld can be instructed to work together to "garbage collect" unused
> input sections.
> > This feature eliminates unused
Hi Christoph / Roger , thanks for the reviews !
Best regards , Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 21. November 2019 23:13
> To: Roger Riggs ; core-libs-
> d...@openjdk.java.net; Baesken, Matthias
> Subject: RE: RFR [XS]
Hello,
gcc and ld can be instructed to work together to "garbage collect" unused input
sections.
This feature eliminates unused code from native libraries. As a prerequisite to
take full advantage of the feature,
the source files need to be compiled with "-ffunction-sections -fdata-sections".
Hello, please review this small change .
JLI_StrTok is only used in one function, so the define can be replaced,
probably we should use the "safer" strtok_r (the MT safety might not be a big
deal in the launcher however).
Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8234339
Thanks for the review !
Alan, may I add you as reviewer too ?
Best regards, Matthias
> -Original Message-
> From: David Holmes
> Sent: Freitag, 20. September 2019 11:41
> To: Baesken, Matthias ; 'hotspot-
> d...@openjdk.java.net' ; core-libs-
> d...@openjdk.java.net
Hi David , I adjusted the test (
test/jdk/tools/launcher/TestSpecialArgs.java ) and removed the comments in
os_bsd.cpp (suggested by you) .
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/
Best regards, Matthias
> Hi Matthias,
>
> On 20/09/2019 5:03 pm
ng this up.
>
> On 19/09/2019 4:57 pm, Baesken, Matthias wrote:
> > Hello, as discussed below , I want to cleanup some older references to
> sun.java.launcher.pid.
> > Please review the following change.
> >
> > After removal of some code belonging ol
> 8231171: remove reamining sun.java.launcher.pid references
>
> to do the additional cleanup .
>
> Best regards, Matthias
>
>
> > -Original Message-
> > From: David Holmes
> > Sent: Mittwoch, 18. September 2019 03:16
> > To: Baesken, M
Thanks Martin .
May I get a second review ?
Best regards, Matthias
From: Doerr, Martin
Sent: Mittwoch, 24. Juli 2019 12:14
To: Baesken, Matthias ;
'hotspot-...@openjdk.java.net' ;
core-libs-dev@openjdk.java.net; net-...@openjdk.java.net
Cc: 'ppc-aix-port-...@openjdk.java.net'
Subject: RE
Hello, seems we need another "CFRelease(cflocale)"in an early return
case (see the default: ...) , new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.1/
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Mittwoc
Juli 2019 18:39
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR: 8228501: java_props_macosx.c - provide missing CFRelease
> for CFLocaleCopyCurrent was: RE: java_props_macosx.c :
> CFLocaleCopyCurrent() needs CFRelease ?
>
> Thanks, Matthias. C
Hello please review this patch .
It fixes a couple of xlc16/xlclang warnings , especially comparison of
distinct pointer types and string literal conversion warnings .
When building with xlc16/xlclang, we still have a couple of warnings that have
to be fixed :
warning: ISO C++11 does not
, the docu
https://developer.apple.com/documentation/corefoundation/1542359-cfdatacreate?language=objc
says the ownership of the returned object follows the Create rule .
Do I miss something ?
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Die
tching them. Yes, I believe they should be released
> > appropriately.
> >
> > Naoto
> >
> > On 7/22/19 4:01 AM, Baesken, Matthias wrote:
> > > Hello , maybe someone with more OSX dev knowledge could comment
> > on this .
> > > If I underst
ppropriately.
>
> Naoto
>
> On 7/22/19 4:01 AM, Baesken, Matthias wrote:
> > Hello , maybe someone with more OSX dev knowledge could comment
> on this .
> > If I understand it correctly , the OSX Core Foundation Ownership Policy
> > :
> >
> >
&
Hello , maybe someone with more OSX dev knowledge could comment on this .
If I understand it correctly , the OSX Core Foundation Ownership Policy :
Thanks for the additional review !
Best regards, Matthias
From: Lindenmaier, Goetz
Sent: Freitag, 19. Juli 2019 09:33
To: Baesken, Matthias ; Schmidt, Lutz
; Doerr, Martin
Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX
Hi Matthias,
This looks good, thanks for doing
are we then from enabling "warnings as errors" on AIX? :P
Best regards
Christoph
From: awt-dev
mailto:awt-dev-boun...@openjdk.java.net>> On
Behalf Of Baesken, Matthias
Sent: Dienstag, 16. Juli 2019 17:04
To: Java Core Libs
mailto:core-libs-dev@openjdk.java.net>>
Hello, please review the following AIX related change .
It fixes a number of missing inclusions leading to
implicit-function-declaration warnings when compiling with the recent xlc16
/xlclang .
At various places in the native C coding in jdk, we miss header inclusions on
AIX.
This leads
it might be
better to keep what we have .
Best regards, Matthias
From: Langer, Christoph
Sent: Dienstag, 18. Juni 2019 10:59
To: jdk-updates-...@openjdk.java.net
Cc: Java Core Libs ; Baesken, Matthias
Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base
Hi
Hello, is the latest revision fine with you ?
May I add you as a reviewer ?
Thanks, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 2. April 2019 14:55
> To: 'Alan Bateman'
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR: 8218547:
ateman
> Sent: Samstag, 30. März 2019 10:04
> To: Baesken, Matthias
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8218547: Simplify JLI_Open on Windows in native code
> (libjli) - was : RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
Thanks. Alan, are you fine with the current webrev, if yes may I add you as
reviewer ?
Best regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 28. März 2019 12:41
> To: Baesken, Matthias
> Cc: core-libs-dev@openjdk.java.ne
jar in a short path
There exist already quite a few tests using "-jar some.jar" with "normal"
/ shorter paths in test/jdk/tools/launcher/Arrrghs.java.
Regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 28. März 2019 11:
Hello could you please look into it ?
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Montag, 25. März 2019 18:05
> To: Langer, Christoph
> Cc: 'core-libs-dev@openjdk.java.net' ;
> 'Alan Bateman'
> Subject: RE: RFR: 8218547: Simplif
(on Windows) JLI_Open on a jar
file with a "long" path (> 260 chars).
[ JLI_Open is currently called from parse_manifest.c with jarfile as
parameter ]
Best regards, Matthias
> -Original Message-----
> From: Baesken, Matthias
> Sent: Montag
nntag, 24. März 2019 07:14
> To: Baesken, Matthias
> Cc: core-libs-dev@openjdk.java.net; Alan Bateman
>
> Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code
> (libjli) - was : RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
&g
sily reuse the HS coding, so the have
> to
> take it over to jli .
>
> Best regards, Matthias
>
>
>
> > -Original Message-
> > From: Baesken, Matthias
> > Sent: Mittwoch, 6. Februar 2019 09:56
> > To: Langer, Christoph
> > Cc: Chris Hega
it the same way in JLI_Open . Is that fine with you?
Unfortunately I think we cannot easily reuse the HS coding, so the have to
take it over to jli .
Best regards, Matthias
> -Original Message-----
> From: Baesken, Matthias
> Sent: Mittwoch, 6. Februar 2019 09:56
> To: Langer, Ch
Looks good to me (not a Reviewer however).
Best regards, Matthias
>
> Message: 2
> Date: Mon, 18 Feb 2019 15:35:20 +
> From: "Langer, Christoph"
> To: "Zeller, Arno" , Nishit Jain
> , Naoto Sato ,
> Roger
> Riggs
> Cc: core-libs-dev
> Subject: RE: RFR(XS):JDK-8219228:
>
019 10:08
> To: Baesken, Matthias
> Cc: core-libs-dev@openjdk.java.net; Alan Bateman
>
> Subject: RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> Hi Matthias,
>
> thanks for opening the bug. I refined its description a lit
; From: Langer, Christoph
> Sent: Dienstag, 29. Januar 2019 09:59
> To: Baesken, Matthias
> Cc: Chris Hegarty ; core-libs-
> d...@openjdk.java.net
> Subject: RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> Hi Matthias,
>
> >
v@openjdk.java.net; Baesken,
> Matthias
> Subject: RE: JDK-8217880 AIX build issue about JDK-8214533
>
> Hello Goetz.
>
> Thank you for build testing.
>
> Yes, I need a sponsor.
> If possible, could you handle it ?
>
> Thanks,
> Ichiroh Takiguchi
>
shows/tests the issue?
>
Maybe I could put something into the existing
jdk/test/jdk/tools/launcher
tests.
Best regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 28. Januar 2019 14:23
> To: Baesken, Matthias ; Alan Bateman
> ;
rds, Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Sonntag, 27. Januar 2019 16:57
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Cc: Langer, Christoph
> Subject: Re: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windo
Hello, seems 8214533 got pushed recently into jdk/jdk. Now we see
build errors on AIX , are they related to this change ?
/nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
error: Decoder is not public in EUC_JP; cannot be
4
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> On 23/01/2019 08:29, Baesken, Matthias wrote:
> > Hello Alan, here is a second webrev :
> >
> > htt
Mittwoch, 16. Januar 2019 16:43
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> On 16/01/2019 14:43, Baesken, Matthias wrote:
> > Hi Alan , do you
> -Original Message-
> From: Alan Bateman
> Sent: Mittwoch, 16. Januar 2019 10:37
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> On 16/01/2019 09:07, Baes
man
> Sent: Mittwoch, 16. Januar 2019 09:51
> To: Baesken, Matthias ; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
>
> On 16/01/2019 08:42, Baesken, Matthias wrote:
> > Hello, please
Hello, please review this small adjustment to parse_manifest.c .
It adds support for extended - length paths (on Window) .
(see
https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation
For extended length paths )
Additionally , some small
gt; -Original Message-----
> From: Sean Mullan
> Sent: Donnerstag, 8. November 2018 20:36
> To: Baesken, Matthias ; Langer, Christoph
> ; Alan Bateman ;
> security-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErr
Hi Adam , the webrev looks OK to me (not a Reviewer however). I think it
will not break anything on lower xlc versions (like xlc 12.1 that we are
using).
Are you able to do a full successful build with this change (when using xlc
13.1) ?
Do you have a chance to test with the
Thanks for the reviews !
> -Original Message-
> From: Alan Bateman
> Sent: Donnerstag, 15. November 2018 11:08
> To: Baesken, Matthias ; Langer, Christoph
>
> Subject: Re: FW: RFR : 8211106: [windows] Update OS detection code to
> recognize Windows Server 2019
>
2019, ... "
Alan / Bob - can I you as reviewers ?
Best regards , Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Samstag, 20. Oktober 2018 10:06
> To: Baesken, Matthias
> Cc: hotspot-dev Source Developers ; core-
> libs-...@openjdk.java.net; Moldenhauer,
the other places too ).
Thanks, Matthias
> -Original Message-
> From: Sean Mullan
> Sent: Freitag, 12. Oktober 2018 17:19
> To: Langer, Christoph ; Baesken, Matthias
> ; Alan Bateman ;
> security-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR
Hi Volker, looks good (not a Reviewer however) !
Maybe you should also adjust the Copyright year info in the files you touched .
Best regards, Matthias
-Original Message-
Hi,
can I please have a review for the following tiny change which fixes
the license header on a few
ore backporting it to jdk11u .
Best regards, Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Samstag, 20. Oktober 2018 10:06
> To: Baesken, Matthias
> Cc: hotspot-dev Source Developers ; core-
> libs-...@openjdk.java.net; Moldenhauer, Niclas
>
>
s/8211106.2/
Best regards, Matthias
From: Bob Vandette
Sent: Donnerstag, 18. Oktober 2018 16:36
To: Baesken, Matthias
Cc: hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; Langer,
Christoph
Subject: Re: RFR : 8211106: [windows] Update OS detection code to recognize
Windows
for the list of build numbers )
Thanks, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Freitag, 12. Oktober 2018 08:57
> To: 'Bob Vandette'
> Cc: 'hotspot-...@openjdk.java.net' ;
> 'core-libs-dev@openjdk.java.net' ;
> Langer, Christoph
> Su
ards ,
Matthias
From: Alan Bateman
Sent: Freitag, 12. Oktober 2018 11:18
To: Baesken, Matthias ;
security-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance
some IOExceptions with path causing the issue
Exceptions=hostInfo,jar,ioExceptionsWithPath
Thanks, Matthias
From: Baesken, Matthias
Sent: Dienstag, 9. Oktober 2018 14:12
To: security-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Cc: Alan Bateman (alan.bate...@oracle.com)
Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath
I got the info that the GA of Windows Server 2019 has build number 17763
.
Should I update the webrev to check this build number (would mean we do not
detect the preview as Windows Server 2019) , or keep it the way it is ?
Current webrev :
n .
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 2. Oktober 2018 17:03
> To: Bob Vandette
> Cc: hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net;
> Moldenhauer, Niclas
> Subject: RE: RFR : 8211106: [windows] Update OS detection
messages to the
java.security file .
Best regards, Matthias
From: Baesken, Matthias
Sent: Dienstag, 9. Oktober 2018 13:40
To: core-libs-dev@openjdk.java.net
Cc: Langer, Christoph ; Lindenmaier, Goetz
Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some
IOExceptions
Hello, please review the following change .
It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and
current working directory information.
For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added.
bug and webrev :
build number 17677 ( Windows Server 2019
preview , seems older than what you are seeing)
and 17723 .
Best regards, Matthias
> -Original Message-
> From: Bob Vandette
> Sent: Dienstag, 2. Oktober 2018 16:09
> To: Baesken, Matthias
> Cc: hotspot-...@openjdk.java.n
Hello, please review change 8211106 .
It updates the Windows OS detection code to recognize Windows Server 2019 .
For this we have to look at the build number (dwBuildNumber of
OSVERSIONINFOEX),
https://docs.microsoft.com/en-us/windows/desktop/api/Winnt/ns-winnt-_osversioninfoexa
Hi, thanks for your comments, I posted a second webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.1/webrev/
Best regards, Matthias
> -Original Message-
> From: naoto.s...@oracle.com
> Sent: Mittwoch, 26. September 2018 18:49
> To: Baesken, Matthias ; co
Hello, could you please review this small change (windows only) ?
Currently, the function "getJavaIDFromLangID"(located in windows
java_props_md.c)
only does proper deallocations after a successful call to the function
SetupI18nProps. See
if (SetupI18nProps(MAKELCID(langID,
1 - 100 of 179 matches
Mail list logo
