Hello Alan,
On 27/06/19 4:22 PM, Alan Bateman wrote:
> On 27/06/2019 11:16, Remi Forax wrote:
>> Is a boolean isEnded that records if end() was already called is not
>> enough ?
>>
> I'm sure Jaikiran will create tests that cover the different
> combinations of overriding end and close. It might e
> On Jun 27, 2019, at 4:29 PM, Andy Herrick wrote:
>
>
>
> On 6/27/2019 4:07 PM, Scott Palmer wrote:
>> I also just noticed that "--icon" is not allowed with "--package-type msi"
>> when creating the msi using --app-image. It should be, unless there is some
>> other way to set the icon t
Hi Alexey,
Looks good.
Thanks,
Alexander
On 6/27/2019 3:02 PM, Alexey Semenyuk wrote:
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).
- Eliminate unexpected console window in .exe installers on Wi
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).
- Eliminate unexpected console window in .exe installers on Windows
platform.
[1] https://bugs.openjdk.java.net/browse/JDK-8226835
[2] http://cr.ope
Arh. Yet another serialization bug.
But yes, this is a bug. Thanks for finding and diagnosing it.
Like Martin, I've often forgotten that classes themselves can be included in a
serial stream, as well as instances of those classes. In fact I seem to recall
arguing that because EnumSet u
Hi Stuart!
On 6/27/19 2:25 PM, Stuart Marks wrote:
Hi Ivan,
I think this fix is correct and clearly the spec needed to be fixed.
Since it is a change to the normative portion of the spec, though, it
needs a CSR. This is probably mostly a formality to make sure the
change is tracked for TCK
On 6/19/19 12:51 AM, Abraham Marín Pérez wrote:
private void decorate(Map data) {
//...
data.computeIfPresent("field", (k, v) -> highlightDifferences(v,
otherValue));
//...
}
At one point an emptyMap() was passed to this method, causing an UOE. [...]
On the face of it, the d
Hi Ivan,
I think this fix is correct and clearly the spec needed to be fixed. Since it is
a change to the normative portion of the spec, though, it needs a CSR. This is
probably mostly a formality to make sure the change is tracked for TCK purposes.
Can you file a CSR for this please?
Let me
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/provider/CalendarDataUtility on Win
On 6/26/19 9:28 PM, Jaikiran Pai wrote:
I am looking to contribute a patch for the enhancement noted in
https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself
looks relatively straightforward to me and here's what I plan to do:
1. Have both java.util.zip.Inflater and java.util.zip.D
Thanks for the review, Christoph.
I'll wait for a whole day so that everyone sees the fix. Planning to
push it tomorrow.
Naoto
On 6/27/19 2:05 PM, Langer, Christoph wrote:
The change looks good to me. But I would say the assertion in
CalendarDataUtility in line 266 is pointless now, isn't i
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
> Subject: Re: RFR(S)
> > 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 I
On 6/27/19 1:52 PM, Langer, Christoph wrote:
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?
Yes, but would not hurt leaving it. It would catch error if yet another
cas
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: Donnerst
On 6/27/2019 4:07 PM, Scott Palmer wrote:
I also just noticed that "--icon" is not allowed with "--package-type
msi" when creating the msi using --app-image. It should be, unless
there is some other way to set the icon to show in "Add or Remove
programs"?
The --icon option needs to be used
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8226876
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8226876/webrev.00/
This is an issue discovered on fixing a test case refactoring. [1] The
fix is to simply provide the
On Wed, Jun 26, 2019 at 2:39 PM Andy Herrick
wrote:
>
>
> On 6/25/2019 1:44 PM, Scott Palmer wrote:
> > I just tried this out. One thing that has changed since my last testing
> was the “create-installer” vs “--package-type” parameter.
> >
> > “--package-type all” isn’t allowed. If I want to cr
Hi Christoph,
Thanks for discovering the issue and resolving it. Your change looks
good to me. We will work on the actual issue you raised shortly.
Naoto
On 6/27/19 1:51 AM, Langer, Christoph wrote:
Hi,
Please, first of all, review a little test fix. Java level assertions
should be enabled
I would like to rename the other tests too, as well as moving tests up
out of directories named for the previous "modes", but I think that
should all be a separate changeset.
I'd like to leave these name changes in linux and macosx installers for
now to promote discussion of the final test lay
On 27/06/2019 11:16, Remi Forax wrote:
Is a boolean isEnded that records if end() was already called is not enough ?
I'm sure Jaikiran will create tests that cover the different
combinations of overriding end and close. It might enough for close to
check if zsRef.address is 0.
-Alan.
Is a boolean isEnded that records if end() was already called is not enough ?
Rémi
- Mail original -
> De: "Alan Bateman"
> À: "Jaikiran Pai" , "core-libs-dev"
>
> Envoyé: Jeudi 27 Juin 2019 09:13:41
> Objet: Re: Inputs on patch for JDK-8225763?
> On 27/06/2019 05:28, Jaikiran Pai wro
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).
Resol
On 27/06/2019 05:28, Jaikiran Pai wrote:
:
2. Have the close() method call the end() method
One subtle point is that end() is not idempotent. The close() method
defined by AutoCloseable is not required be to either but we should try
hard to specify Inflater::close to be idempotent. It might n
Hi all,
Issue:
https://bugs.openjdk.java.net/browse/JDK-8226863
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8226863--jdk-java-lang-reflect-execalleraccesstest-cannot-launch-on-primordial-thread/webrev.00/webrev/
we have this annoying issue on AIX that the libjvm cannot be invoked on a
prim
25 matches
Mail list logo
