Hi Roger,
Thank you for the review. Please find my comments below.
On 2/21/20 11:42 AM, Roger Riggs wrote:
In the implementation ValueRange.of: 148-150; I would omit the check
here since
it invokes the 4 arg form and does the same check.
The difference in exception message is not worth the
Was any bug ever filed for this? I looked in JBS and I couldn't find anything
that resembled the issue here.
Roman, since you don't have an account on JBS (bugs.openjdk.java.net), I'd
suggest you file a bug via bugs.java.com. Bugs filed there do eventually get
into JBS. (I believe it's
Hi Andy,
Looks good.
Thanks,
Alexander
On 2/21/2020 9:10 AM, Andy Herrick wrote:
After internal discussion of default values for mac-package-identifier
I have removed the fix for [3] from this main fix to issue [2].
please review the revised webrev at [1]
/Andy
On 2/18/2020 2:46 PM, Andy
On 2/14/20 2:34 PM, fo...@univ-mlv.fr wrote:
The thing is that inside the iterator, you already have the right information,
so you don't have to pray to have the right info.
No, the iterator only can guess at the reason that get() threw the exception.
I just disagree on the conclusion,
Hi Naoto,
The CSR looks ok.
In the implementation ValueRange.of: 148-150; I would omit the check
here since
it invokes the 4 arg form and does the same check.
The difference in exception message is not worth the extra code.
Though it would help if it said that the 3 arg form is the same as
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;
> On Feb 21, 2020, at 11:12 AM, Kevin Rushforth
> wrote:
>
> I doubt this has anything to do with jpackage being in incubator or not.
> Fundamentally, just copying binary launchers into another JDK image like you
> are doing is only going to work by accident, if it works at all. If you
After internal discussion of default values for mac-package-identifier I
have removed the fix for [3] from this main fix to issue [2].
please review the revised webrev at [1]
/Andy
On 2/18/2020 2:46 PM, Andy Herrick wrote:
Please review the jpackage fix at [1] for the related issues [2],
I doubt this has anything to do with jpackage being in incubator or not.
Fundamentally, just copying binary launchers into another JDK image like
you are doing is only going to work by accident, if it works at all. If
you need jpackage (or javac or jar or ...) to be in a JDK image, then
you
> On Feb 21, 2020, at 9:39 AM, Michael Hall wrote:
>
>> You can't copy launchers in this way as it requires the module to be in the
>> run-time image.
>
> If I add modules it into the build runtime I think I’m ok but haven’t tried
> it yet.
jpackage seems to need more than just the module
Two subtle comments to the new webrev:
- I'd add "private" to those static finals.
- "cs.name()" in the exception messages can be replaced with "csName".
Otherwise it looks good. If you agree with the above, no further review
is needed. Also, if you need a sponsor, I can sponsor your
> On Feb 21, 2020, at 9:41 AM, Michael Hall wrote:
>
>
>
>> On Feb 21, 2020, at 9:39 AM, Philip Race wrote:
>>
>> Hi,
>>
>> I don't understand what you are doing here.
>> It is like you are copying around an application
>> which has dependent libraries but not copying those libraries.
>>
> On Feb 21, 2020, at 9:39 AM, Philip Race wrote:
>
> Hi,
>
> I don't understand what you are doing here.
> It is like you are copying around an application
> which has dependent libraries but not copying those libraries.
>
> Copying bits out of the JDK to some other location isn't
> On Feb 21, 2020, at 9:36 AM, Alan Bateman wrote:
>
>
>
> On 21/02/2020 15:23, Michael Hall wrote:
>> If I look at the jpackage page…
>>
>> The jpackage tool has been integrated into the JDK, and is now included in
>> JDK 14 early access builds.
>>
>> The normal early access page now
Hi,
I don't understand what you are doing here.
It is like you are copying around an application
which has dependent libraries but not copying those libraries.
Copying bits out of the JDK to some other location isn't something you
can expect to work.
And why does your application need
On 21/02/2020 15:23, Michael Hall wrote:
If I look at the jpackage page…
The jpackage tool has been integrated into the JDK, and is now included in JDK
14 early access builds.
The normal early access page now indicates release candidate and the download
no longer includes -ea
However,
Hi Adam,
Is it possible for the test to control the message-set?
If so, it might be safer to be explicit about the message-set to be used.
(Similar to setting LC_CTYPE=C)
Adding the "error=nn" should be sufficient without matching the full text.
It will be more resilient to possible (though
> On Feb 21, 2020, at 9:27 AM, Scott Palmer wrote:
>
> It's included as a preview feature, so it's still incubating.
>
OK, I’ll include the module. Remove it later.
Thanks
It's included as a preview feature, so it's still incubating.
On Fri, Feb 21, 2020 at 10:24 AM Michael Hall wrote:
> If I look at the jpackage page…
>
> The jpackage tool has been integrated into the JDK, and is now included in
> JDK 14 early access builds.
>
> The normal early access page now
If I look at the jpackage page…
The jpackage tool has been integrated into the JDK, and is now included in JDK
14 early access builds.
The normal early access page now indicates release candidate and the download
no longer includes -ea
However, the included jpackage still shows…
jpackage
> On Feb 21, 2020, at 9:30 AM, Severin Gehwolf wrote:
>
> Hi Bob,
>
> On Fri, 2020-02-21 at 09:11 -0500, Bob Vandette wrote:
>> Severin,
>>
>> Don’t we need the contents of /proc/self/mountinfo in order to construct the
>> path to the cgroup controllers?
>
> There is only one for unified
Hi All,
Reviews and sponsor requested for a small test change.
Parts of the test appear to be pattern-matching on error messages from
catalogues on the system.
When an AIX machine has the file set "bos.msg.en_US.rte", the messages are
different for the same codes.
E.g. for Error code 13 (in
Hi Bob,
On Fri, 2020-02-21 at 09:11 -0500, Bob Vandette wrote:
> Severin,
>
> Don’t we need the contents of /proc/self/mountinfo in order to construct the
> path to the cgroup controllers?
There is only one for unified (cgroups v2), but yes it's beeing used.
See
Severin,
Don’t we need the contents of /proc/self/mountinfo in order to construct the
path to the cgroup controllers?
On Thu, 2020-02-20 at 14:50 +, Baesken, Matthias wrote:
> Hi Severin,
>
> grep cgroup /proc/self/mountinfo
>
> returns nothing.
>
> Best Regards, Matthias
>
Hi,
Could I please get a review of this fix to the detection heuristic of
cgroup v1 vs cgroup v2? Matthias (in CC) discovered that on some old
systems the JDK Metrics code throws InternalError caused by wrong
detection logic when Metrics are being created on Linux.
The reason for this is that
Hello Naoto.
I appreciate your suggestions.
I applied your suggestions into new patch.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8235834
Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.01/
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On
Morning Christoph,
> On Feb 21, 2020, at 3:11 AM, Langer, Christoph
> wrote:
>
> Hi Lance,
>
> thanks for reviewing. Any results from Mach5? I’ll push it after I get your
> ok.
It finished late last night and it ran clean
>
> The manifest fix will still apply after this – but you wanted
Hello!
I've been testing out jpackage with a variety of javafx applications, and
for the most part am happy with it. However, I have one question.
Is there any way currently to override the default launcher created by
jpackage entirely with a custom launcher script? And if not, are there
plans
Hello,
previous week I wrote a couple of messages regarding integration of JEP 254
into j.u.StringJoiner.
As Brent Christian pointed out [1], there's already existing JDK-8148937 [2]
along with the patch [3].
In comments of it was pointed out, that the patch applied in 2016
brought some
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
Hi Lance,
thanks for reviewing. Any results from Mach5? I'll push it after I get your ok.
The manifest fix will still apply after this - but you wanted to update the
webrev anyway with some test updates, right?
When both of these fixes are in, I'll look at augmenting Jai's current proposal
31 matches
Mail list logo
