Hello,
test/java/util/Calendar/SupplementalJapaneseEraTest.sh
test/java/util/Calendar/GenericTimeZoneNamesTest.sh
test/java/util/Calendar/NarrowNamesTest.sh
Please review this patch to refactor above shell script tests to java.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210407
Webrev: http
Thank you for reviewing!
Change now pushed.
Thanks,
Amy
On 2018/10/23 1:24 PM, Weijun Wang wrote:
+1.
Thanks
Max
On Oct 11, 2018, at 2:27 PM, Remi Forax wrote:
Looks good !
Rémi
- Mail original -
De: "Amy Lu"
À: "core-libs-dev"
Envoyé: Jeudi 11 Octobre 2018 08:13:44
Objet: Re
* Stephen Colebourne:
> Fixing the parser to handle values like 25:00 would be relatively
> easy. However, these rules are also exposed in the public API of
> java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has
> methods `getLocalTime()` and `isMidnightEndOfDay()`. These would ne
+1.
Thanks
Max
> On Oct 11, 2018, at 2:27 PM, Remi Forax wrote:
>
> Looks good !
>
> Rémi
>
> - Mail original -
>> De: "Amy Lu"
>> À: "core-libs-dev"
>> Envoyé: Jeudi 11 Octobre 2018 08:13:44
>> Objet: Re: [12] RFR of JDK-8210353: Move
>> java/util/Arrays/TimSortStackSize2.java bac
Hello Martin and Everyone,
@Martin : Thank you for the response.
I have attached the PATCH file to this email.
Request you to sponsor this change.
Please find file extract in case my attachment stripped out.
diff -r ebe635565ff3 src/share/classes/java/util/TreeSet.java
--- a/src/share/classes/
Please review.
Thanks,
Amy
On 2018/10/11 4:47 PM, Amy Lu wrote:
java/util/prefs/CheckUserPrefsStorage.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209768
webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/
Tha
java/util/prefs/PrefsSpi.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8210908
webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.00/
Thanks,
Amy
The IANA time-zone database [1] provides details of how time-zones
change over time. The latest release - 2018f - cannot be processed
successfully by the current JDK parser [2]. A workaround exists
however unlike previous cases of tzdb incompatibility, this time it
makes sense for the JDK parser a
Please find another revised and updated patch attached.
On Sun, 2018-10-21 at 15:10 -0700, Martin Buchholz wrote:
> I only took a quick look.
> Looks good, but here's a nitpick - capitalize javadoc that begins
> with "returns"
> On Fri, Oct 19, 2018 at 1:27 AM, Philipp Kunz h> wrote:
> > Hi Mart
Looks good. Thanks for fixing it.
Mandy
On 10/22/18 1:28 PM, Jonathan Gibbons wrote:
OK, enough with fancy; here's the email again:
Please review a small fix to a couple of classes in java.base to fix a
number of broken links in the API documentation. In 3 places, the
anchor ClassLoader.html
OK, enough with fancy; here's the email again:
Please review a small fix to a couple of classes in java.base to fix a
number of broken links in the API documentation. In 3 places, the anchor
ClassLoader.html#name is updated to ClassLoader.html#binary-name.
JBS: https://bugs.openjdk.java.net/b
+1
> On Oct 22, 2018, at 4:26 PM, Jonathan Gibbons
> wrote:
>
> Please review a small fix to a couple of classes in java.base to fix a number
> of broken links in the API documentation. In 3 places, the anchor
> |ClassLoader.html#name| is updated to |ClassLoader.html#binary-name|.
>
> JBS: ht
Please review a small fix to a couple of classes in java.base to fix a
number of broken links in the API documentation. In 3 places, the anchor
|ClassLoader.html#name| is updated to |ClassLoader.html#binary-name|.
JBS: https://bugs.openjdk.java.net/browse/JDK-8211876
Webrev: http://cr.openjdk.j
Hi David,
On Mon, Oct 22, 2018 at 9:00 PM David Lloyd wrote:
>
> On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe wrote:
> > Hi all,
> [...]
> > So far I have not read a single technical reason in this thread why
> > vfork needs to be abandoned now
>
> Note that my patch does not abandon vfork. It
Hi Florian,
our mails crossed... I think I am fine now with posix_spawn(),
provided we do enough testing.
But I'll answer your questions inline.
On Mon, Oct 22, 2018 at 9:00 PM Florian Weimer wrote:
>
> * Thomas Stüfe:
>
> > So far I have not read a single technical reason in this thread why
>
Hi, Brian
562 public void skipNBytes(long n) throws IOException {
563 if (n > 0 && skip(n) != n) {
564 throw new EOFException("End of stream before enough
bytes skipped");
565 }
566 }
If an overrided skip() method were to skip < n bytes but not yet be a
I ran some tests on my local I ran a number of tests on various
machines and architectures, all with glibc variants older than 2.24,
and straced them, and they all used vfork() internally.
That made me curious, and I dug into the glibc sources and examined
the history. If I understand this correc
On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe wrote:
> Hi all,
[...]
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now
Note that my patch does not abandon vfork. It does not even change
the default exec strategy away from vfork, nor does it ca
* Thomas Stüfe:
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now - apart from it being obsolete. If you
> read my initial thread from September, you know that I think we have
> understood vfork's shortcomings very well, and that our (SAPs)
> p
On 2018-10-22 20:52, Vladimir Ivanov wrote:
Looks good!
Thanks, Vladimir!
/Claes
Looks good!
Best regards,
Vladimir Ivanov
On 22/10/2018 02:58, Claes Redestad wrote:
Hi,
StringConcatFactory uses a customized internal foldArguments
implementation which takes positional arguments to avoid intermediary
permutation steps, see JDK-8165492[1]. My intent has been to clean this
up
Hi all,
First off, to be clear, I am certainly shedding no tears if I do not
get to contribute my vfork+exec*2 patch to upstream. It is a lot of
work, and I much rather do something else. However, I have spend too
much of my life with the Runtime.exec() layer to be easy about
changing it.
So far
Thanks for the review, Tobias.
I will rerun the tests and add hs-tier1-3 jobs before the push.
Mandy
On 10/21/18 11:26 PM, Tobias Hartmann wrote:
Hi Mandy,
the compiler related changes look good to me.
Please run hs-tier1-3 if you haven't done so yet.
Best regards,
Tobias
On 16.10.18 18:0
* David Lloyd:
> Sure, but I don't really see this as necessary if glibc is already
> following the vfork-like path. Another thing to know is that at least
> in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag
> is completely ignored. See also [2].
Right, the manual pages are
On Sun, Oct 21, 2018 at 7:25 PM Martin Buchholz wrote:
> As author of the vfork strategy ... I'm supportive of the directions in this
> thread.
Great.
> vfork is even (!) less in favor than it used to be, so migrating off of it
> seems good. Just make sure we don't bring back the OOM problem
On 2018-10-22 14:07, Jim Laskey wrote:
Thank you for doing this.
Thanks for looking at this, Jim!
The MethodHandle changes will simplify many a use case.
Thanks! I'm particularly happy with how this optimization helped
simplify the SCF code - no reason to think it won't help simplify oth
Thank you for doing this. The MethodHandle changes will simplify many a use
case.
Cheers,
— Jim
> On Oct 22, 2018, at 6:58 AM, Claes Redestad wrote:
>
> Hi,
>
> StringConcatFactory uses a customized internal foldArguments
> implementation which takes positional arguments to avoid intermedia
Hi Alan , in case there is a re-release of Windows server 2019 the
buildNumber might (or might not) increase.
But it will not decrease.
So I think we are fine with the current check .
> although I assume we need to be cautious about back porting
Sure we can wait a couple of weeks before
Hi,
StringConcatFactory uses a customized internal foldArguments
implementation which takes positional arguments to avoid intermediary
permutation steps, see JDK-8165492[1]. My intent has been to clean this
up for possible inclusion in the public API.
In preparation of that, I realized that we c
29 matches
Mail list logo
