On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote:
>> Pragmatically, fix the script to ignore those keywords on comment lines.
>> Learn Perl, its just a regular expression pattern match and replace
>> expression.
>>
>> All of the changes have to be manually reviewed by the author and then th
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
Hi Peter,
Are you saying guava has a tiny bug?
On Tue, May 5, 2020 at 12:12 PM Peter Levart wrote:
> Hi Martin,
> On 5/5/20 8:26 PM, Martin Buchholz wrote:
>
> See related:
>
> https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWi
See related:
https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int-
On Tue, May 5, 2020 at 11:03 AM wrote:
> And here is the fix. Please review.
>
> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/
>
> Naoto
>
> On 5/5/20 10:25 AM, naoto.
dk.java.net/~kravikumar/8243541/webrev/
>
>
> All associated tests pass. Please let me know if they look alright.
>
>
> Thanks,
>
> Kiran
>
> On 27/04/2020 15:16, Martin Buchholz wrote:
>
> Hi Kiran,
>
> Thanks for working on this update so promptly.
>
&g
Hi Kiran,
Thanks for working on this update so promptly.
The innocent renaming of America/Godthab to America/Nuuk is causing much
trouble.
Since it's a renaming, both names remain and I expected them to have the
same metadata.
So I expected the entries in TimeZoneNames.java and the translations i
+1 !
\ No newline at end of file
Please fix.
I've always wondered how the timezone-related translations are managed.
CLDR seems to be the master repository of such data, and projects like
OpenJDK are simply supposed to import that data.
But I looked at the CLDR sources, and there doesn't seem to be any "Turkey
Time" strings defined like there
(not a review)
At Google, we decided to stay on rearguard format tzdata files for all our
jdks.
One reason for that was being able to easily support older jdk versions
with the same data files.
Vanguard still seems riskier to me than rearguard.
Of course, eventually we'll need to switch to vanguard
On Tue, Sep 17, 2019 at 9:45 AM wrote:
> +1
>
> On 9/17/19 8:29 AM, Martin Buchholz wrote:
> > Looks good to me.
> > At Google we also integrated tzdata2019c, and it was uneventful (good!).
> > But we're still using rearguard format.
> > The vanguard/rearg
Looks good to me.
At Google we also integrated tzdata2019c, and it was uneventful (good!).
But we're still using rearguard format.
The vanguard/rearguard distinction is a source of errors, so it should be
made clear what format is being used to import the files.
If you have a script to update the j
Thanks for the update and redundancy removal. Looks good to me.
What is the recommendation for older releases? Migrate to vanguard format
by backporting recent changes or stay on rearguard forever?
On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil
wrote:
> Hi all,
> Please review the patch for tz
https://en.wikipedia.org/wiki/Reiwa_period
On Mon, Apr 1, 2019 at 9:16 AM Remi Forax wrote:
> Hi Naoto,
> just for my education,
> what is the translation of "Reiwa" ?
>
LGTM.
On Mon, Oct 29, 2018 at 8:19 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2018g) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213085
> Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/
>
> All the TimeZone related test
Looks good to me.
On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2018f) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/
>
> All the TimeZone
retargeted bug to java.util:i18n, the right mailing list seems to be
i18n-dev.
On Fri, Aug 10, 2018 at 8:42 AM, Adam Farley8
wrote:
> Hi All,
>
> This bug could be fixed by comparing the Class Loader with a blank
> static volatile Object (defined outside the method scope) at the
> end of the get
Looks good.
On Tue, May 22, 2018 at 3:49 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2018e) to JDK.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203233
> Webrev: http://cr.openjdk.java.net/~rpatil/8203233/webrev.00/
>
> All the TimeZone related te
On Tue, Feb 13, 2018 at 10:24 PM, Mark Davis ☕️ wrote:
> I'm pretty annoyed with the TZ group lately; there seems to be little
> consideration for compatibility.
>
> I think, if it comes to it, we may need to be prepared to fork the "input
> data" in CLDR. My hope is that they will instead at lea
On Tue, Feb 13, 2018 at 3:02 PM, Stephen Colebourne
wrote:
>
> In the short term, I don't think CLDR should change its data, nor do I
> think OpenJDK should change. ie. for Ireland, standard=winter and
> daylight=summer should continue to be true in both projects.
>
I agree
> If TZDB insists o
Google has been successfully running jdk8 and jdk9 with 2018c.
On Mon, Jan 29, 2018 at 12:49 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2018c) into JDK10.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195837
> Webrev: http://cr.openjdk.java.net/~r
Looks good to me too.
I've always wondered about how the corresponding java source files are
maintained. Is it all manual or do y'all have some magic script to help
keep IANA data and java data aligned? Do we need more testing that
mistakes don't creep in?
On Tue, Nov 7, 2017 at 3:41 AM, Ramana
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/Currency-PropertiesTest/
tzdata2017c came out today, and the elves at Google are working hard to
incorporate changes in hours or days instead of weeks or quarters. One
thing we noticed is that one of the java.time tck tests was broken by
tzdata rewrite of history. Here's the fix we're applying (s/1879/1892/g):
@@ -941,2
Looks even better!
On Wed, May 31, 2017 at 2:20 PM, Naoto Sato wrote:
> Thanks, Martin. Updated the webrev for each:
>
> http://cr.openjdk.java.net/~naoto/8176160/webrev.01/
> http://cr.openjdk.java.net/~naoto/8176847/webrev.01/
>
> Naoto
>
> On 5/31/17 1:00 P
Thanks - looks good.
---
+private final static List cals =
+List.of("gregorian", "japanese", "julian");
If you inline this into main, your beautiful stream pipeline will be even
more beautiful!
---
+import static java.util.Calendar.Builder;
My colleagues would frown upon static im
Looks good to me!
On Wed, Mar 29, 2017 at 11:31 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2017b) to JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177449
> Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/
>
> All the TimeZone re
I say we make this extraordinarily safe fix in jdk9:
https://bugs.openjdk.java.net/browse/JDK-8176886
--- a/src/java.base/share/classes/java/util/Date.java
+++ b/src/java.base/share/classes/java/util/Date.java
@@ -728,7 +728,6 @@
* @see java.util.Calendar
* @deprecated As of JDK ve
Thanks as always for keeping the tzdata pipeline moving!
Looks good to me.
On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2016j) to JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
> Webrev: http://cr.openjdk.jav
Looks good!
On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2016i) to JDK8U.
> Since tzdata is cumulative, this bug fix backports both the tzdata
> versions(tzdata2016h+tzdata2016i) into jdk8u.
>
> Bug: https://bugs.openjdk.ja
Looks good to me!
On Mon, Nov 7, 2016 at 2:43 AM, Ramanand Patil
wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2016i) to JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169191
> Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/
>
> All the TimeZone rela
Looks good to me!
On Mon, Oct 24, 2016 at 12:28 AM, Ramanand Patil
wrote:
> Hi all,
>
> Please review the latest TZDATA integration (tzdata2016h) to JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168512
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/
>
>
>
> All the T
es. Though I found very few zone names are missing from this
> file like: "Europe/Busingen", "America/Fort_Nelson", "Antarctica/Troll"
> etc...
>
>
> Regards,
> Ramanand.
>
> From: Martin Buchholz [mailto:marti...@google.com]
> Sent: Monday, Oct
Thanks!
On Mon, Oct 3, 2016 at 12:22 AM, Rachna Goel wrote:
> Hi,
>
> Please review this simple documentation fix for JDK-8166993.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8166993
>
> webrev :http://cr.openjdk.java.net/~rgoel/JDK-8166993/webrev/
>
> Thanks,
>
> Rachna
>
>
Hi Ramanand,
Pleased to meet you!
I expected to see Yangon added to ZoneName, because of the existing
reference to Rangoon
java/time/test/java/time/format/ZoneName.java:179:"Asia/Rangoon",
"Myanmar", "Asia/Rangoon",
Is ZoneName.java trying to maintain a comprehensive list of zone names?
I have no idea what I'm doing - feel free to take ownership.
https://bugs.openjdk.java.net/browse/JDK-8166983
; width information (LONG, SHORT, NARROW) which is the same thing as its
> format form, e.g., Calendar.LONG == Calendar.LONG_FORMAT.
>
> Masayoshi
>
>
> On 3/28/2015 4:31 AM, Martin Buchholz wrote:
>
> Don't know much about Calendar, but:
>
> do you want
Don't know much about Calendar, but:
do you want below to try fallback twice? Eg. if it's still null after
trying toStandaloneStyle(style), do you want to also try fallback to
getBaseStyle(style) ?
2093 // Perform fallback here to follow the CLDR rules2094
if (val == null
Hi Naoto,
I'd like you to do a code review to fix test breakage on macosx.
https://bugs.openjdk.java.net/browse/JDK-8055675#comment-13541658
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-PropertiesTest-hygiene/
i Martin,
>
> Initial intention for not copying the JDK was to avoid timeout for some
> cases in slow networked environment. But it still does not avoid all the
> cases. So, yes I am fine with your fix.
>
> Naoto
>
>
> On 8/16/14, 6:11 PM, Martin Buchholz wrote:
>
>>
Hi Naoto, Alan,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-concurrency/
https://bugs.openjdk.java.net/browse/JDK-8055253
This will fix the transient failures in Currency ONCE AND FOR ALL!
On Wed, Sep 22, 2010 at 14:53, Naoto Sato wrote:
>> Also, is it possible to get a bug id for this?
>
> I am not familiar with this process, but according to this page
> (http://openjdk.java.net/contribute/), you can create a new bug report in
> the OpenJDK Bugzilla.
An Oracle sponsor still needs
On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes
wrote:
> 2009/12/10 Joseph D. Darcy :
> I added the fixes mentioned and tried to push. I was greeted with this:
>
> remote:
> remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh:
> Executable files not permitted
> remote:
>
> Funny becau
Hello i18n gods,
Sorry for being such a stranger to this mailing list.
Anyways, here's a bug report:
If you test java/util/ResourceBundle/Test4300693.java with
-vmoption:-enablesystemassertions,
you get an assertion failure as follows (please fix):
jtreg -v:nopass,fail -vmoption:-enablesystemas
r 204 constants
more obvious than before.
I intend to fold the two isSurrogate patches into one and commit them
when I get CCC approval. Speaking of which... has that happened yet?
Martin
On Wed, Aug 5, 2009 at 09:37, Joseph D. Darcy wrote:
> Martin Buchholz wrote:
>>
>> Hi Masay
>
> Thanks,
> Masayoshi
>
> On 8/5/2009 11:03 AM, Martin Buchholz wrote:
>>
>> Hi i18n team,
>>
>> FYI:
>>
>> I am intending to commit these changes to java.lang.Character
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurr
Hi i18n team,
FYI:
I am intending to commit these changes to java.lang.Character
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurrogate/
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurrogate2/
(follow-on change)
as soon as I have CCC approval.
Martin
On Sat, Sep 13, 2008 at 14:57, Xueming Shen <[EMAIL PROTECTED]> wrote:
>
> Martin, don't trap people into using -Dfile.encoding, always treat it as a
> read only property:-)
>
> I believe initializeEncoding(env) gets invoked before -Dxyz=abc overwrites
> the default one,
> beside the "jnu encoding
to get the file's length without an error
> when it goes to read data from the file and has trouble.
>
> I don't -think- I'm doing anything screwy in there - could it be that
> ISO-8859-1 isn't giving good round-trip conversions in practice? Would this
>
, Naoto Sato <[EMAIL PROTECTED]> wrote:
> Why ISO-8859-1? CJK filenames are guaranteed to fail in that case. I'd
> rather choose UTF-8, as the default encoding on recent Unix/Linux are all
> UTF-8 so the filenames are likely in UTF-8.
>
> Naoto
>
> Martin Buchholz wro
Java made the decision to use String as an abstraction
for many OS-specific objects, like filenames (or environment variables).
Most of the time this works fine, but occasionally you can notice
that the underlying OS (in the case of Unix) actually uses
arbitrary byte arrays as filenames.
It would
e to check OS tzdata version. Can
> you elaborate your suggestion a bit more?
>
> Thanks,
> Masayoshi
>
> On 1/30/2008 8:51 AM, Martin Buchholz wrote:
>> Dalibor Topic wrote:
>>
>>> Masayoshi Okutsu wrote:
>>> From the POV of operating system distributor
Dalibor Topic wrote:
> Masayoshi Okutsu wrote:
> From the POV of operating system distributors that already need to
> support tzdata for other applications, and therefore need to keep it
> current anyway for their customers, I think it's preferable to rely on
> system facilities where such facili
53 matches
Mail list logo
