Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Updated JNLPConverter to support latest CLI changes and bug fixes.
- Added getMessage() to exceptions, otherwise null was printed.
- Restored
Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/
> On Mar 22, 2019, at 4:32 PM, Brian Burkhalter
> wrote:
>
> Patch updated for the sake of formality.
> On Mar 22, 2019, at 3:31 PM, Martin Buchholz wrote:
>
> No need to check for short strings in tooLongMsg.
Yeah that was stupid on my part.
> Getting the actual length calculation 100% is not very important, but THIS IS
> JAVA so here's an attempt that looks correct even for maximal length
No need to check for short strings in tooLongMsg.
Getting the actual length calculation 100% is not very important, but THIS
IS JAVA so here's an attempt that looks correct even for maximal length
input (untested - you could check that the exception detail gets the 3x
expansion right):
> On Mar 18, 2019, at 1:03 PM, Martin Buchholz wrote:
>
> Below is another attempt at micro-optimization (might be too tricky!), BUT:
I like this version better and have updated the CR accordingly:
http://cr.openjdk.java.net/~bpb/8219196/webrev.02/
I refrained from doing a global replace of
Hi Christoph!
UnixFileSystem_md.c:
Should the second error message be "Could not *close* file"?
UnixFileSystem.java:
Line spacing looks inconsistent. Please leave an empty line before
@Override at lines 267, 269, 271, 273, etc.
With kind regards,
Ivan
On 3/22/19 1:37 AM, Langer, Christoph
On 22/03/2019 14:37, Baesken, Matthias wrote:
Hello, here is the new webrev .
I took over and adjusted coding from os::open + create_unc_path
functions in os_windows.cpp in hotspot :
http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/
This looks quite good. For
Instead of removing the file path, would it be possible to add it to all
implementations guarded by jdk.includeInExceptions=filename?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Alan
Bateman
Gesendet: Freitag, März 22, 2019
Is there ever a situation where the memory.limit_in_bytes could be unlimited
but the
hierarchical_memory_limit is not?
Could you maybe combine subsystem_file_contents with
subsystem_file_line_contents
by adding an additional argument?
BTW: I found another problem with the mountinfo/cgroup
Hi Deepak,
Please modify the copyright year accordingly. Otherwise it looks good to me.
Naoto
On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
Hi All,
Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:-
JBS report:
On 3/22/2019 9:56 AM, Mandy Chung wrote:
Hi Adam,
On 3/22/19 8:40 AM, Joe Darcy wrote:
Please update distinct versions of a webrev (e.g. distinguished with
.1, .2 directory names) rather than overwriting a single one. This
make it easier for those coming to the review thread later to see
Hi Adam,
On 3/22/2019 9:14 AM, Adam Farley8 wrote:
Hi Joe,
I was aware that webrevs should be versioned, though I didn't see the
value for small change sets like this one.
You seem to think there is a value. Can you explain it to me?
The time of reviewers is valuable and should not be
Hi Adam,
On 3/22/19 8:40 AM, Joe Darcy wrote:
Please update distinct versions of a webrev (e.g. distinguished with
.1, .2 directory names) rather than overwriting a single one. This
make it easier for those coming to the review thread later to see the
evolution of the changes over time.
Hi Joe,
I was aware that webrevs should be versioned, though I didn't see the
value for small change sets like this one.
You seem to think there is a value. Can you explain it to me?
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 22/03/2019 15:40:15:
> From: Joe Darcy
> To:
For completeness reasons, here is the corrected version of the complete patch
I'm proposing.
= PATCH =
diff -r 96c45aa61056 src/java.base/share/classes/jdk/internal/module/Checks.java
--- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar
22
Hi All,
Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:-
JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
https://bugs.openjdk.java.net/browse/JDK-8210633
Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
Master
A quick comment below...
On 3/22/2019 4:33 AM, Adam Farley8 wrote:
Hi Mandy,
Answers below. :)
Mandy Chung wrote on 22/03/2019 00:35:00:
From: Mandy Chung
To: Adam Farley8
Cc: core-libs-dev
Date: 22/03/2019 00:35
Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
to
I'm sorry. Another correction.
>
> I wonder if this should do the trick.
>
> What do you think, Alan?
>
> PATCH
> diff -r 96c45aa61056
> src/java.base/share/classes/jdk/internal/module/Checks.java
> --- a/src/java.base/share/classes/jdk/internal/module/Checks.java
Hello, here is the new webrev .
I took over and adjusted coding from os::open + create_unc_path
functions in os_windows.cpp in hotspot :
http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/
Best regards, Matthias
> -Original Message-
> From: Baesken,
Hi Gary,
Holding a static reference to the implementation solves the problem.
But I noticed that the object that is bound in the registry is the
RemoteHostImpl
and it should be the RemoteHost stub.
Line 145: should be:
bind(name.toString(), stub);
That is likely to solve the
I wonder if this should do the trick.
What do you think, Alan?
PATCH
diff -r 96c45aa61056 src/java.base/share/classes/jdk/internal/module/Checks.java
--- a/src/java.base/share/classes/jdk/internal/module/Checks.java Fri Mar
22 13:42:45 2019 +0530
+++
On 22/03/2019 08:37, Langer, Christoph wrote:
Hi,
when contemplating over JDK-8211752, I found a few minor cleanups for the
implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221262
Webrev:
Thanks Alan for your fast response.
I'm "glad" the root issue remains even though the initial patch is wrong.
I guess "uses" could be affected here as well, not just "mainClass" and
"provides".
How do we move on from now? Can I help in anyway?
Christoph
> On 22/03/2019 11:30, Christoph Dreis
On 22/03/2019 11:30, Christoph Dreis wrote:
Hi,
I recently stumbled upon jdk.internal.module.Checks and was wondering if you
could help me understanding if I face a bug. The mentioned class has a
private static field containing a list of reserved keywords. When checking
the list for
On a second thought, the patched posted is not safe as it is used for
package name checks as well.
And while var is not a type-identifier, it is still an identifier. So it
should be possible to name your package "var" if I'm not mistaken.
The question remains. Should we change anything here in
Hi Mandy,
Answers below. :)
Mandy Chung wrote on 22/03/2019 00:35:00:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 22/03/2019 00:35
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> 217
Hi,
I recently stumbled upon jdk.internal.module.Checks and was wondering if you
could help me understanding if I face a bug. The mentioned class has a
private static field containing a list of reserved keywords. When checking
the list for completeness, I noticed that "var" seems to be missing
Hi,
Please review this change which improves container detection support
tin the JVM. While docker container detection works quite well the
results for systemd slices with memory limits are mixed and depend on
the Linux kernel version in use. With newer kernel versions becoming
more widely used
Hi,
when contemplating over JDK-8211752, I found a few minor cleanups for the
implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221262
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/
Thanks
Christoph
Here's a proposed fix for the intermittent jstatd test failure.
By moving the exported object from a local method variable to a
static class variable a strong reference is held so the object
will not be garbage collected prematurely.
Webrev:
30 matches
Mail list logo
