From patrick.zhang at oracle.com Fri Mar 1 01:35:33 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Fri, 01 Mar 2013 17:35:33 +0800 Subject: [threeten-dev] Please help to review new test code for java.time.Period In-Reply-To: <5123470A.4060406@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> Message-ID: <51307665.30203@oracle.com> Hi Team, Please help to review new test cases for java.time.Period. Impacted method list is bleow. plus() minus() minusDays() minusYears() minusMonths() plusYears(). plusMonths() and plusDays are not touched since it has been included. And the new test code dose not introduce data provider. It just follow the old programming style of plusXXX(). webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Period/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Period/TCKPeriod.jtr Regards Patrick From patrick.zhang at oracle.com Fri Mar 1 01:40:58 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Fri, 01 Mar 2013 17:40:58 +0800 Subject: [threeten-dev] Please help to review new test code for java.time.Duration In-Reply-To: <51307665.30203@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <51307665.30203@oracle.com> Message-ID: <513077AA.7090609@oracle.com> Hi Team, Please help to review new test cases for java.time.Duration. Impacted method list is bleow. minusDays() minusHours() minusMinutes() plusDays() plusHours() plusMinutes() withNanos() withSeconds() toDays() toHours() toMinutes() webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Duration/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Duration/TCKDuration.jtr Regards Patrick From roger.riggs at oracle.com Fri Mar 1 07:05:45 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 01 Mar 2013 10:05:45 -0500 Subject: [threeten-dev] Please help to review new test code for java.time.Period In-Reply-To: <51307665.30203@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <51307665.30203@oracle.com> Message-ID: <5130C3C9.1000002@oracle.com> Hi Patrick, These look fine. I'm not sure if it is a feature or a bug but the way that TestNG works, the first failure terminates the test. So if anything breaks then only the first case will be reported as a failure. Roger On 3/1/2013 4:35 AM, patrick zhang wrote: > Hi Team, > > Please help to review new test cases for java.time.Period. > Impacted method list is bleow. > plus() > minus() > minusDays() > minusYears() > minusMonths() > > plusYears(). plusMonths() and plusDays are not touched since it has > been included. And the new test code dose not introduce data provider. > It just follow the old programming style of plusXXX(). > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Period/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Period/TCKPeriod.jtr > > Regards > Patrick From roger.riggs at oracle.com Fri Mar 1 10:08:10 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 01 Mar 2013 13:08:10 -0500 Subject: [threeten-dev] Please help to review new test code for java.time.Duration In-Reply-To: <513077AA.7090609@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <51307665.30203@oracle.com> <513077AA.7090609@oracle.com> Message-ID: <5130EE8A.2020109@oracle.com> Hi Patrick, These look fine too. Thanks, Roger On 3/1/2013 4:40 AM, patrick zhang wrote: > Hi Team, > > Please help to review new test cases for java.time.Duration. > Impacted method list is bleow. > > minusDays() > minusHours() > minusMinutes() > plusDays() > plusHours() > plusMinutes() > withNanos() > withSeconds() > toDays() > toHours() > toMinutes() > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Duration/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Duration/TCKDuration.jtr > > Regards > Patrick > > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Fri Mar 1 10:25:17 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Mar 2013 10:25:17 -0800 Subject: [threeten-dev] Fwd: Re: [threeten-develop] Review fix for periodUntil issue 273 Message-ID: <5130F28D.5090105@oracle.com> -------- Original Message -------- Message-ID: <5130EA4E.40203 at oracle.com> Date: Fri, 01 Mar 2013 09:50:06 -0800 From: Xueming Shen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: threeten-develop at lists.sourceforge.net Subject: Re: [threeten-develop] Review fix for periodUntil issue 273 References: <512F891E.2000303 at oracle.com> <5130E859.80704 at oracle.com> In-Reply-To: <5130E859.80704 at oracle.com> Content-Type: multipart/alternative; boundary="------------010105070200000205030007" On 3/1/13 9:41 AM, Xueming Shen wrote: > -ChronoDateImple.periodUntil(t, u) > The "convention" is to align the "case" to the "switch" in jdk source code? > > - Understood it is kinda of 310 convention to have "... == false", but I would suggest to > use the the normal (! X) instead. > > -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed using the chronology > of this date. If necessary, the input date will be converted to match" (btw, there are two > "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle "same type" of CLD I meant to say 3. > now, (their java doc currently simply is inherited from the super class). Is it possible to have > a better alternative? at least they all have a isodate. > > -Sherman > > > On 2/28/13 8:43 AM, roger riggs wrote: >> Please review bug fix/improvements for: >> >> PeriodUntil throws exception: unable to calculate period between objects of different types >> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ >> >> >> The periodUntil methods do not correctly compute the period >> for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. >> ChronoDateImpl is enhanced to support 12 month based calendars. >> >> The ValueRange.getIntValue method should throw similar exceptions >> when the field is not an int field. Provides better feedback for >> the generic Temporal.get access to fields that are not int field. >> >> Added simple tests to TestHijrahChronology, TestJapaneseChronology, >> TestMinguoChronology, and TestHijrahChronology >> >> Thanks, Roger >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> >> >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > From xueming.shen at oracle.com Fri Mar 1 11:40:09 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Mar 2013 11:40:09 -0800 Subject: [threeten-dev] Fwd: Re: [threeten-develop] Review fix for periodUntil issue 273 In-Reply-To: <5130F28D.5090105@oracle.com> References: <5130F28D.5090105@oracle.com> Message-ID: <51310419.2070603@oracle.com> while we are on this, it appears two ChronoLocalDate.periodUntil() methods are declared as "public abstract ...", any particular reason to do that? or just a "leftover" of the previous life of CLD as an abstract class, instead of an interface now? On 03/01/2013 10:25 AM, Xueming Shen wrote: > > > -------- Original Message -------- > Message-ID: <5130EA4E.40203 at oracle.com> > Date: Fri, 01 Mar 2013 09:50:06 -0800 > From: Xueming Shen > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 > MIME-Version: 1.0 > To: threeten-develop at lists.sourceforge.net > Subject: Re: [threeten-develop] Review fix for periodUntil issue 273 > References: <512F891E.2000303 at oracle.com> <5130E859.80704 at oracle.com> > In-Reply-To: <5130E859.80704 at oracle.com> > Content-Type: multipart/alternative; boundary="------------010105070200000205030007" > > > > On 3/1/13 9:41 AM, Xueming Shen wrote: >> -ChronoDateImple.periodUntil(t, u) >> The "convention" is to align the "case" to the "switch" in jdk source code? >> >> - Understood it is kinda of 310 convention to have "... == false", but I would suggest to >> use the the normal (! X) instead. >> >> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed using the chronology >> of this date. If necessary, the input date will be converted to match" (btw, there are two >> "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle "same type" of CLD > > I meant to say 3. > > >> now, (their java doc currently simply is inherited from the super class). Is it possible to have >> a better alternative? at least they all have a isodate. >> >> -Sherman >> >> >> On 2/28/13 8:43 AM, roger riggs wrote: >>> Please review bug fix/improvements for: >>> >>> PeriodUntil throws exception: unable to calculate period between objects of different types >>> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ >>> >>> >>> The periodUntil methods do not correctly compute the period >>> for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. >>> ChronoDateImpl is enhanced to support 12 month based calendars. >>> >>> The ValueRange.getIntValue method should throw similar exceptions >>> when the field is not an int field. Provides better feedback for >>> the generic Temporal.get access to fields that are not int field. >>> >>> Added simple tests to TestHijrahChronology, TestJapaneseChronology, >>> TestMinguoChronology, and TestHijrahChronology >>> >>> Thanks, Roger >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> >>> >>> _______________________________________________ >>> threeten-develop mailing list >>> threeten-develop at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > From roger.riggs at oracle.com Fri Mar 1 11:54:08 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 01 Mar 2013 14:54:08 -0500 Subject: [threeten-dev] Fwd: Re: [threeten-develop] Review fix for periodUntil issue 273 In-Reply-To: <51310419.2070603@oracle.com> References: <5130F28D.5090105@oracle.com> <51310419.2070603@oracle.com> Message-ID: <51310760.3040207@oracle.com> Hi Sherman, Thanks for the comments. On 3/1/2013 2:40 PM, Xueming Shen wrote: > while we are on this, it appears two ChronoLocalDate.periodUntil() > methods > are declared as "public abstract ...", any particular reason to do > that? or just > a "leftover" of the previous life of CLD as an abstract class, instead > of an interface > now? Will fix, it is a left over from the before the transition to interface. > > On 03/01/2013 10:25 AM, Xueming Shen wrote: >> >> ... >> >> On 3/1/13 9:41 AM, Xueming Shen wrote: >>> -ChronoDateImple.periodUntil(t, u) >>> The "convention" is to align the "case" to the "switch" in jdk >>> source code? Netbeans doesn't see it that way and for now I'd stay consistent with the rest of 310. If we decide to make a pass and update to JDK conventions, i'd rather do that separately. >>> >>> - Understood it is kinda of 310 convention to have "... == false", >>> but I would suggest to >>> use the the normal (! X) instead. Same >>> >>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed >>> using the chronology >>> of this date. If necessary, the input date will be converted to >>> match" (btw, there are two >>> "the"s here), but all our 4 jdk-provided ChronoLocalDate only >>> handle "same type" of CLD >> >> I meant to say 3. True, though this is odd, the two periodUntil methods have different assertions for whether the date is converted or only handle the same type. I'll wait to commit until I can understand why. >> >> >>> now, (their java doc currently simply is inherited from the super >>> class). Is it possible to have >>> a better alternative? at least they all have a isodate. If they are all to be converted, the javadoc would be consistent. Thanks, Roger >>> >>> -Sherman >>> >>> >>> On 2/28/13 8:43 AM, roger riggs wrote: >>>> Please review bug fix/improvements for: >>>> >>>> PeriodUntil throws exception: unable to calculate period between >>>> objects of different types >>>> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ >>>> >>>> >>>> The periodUntil methods do not correctly compute the period >>>> for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. >>>> ChronoDateImpl is enhanced to support 12 month based calendars. >>>> >>>> The ValueRange.getIntValue method should throw similar exceptions >>>> when the field is not an int field. Provides better feedback for >>>> the generic Temporal.get access to fields that are not int field. >>>> >>>> Added simple tests to TestHijrahChronology, TestJapaneseChronology, >>>> TestMinguoChronology, and TestHijrahChronology >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_d2d_feb >>>> >>>> >>>> _______________________________________________ >>>> threeten-develop mailing list >>>> threeten-develop at lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >> > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Fri Mar 1 12:34:55 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Mar 2013 12:34:55 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: #245 Add UnsupportedTemporalElementException In-Reply-To: <512FE601.3040008@oracle.com> References: <20130227042827.38A5847456@hg.openjdk.java.net> <512F1A9B.5020900@oracle.com> <512F63CE.2090801@oracle.com> <512FE04C.4050504@oracle.com> <512FE601.3040008@oracle.com> Message-ID: <513110EF.1070906@oracle.com> it appears you also undo-ed my small "fix-findbugs" changes as well :-) http://hg.openjdk.java.net/threeten/threeten/jdk/rev/928b3fb5edbc On 02/28/2013 03:19 PM, roger riggs wrote: > Hi, > > My mistake. The test has been restored also. > > Thanks, Roger > > > On 2/28/2013 5:55 PM, Masayoshi Okutsu wrote: >> On 2/28/2013 11:03 PM, roger riggs wrote: >>> Hi, >>> >>> I had difficulty with the merge on this one and did not notice the problem. >>> (no tests failed; I suppose that means we have a gap in tests). >> >> No. You removed the test changes as well. >> >> Masayoshi From roger.riggs at oracle.com Fri Mar 1 12:48:06 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 01 Mar 2013 15:48:06 -0500 Subject: [threeten-dev] hg: threeten/threeten/jdk: #245 Add ... In-Reply-To: <513110EF.1070906@oracle.com> References: <20130227042827.38A5847456@hg.openjdk.java.net> <512F1A9B.5020900@oracle.com> <512F63CE.2090801@oracle.com> <512FE04C.4050504@oracle.com> <512FE601.3040008@oracle.com> <513110EF.1070906@oracle.com> Message-ID: <51311406.4060306@oracle.com> (That was not a good day). I will restore them. Roger On 3/1/2013 3:34 PM, Xueming Shen wrote: > it appears you also undo-ed my small "fix-findbugs" changes as well :-) > > http://hg.openjdk.java.net/threeten/threeten/jdk/rev/928b3fb5edbc > > On 02/28/2013 03:19 PM, roger riggs wrote: >> Hi, >> >> My mistake. The test has been restored also. >> >> Thanks, Roger >> >> >> On 2/28/2013 5:55 PM, Masayoshi Okutsu wrote: >>> On 2/28/2013 11:03 PM, roger riggs wrote: >>>> Hi, >>>> >>>> I had difficulty with the merge on this one and did not notice the >>>> problem. >>>> (no tests failed; I suppose that means we have a gap in tests). >>> >>> No. You removed the test changes as well. >>> >>> Masayoshi > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From roger.riggs at oracle.com Fri Mar 1 14:56:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 01 Mar 2013 17:56:52 -0500 Subject: [threeten-dev] Review fix for periodUntil issue 273 In-Reply-To: <51310419.2070603@oracle.com> References: <5130F28D.5090105@oracle.com> <51310419.2070603@oracle.com> Message-ID: <51313234.5050505@oracle.com> Revised the webrev: http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ Thanks, Roger On 3/1/2013 2:40 PM, Xueming Shen wrote: > while we are on this, it appears two ChronoLocalDate.periodUntil() > methods > are declared as "public abstract ...", any particular reason to do > that? or just > a "leftover" of the previous life of CLD as an abstract class, instead > of an interface > now? > > On 03/01/2013 10:25 AM, Xueming Shen wrote: >> >> On 3/1/13 9:41 AM, Xueming Shen wrote: >>> -ChronoDateImple.periodUntil(t, u) >>> The "convention" is to align the "case" to the "switch" in jdk >>> source code? >>> >>> - Understood it is kinda of 310 convention to have "... == false", >>> but I would suggest to >>> use the the normal (! X) instead. >>> >>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed >>> using the chronology >>> of this date. If necessary, the input date will be converted to >>> match" (btw, there are two >>> "the"s here), but all our 4 jdk-provided ChronoLocalDate only >>> handle "same type" of CLD >> >> I meant to say 3. >> >> >>> now, (their java doc currently simply is inherited from the super >>> class). Is it possible to have >>> a better alternative? at least they all have a isodate. >>> >>> -Sherman >>> From xueming.shen at oracle.com Fri Mar 1 15:37:51 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Mar 2013 15:37:51 -0800 Subject: [threeten-dev] Review fix for periodUntil issue 273 In-Reply-To: <51313234.5050505@oracle.com> References: <5130F28D.5090105@oracle.com> <51310419.2070603@oracle.com> <51313234.5050505@oracle.com> Message-ID: <51313BCF.1050606@oracle.com> (1) "public" is also not needed for interface method (2) ChronoDateImpl#332: LocalDate.periodUntil() has requirenonNull(endDate...) before throwing DTE, to be consistent? otherwise looks fine. On 03/01/2013 02:56 PM, roger riggs wrote: > Revised the webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ > > Thanks, Roger > > On 3/1/2013 2:40 PM, Xueming Shen wrote: >> while we are on this, it appears two ChronoLocalDate.periodUntil() methods >> are declared as "public abstract ...", any particular reason to do that? or just >> a "leftover" of the previous life of CLD as an abstract class, instead of an interface >> now? >> >> On 03/01/2013 10:25 AM, Xueming Shen wrote: >>> >>> On 3/1/13 9:41 AM, Xueming Shen wrote: >>>> -ChronoDateImple.periodUntil(t, u) >>>> The "convention" is to align the "case" to the "switch" in jdk source code? >>>> >>>> - Understood it is kinda of 310 convention to have "... == false", but I would suggest to >>>> use the the normal (! X) instead. >>>> >>>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed using the chronology >>>> of this date. If necessary, the input date will be converted to match" (btw, there are two >>>> "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle "same type" of CLD >>> >>> I meant to say 3. >>> >>> >>>> now, (their java doc currently simply is inherited from the super class). Is it possible to have >>>> a better alternative? at least they all have a isodate. >>>> >>>> -Sherman >>>> From xueming.shen at oracle.com Fri Mar 1 15:47:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Mar 2013 15:47:57 -0800 Subject: [threeten-dev] Review fix for periodUntil issue 273 In-Reply-To: <51313BCF.1050606@oracle.com> References: <5130F28D.5090105@oracle.com> <51310419.2070603@oracle.com> <51313234.5050505@oracle.com> <51313BCF.1050606@oracle.com> Message-ID: <51313E2D.1090405@oracle.com> (3) ChronoLocalDate#535 and #540 are redundant, Ln#535 probably can be just removed. Same as the wording in LocalDate.periodUntil(CLD). On 03/01/2013 03:37 PM, Xueming Shen wrote: > > (1) "public" is also not needed for interface method > (2) ChronoDateImpl#332: > LocalDate.periodUntil() has requirenonNull(endDate...) before throwing DTE, to be consistent? > > otherwise looks fine. > > On 03/01/2013 02:56 PM, roger riggs wrote: >> Revised the webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ >> >> Thanks, Roger >> >> On 3/1/2013 2:40 PM, Xueming Shen wrote: >>> while we are on this, it appears two ChronoLocalDate.periodUntil() methods >>> are declared as "public abstract ...", any particular reason to do that? or just >>> a "leftover" of the previous life of CLD as an abstract class, instead of an interface >>> now? >>> >>> On 03/01/2013 10:25 AM, Xueming Shen wrote: >>>> >>>> On 3/1/13 9:41 AM, Xueming Shen wrote: >>>>> -ChronoDateImple.periodUntil(t, u) >>>>> The "convention" is to align the "case" to the "switch" in jdk source code? >>>>> >>>>> - Understood it is kinda of 310 convention to have "... == false", but I would suggest to >>>>> use the the normal (! X) instead. >>>>> >>>>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed using the chronology >>>>> of this date. If necessary, the input date will be converted to match" (btw, there are two >>>>> "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle "same type" of CLD >>>> >>>> I meant to say 3. >>>> >>>> >>>>> now, (their java doc currently simply is inherited from the super class). Is it possible to have >>>>> a better alternative? at least they all have a isodate. >>>>> >>>>> -Sherman >>>>> > From roger.riggs at oracle.com Sat Mar 2 07:42:51 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 02 Mar 2013 15:42:51 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: #273 PeriodUntil throws exception Message-ID: <20130302154330.03875477DF@hg.openjdk.java.net> Changeset: f90fd81415b6 Author: rriggs Date: 2013-03-02 10:42 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f90fd81415b6 #273 PeriodUntil throws exception The periodUntil methods do not correctly compute the period for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. ChronoDateImpl is enhanced to support 12 month based calendars. Added simple tests to TestHijrahChronology, TestJapaneseChronology, TestMinguoChronology, and TestHijrahChronology ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TestHijrahChronology.java ! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TestMinguoChronology.java ! test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java From roger.riggs at oracle.com Sat Mar 2 08:20:51 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 02 Mar 2013 16:20:51 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130302162116.7A465477E0@hg.openjdk.java.net> Changeset: f0f20478cf36 Author: rriggs Date: 2013-03-01 16:17 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f0f20478cf36 Updated to address the FindBugs complaints: restored changeset 7177 ! src/share/classes/java/time/format/DateTimeBuilder.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeTextProvider.java Changeset: ede4d518943b Author: rriggs Date: 2013-03-02 11:20 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ede4d518943b Merge From roger.riggs at oracle.com Sat Mar 2 08:48:14 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 02 Mar 2013 11:48:14 -0500 Subject: [threeten-dev] Review of javadoc updates Message-ID: <51322D4E.6050304@oracle.com> Hi, This javadoc-only change raises the visiblity and enhances the descriptions of the DateTimeFormatter patterns and fixes a number of complaints that the javadoc tool has about the html markup. https://github.com/ThreeTen/threeten/issues/240 webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From roger.riggs at oracle.com Sat Mar 2 11:02:50 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 02 Mar 2013 14:02:50 -0500 Subject: [threeten-dev] DisplayNames for field names Message-ID: <51324CDA.7060108@oracle.com> Hi, Issue#103 requests locale based display names for field names. The data is available and it only needs a TemporalField/ChronoField.getDisplayName method plus a little plumbing. Please review and comment: webrev: http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ javadoc: TemporalField and ChronoField: http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Sat Mar 2 11:31:06 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 02 Mar 2013 11:31:06 -0800 Subject: [threeten-dev] hg: threeten/threeten/jdk: #273 PeriodUntil throws exception In-Reply-To: <20130302154330.03875477DF@hg.openjdk.java.net> References: <20130302154330.03875477DF@hg.openjdk.java.net> Message-ID: <5132537A.3050003@oracle.com> I guess the code before the change was intentionally to hide the Objects.requireNoNull() inside/after the "instanceof" check, so non-null && instanceof == true "endDate" (99.9%+ in real world scenario) would only take one "if" check. The Objects.requreNoNull there is only to give you an accurate error message. -Sherman On 3/2/13 7:42 AM, roger.riggs at oracle.com wrote: > Changeset: f90fd81415b6 > Author: rriggs > Date: 2013-03-02 10:42 -0500 > URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f90fd81415b6 > > #273 PeriodUntil throws exception > The periodUntil methods do not correctly compute the period > for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. > ChronoDateImpl is enhanced to support 12 month based calendars. > > Added simple tests to TestHijrahChronology, TestJapaneseChronology, > TestMinguoChronology, and TestHijrahChronology > > ! src/share/classes/java/time/LocalDate.java > ! src/share/classes/java/time/chrono/ChronoDateImpl.java > ! src/share/classes/java/time/chrono/ChronoLocalDate.java > ! test/java/time/tck/java/time/chrono/TestHijrahChronology.java > ! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java > ! test/java/time/tck/java/time/chrono/TestMinguoChronology.java > ! test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java > From masayoshi.okutsu at oracle.com Sun Mar 3 00:30:56 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sun, 03 Mar 2013 17:30:56 +0900 Subject: [threeten-dev] Request for review: quarter text support Message-ID: <51330A40.6070108@oracle.com> I've added quarter text support. Actual names are supported in English only under the default locale data provider. You can specify -Djava.locale.provider=CLDR if localized names are required. I will add localized names into the existing JRE resources (as separate resource bundles) later if I have time. Also: - changed DateTimeFormatterBuilder.getLocalizedName to DateTimeTextProvider.getLocalizedResource (package private). - changed TestTextParser/Printer to specify Locale.ROOT for string case conversions in order to avoid any surprises with the Turkish locale. - the "MonthNarrow" to "MonthNarrows" change in CLDRConverter.java is a piggy back fix. Webrev: http://cr.openjdk.java.net/~okutsu/310/quartertext/webrev.01/ Thanks, Masayoshi From patrick.zhang at oracle.com Sun Mar 3 19:00:50 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Mon, 04 Mar 2013 11:00:50 +0800 Subject: [threeten-dev] periodUntil(Temporal, TemporalUnit) does not work properly In-Reply-To: <512F6F90.1090501@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F6F90.1090501@oracle.com> Message-ID: <51340E62.9080206@oracle.com> Hi Roger, I see some code change related with this bug. Has it been fixed? I will write some new test cases for it. Regards Patrick On 2013-2-28 22:54, roger riggs wrote: > Hi Patrick, > > These are bugs. > The code delegates to the isoDate but does not supply the isoDate of > the endDate. > > I'll look into fixing it. > > Roger > > On 2/28/2013 2:59 AM, patrick zhang wrote: >> Hi Team, >> >> I am checking some functions in HijrahDate >> <../../../java/time/chrono/HijrahDate.html>, JapaneseDate >> <../../../java/time/chrono/JapaneseDate.html>, MinguoDate >> <../../../java/time/chrono/MinguoDate.html> and ThaiBuddhistDate. >> <../../../java/time/chrono/ThaiBuddhistDate.html> >> It looks periodUntil(Temporal, TemporalUnit) does not work properly. >> >> Any suggestion about it? The similar problem happens for all 4 classes. >> >> sample code: >> ========================================== >> LocalDate date1 = LocalDate.of(1970, 1, 1) ; >> LocalDate date2 = LocalDate.of(1968, 2, 10) ; >> System.out.println(date2.periodUntil(date1,ChronoUnit.DAYS)) ; >> >> MinguoDate date3 = MinguoDate.of(1970, 1, 1) ; >> MinguoDate date4 = MinguoDate.of(1968, 2, 10) ; >> System.out.println(date4.periodUntil(date3,ChronoUnit.DAYS)) ; >> ========================================== >> >> output: >> ========================================== >> 691 >> Exception in thread "main" java.time.DateTimeException: Unable to >> calculate period between objects of two different types >> at java.time.LocalDate.periodUntil(LocalDate.java:1517) >> at >> java.time.chrono.ChronoDateImpl.periodUntil(ChronoDateImpl.java:334) >> at java.time.chrono.MinguoDate.periodUntil(MinguoDate.java:96) >> at mytest.TestMinguoDate.main(TestMinguoDate.java:20) >> ========================================== >> >> Regards >> Patrick > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From roger.riggs at oracle.com Mon Mar 4 09:53:41 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 04 Mar 2013 12:53:41 -0500 Subject: [threeten-dev] Review for minor update to ValueRange checkValidIntValue Message-ID: <5134DFA5.2000600@oracle.com> Hi, A simple fix for the exception and message when TemporalAccessor.get() is used (incorrectly) to retrieve Fields with long values. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ Thanks, Roger From xueming.shen at oracle.com Mon Mar 4 13:49:22 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 04 Mar 2013 21:49:22 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated test test/java/time/tck/java/time/TCKDuration.java Message-ID: <20130304215004.4C65147820@hg.openjdk.java.net> Changeset: a359ec7dce4d Author: sherman Date: 2013-03-04 13:45 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a359ec7dce4d Updated test test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKDuration.java From xueming.shen at oracle.com Mon Mar 4 13:54:19 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 04 Mar 2013 21:54:19 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated test test/java/time/tck/java/time/TCKPeriod.java Message-ID: <20130304215436.973A747821@hg.openjdk.java.net> Changeset: f66a28a0599c Author: sherman Date: 2013-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f66a28a0599c Updated test test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKPeriod.java From masayoshi.okutsu at oracle.com Mon Mar 4 19:25:10 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 05 Mar 2013 12:25:10 +0900 Subject: [threeten-dev] DisplayNames for field names In-Reply-To: <51324CDA.7060108@oracle.com> References: <51324CDA.7060108@oracle.com> Message-ID: <51356596.1070807@oracle.com> I wonder if TemporalField.getDisplayName should describe the default behavior, returning the getName() value. Should the getDisplayName implementations check null locale? Masayoshi On 3/3/2013 4:02 AM, roger riggs wrote: > Hi, > > Issue#103 requests > locale based display names for field names. > The data is available and it only needs a > TemporalField/ChronoField.getDisplayName > method plus a little plumbing. > > Please review and comment: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > > javadoc: TemporalField and ChronoField: > http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ > From xueming.shen at oracle.com Mon Mar 4 21:08:11 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 04 Mar 2013 21:08:11 -0800 Subject: [threeten-dev] Request for review: quarter text support In-Reply-To: <51330A40.6070108@oracle.com> References: <51330A40.6070108@oracle.com> Message-ID: <51357DBB.4050406@oracle.com> looks fine for me. On 3/3/13 12:30 AM, Masayoshi Okutsu wrote: > I've added quarter text support. Actual names are supported in English > only under the default locale data provider. You can specify > -Djava.locale.provider=CLDR if localized names are required. I will > add localized names into the existing JRE resources (as separate > resource bundles) later if I have time. > > Also: > > - changed DateTimeFormatterBuilder.getLocalizedName to > DateTimeTextProvider.getLocalizedResource (package private). > > - changed TestTextParser/Printer to specify Locale.ROOT for string > case conversions in order to avoid any surprises with the Turkish locale. > > - the "MonthNarrow" to "MonthNarrows" change in CLDRConverter.java is > a piggy back fix. > > Webrev: > http://cr.openjdk.java.net/~okutsu/310/quartertext/webrev.01/ > > Thanks, > Masayoshi > From patrick.zhang at oracle.com Mon Mar 4 22:58:53 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Tue, 05 Mar 2013 14:58:53 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.MinguoChronology In-Reply-To: <512F148D.1060508@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> Message-ID: <513597AD.8080306@oracle.com> Hi Team, Please help to review new added test for missed api in java.time.chrono.MinguoChronology. As one initial review version, the webrev includes MinguoChronology only. Similar test logic will be applied to IsoChronology, HijrahChronology and JapaneseChronology in future webrev. Description: 1. check new factory method. |* date <../../../java/time/chrono/MinguoChronology.html#date%28java.time.chrono.Era,%20int,%20int,%20int%29>*(Era <../../../java/time/chrono/Era.html> era, int yearOfEra, int month, int dayOfMonth) ||*dateYearDay <../../../java/time/chrono/MinguoChronology.html#dateYearDay%28java.time.chrono.Era,%20int,%20int%29>*(Era <../../../java/time/chrono/Era.html> era, int yearOfEra, int dayOfYear)| 2. check now() related function in MinguoChronology and MinguoDate. |*dateNow <../../../java/time/chrono/MinguoChronology.html#dateNow%28%29>*()| |*dateNow <../../../java/time/chrono/MinguoChronology.html#dateNow%28java.time.Clock%29>*(Clock <../../../java/time/Clock.html> clock)| |*dateNow <../../../java/time/chrono/MinguoChronology.html#dateNow%28java.time.ZoneId%29>*(ZoneId <../../../java/time/ZoneId.html> zone)| 3. |check | <../../../java/time/chrono/MinguoChronology.html#localDateTime%28java.time.temporal.TemporalAccessor%29>|*localDateTime <../../../java/time/chrono/MinguoChronology.html#localDateTime%28java.time.temporal.TemporalAccessor%29>*(TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html> temporal)| and |*zonedDateTime <../../../java/time/chrono/MinguoChronology.html#localDateTime%28java.time.temporal.TemporalAccessor%29>*(TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html> temporal) In jsr310, we have 3 datetime classes which implements ||TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html>: LocalDateTime, OffsetDateTime and ZonedDateTime According to description in javadoc, all 3 classes can be used in ||*localDateTime <../../../java/time/chrono/MinguoChronology.html#localDateTime%28java.time.temporal.TemporalAccessor%29>*(TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html> temporal). But LocalDateTime can not be used in ||*zonedDateTime <../../../java/time/chrono/MinguoChronology.html#localDateTime%28java.time.temporal.TemporalAccessor%29>*(TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html> temporal) since it does not contain one Offset. All other ||TemporalAccessor <../../../java/time/temporal/TemporalAccessor.html> should throws DataTimeException for both methods.| | Above logic have been verified in test_localDateTime() and test_zonedDateTime(). ||4. check ||*zonedDateTime <../../../java/time/chrono/MinguoChronology.html#zonedDateTime%28java.time.Instant,%20java.time.ZoneId%29>*(Instant <../../../java/time/Instant.html> instant, ZoneId <../../../java/time/ZoneId.html> zone)| See test_Instant_zonedDateTime(). Similar with |test_zonedDateTime() webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/TestMinguoChronology.jtr Regards Patrick || | From patrick.zhang at oracle.com Mon Mar 4 23:34:12 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Tue, 05 Mar 2013 15:34:12 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.Era In-Reply-To: <513597AD.8080306@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> Message-ID: <51359FF4.70202@oracle.com> Hi Team, Please help to review new added case for java.time.chrono.Era. It only checkes Chronology.eras() equals with Era.values() simply. webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr Regards Patrick From masayoshi.okutsu at oracle.com Mon Mar 4 23:49:19 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Tue, 05 Mar 2013 07:49:19 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Quarter names (text) support. Resources are available in English only Message-ID: <20130305074944.B6A8F47835@hg.openjdk.java.net> Changeset: 6bc0e3a7a693 Author: okutsu Date: 2013-03-05 16:48 +0900 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6bc0e3a7a693 Quarter names (text) support. Resources are available in English only with the default locale provider (for now). ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! test/java/time/test/java/time/format/TestTextParser.java ! test/java/time/test/java/time/format/TestTextPrinter.java From scolebourne at joda.org Tue Mar 5 05:26:00 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 13:26:00 +0000 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.Era In-Reply-To: <51359FF4.70202@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com> Message-ID: You need a blank line at the end of each file. The "for(FooEra" part is missing a space between for" and "(FooEra" in each file The indentation within the last loop is too much (shoud be indented by 4). The tests themselves look fine, thanks Stephen On 5 March 2013 07:34, patrick zhang wrote: > Hi Team, > > Please help to review new added case for java.time.chrono.Era. It only > checkes Chronology.eras() equals with Era.values() simply. > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr > > Regards > Patrick From scolebourne at joda.org Tue Mar 5 05:32:05 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 13:32:05 +0000 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.MinguoChronology In-Reply-To: <513597AD.8080306@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> Message-ID: Looks good to me. thanks Stephen On 5 March 2013 06:58, patrick zhang wrote: > Hi Team, > > Please help to review new added test for missed api in > java.time.chrono.MinguoChronology. > As one initial review version, the webrev includes MinguoChronology only. > Similar test logic will be applied to IsoChronology, HijrahChronology and > JapaneseChronology in future webrev. > > Description: > 1. check new factory method. > date(Era era, int yearOfEra, int month, int dayOfMonth) > dateYearDay(Era era, int yearOfEra, int dayOfYear) > 2. check now() related function in MinguoChronology and MinguoDate. > dateNow() > dateNow(Clock clock) > dateNow(ZoneId zone) > 3. check localDateTime(TemporalAccessor temporal) and > zonedDateTime(TemporalAccessor temporal) > In jsr310, we have 3 datetime classes which implements TemporalAccessor: > LocalDateTime, OffsetDateTime and ZonedDateTime > According to description in javadoc, all 3 classes can be used in > localDateTime(TemporalAccessor temporal). But LocalDateTime can not be used > in zonedDateTime(TemporalAccessor temporal) since it does not contain one > Offset. All other TemporalAccessor should throws DataTimeException for both > methods. > Above logic have been verified in test_localDateTime() and > test_zonedDateTime(). > 4. check zonedDateTime(Instant instant, ZoneId zone) > See test_Instant_zonedDateTime(). Similar with test_zonedDateTime() > > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/MinguoChronology/TestMinguoChronology.jtr > > Regards > Patrick > From scolebourne at joda.org Tue Mar 5 05:37:34 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 13:37:34 +0000 Subject: [threeten-dev] Request for review: quarter text support In-Reply-To: <51330A40.6070108@oracle.com> References: <51330A40.6070108@oracle.com> Message-ID: Looks good to me. Stephen On 3 March 2013 08:30, Masayoshi Okutsu wrote: > I've added quarter text support. Actual names are supported in English only > under the default locale data provider. You can specify > -Djava.locale.provider=CLDR if localized names are required. I will add > localized names into the existing JRE resources (as separate resource > bundles) later if I have time. > > Also: > > - changed DateTimeFormatterBuilder.getLocalizedName to > DateTimeTextProvider.getLocalizedResource (package private). > > - changed TestTextParser/Printer to specify Locale.ROOT for string case > conversions in order to avoid any surprises with the Turkish locale. > > - the "MonthNarrow" to "MonthNarrows" change in CLDRConverter.java is a > piggy back fix. > > Webrev: > http://cr.openjdk.java.net/~okutsu/310/quartertext/webrev.01/ > > Thanks, > Masayoshi > From scolebourne at joda.org Tue Mar 5 05:49:10 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 13:49:10 +0000 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: <5134DFA5.2000600@oracle.com> References: <5134DFA5.2000600@oracle.com> Message-ID: I don't think this change can go in. The checkValidValue methods are public, and so can be called by anyone at any time in any way. The UTTE is intended for use when the Field or Unit passed in is unsupported by the target object. In these methods, the field is optional, and supported/not-supported is not a quality of the ValueRange class. Thus UTTE is just plain wrong to be thrown here. A correct fix would be to inline the code change into TemporalAccesor and anywhere else that has a similar use of the check method. If it is widely used, a package scoped method (in an appropriate location) may be a solution. thanks Stephen On 4 March 2013 17:53, roger riggs wrote: > Hi, > > A simple fix for the exception and message when TemporalAccessor.get() > is used (incorrectly) to retrieve Fields with long values. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > > Thanks, Roger > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > From scolebourne at joda.org Tue Mar 5 05:51:25 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 13:51:25 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: #273 PeriodUntil throws exception In-Reply-To: <5132537A.3050003@oracle.com> References: <20130302154330.03875477DF@hg.openjdk.java.net> <5132537A.3050003@oracle.com> Message-ID: That was the original intention (a small performance tweak). Doubt it really matters. Stephen On 2 March 2013 19:31, Xueming Shen wrote: > I guess the code before the change was intentionally to hide the > Objects.requireNoNull() > inside/after the "instanceof" check, so non-null && instanceof == true > "endDate" (99.9%+ > in real world scenario) would only take one "if" check. The > Objects.requreNoNull there > is only to give you an accurate error message. > > -Sherman > > > On 3/2/13 7:42 AM, roger.riggs at oracle.com wrote: >> >> Changeset: f90fd81415b6 >> Author: rriggs >> Date: 2013-03-02 10:42 -0500 >> URL: >> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f90fd81415b6 >> >> #273 PeriodUntil throws exception >> The periodUntil methods do not correctly compute the period >> for HijrahDate, ThaiBuddistDate, MinguoDate, and JapaneseDate. >> ChronoDateImpl is enhanced to support 12 month based calendars. >> >> Added simple tests to TestHijrahChronology, TestJapaneseChronology, >> TestMinguoChronology, and TestHijrahChronology >> >> ! src/share/classes/java/time/LocalDate.java >> ! src/share/classes/java/time/chrono/ChronoDateImpl.java >> ! src/share/classes/java/time/chrono/ChronoLocalDate.java >> ! test/java/time/tck/java/time/chrono/TestHijrahChronology.java >> ! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java >> ! test/java/time/tck/java/time/chrono/TestMinguoChronology.java >> ! test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java >> > From scolebourne at joda.org Tue Mar 5 06:02:00 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 14:02:00 +0000 Subject: [threeten-dev] Review of javadoc updates In-Reply-To: <51322D4E.6050304@oracle.com> References: <51322D4E.6050304@oracle.com> Message-ID: I don't like the » as it makes it a lot harder to read as source code (which is more common than reading HTML). Is there an alternative arrow like symbol we could use, such a => or just a colon? This phrase reads badly "Pattern letter 'u' is the proleptic year which is the same as the CLDR definition extended year, instead the SimpleDateFormat definition for numeric day of week." In the example table for the public constants, it would be good to have two examples when there is a choice: ISO_DATE ... '2011-12-03'; '2011-12-03+01:00' The description of the pattern letters needs more work to match SimpleDateFormat (and that in builder altering to match letters to methods), but that is a separate change. thanks Stephen On 2 March 2013 16:48, roger riggs wrote: > Hi, > > This javadoc-only change raises the visiblity and enhances the > descriptions of the DateTimeFormatter patterns and fixes a number > of complaints that the javadoc tool has about the html markup. > > https://github.com/ThreeTen/threeten/issues/240 > > webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ > > javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > From scolebourne at joda.org Tue Mar 5 06:05:03 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 14:05:03 +0000 Subject: [threeten-dev] Non-webrev: Part one of better date parsing In-Reply-To: References: <512E5934.3080900@oracle.com> Message-ID: This patch is needed to fix Japanese era parsing and allow day-of-year to change its meaning (if that is so decided). Can it be pushed? Stephen On 27 February 2013 22:11, Stephen Colebourne wrote: > I envisage a boolean flag indicating strict/lenient, passed to > TemporalField and Chronology. > > I don't think that affects this patch, which is simply locating the > builder code in the right location - ChronoField is by definition > meaningless without the chronology, so thats where the logic has to > sit. > > Stephen > > > On 27 February 2013 19:06, roger riggs wrote: >> Hi Stephen, >> >> To extend it will require that the semantics of various leniency levels >> would be >> propagated to the Chronology. It would be better if the leniency >> concepts can be self contained in the parser. In related cases, the >> dates are corrected to the "previous valid" date. >> >> Roger >> >> >> On 2/27/2013 11:37 AM, Stephen Colebourne wrote: >>> >>> Issue: #268 >>> Patch: https://gist.github.com/jodastephen/5049319 >>> >>> This can then be extended to "fix" the stricter Japanese era >>> requirements, and add lenient/strict resolving in general. >>> >>> Stephen >> >> From scolebourne at joda.org Tue Mar 5 06:08:37 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 5 Mar 2013 14:08:37 +0000 Subject: [threeten-dev] Review fix for periodUntil issue 273 In-Reply-To: <51313234.5050505@oracle.com> References: <5130F28D.5090105@oracle.com> <51310419.2070603@oracle.com> <51313234.5050505@oracle.com> Message-ID: I would not have added the check to ensure a 12 month year (I'd just rely on Javadoc rather than slowing user code). Personally, I'd like to see the use of "public abstract" on all methods in interfaces where there is at least one "default" ("public default") method. This should be adopted as a new coding standard by Oracle in the light of the trait-like design of default methods in interfaces. thanks Stephen On 1 March 2013 22:56, roger riggs wrote: > Revised the webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/ > > Thanks, Roger > > > On 3/1/2013 2:40 PM, Xueming Shen wrote: >> >> while we are on this, it appears two ChronoLocalDate.periodUntil() methods >> are declared as "public abstract ...", any particular reason to do that? >> or just >> a "leftover" of the previous life of CLD as an abstract class, instead of >> an interface >> now? >> >> On 03/01/2013 10:25 AM, Xueming Shen wrote: >>> >>> >>> On 3/1/13 9:41 AM, Xueming Shen wrote: >>>> >>>> -ChronoDateImple.periodUntil(t, u) >>>> The "convention" is to align the "case" to the "switch" in jdk source >>>> code? >>>> >>>> - Understood it is kinda of 310 convention to have "... == false", but I >>>> would suggest to >>>> use the the normal (! X) instead. >>>> >>>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed >>>> using the chronology >>>> of this date. If necessary, the input date will be converted to match" >>>> (btw, there are two >>>> "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle >>>> "same type" of CLD >>> >>> >>> I meant to say 3. >>> >>> >>>> now, (their java doc currently simply is inherited from the super >>>> class). Is it possible to have >>>> a better alternative? at least they all have a isodate. >>>> >>>> -Sherman >>>> > From roger.riggs at oracle.com Tue Mar 5 08:16:42 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 05 Mar 2013 11:16:42 -0500 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: References: <5134DFA5.2000600@oracle.com> Message-ID: <51361A6A.3030204@oracle.com> Hi, Makes sense. I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. The @throws clauses were slightly out of alignment with TemporalAccessor.get. To make it simplier to maintain the implementers now use {@inheritDoc}. The ValueRange.checkValidIntValue exception message is updated to more informative. Updated webrev: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ Thanks, Roger On 3/5/2013 8:49 AM, Stephen Colebourne wrote: > I don't think this change can go in. > > The checkValidValue methods are public, and so can be called by anyone > at any time in any way. The UTTE is intended for use when the Field or > Unit passed in is unsupported by the target object. In these methods, > the field is optional, and supported/not-supported is not a quality of > the ValueRange class. Thus UTTE is just plain wrong to be thrown here. > > A correct fix would be to inline the code change into TemporalAccesor > and anywhere else that has a similar use of the check method. If it is > widely used, a package scoped method (in an appropriate location) may > be a solution. > > thanks > Stephen > > > > On 4 March 2013 17:53, roger riggs wrote: >> Hi, >> >> A simple fix for the exception and message when TemporalAccessor.get() >> is used (incorrectly) to retrieve Fields with long values. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> >> Thanks, Roger >> >> From roger.riggs at oracle.com Tue Mar 5 09:42:28 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 05 Mar 2013 12:42:28 -0500 Subject: [threeten-dev] Non-webrev: Part one of better date parsing In-Reply-To: References: <512E5934.3080900@oracle.com> Message-ID: <51362E84.2090004@oracle.com> hi, I don't have a better alternative. Dealing with the map is pretty heavyweight but fits the parser model. I'd have rather seen that code in the type that was being constructed (like a lenient "from" method) and using the TemporalAccessor and isSupported. But this is headed in a useful direction. So yes, push. Roger On 3/5/2013 9:05 AM, Stephen Colebourne wrote: > This patch is needed to fix Japanese era parsing and allow day-of-year > to change its meaning (if that is so decided). Can it be pushed? > Stephen > > > On 27 February 2013 22:11, Stephen Colebourne wrote: >> I envisage a boolean flag indicating strict/lenient, passed to >> TemporalField and Chronology. >> >> I don't think that affects this patch, which is simply locating the >> builder code in the right location - ChronoField is by definition >> meaningless without the chronology, so thats where the logic has to >> sit. >> >> Stephen >> >> >> On 27 February 2013 19:06, roger riggs wrote: >>> Hi Stephen, >>> >>> To extend it will require that the semantics of various leniency levels >>> would be >>> propagated to the Chronology. It would be better if the leniency >>> concepts can be self contained in the parser. In related cases, the >>> dates are corrected to the "previous valid" date. >>> >>> Roger >>> >>> >>> On 2/27/2013 11:37 AM, Stephen Colebourne wrote: >>>> Issue: #268 >>>> Patch: https://gist.github.com/jodastephen/5049319 >>>> >>>> This can then be extended to "fix" the stricter Japanese era >>>> requirements, and add lenient/strict resolving in general. >>>> >>>> Stephen >>> -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From roger.riggs at oracle.com Tue Mar 5 13:32:30 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 05 Mar 2013 16:32:30 -0500 Subject: [threeten-dev] Add standalone text styles Message-ID: <5136646E.8060005@oracle.com> Please review this addition to add TextStyle enum values for standalone versions of FULL, SHORT, NARROW to support CLDR defined patterns. http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ More work is needed after the public API is defined. Thanks, Roger From roger.riggs at oracle.com Tue Mar 5 14:50:08 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 05 Mar 2013 17:50:08 -0500 Subject: [threeten-dev] [threeten-develop] DisplayNames for field names In-Reply-To: References: <51324CDA.7060108@oracle.com> Message-ID: <513676A0.5010608@oracle.com> Hi, On 3/5/2013 8:42 AM, Stephen Colebourne wrote: > Not sure that the aligned-week-of-year should be assigned the "week" key. Probably not best. For most fields CLDR does not have locale specific data. Corresponds to the CLDR 'w' week-of-year and would be appropriate for IsoFields.WEEK_OF_WEEK_BASED_YEAR and WeekFields.weekOfYear(). Updated: webrev: http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ Roger > > The ChronoField implementation should throw NPE is loclae is null, > which requires an Objects.requireNotNull and a test. > > Otherwise good. > thanks > Stephen > > > On 2 March 2013 19:02, roger riggs > wrote: > > Hi, > > Issue#103 requests > locale based display names for field names. > The data is available and it only needs a > TemporalField/ChronoField.getDisplayName > method plus a little plumbing. > > Please review and comment: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > > > javadoc: TemporalField and ChronoField: > http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ > > From xueming.shen at oracle.com Tue Mar 5 15:41:23 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Mar 2013 15:41:23 -0800 Subject: [threeten-dev] Ser performance Message-ID: <513682A3.2050408@oracle.com> Just tried a non-scientific performance measurement on the proxy pattern used by the Ser spec/impl, here is the data from the simple benchmark SerTest.java. It appears the (1) expected slowdown is obvious on the serialization side, particular in LocalTime (2) the de-serialization side may be just fine. http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/ http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/SerTest.java ---------------------Proxy pattern---------------- java SerTest 1000 --------LocalDate-------- serSize=16 Writing: 6655 Reading: 3224 --------LocalTime-------- serSize=17 Writing: 6125 Reading: 2937 --------LocalDateTime-------- serSize=23 Writing: 6188 Reading: 3383 ---------------------Simple/direct serialization------- --------LocalDate-------- serSize=14 Writing: 3418 Reading: 3836 --------LocalTime-------- serSize=13 Writing: 2756 Reading: 2358 --------LocalDateTime-------- serSize=22 Writing: 3266 Reading: 4407 From roger.riggs at oracle.com Tue Mar 5 19:08:54 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 06 Mar 2013 03:08:54 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20130306030941.6A3824787C@hg.openjdk.java.net> Changeset: 3f42e3384647 Author: rriggs Date: 2013-02-27 15:31 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3f42e3384647 Updated html markup flagged by javadoc as problematic: - changed "->" in comments to » - removed

that were not properly nested - escaped "" to be <?> corrected javadoc reference to IllegalCalenarFieldValueException to DateTimeException ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 86c7ad8dbf5a Author: rriggs Date: 2013-03-05 21:48 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/86c7ad8dbf5a #240 DateTimeFormatter pattern javadoc. Moved the description of the patterns to the class javadoc and added a summary of the predefined formatters. Updated comments in appendPattern about the changes relative to SimpleDateFormat and CLDR. ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: f0fbbf624594 Author: rriggs Date: 2013-03-05 22:07 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f0fbbf624594 Merge ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java From masayoshi.okutsu at oracle.com Tue Mar 5 19:31:26 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 06 Mar 2013 12:31:26 +0900 Subject: [threeten-dev] Add standalone text styles In-Reply-To: <5136646E.8060005@oracle.com> References: <5136646E.8060005@oracle.com> Message-ID: <5136B88E.7020108@oracle.com> Here are my comments. - LDML (UTS#35) calls non-stand-alone styles format styles (forms) rather than normal styles. I prefer to follow the LDML naming. - I suspect that it's hard for most developers to understand the differences between the "normal" and stand-alone constants from the descriptions. The examples are the same ones, like "Monday". - It happens to work if you use DateFormat styles as an index to the time zone names array. But it's not correct to use DateFormat styles. - TBD part: Calendar defines both format and standalone styles to which the TextStyles need to map. If you add the standalone constants to TextStyle, I can take care of the rest. Masayoshi On 3/6/2013 6:32 AM, roger riggs wrote: > Please review this addition to add TextStyle enum values for > standalone versions > of FULL, SHORT, NARROW to support CLDR defined patterns. > > http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ > > More work is needed after the public API is defined. > > Thanks, Roger > From Roger.Riggs at Oracle.com Tue Mar 5 19:39:49 2013 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 05 Mar 2013 22:39:49 -0500 Subject: [threeten-dev] Review of javadoc updates In-Reply-To: References: <51322D4E.6050304@oracle.com> Message-ID: <5136BA85.1020403@Oracle.com> Hi, On 03/05/2013 09:02 AM, Stephen Colebourne wrote: > I don't like the » as it makes it a lot harder to read as source > code (which is more common than reading HTML). Is there an alternative > arrow like symbol we could use, such a => or just a colon? The unbalanced ">" is flagged as an error, so something else is needed. I replaced the delimiter with "--"; the lines in Duration include the phrase "parses as" that can act as a delimiter. > > This phrase reads badly > "Pattern letter 'u' is the proleptic year which is the same as the > CLDR definition extended year, instead the SimpleDateFormat definition > for numeric day of week." Reworded to remove the reference to CLDR, its unneeded. We may want to separately describe differences the relationship to CLDR. > > In the example table for the public constants, it would be good to > have two examples when there is a choice: > ISO_DATE ... '2011-12-03'; '2011-12-03+01:00' Added examples. Thanks, Roger > > The description of the pattern letters needs more work to match > SimpleDateFormat (and that in builder altering to match letters to > methods), but that is a separate change. > > thanks > Stephen > > > On 2 March 2013 16:48, roger riggs wrote: >> Hi, >> >> This javadoc-only change raises the visiblity and enhances the >> descriptions of the DateTimeFormatter patterns and fixes a number >> of complaints that the javadoc tool has about the html markup. >> >> https://github.com/ThreeTen/threeten/issues/240 >> >> webrev: http://cr.openjdk.java.net/~rriggs/webrev-pattern-javadoc-240/ >> >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-pattern-javadoc-240/ >> >> -- >> Thanks, Roger >> >> Oracle Java Platform Group >> >> Green Oracle Oracle is committed to >> developing practices and products that help protect the environment >> From patrick.zhang at oracle.com Tue Mar 5 20:47:36 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Wed, 06 Mar 2013 12:47:36 +0800 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.Era In-Reply-To: References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com> Message-ID: <5136CA68.9090402@oracle.com> Hi Stephen, Sorry for the bad format of new files. :). Now it is updated. Is it ok? webrev: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ test result: http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKThaiBuddhistEra.jtr Regards Patrick On 3/5/13 9:26 PM, Stephen Colebourne wrote: > You need a blank line at the end of each file. > > The "for(FooEra" part is missing a space between for" and "(FooEra" in each file > > The indentation within the last loop is too much (shoud be indented by 4). > > The tests themselves look fine, > thanks > Stephen > > > On 5 March 2013 07:34, patrick zhang wrote: >> Hi Team, >> >> Please help to review new added case for java.time.chrono.Era. It only >> checkes Chronology.eras() equals with Era.values() simply. >> >> webrev: >> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ >> >> test result: >> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr >> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr >> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr >> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr >> >> Regards >> Patrick From Roger.Riggs at Oracle.com Tue Mar 5 21:04:46 2013 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 06 Mar 2013 00:04:46 -0500 Subject: [threeten-dev] Add standalone text styles In-Reply-To: <5136B88E.7020108@oracle.com> References: <5136646E.8060005@oracle.com> <5136B88E.7020108@oracle.com> Message-ID: <5136CE6E.8040007@Oracle.com> Hi, Thanks for the comments. On 03/05/2013 10:31 PM, Masayoshi Okutsu wrote: > Here are my comments. > > - LDML (UTS#35) calls non-stand-alone styles format styles (forms) > rather than normal styles. I prefer to follow the LDML naming. Updated to use CLDR friendly terminology. > > - I suspect that it's hard for most developers to understand the > differences between the "normal" and stand-alone constants from the > descriptions. The examples are the same ones, like "Monday". The explanation can be expanded with more examples. > > - It happens to work if you use DateFormat styles as an index to the > time zone names array. But it's not correct to use DateFormat styles. I could not checkin something that didn't work. I replaced the DateFormat references with literals. But it was quite unclear where the values were defined in the implementation. There was some very brittle code dependent on the enum values. > > - TBD part: Calendar defines both format and standalone styles to > which the TextStyles need to map. > > If you add the standalone constants to TextStyle, I can take care of > the rest. ok, I'll push, but there may still be some additional comments about the public API. Roger > > Masayoshi > > On 3/6/2013 6:32 AM, roger riggs wrote: >> Please review this addition to add TextStyle enum values for >> standalone versions >> of FULL, SHORT, NARROW to support CLDR defined patterns. >> >> http://cr.openjdk.java.net/~rriggs/webrev-addstandalone/ >> >> More work is needed after the public API is defined. >> >> Thanks, Roger >> > From roger.riggs at oracle.com Tue Mar 5 21:03:05 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 06 Mar 2013 05:03:05 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130306050344.637D94787D@hg.openjdk.java.net> Changeset: e64803b886e3 Author: rriggs Date: 2013-03-05 23:58 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e64803b886e3 #64 Need TextStyles for Standalone patterns.

Added FULL_STANDALONE, SHORT_STANDALONE, NARROW_STANDALONE to the enum and methods isStandalone, asStandalone(), and asNormal as useful conversions. ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/format/TextStyle.java + test/java/time/tck/java/time/format/TCKTextStyle.java Changeset: 5fb3bd515044 Author: rriggs Date: 2013-03-06 00:02 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5fb3bd515044 Merge ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java From scolebourne at joda.org Wed Mar 6 00:51:26 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Mar 2013 08:51:26 +0000 Subject: [threeten-dev] [threeten-develop] DisplayNames for field names In-Reply-To: <513676A0.5010608@oracle.com> References: <51324CDA.7060108@oracle.com> <513676A0.5010608@oracle.com> Message-ID: The default method in TemporalField still needs changing to check for null locale. Otherwise good to push. Stephen On 5 March 2013 22:50, roger riggs wrote: > Hi, > > > On 3/5/2013 8:42 AM, Stephen Colebourne wrote: > > Not sure that the aligned-week-of-year should be assigned the "week" key. > > Probably not best. For most fields CLDR does not have locale specific data. > > Corresponds to the CLDR 'w' week-of-year and would be appropriate > for IsoFields.WEEK_OF_WEEK_BASED_YEAR and WeekFields.weekOfYear(). > > Updated: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ > > > Roger > > > The ChronoField implementation should throw NPE is loclae is null, which > requires an Objects.requireNotNull and a test. > > Otherwise good. > thanks > Stephen > > > On 2 March 2013 19:02, roger riggs wrote: >> >> Hi, >> >> Issue #103 requests locale based display names for field names. >> The data is available and it only needs a >> TemporalField/ChronoField.getDisplayName >> method plus a little plumbing. >> >> Please review and comment: >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-field-displayname-103/ >> >> javadoc: TemporalField and ChronoField: >> http://cr.openjdk.java.net/~rriggs/javadoc-field-displayname-103/ >> >> > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop > From scolebourne at joda.org Wed Mar 6 00:58:27 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Mar 2013 08:58:27 +0000 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: <51361A6A.3030204@oracle.com> References: <5134DFA5.2000600@oracle.com> <51361A6A.3030204@oracle.com> Message-ID: I hate the inheritDoc change. Is it done this way anywhere else in the JDK (I don't think so). While I accept it may be easier for maintainers, it is far worse for most developers who are just reading the Javadoc as source code (having hit F3 in Eclipse to jump to the source code of the method they are working with). While the HTML tool can hunt down the inheritDoc, regular users cannot. The inlined code looks OK, however the Javadoc of the method is now wrong as it specifies the implementation. thanks Stephen On 5 March 2013 16:16, roger riggs wrote: > Hi, > > Makes sense. > > I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. > The @throws clauses were slightly out of alignment with > TemporalAccessor.get. > To make it simplier to maintain the implementers now use {@inheritDoc}. > The ValueRange.checkValidIntValue exception message is updated to more > informative. > > Updated webrev: > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ > javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ > > Thanks, Roger > > On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >> I don't think this change can go in. >> >> The checkValidValue methods are public, and so can be called by anyone >> at any time in any way. The UTTE is intended for use when the Field or >> Unit passed in is unsupported by the target object. In these methods, >> the field is optional, and supported/not-supported is not a quality of >> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >> >> A correct fix would be to inline the code change into TemporalAccesor >> and anywhere else that has a similar use of the check method. If it is >> widely used, a package scoped method (in an appropriate location) may >> be a solution. >> >> thanks >> Stephen >> >> >> >> On 4 March 2013 17:53, roger riggs wrote: >>> Hi, >>> >>> A simple fix for the exception and message when TemporalAccessor.get() >>> is used (incorrectly) to retrieve Fields with long values. >>> >>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>> >>> Thanks, Roger >>> >>> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop From scolebourne at joda.org Wed Mar 6 01:11:40 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Mar 2013 09:11:40 +0000 Subject: [threeten-dev] Ser performance In-Reply-To: <513682A3.2050408@oracle.com> References: <513682A3.2050408@oracle.com> Message-ID: See also http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html The format focusses on reducing the size of a single object, by reducing the header (short class name Ser), sharing the header (shared between all classes in the same package) and an optimal data format (although it could be reduced more, 2 byte saving in LocalDate would be easy). Your test averages the message size over 1000 stores, which naturally ignores the cost of the header. But its the header cost which dominates in typical application messages. Your test also doesn't place multiple classes from the same package in the same stream, say 2 LocalDates, 2 LocalTimes a Period and a Duration. The Ser approach should shine there. Your "simple" version is still quite advanced, using the Unsafe class. The simplest serialization would simply be to have no readObject writeObject other than for validation. I don't understand why LocalTime size would be larger and speed slower than the alternative. Stephen On 5 March 2013 23:41, Xueming Shen wrote: > Just tried a non-scientific performance measurement on the proxy pattern > used by the Ser spec/impl, here is the data from the simple benchmark > SerTest.java. > > It appears the > (1) expected slowdown is obvious on the serialization side, particular in > LocalTime > (2) the de-serialization side may be just fine. > > http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/ > http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/SerTest.java > > ---------------------Proxy pattern---------------- > java SerTest 1000 > --------LocalDate-------- > serSize=16 > Writing: 6655 > Reading: 3224 > --------LocalTime-------- > serSize=17 > Writing: 6125 > Reading: 2937 > --------LocalDateTime-------- > serSize=23 > Writing: 6188 > Reading: 3383 > > ---------------------Simple/direct serialization------- > --------LocalDate-------- > serSize=14 > Writing: 3418 > Reading: 3836 > --------LocalTime-------- > serSize=13 > Writing: 2756 > Reading: 2358 > --------LocalDateTime-------- > serSize=22 > Writing: 3266 > Reading: 4407 > From scolebourne at joda.org Wed Mar 6 01:17:32 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Mar 2013 09:17:32 +0000 Subject: [threeten-dev] Please help to review new test cases for java.time.chrono.Era In-Reply-To: <5136CA68.9090402@oracle.com> References: <50EFCCF6.50300@oracle.com> <50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com> <50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com> <5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com> <512343C3.70805@oracle.com> <5123470A.4060406@oracle.com> <512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com> <5136CA68.9090402@oracle.com> Message-ID: Fine by me. thanks Stephen On 6 March 2013 04:47, Patrick Zhang wrote: > Hi Stephen, > > Sorry for the bad format of new files. :). Now it is updated. > Is it ok? > > > webrev: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ > > test result: > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr > http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKThaiBuddhistEra.jtr > > Regards > Patrick > > > On 3/5/13 9:26 PM, Stephen Colebourne wrote: >> >> You need a blank line at the end of each file. >> >> The "for(FooEra" part is missing a space between for" and "(FooEra" in >> each file >> >> The indentation within the last loop is too much (shoud be indented by 4). >> >> The tests themselves look fine, >> thanks >> Stephen >> >> >> On 5 March 2013 07:34, patrick zhang wrote: >>> >>> Hi Team, >>> >>> Please help to review new added case for java.time.chrono.Era. It only >>> checkes Chronology.eras() equals with Era.values() simply. >>> >>> webrev: >>> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/webrev/ >>> >>> test result: >>> >>> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKHijrahEra.jtr >>> >>> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKIsoEra.jtr >>> >>> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKJapaneseEra.jtr >>> >>> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/chrono/Era/TCKMinguoEra.jtr >>> >>> Regards >>> Patrick From scolebourne at joda.org Wed Mar 6 03:30:43 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 06 Mar 2013 11:30:43 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets Message-ID: <20130306113135.5B60C47892@hg.openjdk.java.net> Changeset: ac8dfa77cb91 Author: scolebourne Date: 2013-02-27 16:34 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ac8dfa77cb91 Move date resolution to Chronology See #268 ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/format/DateTimeBuilder.java Changeset: 1e9038f5673c Author: scolebourne Date: 2013-03-06 10:30 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1e9038f5673c Merge ! src/share/classes/java/time/format/DateTimeBuilder.java Changeset: d35363a56057 Author: scolebourne Date: 2013-03-06 11:07 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d35363a56057 Fix formatting and enhance Javadoc ! src/share/classes/java/time/format/DateTimeFormatter.java From roger.riggs at oracle.com Wed Mar 6 05:14:38 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 06 Mar 2013 13:14:38 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130306131515.86DB547896@hg.openjdk.java.net> Changeset: eb9ab11c1f2b Author: rriggs Date: 2013-03-06 08:07 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/eb9ab11c1f2b #103 TemporalField.getDisplayName(locale). Implemented to allow ChronoField names to be translated to Locale specific terminology. ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java + test/java/time/test/java/time/temporal/TestChronoField.java Changeset: 8bcb175e7159 Author: rriggs Date: 2013-03-06 08:14 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8bcb175e7159 Merge From roger.riggs at oracle.com Wed Mar 6 07:42:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 06 Mar 2013 10:42:52 -0500 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: References: <5134DFA5.2000600@oracle.com> <51361A6A.3030204@oracle.com> Message-ID: <513763FC.2050708@oracle.com> Hi Stephen, On 3/6/2013 3:58 AM, Stephen Colebourne wrote: > I hate the inheritDoc change. Is it done this way anywhere else in the > JDK (I don't think so). While I accept it may be easier for > maintainers, it is far worse for most developers who are just reading > the Javadoc as source code (having hit F3 in Eclipse to jump to the > source code of the method they are working with). While the HTML tool > can hunt down the inheritDoc, regular users cannot. I count 94 classes in src/share/classes/java that use {@inheridDoc}, mostly for exception text on @throws clauses. (mostly in AWT and in collections.) I don't usually develop with the JDK source (as an application developer), there is too much a chance of depending on an implementation, not the spec but I can see the point. We also have quite a number of subclass methods that just say @Override and have no source for the javadoc at all. I can put them back but to me it is more useful to know that the semantics of the exceptions are the unchanged (subclasses rarely change the exception semantics). > > The inlined code looks OK, however the Javadoc of the method is now > wrong as it specifies the implementation. I don't see the difference from the previous text. The conditions from separate @throws have been combined. Both new and old text define the conditions under which the exception is thrown and which exception. Roger > > thanks > Stephen > > > On 5 March 2013 16:16, roger riggs wrote: >> Hi, >> >> Makes sense. >> >> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. >> The @throws clauses were slightly out of alignment with >> TemporalAccessor.get. >> To make it simplier to maintain the implementers now use {@inheritDoc}. >> The ValueRange.checkValidIntValue exception message is updated to more >> informative. >> >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ >> >> Thanks, Roger >> >> On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >>> I don't think this change can go in. >>> >>> The checkValidValue methods are public, and so can be called by anyone >>> at any time in any way. The UTTE is intended for use when the Field or >>> Unit passed in is unsupported by the target object. In these methods, >>> the field is optional, and supported/not-supported is not a quality of >>> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >>> >>> A correct fix would be to inline the code change into TemporalAccesor >>> and anywhere else that has a similar use of the check method. If it is >>> widely used, a package scoped method (in an appropriate location) may >>> be a solution. >>> >>> thanks >>> Stephen >>> >>> >>> >>> On 4 March 2013 17:53, roger riggs wrote: >>>> Hi, >>>> >>>> A simple fix for the exception and message when TemporalAccessor.get() >>>> is used (incorrectly) to retrieve Fields with long values. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>>> >>>> Thanks, Roger >>>> >>>> From scolebourne at joda.org Wed Mar 6 08:00:45 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Mar 2013 16:00:45 +0000 Subject: [threeten-dev] Non webrev: parsing builder classes Message-ID: Extract Parsed class from DTParseContext Merge with DateTimeBuilder Refactor and adjust processing order Add proper cross-check, fixing TODO https://gist.github.com/jodastephen/5100331 As always, I'm effectively blocked for further development while waiting approval. thanks Stephen From xueming.shen at oracle.com Wed Mar 6 09:18:10 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Mar 2013 09:18:10 -0800 Subject: [threeten-dev] Non webrev: parsing builder classes In-Reply-To: References: Message-ID: <51377A52.6040909@oracle.com> took a quick scan, looks fine. On 03/06/2013 08:00 AM, Stephen Colebourne wrote: > Extract Parsed class from DTParseContext > Merge with DateTimeBuilder > Refactor and adjust processing order > Add proper cross-check, fixing TODO > > https://gist.github.com/jodastephen/5100331 > > As always, I'm effectively blocked for further development while > waiting approval. > thanks > Stephen From xueming.shen at oracle.com Wed Mar 6 09:41:29 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Mar 2013 09:41:29 -0800 Subject: [threeten-dev] Ser performance In-Reply-To: References: <513682A3.2050408@oracle.com> Message-ID: <51377FC9.5090608@oracle.com> On 03/06/2013 01:11 AM, Stephen Colebourne wrote: > See also > http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html > > The format focusses on reducing the size of a single object, by > reducing the header (short class name Ser), sharing the header (shared > between all classes in the same package) and an optimal data format > (although it could be reduced more, 2 byte saving in LocalDate would > be easy). > > Your test averages the message size over 1000 stores, which naturally > ignores the cost of the header. But its the header cost which > dominates in typical application messages. Understood the deliberation of using Ser for the class desp saving. I'm not sure which user case, bulk data transferring or single date sending/receiving, is more important in real application world. > Your test also doesn't place multiple classes from the same package in > the same stream, say 2 LocalDates, 2 LocalTimes a Period and a > Duration. The Ser approach should shine there. > > Your "simple" version is still quite advanced, using the Unsafe class. > The simplest serialization would simply be to have no readObject > writeObject other than for validation. > The Unsafe is mainly for the "final" fields, a workaround for that long-waiting rfe of easy-serialization vs final field. -Sherman > I don't understand why LocalTime size would be larger and speed slower > than the alternative. > > Stephen > > > > On 5 March 2013 23:41, Xueming Shen wrote: >> Just tried a non-scientific performance measurement on the proxy pattern >> used by the Ser spec/impl, here is the data from the simple benchmark >> SerTest.java. >> >> It appears the >> (1) expected slowdown is obvious on the serialization side, particular in >> LocalTime >> (2) the de-serialization side may be just fine. >> >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/ >> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serPerm/SerTest.java >> >> ---------------------Proxy pattern---------------- >> java SerTest 1000 >> --------LocalDate-------- >> serSize=16 >> Writing: 6655 >> Reading: 3224 >> --------LocalTime-------- >> serSize=17 >> Writing: 6125 >> Reading: 2937 >> --------LocalDateTime-------- >> serSize=23 >> Writing: 6188 >> Reading: 3383 >> >> ---------------------Simple/direct serialization------- >> --------LocalDate-------- >> serSize=14 >> Writing: 3418 >> Reading: 3836 >> --------LocalTime-------- >> serSize=13 >> Writing: 2756 >> Reading: 2358 >> --------LocalDateTime-------- >> serSize=22 >> Writing: 3266 >> Reading: 4407 >> From scolebourne at joda.org Wed Mar 6 10:42:19 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 06 Mar 2013 18:42:19 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets Message-ID: <20130306184401.4DD29478AA@hg.openjdk.java.net> Changeset: c88c08f0effb Author: scolebourne Date: 2013-03-06 11:47 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c88c08f0effb Rename instance variable ! src/share/classes/java/time/format/DateTimeBuilder.java Changeset: e5c9a73cbf0f Author: scolebourne Date: 2013-03-06 12:14 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e5c9a73cbf0f Simplify method calls during parse resolution Hides the builder even more ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeParseContext.java Changeset: b60304856d2e Author: scolebourne Date: 2013-03-06 12:48 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b60304856d2e Make Parsed class TemporalAccessor rather than DTParseContext Change is better OO and avoids repeated calls to currentParsed() Promote Parsed to top-level as class now larger Allows DTBuidler to be merged into Parsed ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeParseContext.java + src/share/classes/java/time/format/Parsed.java Changeset: af26fda82574 Author: scolebourne Date: 2013-03-06 15:12 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/af26fda82574 Move DateTimeBuilder logic into Parsed Puts main resolving code in one place ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/IsoChronology.java - src/share/classes/java/time/format/DateTimeBuilder.java ! src/share/classes/java/time/format/Parsed.java Changeset: b5303ddfd0a1 Author: scolebourne Date: 2013-03-06 15:55 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b5303ddfd0a1 Add proper cross-check at the end of parsing ! src/share/classes/java/time/format/Parsed.java Changeset: 02fd28e54a51 Author: scolebourne Date: 2013-03-06 18:38 +0000 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/02fd28e54a51 Merge From roger.riggs at oracle.com Wed Mar 6 11:17:31 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 06 Mar 2013 19:17:31 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: #187 Fractional second formatting; add # as a reserved character Message-ID: <20130306191758.50EFE478AB@hg.openjdk.java.net> Changeset: be58b440da51 Author: rriggs Date: 2013-03-06 14:16 -0500 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/be58b440da51 #187 Fractional second formatting; add # as a reserved character ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java From roger.riggs at oracle.com Wed Mar 6 13:27:54 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 06 Mar 2013 16:27:54 -0500 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: References: <5134DFA5.2000600@oracle.com> <51361A6A.3030204@oracle.com> Message-ID: <5137B4DA.9040304@oracle.com> Hi, Reverted the javadoc for @inheritDoc; the overridden methods all have the same @throws clauses. Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ Roger On 3/6/2013 3:58 AM, Stephen Colebourne wrote: > I hate the inheritDoc change. Is it done this way anywhere else in the > JDK (I don't think so). While I accept it may be easier for > maintainers, it is far worse for most developers who are just reading > the Javadoc as source code (having hit F3 in Eclipse to jump to the > source code of the method they are working with). While the HTML tool > can hunt down the inheritDoc, regular users cannot. > > The inlined code looks OK, however the Javadoc of the method is now > wrong as it specifies the implementation. > > thanks > Stephen > > > On 5 March 2013 16:16, roger riggs wrote: >> Hi, >> >> Makes sense. >> >> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get. >> The @throws clauses were slightly out of alignment with >> TemporalAccessor.get. >> To make it simplier to maintain the implementers now use {@inheritDoc}. >> The ValueRange.checkValidIntValue exception message is updated to more >> informative. >> >> Updated webrev: >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/ >> >> Thanks, Roger >> >> On 3/5/2013 8:49 AM, Stephen Colebourne wrote: >>> I don't think this change can go in. >>> >>> The checkValidValue methods are public, and so can be called by anyone >>> at any time in any way. The UTTE is intended for use when the Field or >>> Unit passed in is unsupported by the target object. In these methods, >>> the field is optional, and supported/not-supported is not a quality of >>> the ValueRange class. Thus UTTE is just plain wrong to be thrown here. >>> >>> A correct fix would be to inline the code change into TemporalAccesor >>> and anywhere else that has a similar use of the check method. If it is >>> widely used, a package scoped method (in an appropriate location) may >>> be a solution. >>> >>> thanks >>> Stephen >>> >>> >>> >>> On 4 March 2013 17:53, roger riggs wrote: >>>> Hi, >>>> >>>> A simple fix for the exception and message when TemporalAccessor.get() >>>> is used (incorrectly) to retrieve Fields with long values. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/ >>>> >>>> Thanks, Roger >>>> >>>> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> threeten-develop mailing list >> threeten-develop at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > threeten-develop mailing list > threeten-develop at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Wed Mar 6 15:46:37 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Mar 2013 15:46:37 -0800 Subject: [threeten-dev] Minor performance tuning for LocalDate.of(int, int, int) Message-ID: <5137D55D.6050107@oracle.com> (1) LocalDate.of(int, int, int) appears to create a use-and-throw "Month" object for validation purse only, it can be "saved" with a hard-coded Month.length, something worth doing? given we are talking about "immutable" LD date type and assume new objects would be frequently "created" instead of "mutated". (2) LocalDate.ofYearDay(int, int) LocalDate.resolvePreviousValid(int, int, int) Shouldn't they just call new LocalDate(year, month, day)? all fields have been validated already, it is unnecessary to go of()->create()-> new LocalDate() Here is the proposed update, opinion? http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm/ -Sherman From scolebourne at joda.org Thu Mar 7 02:11:53 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 7 Mar 2013 10:11:53 +0000 Subject: [threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue In-Reply-To: <5137B4DA.9040304@oracle.com> References: <5134DFA5.2000600@oracle.com> <51361A6A.3030204@oracle.com> <5137B4DA.9040304@oracle.com> Message-ID: The Javadoc in TemporalAccessor still needs fixing: * Implementations must not alter either this object. *

* The default implementation must behave equivalent to this code: * 

 *  return range(field).checkValidIntValue(getLong(field), field);

The first line is a typo. The second part describes the default
implementation, and thus needs adjusting to match the new
implementation.

Stephen



On 6 March 2013 21:27, roger riggs  wrote:
> Reverted the javadoc for @inheritDoc; the overridden methods all have
> the same @throws clauses.
>
> Updated webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>
> Roger
>
>
>
> On 3/6/2013 3:58 AM, Stephen Colebourne wrote:
>
> I hate the inheritDoc change. Is it done this way anywhere else in the
> JDK (I don't think so). While I accept it may be easier for
> maintainers, it is far worse for most developers who are just reading
> the Javadoc as source code (having hit F3 in Eclipse to jump to the
> source code of the method they are working with). While the HTML tool
> can hunt down the inheritDoc, regular users cannot.
>
> The inlined code looks OK, however the Javadoc of the method is now
> wrong as it specifies the implementation.
>
> thanks
> Stephen
>
>
> On 5 March 2013 16:16, roger riggs  wrote:
>
> Hi,
>
> Makes sense.
>
> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get.
> The @throws clauses were slightly out of alignment with
> TemporalAccessor.get.
> To make it simplier to maintain the implementers now use {@inheritDoc}.
> The ValueRange.checkValidIntValue exception message is updated to more
> informative.
>
> Updated webrev:
>
> Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/
>
> Thanks, Roger
>
> On 3/5/2013 8:49 AM, Stephen Colebourne wrote:
>
> I don't think this change can go in.
>
> The checkValidValue methods are public, and so can be called by anyone
> at any time in any way. The UTTE is intended for use when the Field or
> Unit passed in is unsupported by the target object. In these methods,
> the field is optional, and supported/not-supported is not a quality of
> the ValueRange class. Thus UTTE is just plain wrong to be thrown here.
>
> A correct fix would be to inline the code change into TemporalAccesor
> and anywhere else that has a similar use of the check method. If it is
> widely used, a package scoped method (in an appropriate location) may
> be a solution.
>
> thanks
> Stephen
>
>
>
> On 4 March 2013 17:53, roger riggs  wrote:
>
> Hi,
>
> A simple fix for the exception and message when TemporalAccessor.get()
> is used (incorrectly) to retrieve Fields with long values.
>
> Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>
> Thanks, Roger
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
> --
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>

From scolebourne at joda.org  Thu Mar  7 02:20:03 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 7 Mar 2013 10:20:03 +0000
Subject: [threeten-dev] Minor performance tuning for LocalDate.of(int,
 int, int)
In-Reply-To: <5137D55D.6050107@oracle.com>
References: <5137D55D.6050107@oracle.com>
Message-ID: 

The patch is fine. I think I would have created a new private method
create(int,int,int) that took in y/m/d that have been validated:

public static LocalDate of(int year, Month month, int dayOfMonth) {
  YEAR.checkValidValue(year);
  Objects.requireNonNull(month, "month");
  DAY_OF_MONTH.checkValidValue(dayOfMonth);
  return create(year, month.getValue(), dayOfMonth);
}

public static LocalDate of(int year, int month, int dayOfMonth) {
  YEAR.checkValidValue(year);
  MONTH_OF_YEAR.checkValidValue(month);
  DAY_OF_MONTH.checkValidValue(dayOfMonth);
  return create(year,month,day)
}

Mainly to avoid duplicated code. I suspect its smaller bytecode size
and better to hotspot.

You're free to push existing patch or amended one.
Stephen


On 6 March 2013 23:46, Xueming Shen  wrote:
>
> (1) LocalDate.of(int, int, int)
>      appears to create a use-and-throw "Month" object for validation purse
>      only,  it can be "saved" with a hard-coded Month.length, something
> worth
>      doing? given we are talking about "immutable" LD date type and assume
>      new objects would be frequently "created" instead of "mutated".
>
> (2) LocalDate.ofYearDay(int, int)
>      LocalDate.resolvePreviousValid(int, int, int)
>     Shouldn't they just call new LocalDate(year, month, day)?
>     all fields have been validated already, it is unnecessary to go
>     of()->create()-> new LocalDate()
>
> Here is the proposed update, opinion?
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm/
>
> -Sherman
>
>

From scolebourne at joda.org  Thu Mar  7 10:36:00 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 7 Mar 2013 18:36:00 +0000
Subject: [threeten-dev] Non webrev: Refactor enhance test resolving
Message-ID: 

Removes the public resolveYearOfEra method and refactors the resolving
to be more reliable, and hopefully faster.
Tested for main ISO cases.

See
https://gist.github.com/jodastephen/5110523

Stephen

From xueming.shen at oracle.com  Thu Mar  7 11:22:38 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 07 Mar 2013 11:22:38 -0800
Subject: [threeten-dev] Minor performance tuning for LocalDate.of(int,
 int, int)
In-Reply-To: 
References: <5137D55D.6050107@oracle.com>
	
Message-ID: <5138E8FE.7030608@oracle.com>

Updated as suggested.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm

-Sherman

On 03/07/2013 02:20 AM, Stephen Colebourne wrote:
> The patch is fine. I think I would have created a new private method
> create(int,int,int) that took in y/m/d that have been validated:
>
> public static LocalDate of(int year, Month month, int dayOfMonth) {
>    YEAR.checkValidValue(year);
>    Objects.requireNonNull(month, "month");
>    DAY_OF_MONTH.checkValidValue(dayOfMonth);
>    return create(year, month.getValue(), dayOfMonth);
> }
>
> public static LocalDate of(int year, int month, int dayOfMonth) {
>    YEAR.checkValidValue(year);
>    MONTH_OF_YEAR.checkValidValue(month);
>    DAY_OF_MONTH.checkValidValue(dayOfMonth);
>    return create(year,month,day)
> }
>
> Mainly to avoid duplicated code. I suspect its smaller bytecode size
> and better to hotspot.
>
> You're free to push existing patch or amended one.
> Stephen
>
>
> On 6 March 2013 23:46, Xueming Shen  wrote:
>> (1) LocalDate.of(int, int, int)
>>       appears to create a use-and-throw "Month" object for validation purse
>>       only,  it can be "saved" with a hard-coded Month.length, something
>> worth
>>       doing? given we are talking about "immutable" LD date type and assume
>>       new objects would be frequently "created" instead of "mutated".
>>
>> (2) LocalDate.ofYearDay(int, int)
>>       LocalDate.resolvePreviousValid(int, int, int)
>>      Shouldn't they just call new LocalDate(year, month, day)?
>>      all fields have been validated already, it is unnecessary to go
>>      of()->create()->  new LocalDate()
>>
>> Here is the proposed update, opinion?
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm/
>>
>> -Sherman
>>
>>


From scolebourne at joda.org  Thu Mar  7 11:42:06 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 7 Mar 2013 19:42:06 +0000
Subject: [threeten-dev] Minor performance tuning for LocalDate.of(int,
 int, int)
In-Reply-To: <5138E8FE.7030608@oracle.com>
References: <5137D55D.6050107@oracle.com>
	
	<5138E8FE.7030608@oracle.com>
Message-ID: 

Looks good to push
Stephen

On 7 March 2013 19:22, Xueming Shen  wrote:
> Updated as suggested.
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm
>
> -Sherman
>
>
> On 03/07/2013 02:20 AM, Stephen Colebourne wrote:
>>
>> The patch is fine. I think I would have created a new private method
>> create(int,int,int) that took in y/m/d that have been validated:
>>
>> public static LocalDate of(int year, Month month, int dayOfMonth) {
>>    YEAR.checkValidValue(year);
>>    Objects.requireNonNull(month, "month");
>>    DAY_OF_MONTH.checkValidValue(dayOfMonth);
>>    return create(year, month.getValue(), dayOfMonth);
>> }
>>
>> public static LocalDate of(int year, int month, int dayOfMonth) {
>>    YEAR.checkValidValue(year);
>>    MONTH_OF_YEAR.checkValidValue(month);
>>    DAY_OF_MONTH.checkValidValue(dayOfMonth);
>>    return create(year,month,day)
>> }
>>
>> Mainly to avoid duplicated code. I suspect its smaller bytecode size
>> and better to hotspot.
>>
>> You're free to push existing patch or amended one.
>> Stephen
>>
>>
>> On 6 March 2013 23:46, Xueming Shen  wrote:
>>>
>>> (1) LocalDate.of(int, int, int)
>>>       appears to create a use-and-throw "Month" object for validation
>>> purse
>>>       only,  it can be "saved" with a hard-coded Month.length, something
>>> worth
>>>       doing? given we are talking about "immutable" LD date type and
>>> assume
>>>       new objects would be frequently "created" instead of "mutated".
>>>
>>> (2) LocalDate.ofYearDay(int, int)
>>>       LocalDate.resolvePreviousValid(int, int, int)
>>>      Shouldn't they just call new LocalDate(year, month, day)?
>>>      all fields have been validated already, it is unnecessary to go
>>>      of()->create()->  new LocalDate()
>>>
>>> Here is the proposed update, opinion?
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ldPerm/
>>>
>>> -Sherman
>>>
>>>
>

From xueming.shen at oracle.com  Thu Mar  7 11:59:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 07 Mar 2013 19:59:16 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Minor LocalDate factory
	method performace	tuning.
Message-ID: <20130307195949.201AE47E28@hg.openjdk.java.net>

Changeset: a4b71ee1196c
Author:    sherman
Date:      2013-03-07 11:55 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a4b71ee1196c

Minor LocalDate factory method performace tuning.

! src/share/classes/java/time/LocalDate.java


From xueming.shen at oracle.com  Thu Mar  7 12:07:51 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 07 Mar 2013 20:07:51 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Test update for
	java.time.chrono.Era
Message-ID: <20130307200818.44B3947E2C@hg.openjdk.java.net>

Changeset: c4ad2f89f71e
Author:    sherman
Date:      2013-03-07 12:03 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c4ad2f89f71e

Test update for java.time.chrono.Era

+ test/java/time/tck/java/time/chrono/TCKHijrahEra.java
+ test/java/time/tck/java/time/chrono/TCKIsoEra.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
+ test/java/time/tck/java/time/chrono/TCKMinguoEra.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java


From xueming.shen at oracle.com  Thu Mar  7 12:15:49 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 07 Mar 2013 20:15:49 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Test update for
	MinguoChronology.java
Message-ID: <20130307201601.C988F47E2F@hg.openjdk.java.net>

Changeset: ac95aafa2d13
Author:    sherman
Date:      2013-03-07 12:11 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ac95aafa2d13

Test update for MinguoChronology.java

! test/java/time/tck/java/time/chrono/TestMinguoChronology.java


From scolebourne at joda.org  Thu Mar  7 12:56:54 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Thu, 07 Mar 2013 20:56:54 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets
Message-ID: <20130307205743.7A78D47E3B@hg.openjdk.java.net>

Changeset: 8aca6a33db80
Author:    scolebourne
Date:      2013-03-07 15:04 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8aca6a33db80

Remove dead cut-paste code

! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java

Changeset: 71b654aec2d0
Author:    scolebourne
Date:      2013-03-07 20:53 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/71b654aec2d0

Add ZoneId.getAvailableZoneIds()

! src/share/classes/java/time/ZoneId.java
! test/java/time/tck/java/time/TCKZoneId.java

Changeset: d662821873a2
Author:    scolebourne
Date:      2013-03-07 20:56 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d662821873a2

Merge



From xueming.shen at oracle.com  Thu Mar  7 21:10:32 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 07 Mar 2013 21:10:32 -0800
Subject: [threeten-dev] Ser performance
In-Reply-To: <51377FC9.5090608@oracle.com>
References: <513682A3.2050408@oracle.com>
	
	<51377FC9.5090608@oracle.com>
Message-ID: <513972C8.8020208@oracle.com>

I was asked to compare the ZDT and GregorianCalendar the other day, here
are the data.

--------LocalDate--------
serSize=16
Writing: 6655
Reading: 3318
--------LocalTime--------
serSize=17
Writing: 6335
Reading: 2968
--------LocalDateTime--------
serSize=23
Writing: 6317
Reading: 3392
--------ZonedDateTime--------
serSize=46
Writing: 7731
Reading: 15841
--------GregorianCal--------
serSize=266
Writing: 28491
Reading: 43594
--------ZoneId.of()--------
Reading: 4500

Obviously JSR310 ZDT is much faster than GregorianCalendar, both
serialization and de-ser. with a much smaller size, as expected.

However I noticed that the ZDT reading/de-serialization time is kinda 
"unproportional"
bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. It 
appears we "spend"
most of the ZoneRegion.ofId() time on the name validation via the regex. 
the regex's
matches() is too slow for this "simple" validation, unfortunately. 
Though I hate to propose,
as the proud maintainer of jdk regex:-), but I think it might worth 
considering the simple
char by char direct match, as we did in java.nio.Charset for the similar 
name validation
situation, as showed in the following webrev.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/

It boost the ZoneId.of() speed from 4500 to 1261, and cut the ZDT 
de-serialization
time almost in half.
(test case: 
http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/SerTest.java)

--------LocalDate--------
serSize=16
Writing: 6741
Reading: 3328
--------LocalTime--------
serSize=17
Writing: 6237
Reading: 3000
--------LocalDateTime--------
serSize=23
Writing: 6290
Reading: 3412
--------ZonedDateTime--------
serSize=46
Writing: 7566
Reading: 8054
--------GregorianCal--------
serSize=266
Writing: 29517
Reading: 42369
--------ZoneId.of()--------
Reading: 1261

-Sherman


From scolebourne at joda.org  Fri Mar  8 02:02:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 8 Mar 2013 10:02:26 +0000
Subject: [threeten-dev] Ser performance
In-Reply-To: <513972C8.8020208@oracle.com>
References: <513682A3.2050408@oracle.com>
	
	<51377FC9.5090608@oracle.com> <513972C8.8020208@oracle.com>
Message-ID: 

On 8 March 2013 05:10, Xueming Shen  wrote:
> However I noticed that the ZDT reading/de-serialization time is kinda
> "unproportional"
> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. It
> appears we "spend"
> most of the ZoneRegion.ofId() time on the name validation via the regex. the
> regex's
> matches() is too slow for this "simple" validation, unfortunately. Though I
> hate to propose,
> as the proud maintainer of jdk regex:-), but I think it might worth
> considering the simple
> char by char direct match, as we did in java.nio.Charset for the similar
> name validation
> situation, as showed in the following webrev.
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/

I'm happy with the principle of the change. I think it might be
cleaner to read and faster if you checked the first character, then
checked the remaining characters. This is safe as the string is at
least length 2.

You should also delete the pattern rather than just commenting it out.

I'd also prefer the checkName() method to be located after ofId(), not
before, in the source file.

thanks
Stephen

From roger.riggs at oracle.com  Fri Mar  8 07:25:44 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 08 Mar 2013 10:25:44 -0500
Subject: [threeten-dev] Ser performance
In-Reply-To: <513972C8.8020208@oracle.com>
References: <513682A3.2050408@oracle.com>
	
	<51377FC9.5090608@oracle.com> <513972C8.8020208@oracle.com>
Message-ID: <513A02F8.5020909@oracle.com>

Hi Sherman,

I would also be interested in the comparison with the serialization of 
java.util.Date
though it is likely to be similar to LocalDate since it just serializes 
a long.

Does Regex have an patterns for which it has optimized implementations?
It should be possible to normalize the patterns and with some data gathering
code up some specific implementations.

Regex has always seemed like overkill to me for most patterns.

The code for checkname could be optimized a bit as Stephen suggested
and could also put the individual comparisons in numeric order and
if the character was > making a quick continue.

Either way its a good improvement.

Thanks, Roger


On 3/8/2013 12:10 AM, Xueming Shen wrote:
> I was asked to compare the ZDT and GregorianCalendar the other day, here
> are the data.
>
> --------LocalDate--------
> serSize=16
> Writing: 6655
> Reading: 3318
> --------LocalTime--------
> serSize=17
> Writing: 6335
> Reading: 2968
> --------LocalDateTime--------
> serSize=23
> Writing: 6317
> Reading: 3392
> --------ZonedDateTime--------
> serSize=46
> Writing: 7731
> Reading: 15841
> --------GregorianCal--------
> serSize=266
> Writing: 28491
> Reading: 43594
> --------ZoneId.of()--------
> Reading: 4500
>
> Obviously JSR310 ZDT is much faster than GregorianCalendar, both
> serialization and de-ser. with a much smaller size, as expected.
>
> However I noticed that the ZDT reading/de-serialization time is kinda 
> "unproportional"
> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. 
> It appears we "spend"
> most of the ZoneRegion.ofId() time on the name validation via the 
> regex. the regex's
> matches() is too slow for this "simple" validation, unfortunately. 
> Though I hate to propose,
> as the proud maintainer of jdk regex:-), but I think it might worth 
> considering the simple
> char by char direct match, as we did in java.nio.Charset for the 
> similar name validation
> situation, as showed in the following webrev.
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>
> It boost the ZoneId.of() speed from 4500 to 1261, and cut the ZDT 
> de-serialization
> time almost in half.
> (test case: 
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/SerTest.java)
>
> --------LocalDate--------
> serSize=16
> Writing: 6741
> Reading: 3328
> --------LocalTime--------
> serSize=17
> Writing: 6237
> Reading: 3000
> --------LocalDateTime--------
> serSize=23
> Writing: 6290
> Reading: 3412
> --------ZonedDateTime--------
> serSize=46
> Writing: 7566
> Reading: 8054
> --------GregorianCal--------
> serSize=266
> Writing: 29517
> Reading: 42369
> --------ZoneId.of()--------
> Reading: 1261
>
> -Sherman
>


From xueming.shen at oracle.com  Fri Mar  8 08:17:08 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 08:17:08 -0800
Subject: [threeten-dev] Ser performance
In-Reply-To: <513A02F8.5020909@oracle.com>
References: <513682A3.2050408@oracle.com>
	
	<51377FC9.5090608@oracle.com> <513972C8.8020208@oracle.com>
	<513A02F8.5020909@oracle.com>
Message-ID: <513A0F04.8090700@oracle.com>

On 3/8/13 7:25 AM, roger riggs wrote:
> Hi Sherman,
>
> I would also be interested in the comparison with the serialization of 
> java.util.Date
> though it is likely to be similar to LocalDate since it just 
> serializes a long.
>
> Does Regex have an patterns for which it has optimized implementations?
> It should be possible to normalize the patterns and with some data 
> gathering
> code up some specific implementations.
>
> Regex has always seemed like overkill to me for most patterns.
>
> The code for checkname could be optimized a bit as Stephen suggested
> and could also put the individual comparisons in numeric order and
> if the character was > making a quick continue.

I will try the suggested one, but I remember, if my memory servers me
correctly, the current code is actually faster. I remember I tried the
similar "optimization" years ago on the charset version, but it ends up
the existing one is faster. But my memory might be wrong and the
hotspot might be different:-)



>
> Either way its a good improvement.
>
> Thanks, Roger
>
>
> On 3/8/2013 12:10 AM, Xueming Shen wrote:
>> I was asked to compare the ZDT and GregorianCalendar the other day, here
>> are the data.
>>
>> --------LocalDate--------
>> serSize=16
>> Writing: 6655
>> Reading: 3318
>> --------LocalTime--------
>> serSize=17
>> Writing: 6335
>> Reading: 2968
>> --------LocalDateTime--------
>> serSize=23
>> Writing: 6317
>> Reading: 3392
>> --------ZonedDateTime--------
>> serSize=46
>> Writing: 7731
>> Reading: 15841
>> --------GregorianCal--------
>> serSize=266
>> Writing: 28491
>> Reading: 43594
>> --------ZoneId.of()--------
>> Reading: 4500
>>
>> Obviously JSR310 ZDT is much faster than GregorianCalendar, both
>> serialization and de-ser. with a much smaller size, as expected.
>>
>> However I noticed that the ZDT reading/de-serialization time is kinda 
>> "unproportional"
>> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. 
>> It appears we "spend"
>> most of the ZoneRegion.ofId() time on the name validation via the 
>> regex. the regex's
>> matches() is too slow for this "simple" validation, unfortunately. 
>> Though I hate to propose,
>> as the proud maintainer of jdk regex:-), but I think it might worth 
>> considering the simple
>> char by char direct match, as we did in java.nio.Charset for the 
>> similar name validation
>> situation, as showed in the following webrev.
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>>
>> It boost the ZoneId.of() speed from 4500 to 1261, and cut the ZDT 
>> de-serialization
>> time almost in half.
>> (test case: 
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/SerTest.java)
>>
>> --------LocalDate--------
>> serSize=16
>> Writing: 6741
>> Reading: 3328
>> --------LocalTime--------
>> serSize=17
>> Writing: 6237
>> Reading: 3000
>> --------LocalDateTime--------
>> serSize=23
>> Writing: 6290
>> Reading: 3412
>> --------ZonedDateTime--------
>> serSize=46
>> Writing: 7566
>> Reading: 8054
>> --------GregorianCal--------
>> serSize=266
>> Writing: 29517
>> Reading: 42369
>> --------ZoneId.of()--------
>> Reading: 1261
>>
>> -Sherman
>>
>


From xueming.shen at oracle.com  Fri Mar  8 08:27:34 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 08:27:34 -0800
Subject: [threeten-dev] Ser performance
In-Reply-To: 
References: <513682A3.2050408@oracle.com>
	
	<51377FC9.5090608@oracle.com> <513972C8.8020208@oracle.com>
	
Message-ID: <513A1176.5040408@oracle.com>

On 3/8/13 2:02 AM, Stephen Colebourne wrote:
> On 8 March 2013 05:10, Xueming Shen  wrote:
>> However I noticed that the ZDT reading/de-serialization time is kinda
>> "unproportional"
>> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. It
>> appears we "spend"
>> most of the ZoneRegion.ofId() time on the name validation via the regex. the
>> regex's
>> matches() is too slow for this "simple" validation, unfortunately. Though I
>> hate to propose,
>> as the proud maintainer of jdk regex:-), but I think it might worth
>> considering the simple
>> char by char direct match, as we did in java.nio.Charset for the similar
>> name validation
>> situation, as showed in the following webrev.
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
> I'm happy with the principle of the change. I think it might be
> cleaner to read and faster if you checked the first character, then
> checked the remaining characters. This is safe as the string is at
> least length 2.

The assumption of current impl is that in "normal" scenario the tested
zoneId name is valid and  most of the character is A-Z and a-z. Maybe
we should move _ and / up before 0-9. But I would guess the suggested
approach would not be faster.

>
> You should also delete the pattern rather than just commenting it out.
>
> I'd also prefer the checkName() method to be located after ofId(), not
> before, in the source file.
>
> thanks
> Stephen


From scolebourne at joda.org  Fri Mar  8 08:46:05 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 8 Mar 2013 16:46:05 +0000
Subject: [threeten-dev] Non webrev: Refactor enhance test resolving
In-Reply-To: 
References: 
Message-ID: 

I'm planning on pushing this before I go home in an hour or two...
Stephen

On 7 March 2013 18:36, Stephen Colebourne  wrote:
> Removes the public resolveYearOfEra method and refactors the resolving
> to be more reliable, and hopefully faster.
> Tested for main ISO cases.
>
> See
> https://gist.github.com/jodastephen/5110523
>
> Stephen

From roger.riggs at oracle.com  Fri Mar  8 09:33:25 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 08 Mar 2013 12:33:25 -0500
Subject: [threeten-dev] Non webrev: Refactor enhance test resolving
In-Reply-To: 
References: 
	
Message-ID: <513A20E5.2080909@oracle.com>

ok,  it looks more useful to be more general than just resolving year of 
era.

Thanks, Roger

On 3/8/2013 11:46 AM, Stephen Colebourne wrote:
> I'm planning on pushing this before I go home in an hour or two...
> Stephen
>
> On 7 March 2013 18:36, Stephen Colebourne  wrote:
>> Removes the public resolveYearOfEra method and refactors the resolving
>> to be more reliable, and hopefully faster.
>> Tested for main ISO cases.
>>
>> See
>> https://gist.github.com/jodastephen/5110523
>>
>> Stephen


From scolebourne at joda.org  Fri Mar  8 09:48:20 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Fri, 08 Mar 2013 17:48:20 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Refactor,
	enhance and test resolving logic
Message-ID: <20130308174909.C721C4800F@hg.openjdk.java.net>

Changeset: 402b7e4840b3
Author:    scolebourne
Date:      2013-03-07 20:53 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/402b7e4840b3

Refactor, enhance and test resolving logic

Remove public resolveYearOfEra method

! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/format/Parsed.java
+ test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java


From xueming.shen at oracle.com  Fri Mar  8 10:05:43 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 10:05:43 -0800
Subject: [threeten-dev] Ser performance
In-Reply-To: <513A1176.5040408@oracle.com>
References: <513682A3.2050408@oracle.com>		<51377FC9.5090608@oracle.com>
	<513972C8.8020208@oracle.com>	
	<513A1176.5040408@oracle.com>
Message-ID: <513A2877.1070808@oracle.com>


I would assume "check first char first" is something similar to

         char c = zoneId.charAt(0);
         if (c < 'A' || c > 'z' || (c > 'Z' && c < 'a'))
             throw new DateTimeException("Invalid ID for region-based ZoneId, invalid format: " + zoneId);
         for (int i = 1; i < n; i++) {
             c = zoneId.charAt(i);
             if (c >= 'a' && c <= 'z') continue;
             if (c >= 'A' && c <= 'Z') continue;
             if (c == '/') continue;
             if (c >= '0' && c <= '9') continue;
             if (c == '~') continue;
             if (c == '.') continue;
             if (c == '_') continue;
             if (c == '+') continue;
             if (c == '-') continue;
             throw new DateTimeException("Invalid ID for region-based ZoneId, invalid format: " + zoneId);
         }

There is no change in speed, and personally I prefer the proposed one.
Moving the lower case the first check obviously brings in 5%+ boost,
with the assumption that the "original" tzdb names should be used
in most scenario, which has a capital first character followed by lower
case characters as the rest.

Webrev has been updated to
(1) moved up lower case
(2) removed pattern
(3) moved the checkName after ofId()

http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/

Added j.u.Date, it is around the expected number.

--------LocalDate--------
serSize=16
Writing: 6696
Reading: 3218
--------LocalTime--------
serSize=17
Writing: 6166
Reading: 2959
--------LocalDateTime--------
serSize=23
Writing: 6268
Reading: 3606
--------ZonedDateTime--------
serSize=46
Writing: 7543
Reading: 8450
--------Date--------
serSize=17
Writing: 2951
Reading: 3485
--------GregorianCal--------
serSize=266
Writing: 29136
Reading: 43823
--------ZoneId.of()--------
Reading: 987

-Sherman

On 03/08/2013 08:27 AM, Xueming Shen wrote:
> On 3/8/13 2:02 AM, Stephen Colebourne wrote:
>> On 8 March 2013 05:10, Xueming Shen  wrote:
>>> However I noticed that the ZDT reading/de-serialization time is kinda
>>> "unproportional"
>>> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. It
>>> appears we "spend"
>>> most of the ZoneRegion.ofId() time on the name validation via the regex. the
>>> regex's
>>> matches() is too slow for this "simple" validation, unfortunately. Though I
>>> hate to propose,
>>> as the proud maintainer of jdk regex:-), but I think it might worth
>>> considering the simple
>>> char by char direct match, as we did in java.nio.Charset for the similar
>>> name validation
>>> situation, as showed in the following webrev.
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>> I'm happy with the principle of the change. I think it might be
>> cleaner to read and faster if you checked the first character, then
>> checked the remaining characters. This is safe as the string is at
>> least length 2.
>
> The assumption of current impl is that in "normal" scenario the tested
> zoneId name is valid and  most of the character is A-Z and a-z. Maybe
> we should move _ and / up before 0-9. But I would guess the suggested
> approach would not be faster.
>
>>
>> You should also delete the pattern rather than just commenting it out.
>>
>> I'd also prefer the checkName() method to be located after ofId(), not
>> before, in the source file.
>>
>> thanks
>> Stephen
>


From roger.riggs at oracle.com  Fri Mar  8 10:28:17 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 08 Mar 2013 13:28:17 -0500
Subject: [threeten-dev] Ser performance
In-Reply-To: <513A2877.1070808@oracle.com>
References: <513682A3.2050408@oracle.com>		<51377FC9.5090608@oracle.com>
	<513972C8.8020208@oracle.com>	
	<513A1176.5040408@oracle.com> <513A2877.1070808@oracle.com>
Message-ID: <513A2DC1.9050903@oracle.com>

Hi Sherman,

Check the loop initial value, I think char(0) is not being checked.

Personal preference is to avoid redundant and complex expressions in the 
loop
(i != 0).

Roger

On 3/8/2013 1:05 PM, Xueming Shen wrote:
>
> I would assume "check first char first" is something similar to
>
>         char c = zoneId.charAt(0);
>         if (c < 'A' || c > 'z' || (c > 'Z' && c < 'a'))
>             throw new DateTimeException("Invalid ID for region-based 
> ZoneId, invalid format: " + zoneId);
>         for (int i = 1; i < n; i++) {
>             c = zoneId.charAt(i);
>             if (c >= 'a' && c <= 'z') continue;
>             if (c >= 'A' && c <= 'Z') continue;
>             if (c == '/') continue;
>             if (c >= '0' && c <= '9') continue;
>             if (c == '~') continue;
>             if (c == '.') continue;
>             if (c == '_') continue;
>             if (c == '+') continue;
>             if (c == '-') continue;
>             throw new DateTimeException("Invalid ID for region-based 
> ZoneId, invalid format: " + zoneId);
>         }
>
> There is no change in speed, and personally I prefer the proposed one.
> Moving the lower case the first check obviously brings in 5%+ boost,
> with the assumption that the "original" tzdb names should be used
> in most scenario, which has a capital first character followed by lower
> case characters as the rest.
>
> Webrev has been updated to
> (1) moved up lower case
> (2) removed pattern
> (3) moved the checkName after ofId()
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>
> Added j.u.Date, it is around the expected number.
>
> --------LocalDate--------
> serSize=16
> Writing: 6696
> Reading: 3218
> --------LocalTime--------
> serSize=17
> Writing: 6166
> Reading: 2959
> --------LocalDateTime--------
> serSize=23
> Writing: 6268
> Reading: 3606
> --------ZonedDateTime--------
> serSize=46
> Writing: 7543
> Reading: 8450
> --------Date--------
> serSize=17
> Writing: 2951
> Reading: 3485
> --------GregorianCal--------
> serSize=266
> Writing: 29136
> Reading: 43823
> --------ZoneId.of()--------
> Reading: 987
>
> -Sherman
>
> On 03/08/2013 08:27 AM, Xueming Shen wrote:
>> On 3/8/13 2:02 AM, Stephen Colebourne wrote:
>>> On 8 March 2013 05:10, Xueming Shen  wrote:
>>>> However I noticed that the ZDT reading/de-serialization time is kinda
>>>> "unproportional"
>>>> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read 
>>>> in. It
>>>> appears we "spend"
>>>> most of the ZoneRegion.ofId() time on the name validation via the 
>>>> regex. the
>>>> regex's
>>>> matches() is too slow for this "simple" validation, unfortunately. 
>>>> Though I
>>>> hate to propose,
>>>> as the proud maintainer of jdk regex:-), but I think it might worth
>>>> considering the simple
>>>> char by char direct match, as we did in java.nio.Charset for the 
>>>> similar
>>>> name validation
>>>> situation, as showed in the following webrev.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>>> I'm happy with the principle of the change. I think it might be
>>> cleaner to read and faster if you checked the first character, then
>>> checked the remaining characters. This is safe as the string is at
>>> least length 2.
>>
>> The assumption of current impl is that in "normal" scenario the tested
>> zoneId name is valid and  most of the character is A-Z and a-z. Maybe
>> we should move _ and / up before 0-9. But I would guess the suggested
>> approach would not be faster.
>>
>>>
>>> You should also delete the pattern rather than just commenting it out.
>>>
>>> I'd also prefer the checkName() method to be located after ofId(), not
>>> before, in the source file.
>>>
>>> thanks
>>> Stephen
>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From roger.riggs at oracle.com  Fri Mar  8 10:34:40 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 08 Mar 2013 13:34:40 -0500
Subject: [threeten-dev] [threeten-develop] Review for minor update to
	ValueRange checkValidIntValue
In-Reply-To: 
References: <5134DFA5.2000600@oracle.com>
	
	<51361A6A.3030204@oracle.com>
	
	<5137B4DA.9040304@oracle.com>
	
Message-ID: <513A2F40.9000400@oracle.com>

Hi Stephen,

The description of the default implementation is redundant with
the requirements described in the exceptions and is unnecessary.

Roger

On 3/7/2013 5:11 AM, Stephen Colebourne wrote:
> The Javadoc in TemporalAccessor still needs fixing:
>
> * Implementations must not alter either this object.
>   * 

>   * The default implementation must behave equivalent to this code:
>   * 
>   *  return range(field).checkValidIntValue(getLong(field), field);
>
> The first line is a typo. The second part describes the default
> implementation, and thus needs adjusting to match the new
> implementation.
>
> Stephen
>
>
>
> On 6 March 2013 21:27, roger riggs  wrote:
>> Reverted the javadoc for @inheritDoc; the overridden methods all have
>> the same @throws clauses.
>>
>> Updated webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>>
>> Roger
>>
>>
>>
>> On 3/6/2013 3:58 AM, Stephen Colebourne wrote:
>>
>> I hate the inheritDoc change. Is it done this way anywhere else in the
>> JDK (I don't think so). While I accept it may be easier for
>> maintainers, it is far worse for most developers who are just reading
>> the Javadoc as source code (having hit F3 in Eclipse to jump to the
>> source code of the method they are working with). While the HTML tool
>> can hunt down the inheritDoc, regular users cannot.
>>
>> The inlined code looks OK, however the Javadoc of the method is now
>> wrong as it specifies the implementation.
>>
>> thanks
>> Stephen
>>
>>
>> On 5 March 2013 16:16, roger riggs  wrote:
>>
>> Hi,
>>
>> Makes sense.
>>
>> I inlined the equivalent of checkValidIntValue in TemporalAccessor.get.
>> The @throws clauses were slightly out of alignment with
>> TemporalAccessor.get.
>> To make it simplier to maintain the implementers now use {@inheritDoc}.
>> The ValueRange.checkValidIntValue exception message is updated to more
>> informative.
>>
>> Updated webrev:
>>
>> Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>> javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/
>>
>> Thanks, Roger
>>
>> On 3/5/2013 8:49 AM, Stephen Colebourne wrote:
>>
>> I don't think this change can go in.
>>
>> The checkValidValue methods are public, and so can be called by anyone
>> at any time in any way. The UTTE is intended for use when the Field or
>> Unit passed in is unsupported by the target object. In these methods,
>> the field is optional, and supported/not-supported is not a quality of
>> the ValueRange class. Thus UTTE is just plain wrong to be thrown here.
>>
>> A correct fix would be to inline the code change into TemporalAccesor
>> and anywhere else that has a similar use of the check method. If it is
>> widely used, a package scoped method (in an appropriate location) may
>> be a solution.
>>
>> thanks
>> Stephen
>>
>>
>>
>> On 4 March 2013 17:53, roger riggs  wrote:
>>
>> Hi,
>>
>> A simple fix for the exception and message when TemporalAccessor.get()
>> is used (incorrectly) to retrieve Fields with long values.
>>
>> Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>>
>> Thanks, Roger
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>>
>> ------------------------------------------------------------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>>
>> --
>> Thanks, Roger
>>
>> Oracle Java Platform Group
>>
>> Oracle is committed to developing practices and products that help protect
>> the environment
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From xueming.shen at oracle.com  Fri Mar  8 10:43:52 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 10:43:52 -0800
Subject: [threeten-dev] Ser performance
In-Reply-To: <513A2DC1.9050903@oracle.com>
References: <513682A3.2050408@oracle.com>		<51377FC9.5090608@oracle.com>	<513972C8.8020208@oracle.com>		<513A1176.5040408@oracle.com>
	<513A2877.1070808@oracle.com> <513A2DC1.9050903@oracle.com>
Message-ID: <513A3168.1030600@oracle.com>

oops:-) updated.

understood the (i!=0). the assumption is that this check should
not be reached in most use scenario (consider all "normal" zid
names, and we are trying to improve the performance for the
"normal" use scenario, in which, the zid names are those tzdb
names, with [A-Z][a-z/]+ pattern). With those "if"s inside the
loop, hotspot probably can do nothing to optimize, with  or
without this check. It looks a little "ugly", but it might be the
most straightforward/fastest one:-)

-Sherman

On 03/08/2013 10:28 AM, roger riggs wrote:
> Hi Sherman,
>
> Check the loop initial value, I think char(0) is not being checked.
>
> Personal preference is to avoid redundant and complex expressions in the loop
> (i != 0).
>
> Roger
>
> On 3/8/2013 1:05 PM, Xueming Shen wrote:
>>
>> I would assume "check first char first" is something similar to
>>
>>         char c = zoneId.charAt(0);
>>         if (c < 'A' || c > 'z' || (c > 'Z' && c < 'a'))
>>             throw new DateTimeException("Invalid ID for region-based ZoneId, invalid format: " + zoneId);
>>         for (int i = 1; i < n; i++) {
>>             c = zoneId.charAt(i);
>>             if (c >= 'a' && c <= 'z') continue;
>>             if (c >= 'A' && c <= 'Z') continue;
>>             if (c == '/') continue;
>>             if (c >= '0' && c <= '9') continue;
>>             if (c == '~') continue;
>>             if (c == '.') continue;
>>             if (c == '_') continue;
>>             if (c == '+') continue;
>>             if (c == '-') continue;
>>             throw new DateTimeException("Invalid ID for region-based ZoneId, invalid format: " + zoneId);
>>         }
>>
>> There is no change in speed, and personally I prefer the proposed one.
>> Moving the lower case the first check obviously brings in 5%+ boost,
>> with the assumption that the "original" tzdb names should be used
>> in most scenario, which has a capital first character followed by lower
>> case characters as the rest.
>>
>> Webrev has been updated to
>> (1) moved up lower case
>> (2) removed pattern
>> (3) moved the checkName after ofId()
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>>
>> Added j.u.Date, it is around the expected number.
>>
>> --------LocalDate--------
>> serSize=16
>> Writing: 6696
>> Reading: 3218
>> --------LocalTime--------
>> serSize=17
>> Writing: 6166
>> Reading: 2959
>> --------LocalDateTime--------
>> serSize=23
>> Writing: 6268
>> Reading: 3606
>> --------ZonedDateTime--------
>> serSize=46
>> Writing: 7543
>> Reading: 8450
>> --------Date--------
>> serSize=17
>> Writing: 2951
>> Reading: 3485
>> --------GregorianCal--------
>> serSize=266
>> Writing: 29136
>> Reading: 43823
>> --------ZoneId.of()--------
>> Reading: 987
>>
>> -Sherman
>>
>> On 03/08/2013 08:27 AM, Xueming Shen wrote:
>>> On 3/8/13 2:02 AM, Stephen Colebourne wrote:
>>>> On 8 March 2013 05:10, Xueming Shen  wrote:
>>>>> However I noticed that the ZDT reading/de-serialization time is kinda
>>>>> "unproportional"
>>>>> bigger, given it only has a LDT, a ZoneOffset and ZoneId to read in. It
>>>>> appears we "spend"
>>>>> most of the ZoneRegion.ofId() time on the name validation via the regex. the
>>>>> regex's
>>>>> matches() is too slow for this "simple" validation, unfortunately. Though I
>>>>> hate to propose,
>>>>> as the proud maintainer of jdk regex:-), but I think it might worth
>>>>> considering the simple
>>>>> char by char direct match, as we did in java.nio.Charset for the similar
>>>>> name validation
>>>>> situation, as showed in the following webrev.
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zidPerm/
>>>> I'm happy with the principle of the change. I think it might be
>>>> cleaner to read and faster if you checked the first character, then
>>>> checked the remaining characters. This is safe as the string is at
>>>> least length 2.
>>>
>>> The assumption of current impl is that in "normal" scenario the tested
>>> zoneId name is valid and  most of the character is A-Z and a-z. Maybe
>>> we should move _ and / up before 0-9. But I would guess the suggested
>>> approach would not be faster.
>>>
>>>>
>>>> You should also delete the pattern rather than just commenting it out.
>>>>
>>>> I'd also prefer the checkName() method to be located after ofId(), not
>>>> before, in the source file.
>>>>
>>>> thanks
>>>> Stephen
>>>
>>
>


From xueming.shen at oracle.com  Fri Mar  8 11:02:44 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 11:02:44 -0800
Subject: [threeten-dev] 2 test failures
Message-ID: <513A35D4.4070308@oracle.com>


        Execution failed: `main' threw exception: java.lang.Exception: failures: 28

    * java/time/test/java/time/format/TestTextParser.java:


        Execution failed: `main' threw exception: java.lang.Exception: failures: 8

    * java/time/test/java/time/format/TestTextPrinter.java:

It appears these two failed on the new quarter name testings. I have not looked
into the details yet, just wonder if it's only my env...

From xueming.shen at oracle.com  Fri Mar  8 11:24:21 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 08 Mar 2013 11:24:21 -0800
Subject: [threeten-dev] 2 test failures
In-Reply-To: <513A35D4.4070308@oracle.com>
References: <513A35D4.4070308@oracle.com>
Message-ID: <513A3AE5.2000404@oracle.com>

my apology, false alarm. I did not re-build all the changes that not
in java/time.

On 03/08/2013 11:02 AM, Xueming Shen wrote:
>
>        Execution failed: `main' threw exception: java.lang.Exception: failures: 28
>
>    * java/time/test/java/time/format/TestTextParser.java:
>
>
>        Execution failed: `main' threw exception: java.lang.Exception: failures: 8
>
>    * java/time/test/java/time/format/TestTextPrinter.java:
>
> It appears these two failed on the new quarter name testings. I have not looked
> into the details yet, just wonder if it's only my env...


From roger.riggs at oracle.com  Fri Mar  8 13:24:54 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 08 Mar 2013 21:24:54 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130308212537.04CC54801B@hg.openjdk.java.net>

Changeset: 5a0759d1c8b9
Author:    rriggs
Date:      2013-03-08 16:17 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5a0759d1c8b9

#274 ValueRange checkValidIntValue exceptions.

Modified TemporalAccessor.get to inline the checkValidIntValue to
throw UnsupportedTemporalTypeException if the value requests is larger than an int.

Updated exceptions on TemporalAccessor.get and overridden methods

Improved exception message in ValueRange.checkValidIntValue () and checkValidValue
and avoid an NPE if field was null.

! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/ValueRange.java
! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java

Changeset: 29972432795c
Author:    rriggs
Date:      2013-03-08 16:24 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/29972432795c

Merge

! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
- src/share/classes/java/time/format/DateTimeBuilder.java


From patrick.zhang at oracle.com  Fri Mar  8 23:14:40 2013
From: patrick.zhang at oracle.com (patrick zhang)
Date: Sat, 09 Mar 2013 15:14:40 +0800
Subject: [threeten-dev] some problems in java.time.YearMonth and
	java.time.Year
In-Reply-To: <51359FF4.70202@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
Message-ID: <513AE160.3050603@oracle.com>

Hi Team,

During investigation for java.time.YearMonth and java.time.Year, I have 
found some problems in it.

1. Year.minus(TemporalAmout) does not work properly.
===========
        Year year = Year.of(5);
        Year result = year.minus(Period.ofYears(2)) ;
        System.out.println(result);
===========
Personally I think above code should work and return Year.of(3). But it 
throws exception:
===========
Exception in thread "main" java.time.DateTimeException: Unsupported 
unit: Months
    at java.time.Year.plus(Year.java:660)
    at java.time.Year.minus(Year.java:727)
    at java.time.Year.minus(Year.java:123)
    at java.time.Period.subtractFrom(Period.java:823)
    at java.time.Year.minus(Year.java:704)
    at mytest.TestEra.main(TestEra.java:18)
============

2. javadoc for Year.minus(long, TemporalUnit) is wrong.
As you know the method will return Year same with minus(TemporalAmout) 
while it is "YearMonth" in current javadoc:
====================

Returns:
    a |YearMonth| based on this year-month with the specified amount
    subtracted, not null 
====================

3. javadoc for java.time.Temporal.ChronoUnit.ERAS is confused.
Here there are 2 problems.
====================
Unit that represents the concept of an era. The ISO calendar system 
doesn't have eras thus it is impossible to add an era to a date or 
date-time. The estimated duration of the era is artificially defined as 
|1,000,00,000 Years|.
====================
I guess it should be 1,000,000,000 years nor |1,000,00,000


|====================
        Year year = Year.of(-1);
        Year result = year.plus(1, ChronoUnit.ERAS);
       
        System.out.println(year.get(ChronoField.ERA) + " " + 
year.get(ChronoField.YEAR_OF_ERA) + " " + year.get(ChronoField.YEAR));
        System.out.println(result.get(ChronoField.ERA) + " " + 
result.get(ChronoField.YEAR_OF_ERA) + " " + result.get(ChronoField.YEAR));

output:
0 2 -1
1 2 2
====================
Since ERAS is not supported in ISO calendar, I think it should not 
return such a strange result.
It looks it only plus 1 on ChronoField.ERAS field simply......

Regards
Patrick

From masayoshi.okutsu at oracle.com  Sat Mar  9 04:38:53 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sat, 09 Mar 2013 21:38:53 +0900
Subject: [threeten-dev] Review request: standalone text support
Message-ID: <513B2D5D.8020007@oracle.com>

I added standalone text support.

- Added 'L' (standalone month names), 'c' (standalone day-of-week 
names), and 'q' (standalone quarter names).

- Changed 'e' to support text (format day-of-week names) as well. And 
"ee" is accepted as a valid pattern. This is consistent with the LDML 
spec. But let me know if this change shouldn't be made.

- "cc" is accepted (as the same pattern as "ee"), which is undefined in 
the LDML spec.

- 6-letters of 'c' and 'e' are handles as invalid patterns.

- Added standalone day-of-weeknames to FormatData_fi.java for testing 
purpose. In JRE fi locale, the format day-of-week names are in the 
standalone form, while the format and standalone names are different in 
CLDR. We won't be able to change the format names of the JRE fi locale 
due to the compatibility risk.

Webrev:
http://cr.openjdk.java.net/~okutsu/310/standalonetext/webrev.00

Thanks,
Masayoshi


From scolebourne at joda.org  Sat Mar  9 07:39:29 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 9 Mar 2013 15:39:29 +0000
Subject: [threeten-dev] Review request: standalone text support
In-Reply-To: <513B2D5D.8020007@oracle.com>
References: <513B2D5D.8020007@oracle.com>
Message-ID: 

- In the tables of pattern letters, it might be clearer to change the
first column to "M/L" to avoid duplicating the rest of the column:

 M       month-of-year               number/text       7; 07; Jul; July; J
 L       month-of-year (stand-alone) number/text       7; 07; Jul; July; J
change to
 M/L     month-of-year               number/text       7; 07; Jul; July; J

with the text describing the stand-alone letter is second

- Looks like issue #244 might also be fixed.

Looks good.
Stephen



On 9 March 2013 12:38, Masayoshi Okutsu  wrote:
> I added standalone text support.
>
> - Added 'L' (standalone month names), 'c' (standalone day-of-week names),
> and 'q' (standalone quarter names).
>
> - Changed 'e' to support text (format day-of-week names) as well. And "ee"
> is accepted as a valid pattern. This is consistent with the LDML spec. But
> let me know if this change shouldn't be made.
>
> - "cc" is accepted (as the same pattern as "ee"), which is undefined in the
> LDML spec.
>
> - 6-letters of 'c' and 'e' are handles as invalid patterns.
>
> - Added standalone day-of-weeknames to FormatData_fi.java for testing
> purpose. In JRE fi locale, the format day-of-week names are in the
> standalone form, while the format and standalone names are different in
> CLDR. We won't be able to change the format names of the JRE fi locale due
> to the compatibility risk.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/310/standalonetext/webrev.00
>
> Thanks,
> Masayoshi
>

From roger.riggs at oracle.com  Sat Mar  9 10:00:32 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Sat, 09 Mar 2013 18:00:32 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: #274 restored description
	of default	implementation of get method
Message-ID: <20130309180115.B02A348039@hg.openjdk.java.net>

Changeset: f1b828b14763
Author:    rriggs
Date:      2013-03-09 13:00 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f1b828b14763

#274 restored description of default implementation of get method

! src/share/classes/java/time/temporal/TemporalAccessor.java


From roger.riggs at oracle.com  Sat Mar  9 10:31:06 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Sat, 09 Mar 2013 13:31:06 -0500
Subject: [threeten-dev] Review request: standalone text support
In-Reply-To: <513B2D5D.8020007@oracle.com>
References: <513B2D5D.8020007@oracle.com>
Message-ID: <513B7FEA.9000605@oracle.com>

Hi Masayoshi,

The distinction and definition of the difference between format and
standalone forms probably needs to be emphasized, folks are
not going to immediately understand the difference.  I would leave the
tables for M and L separate to highlight the difference.
Perhaps some connection can be made concretely to the TextStyle values; 
We can add more of a description and example later.

The implementation looks good.

Thanks, Roger

On 3/9/2013 7:38 AM, Masayoshi Okutsu wrote:
> I added standalone text support.
>
> - Added 'L' (standalone month names), 'c' (standalone day-of-week 
> names), and 'q' (standalone quarter names).
>
> - Changed 'e' to support text (format day-of-week names) as well. And 
> "ee" is accepted as a valid pattern. This is consistent with the LDML 
> spec. But let me know if this change shouldn't be made.
>
> - "cc" is accepted (as the same pattern as "ee"), which is undefined 
> in the LDML spec.
>
> - 6-letters of 'c' and 'e' are handles as invalid patterns.
>
> - Added standalone day-of-weeknames to FormatData_fi.java for testing 
> purpose. In JRE fi locale, the format day-of-week names are in the 
> standalone form, while the format and standalone names are different 
> in CLDR. We won't be able to change the format names of the JRE fi 
> locale due to the compatibility risk.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/310/standalonetext/webrev.00
>
> Thanks,
> Masayoshi
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From masayoshi.okutsu at oracle.com  Sun Mar 10 06:36:00 2013
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Sun, 10 Mar 2013 13:36:00 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Partial fix for #64:
	stand-alone text	support (pattern letters 'L', 'c', and 'q')
Message-ID: <20130310133635.520094804D@hg.openjdk.java.net>

Changeset: 02b563dff230
Author:    okutsu
Date:      2013-03-10 22:35 +0900
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/02b563dff230

Partial fix for #64: stand-alone text support (pattern letters 'L', 'c', and 'q')
                     Changed pattern letter 'e' to support text.

! src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
! src/share/classes/java/time/format/TextStyle.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java


From scolebourne at joda.org  Sun Mar 10 15:30:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 10 Mar 2013 22:30:26 +0000
Subject: [threeten-dev] RFR, non-webrev, fix eras
Message-ID: 

Variety of fixes and enhancements to eras:
https://gist.github.com/jodastephen/5130788

Stephen

From masayoshi.okutsu at oracle.com  Sun Mar 10 22:04:50 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 11 Mar 2013 14:04:50 +0900
Subject: [threeten-dev] Review request: standalone text support
In-Reply-To: 
References: <513B2D5D.8020007@oracle.com>
	
Message-ID: <513D65F2.40804@oracle.com>

I changed the multiple lines to M/L, e/c, and Q/q. I've filed a new 
issue #278 for improving descriptions of format/standalone forms.

I confirmed that #244 is no longer reproducible.

Thanks,
Masayoshi

On 3/10/2013 12:39 AM, Stephen Colebourne wrote:
> - In the tables of pattern letters, it might be clearer to change the
> first column to "M/L" to avoid duplicating the rest of the column:
>
>   M       month-of-year               number/text       7; 07; Jul; July; J
>   L       month-of-year (stand-alone) number/text       7; 07; Jul; July; J
> change to
>   M/L     month-of-year               number/text       7; 07; Jul; July; J
>
> with the text describing the stand-alone letter is second
>
> - Looks like issue #244 might also be fixed.
>
> Looks good.
> Stephen
>
>
>
> On 9 March 2013 12:38, Masayoshi Okutsu  wrote:
>> I added standalone text support.
>>
>> - Added 'L' (standalone month names), 'c' (standalone day-of-week names),
>> and 'q' (standalone quarter names).
>>
>> - Changed 'e' to support text (format day-of-week names) as well. And "ee"
>> is accepted as a valid pattern. This is consistent with the LDML spec. But
>> let me know if this change shouldn't be made.
>>
>> - "cc" is accepted (as the same pattern as "ee"), which is undefined in the
>> LDML spec.
>>
>> - 6-letters of 'c' and 'e' are handles as invalid patterns.
>>
>> - Added standalone day-of-weeknames to FormatData_fi.java for testing
>> purpose. In JRE fi locale, the format day-of-week names are in the
>> standalone form, while the format and standalone names are different in
>> CLDR. We won't be able to change the format names of the JRE fi locale due
>> to the compatibility risk.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/310/standalonetext/webrev.00
>>
>> Thanks,
>> Masayoshi
>>


From xueming.shen at oracle.com  Mon Mar 11 14:13:51 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Mon, 11 Mar 2013 21:13:51 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated ZoneRegion.java
	for minor startup	performance
Message-ID: <20130311211443.92B544807A@hg.openjdk.java.net>

Changeset: bd4c4e0d8f8a
Author:    sherman
Date:      2013-03-11 14:09 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd4c4e0d8f8a

Updated ZoneRegion.java for minor startup performance

! src/share/classes/java/time/ZoneRegion.java


From patrick.zhang at oracle.com  Mon Mar 11 18:38:10 2013
From: patrick.zhang at oracle.com (Patrick Zhang)
Date: Tue, 12 Mar 2013 09:38:10 +0800
Subject: [threeten-dev] some problems in java.time.YearMonth and
	java.time.Year
In-Reply-To: <513AE160.3050603@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com>
Message-ID: <513E8702.2040803@oracle.com>

Hi,

Any suggestion about it?

Regards
Patrick

On 3/9/13 3:14 PM, patrick zhang wrote:
> Hi Team,
>
> During investigation for java.time.YearMonth and java.time.Year, I 
> have found some problems in it.
>
> 1. Year.minus(TemporalAmout) does not work properly.
> ===========
>         Year year = Year.of(5);
>         Year result = year.minus(Period.ofYears(2)) ;
>         System.out.println(result);
> ===========
> Personally I think above code should work and return Year.of(3). But 
> it throws exception:
> ===========
> Exception in thread "main" java.time.DateTimeException: Unsupported 
> unit: Months
>     at java.time.Year.plus(Year.java:660)
>     at java.time.Year.minus(Year.java:727)
>     at java.time.Year.minus(Year.java:123)
>     at java.time.Period.subtractFrom(Period.java:823)
>     at java.time.Year.minus(Year.java:704)
>     at mytest.TestEra.main(TestEra.java:18)
> ============
>
> 2. javadoc for Year.minus(long, TemporalUnit) is wrong.
> As you know the method will return Year same with minus(TemporalAmout) 
> while it is "YearMonth" in current javadoc:
> ====================
>
> Returns:
>     a |YearMonth| based on this year-month with the specified amount
>     subtracted, not null 
> ====================
>
> 3. javadoc for java.time.Temporal.ChronoUnit.ERAS is confused.
> Here there are 2 problems.
> ====================
> Unit that represents the concept of an era. The ISO calendar system 
> doesn't have eras thus it is impossible to add an era to a date or 
> date-time. The estimated duration of the era is artificially defined 
> as |1,000,00,000 Years|.
> ====================
> I guess it should be 1,000,000,000 years nor |1,000,00,000
>
>
> |====================
>         Year year = Year.of(-1);
>         Year result = year.plus(1, ChronoUnit.ERAS);
>
>         System.out.println(year.get(ChronoField.ERA) + " " + 
> year.get(ChronoField.YEAR_OF_ERA) + " " + year.get(ChronoField.YEAR));
>         System.out.println(result.get(ChronoField.ERA) + " " + 
> result.get(ChronoField.YEAR_OF_ERA) + " " + result.get(ChronoField.YEAR));
>
> output:
> 0 2 -1
> 1 2 2
> ====================
> Since ERAS is not supported in ISO calendar, I think it should not 
> return such a strange result.
> It looks it only plus 1 on ChronoField.ERAS field simply......
>
> Regards
> Patrick

From scolebourne at joda.org  Tue Mar 12 08:11:31 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 12 Mar 2013 15:11:31 +0000
Subject: [threeten-dev] some problems in java.time.YearMonth and
	java.time.Year
In-Reply-To: <513AE160.3050603@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com>
	<512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com>
	<51359FF4.70202@oracle.com> <513AE160.3050603@oracle.com>
Message-ID: 

On 9 March 2013 07:14, patrick zhang  wrote:
> 1. Year.minus(TemporalAmout) does not work properly.
> ===========
>         Year year = Year.of(5);
>         Year result = year.minus(Period.ofYears(2)) ;
>         System.out.println(result);
> ===========
> Personally I think above code should work and return Year.of(3). But it
> throws exception:

This is a bug.

> 2. javadoc for Year.minus(long, TemporalUnit) is wrong.
> As you know the method will return Year same with minus(TemporalAmout) while
> it is "YearMonth" in current javadoc:

This is a bug.

3. javadoc for
> java.time.Temporal.ChronoUnit.ERAS is confused.
> Here there are 2 problems.
> ====================
> Unit that represents the concept of an era. The ISO calendar system doesn't
> have eras thus it is impossible to add an era to a date or date-time. The
> estimated duration of the era is artificially defined as 1,000,00,000 Years.
> ====================
> I guess it should be 1,000,000,000 years nor 1,000,00,000

This is a bug.

> ====================
>         Year year = Year.of(-1);
>         Year result = year.plus(1, ChronoUnit.ERAS);
>
>         System.out.println(year.get(ChronoField.ERA) + " " +
> year.get(ChronoField.YEAR_OF_ERA) + " " + year.get(ChronoField.YEAR));
>         System.out.println(result.get(ChronoField.ERA) + " " +
> result.get(ChronoField.YEAR_OF_ERA) + " " + result.get(ChronoField.YEAR));
>
> output:
> 0 2 -1
> 1 2 2
> ====================
> Since ERAS is not supported in ISO calendar, I think it should not return
> such a strange result.
> It looks it only plus 1 on ChronoField.ERAS field simply......

The ISO calendar system does support eras, see IsoEra. BCE is from
proleptic year 0 backwards and CE is from proleptic year 1 forwards,
just like AD/BC in GregorianCalendar.

The code above is therefore correct, as it changes 2BCE to 2CE.

Stephen

From scolebourne at joda.org  Tue Mar 12 08:28:00 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Tue, 12 Mar 2013 15:28:00 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets
Message-ID: <20130312153047.7D7E3480A8@hg.openjdk.java.net>

Changeset: 72bb5d877b83
Author:    scolebourne
Date:      2013-03-12 14:50 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72bb5d877b83

Test Period plus/minus(Period)

! test/java/time/tck/java/time/TCKPeriod.java

Changeset: 6f798f7dab74
Author:    scolebourne
Date:      2013-03-12 14:54 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6f798f7dab74

Enhance and fix eras

Fix range of Japanese and Hijrah, with tests
Unify Javadoc styles
Add Javadoc tables for year-of-era where appropriate

! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoEra.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
! test/java/time/tck/java/time/chrono/TCKHijrahEra.java
! test/java/time/tck/java/time/chrono/TCKIsoEra.java
! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java

Changeset: 97e8eb496b37
Author:    scolebourne
Date:      2013-03-12 15:25 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/97e8eb496b37

Fix Javadoc

! src/share/classes/java/time/temporal/ChronoUnit.java

Changeset: 0e98b03f696a
Author:    scolebourne
Date:      2013-03-12 15:25 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e98b03f696a

Fix Javadoc

! src/share/classes/java/time/Year.java

Changeset: 0dcbfca54160
Author:    scolebourne
Date:      2013-03-12 15:26 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0dcbfca54160

Fix and test Year.plus/minus(Period.ofYears(n))

! src/share/classes/java/time/Period.java
! test/java/time/tck/java/time/TCKYear.java


From scolebourne at joda.org  Tue Mar 12 08:31:58 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 12 Mar 2013 15:31:58 +0000
Subject: [threeten-dev] RFR, non-webrev, fix eras
In-Reply-To: 
References: 
Message-ID: 

Committed in
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6f798f7dab74

On 10 March 2013 22:30, Stephen Colebourne  wrote:
> Variety of fixes and enhancements to eras:
> https://gist.github.com/jodastephen/5130788
>
> Stephen

From scolebourne at joda.org  Tue Mar 12 08:32:56 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 12 Mar 2013 15:32:56 +0000
Subject: [threeten-dev] some problems in java.time.YearMonth and
	java.time.Year
In-Reply-To: 
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com>
	<512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com>
	<51359FF4.70202@oracle.com> <513AE160.3050603@oracle.com>
	
Message-ID: 

Fixed in
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/97e8eb496b37
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e98b03f696a
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0dcbfca54160

Additional tests in
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72bb5d877b83

thanks
Stephen


On 12 March 2013 15:11, Stephen Colebourne  wrote:
> On 9 March 2013 07:14, patrick zhang  wrote:
>> 1. Year.minus(TemporalAmout) does not work properly.
>> ===========
>>         Year year = Year.of(5);
>>         Year result = year.minus(Period.ofYears(2)) ;
>>         System.out.println(result);
>> ===========
>> Personally I think above code should work and return Year.of(3). But it
>> throws exception:
>
> This is a bug.
>
>> 2. javadoc for Year.minus(long, TemporalUnit) is wrong.
>> As you know the method will return Year same with minus(TemporalAmout) while
>> it is "YearMonth" in current javadoc:
>
> This is a bug.
>
> 3. javadoc for
>> java.time.Temporal.ChronoUnit.ERAS is confused.
>> Here there are 2 problems.
>> ====================
>> Unit that represents the concept of an era. The ISO calendar system doesn't
>> have eras thus it is impossible to add an era to a date or date-time. The
>> estimated duration of the era is artificially defined as 1,000,00,000 Years.
>> ====================
>> I guess it should be 1,000,000,000 years nor 1,000,00,000
>
> This is a bug.
>
>> ====================
>>         Year year = Year.of(-1);
>>         Year result = year.plus(1, ChronoUnit.ERAS);
>>
>>         System.out.println(year.get(ChronoField.ERA) + " " +
>> year.get(ChronoField.YEAR_OF_ERA) + " " + year.get(ChronoField.YEAR));
>>         System.out.println(result.get(ChronoField.ERA) + " " +
>> result.get(ChronoField.YEAR_OF_ERA) + " " + result.get(ChronoField.YEAR));
>>
>> output:
>> 0 2 -1
>> 1 2 2
>> ====================
>> Since ERAS is not supported in ISO calendar, I think it should not return
>> such a strange result.
>> It looks it only plus 1 on ChronoField.ERAS field simply......
>
> The ISO calendar system does support eras, see IsoEra. BCE is from
> proleptic year 0 backwards and CE is from proleptic year 1 forwards,
> just like AD/BC in GregorianCalendar.
>
> The code above is therefore correct, as it changes 2BCE to 2CE.
>
> Stephen

From xueming.shen at oracle.com  Tue Mar 12 14:52:02 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 12 Mar 2013 14:52:02 -0700
Subject: [threeten-dev] Some observations of chrono ser
Message-ID: <513FA382.3070309@oracle.com>

Hi,

(1) Chronology.writeReplace() is private, so the proxy Ser mechanism
is actually disabled for all Chronology subclasses. Is it intentional? Given
all JDK subclasses all have readResolve() defined (3 out of 4 to return
the singleton) I would assume the Ser delegation might not be necessary,
though it might be still desirable to "enforce" the Ser pattern here?

(2) Chronology.initCache() tries to load the Chronology implementation
from the ServiceLoader before initializing/registering the built-ins, is it
intentional? If yes, the current implementation as described in (1) may
have an un-desired impact to this design intention. For example, if a
Japanese Chronology in a VM with built-in ja chronology is transferred
to a VM that has a "customized" Japanese Chronology registered, the
current implementation may force to use the built-in (as the Ser mechanism
is off/out now), the Chronology.of(id) logic in Chronology.readExternal()
will never kick in and the "registered/customized" Japanese chronology
will not be used for the deser-ed chronology.

(3) ChronoDateImpl also declares "Serializable", given all its subclasses have
their own declaration of Serializable() and the writeReplace()/write/read
External(), this might not be necessary?

-Sherman

From patrick.zhang at oracle.com  Tue Mar 12 19:21:11 2013
From: patrick.zhang at oracle.com (Patrick Zhang)
Date: Wed, 13 Mar 2013 10:21:11 +0800
Subject: [threeten-dev] some problems in java.time.YearMonth and
	java.time.Year
In-Reply-To: 
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com>
	
	
Message-ID: <513FE297.1080801@oracle.com>

Hi Stephen,

Thanks. I will update the repo and try again. :)

Regards
Patrick

On 3/12/13 11:32 PM, Stephen Colebourne wrote:
> Fixed in
> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/97e8eb496b37
> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e98b03f696a
> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0dcbfca54160
>
> Additional tests in
> http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72bb5d877b83
>
> thanks
> Stephen
>
>
> On 12 March 2013 15:11, Stephen Colebourne  wrote:
>> On 9 March 2013 07:14, patrick zhang  wrote:
>>> 1. Year.minus(TemporalAmout) does not work properly.
>>> ===========
>>>          Year year = Year.of(5);
>>>          Year result = year.minus(Period.ofYears(2)) ;
>>>          System.out.println(result);
>>> ===========
>>> Personally I think above code should work and return Year.of(3). But it
>>> throws exception:
>> This is a bug.
>>
>>> 2. javadoc for Year.minus(long, TemporalUnit) is wrong.
>>> As you know the method will return Year same with minus(TemporalAmout) while
>>> it is "YearMonth" in current javadoc:
>> This is a bug.
>>
>> 3. javadoc for
>>> java.time.Temporal.ChronoUnit.ERAS is confused.
>>> Here there are 2 problems.
>>> ====================
>>> Unit that represents the concept of an era. The ISO calendar system doesn't
>>> have eras thus it is impossible to add an era to a date or date-time. The
>>> estimated duration of the era is artificially defined as 1,000,00,000 Years.
>>> ====================
>>> I guess it should be 1,000,000,000 years nor 1,000,00,000
>> This is a bug.
>>
>>> ====================
>>>          Year year = Year.of(-1);
>>>          Year result = year.plus(1, ChronoUnit.ERAS);
>>>
>>>          System.out.println(year.get(ChronoField.ERA) + " " +
>>> year.get(ChronoField.YEAR_OF_ERA) + " " + year.get(ChronoField.YEAR));
>>>          System.out.println(result.get(ChronoField.ERA) + " " +
>>> result.get(ChronoField.YEAR_OF_ERA) + " " + result.get(ChronoField.YEAR));
>>>
>>> output:
>>> 0 2 -1
>>> 1 2 2
>>> ====================
>>> Since ERAS is not supported in ISO calendar, I think it should not return
>>> such a strange result.
>>> It looks it only plus 1 on ChronoField.ERAS field simply......
>> The ISO calendar system does support eras, see IsoEra. BCE is from
>> proleptic year 0 backwards and CE is from proleptic year 1 forwards,
>> just like AD/BC in GregorianCalendar.
>>
>> The code above is therefore correct, as it changes 2BCE to 2CE.
>>
>> Stephen

From patrick.zhang at oracle.com  Tue Mar 12 21:37:52 2013
From: patrick.zhang at oracle.com (Patrick Zhang)
Date: Wed, 13 Mar 2013 12:37:52 +0800
Subject: [threeten-dev]  what happened to JapaneseChronology?
In-Reply-To: <513E8702.2040803@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com> <513E8702.2040803@oracle.com>
Message-ID: <514002A0.8010604@oracle.com>

Hi Team,

What happened to JapaneseChronology? It will not support the later 2 
eras? It looks it is one new failure and I do not meet it on last week.
=============
System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.MEIJI, 
1, 1, 1));
System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 
1, 1, 1));
System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SEIREKI, 
1, 1, 1));
System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SHOWA, 
1, 1, 1));       //will throw exception
System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.TAISHO, 
1, 1, 1));       //will throw exception
==============

Exception info:
==============
Exception in thread "main" java.lang.IllegalArgumentException
     at java.time.chrono.JapaneseDate.of(JapaneseDate.java:256)
     at 
java.time.chrono.JapaneseChronology.date(JapaneseChronology.java:166)
     at Test.f1(Test.java:17)
     at Test.main(Test.java:5)
==============

Regards
Patrick



From xueming.shen at oracle.com  Wed Mar 13 19:51:45 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 13 Mar 2013 19:51:45 -0700
Subject: [threeten-dev] [JSR310 M7 Review request] 8007572: Replace
 existing jdk timezone data at /lib/zi with JSR310's tzdb.
In-Reply-To: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com>
References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com>
Message-ID: <51413B41.4010305@oracle.com>

This should have been addessed via

JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems 
with hs25-b19 control job* 

-Sherman

On 3/13/13 7:19 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> The build part of this review looks good to me.
>>
> Judging by this changeset, I gather javazic is no longer being run.
> If so, why is the source code being retained in the tree?  It means
> that a build of OpenJDK against itself now fails.  The new
> build system currently finds the javazic source code and tries to compile it,
> but fails because ZoneInfoFile.java has changed and Gen.java can no longer
> compile against it.  Deleting the javazic source code fixes the
> build.
>
> Any reason not to commit this?
>
> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/
>
>> /Erik
>>
>> On 2013-02-07 19:31, Xueming Shen wrote:
>>> Hi,
>>>
>>> 8007572: Replace existing jdk timezone data at /lib/zi
>>> with
>>> JSR310's tzdb.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sherman/8007572/
>>>
>>> Note:
>>> JDK/JRE has been using the time zone data at /lib/zi for
>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own
>>> time zone data file/format lib/tzdb.jar to provide the
>>> time
>>> zone data support for its new java.time date-time classes.
>>>
>>> So we now have two different time zone data files in different
>>> formats
>>> (though from the same time zone data source, Olson tz data, now the
>>> IANA
>>> Time Zone Datebase) to support two sets of date-time APIs
>>> (java.util
>>> date-time classes and java.time date-time classes) in one JDK/JRE,
>>> which
>>> definitely will add the maintenance burden going forward, given the
>>> fact
>>> that we will have to update/distribute the latest tzdb data in
>>> JDK/JRE
>>> periodically [2].
>>>
>>> Also the current way the time-zone data is being
>>> distributed/installed
>>> (at /lib.zi, as individual file for each time zone) has
>>> been
>>> a footprint concern for some configurations, especially the small
>>> embedded
>>> environment. The JEP151 [3] was originally submitted to propose to
>>> store
>>> the time-zone data more efficiently into a single compressed file.
>>> The
>>> JEP 151 has been withdrawn since, with the assumption that JDK 8
>>> may
>>> replace the "zi" data with the much smaller JSR310 tzdb data file.
>>>
>>> As indicated in JEP151, current installed "zi" directory probably
>>> takes
>>> up 1M of disk-space with the 0.5k default file-system-block-size.
>>> Even
>>> with the proposed "store in one single compressed file" approach,
>>> it will
>>> still take about 250K space for all tzdb data in "zi" directory.
>>> JSR310
>>> tzdb data file however is much smaller. It is around 40K for
>>> compressed
>>> and 100k uncompressed, for the same tz data.
>>>
>>> The proposed change is to share the JSR310 time zone data tzdb.jar
>>> with j.u.TimeZone by converting the JSR310 tzdb data completely
>>> (bits
>>> to bits compatible) at runtime into the internal data structure
>>> that
>>> j.u.TimeZone needs for its time zone data functionality/needs.
>>>
>>> Thanks!
>>> -Sherman
>>>
>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123
>>> [2]
>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html
>>> [3] http://openjdk.java.net/jeps/151


From Alan.Bateman at oracle.com  Wed Mar 13 23:47:09 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Mar 2013 06:47:09 +0000
Subject: [threeten-dev] [JSR310 M7 Review request] 8007572: Replace
 existing jdk timezone data at /lib/zi with JSR310's tzdb.
In-Reply-To: <51413B41.4010305@oracle.com>
References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com>
	<51413B41.4010305@oracle.com>
Message-ID: <5141726D.2090107@oracle.com>

On 14/03/2013 02:51, Xueming Shen wrote:
> This should have been addessed via
>
> JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems 
> with hs25-b19 control job* 
> 
>
Right, this was fixed several weeks ago with:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3

There are a lot of changes backed up in jdk8/tl due to several issues. 
Lana Steuck will be integrating them into jdk8/jdk8 soon.

-Alan.




From gnu.andrew at redhat.com  Wed Mar 13 19:19:45 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Mar 2013 22:19:45 -0400 (EDT)
Subject: [threeten-dev] [JSR310 M7 Review request] 8007572: Replace
 existing jdk timezone	data at /lib/zi with JSR310's tzdb.
In-Reply-To: <5114CABE.3070809@oracle.com>
Message-ID: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com>

----- Original Message -----
> The build part of this review looks good to me.
> 

Judging by this changeset, I gather javazic is no longer being run.
If so, why is the source code being retained in the tree?  It means
that a build of OpenJDK against itself now fails.  The new
build system currently finds the javazic source code and tries to compile it,
but fails because ZoneInfoFile.java has changed and Gen.java can no longer
compile against it.  Deleting the javazic source code fixes the
build.

Any reason not to commit this?

http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/

> /Erik
> 
> On 2013-02-07 19:31, Xueming Shen wrote:
> > Hi,
> >
> > 8007572: Replace existing jdk timezone data at /lib/zi
> > with
> > JSR310's tzdb.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~sherman/8007572/
> >
> > Note:
> > JDK/JRE has been using the time zone data at /lib/zi for
> > j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own
> > time zone data file/format lib/tzdb.jar to provide the
> > time
> > zone data support for its new java.time date-time classes.
> >
> > So we now have two different time zone data files in different
> > formats
> > (though from the same time zone data source, Olson tz data, now the
> > IANA
> > Time Zone Datebase) to support two sets of date-time APIs
> > (java.util
> > date-time classes and java.time date-time classes) in one JDK/JRE,
> > which
> > definitely will add the maintenance burden going forward, given the
> > fact
> > that we will have to update/distribute the latest tzdb data in
> > JDK/JRE
> > periodically [2].
> >
> > Also the current way the time-zone data is being
> > distributed/installed
> > (at /lib.zi, as individual file for each time zone) has
> > been
> > a footprint concern for some configurations, especially the small
> > embedded
> > environment. The JEP151 [3] was originally submitted to propose to
> > store
> > the time-zone data more efficiently into a single compressed file.
> > The
> > JEP 151 has been withdrawn since, with the assumption that JDK 8
> > may
> > replace the "zi" data with the much smaller JSR310 tzdb data file.
> >
> > As indicated in JEP151, current installed "zi" directory probably
> > takes
> > up 1M of disk-space with the 0.5k default file-system-block-size.
> > Even
> > with the proposed "store in one single compressed file" approach,
> > it will
> > still take about 250K space for all tzdb data in "zi" directory.
> > JSR310
> > tzdb data file however is much smaller. It is around 40K for
> > compressed
> > and 100k uncompressed, for the same tz data.
> >
> > The proposed change is to share the JSR310 time zone data tzdb.jar
> > with j.u.TimeZone by converting the JSR310 tzdb data completely
> > (bits
> > to bits compatible) at runtime into the internal data structure
> > that
> > j.u.TimeZone needs for its time zone data functionality/needs.
> >
> > Thanks!
> > -Sherman
> >
> > [1] https://jbs.oracle.com/bugs/browse/JDK-4230123
> > [2]
> > http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html
> > [3] http://openjdk.java.net/jeps/151
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From david.holmes at oracle.com  Wed Mar 13 21:26:28 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Mar 2013 14:26:28 +1000
Subject: [threeten-dev] [JSR310 M7 Review request] 8007572: Replace
 existing jdk timezone data at /lib/zi with JSR310's tzdb.
In-Reply-To: <51413B41.4010305@oracle.com>
References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com>
	<51413B41.4010305@oracle.com>
Message-ID: <51415174.5010309@oracle.com>

On 14/03/2013 12:51 PM, Xueming Shen wrote:
> This should have been addessed via
>
> JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems
> with hs25-b19 control job* 

Which is still in the tl repo and unlikely to reach jdk8/jdk8 till b82 
promotion next week.

David

> -Sherman
>
> On 3/13/13 7:19 PM, Andrew Hughes wrote:
>> ----- Original Message -----
>>> The build part of this review looks good to me.
>>>
>> Judging by this changeset, I gather javazic is no longer being run.
>> If so, why is the source code being retained in the tree?  It means
>> that a build of OpenJDK against itself now fails.  The new
>> build system currently finds the javazic source code and tries to
>> compile it,
>> but fails because ZoneInfoFile.java has changed and Gen.java can no
>> longer
>> compile against it.  Deleting the javazic source code fixes the
>> build.
>>
>> Any reason not to commit this?
>>
>> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/
>>
>>> /Erik
>>>
>>> On 2013-02-07 19:31, Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> 8007572: Replace existing jdk timezone data at /lib/zi
>>>> with
>>>> JSR310's tzdb.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sherman/8007572/
>>>>
>>>> Note:
>>>> JDK/JRE has been using the time zone data at /lib/zi for
>>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own
>>>> time zone data file/format lib/tzdb.jar to provide the
>>>> time
>>>> zone data support for its new java.time date-time classes.
>>>>
>>>> So we now have two different time zone data files in different
>>>> formats
>>>> (though from the same time zone data source, Olson tz data, now the
>>>> IANA
>>>> Time Zone Datebase) to support two sets of date-time APIs
>>>> (java.util
>>>> date-time classes and java.time date-time classes) in one JDK/JRE,
>>>> which
>>>> definitely will add the maintenance burden going forward, given the
>>>> fact
>>>> that we will have to update/distribute the latest tzdb data in
>>>> JDK/JRE
>>>> periodically [2].
>>>>
>>>> Also the current way the time-zone data is being
>>>> distributed/installed
>>>> (at /lib.zi, as individual file for each time zone) has
>>>> been
>>>> a footprint concern for some configurations, especially the small
>>>> embedded
>>>> environment. The JEP151 [3] was originally submitted to propose to
>>>> store
>>>> the time-zone data more efficiently into a single compressed file.
>>>> The
>>>> JEP 151 has been withdrawn since, with the assumption that JDK 8
>>>> may
>>>> replace the "zi" data with the much smaller JSR310 tzdb data file.
>>>>
>>>> As indicated in JEP151, current installed "zi" directory probably
>>>> takes
>>>> up 1M of disk-space with the 0.5k default file-system-block-size.
>>>> Even
>>>> with the proposed "store in one single compressed file" approach,
>>>> it will
>>>> still take about 250K space for all tzdb data in "zi" directory.
>>>> JSR310
>>>> tzdb data file however is much smaller. It is around 40K for
>>>> compressed
>>>> and 100k uncompressed, for the same tz data.
>>>>
>>>> The proposed change is to share the JSR310 time zone data tzdb.jar
>>>> with j.u.TimeZone by converting the JSR310 tzdb data completely
>>>> (bits
>>>> to bits compatible) at runtime into the internal data structure
>>>> that
>>>> j.u.TimeZone needs for its time zone data functionality/needs.
>>>>
>>>> Thanks!
>>>> -Sherman
>>>>
>>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123
>>>> [2]
>>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html
>>>>
>>>> [3] http://openjdk.java.net/jeps/151
>

From roger.riggs at oracle.com  Thu Mar 14 07:29:35 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 14 Mar 2013 10:29:35 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <513FA382.3070309@oracle.com>
References: <513FA382.3070309@oracle.com>
Message-ID: <5141DECF.8010905@oracle.com>

Hi  Sherman,

On 3/12/2013 5:52 PM, Xueming Shen wrote:
> Hi,
>
> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
> is actually disabled for all Chronology subclasses. Is it intentional? 
> Given
> all JDK subclasses all have readResolve() defined (3 out of 4 to return
> the singleton) I would assume the Ser delegation might not be necessary,
> though it might be still desirable to "enforce" the Ser pattern here?
Not quite, but still broken.  The writeReplace method can be private but
is used only if the Chronology class is Serializable.
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324

The subclasses are serializable and that is triggering the default 
serialization.

Is there an issue for this?
>
> (2) Chronology.initCache() tries to load the Chronology implementation
> from the ServiceLoader before initializing/registering the built-ins, 
> is it
> intentional? If yes, the current implementation as described in (1) may
> have an un-desired impact to this design intention. For example, if a
> Japanese Chronology in a VM with built-in ja chronology is transferred
> to a VM that has a "customized" Japanese Chronology registered, the
> current implementation may force to use the built-in (as the Ser 
> mechanism
> is off/out now), the Chronology.of(id) logic in Chronology.readExternal()
> will never kick in and the "registered/customized" Japanese chronology
> will not be used for the deser-ed chronology.
It was intentional that the ServiceLoader defined Chronologies would
supercede the built-in ones allowing replacement if as part of 
customization.
It may deserve more discussion.

>
> (3) ChronoDateImpl also declares "Serializable", given all its 
> subclasses have
> their own declaration of Serializable() and the writeReplace()/write/read
> External(), this might not be necessary?
It does seem unnecessary duplication.

Roger

>
> -Sherman

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From xueming.shen at oracle.com  Thu Mar 14 08:40:47 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 14 Mar 2013 08:40:47 -0700
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <5141DECF.8010905@oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
Message-ID: <5141EF7F.7050807@oracle.com>

On 3/14/13 7:29 AM, roger riggs wrote:
> Hi  Sherman,
>
> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>> Hi,
>>
>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>> is actually disabled for all Chronology subclasses. Is it 
>> intentional? Given
>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>> the singleton) I would assume the Ser delegation might not be necessary,
>> though it might be still desirable to "enforce" the Ser pattern here?
> Not quite, but still broken.  The writeReplace method can be private but
> is used only if the Chronology class is Serializable.
> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>
> The subclasses are serializable and that is triggering the default 
> serialization.
>
> Is there an issue for this?

I think a private writeReplace method don't have an effect on how its 
serializable
subclass serializes itself. So I believe the existing 4 jdk Chronology 
subclasses
are using the "jdk default mechanism" (not the Ser delegation/proxy), so 
I was
asking if it is an intentional design/implementation. For any other 
potential
user defined Chronology subclass, does the abstract Chronology have anything
really need to be "serializable" and via the Ser mechanism? Two possible 
designs
here

(1) we want all the Chronology subclasses to be serialized via "Ser" 
(then it can
be done via the Chronology.of(...) when read in), then the 
writeReplace() probably
should be declared as non-private?

(2) if we don't want to enforce the "Ser" serialization for all its 
subclasses, then
the writeReplace() may not need to be defined at all in Chronology?

-Sherman
>>
>> (2) Chronology.initCache() tries to load the Chronology implementation
>> from the ServiceLoader before initializing/registering the built-ins, 
>> is it
>> intentional? If yes, the current implementation as described in (1) may
>> have an un-desired impact to this design intention. For example, if a
>> Japanese Chronology in a VM with built-in ja chronology is transferred
>> to a VM that has a "customized" Japanese Chronology registered, the
>> current implementation may force to use the built-in (as the Ser 
>> mechanism
>> is off/out now), the Chronology.of(id) logic in 
>> Chronology.readExternal()
>> will never kick in and the "registered/customized" Japanese chronology
>> will not be used for the deser-ed chronology.
> It was intentional that the ServiceLoader defined Chronologies would
> supercede the built-in ones allowing replacement if as part of 
> customization.
> It may deserve more discussion.
>
>>
>> (3) ChronoDateImpl also declares "Serializable", given all its 
>> subclasses have
>> their own declaration of Serializable() and the 
>> writeReplace()/write/read
>> External(), this might not be necessary?
> It does seem unnecessary duplication.
>
> Roger
>
>>
>> -Sherman
>
> -- 
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Green Oracle  Oracle is committed to 
> developing practices and products that help protect the environment
>


From gnu.andrew at redhat.com  Thu Mar 14 09:10:14 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 14 Mar 2013 12:10:14 -0400 (EDT)
Subject: [threeten-dev] [JSR310 M7 Review request] 8007572: Replace
 existing jdk timezone data at /lib/zi with JSR310's tzdb.
In-Reply-To: <51415174.5010309@oracle.com>
Message-ID: <155408043.18863217.1363277414103.JavaMail.root@redhat.com>

----- Original Message -----
> On 14/03/2013 12:51 PM, Xueming Shen wrote:
> > This should have been addessed via
> >
> > JDK-8008348 *The leftover jdk/make/tools/javazic causes build
> > problems
> > with hs25-b19 control job*
> > 
> 
> Which is still in the tl repo and unlikely to reach jdk8/jdk8 till
> b82
> promotion next week.
> 

Yep, that's exactly why I'm seeing it.  This is in an IcedTea build
using the latest build drop, b80.

Glad it's been caught and dealt with :)

> David
> 
> > -Sherman
> >
> > On 3/13/13 7:19 PM, Andrew Hughes wrote:
> >> ----- Original Message -----
> >>> The build part of this review looks good to me.
> >>>
> >> Judging by this changeset, I gather javazic is no longer being
> >> run.
> >> If so, why is the source code being retained in the tree?  It
> >> means
> >> that a build of OpenJDK against itself now fails.  The new
> >> build system currently finds the javazic source code and tries to
> >> compile it,
> >> but fails because ZoneInfoFile.java has changed and Gen.java can
> >> no
> >> longer
> >> compile against it.  Deleting the javazic source code fixes the
> >> build.
> >>
> >> Any reason not to commit this?
> >>
> >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/
> >>
> >>> /Erik
> >>>
> >>> On 2013-02-07 19:31, Xueming Shen wrote:
> >>>> Hi,
> >>>>
> >>>> 8007572: Replace existing jdk timezone data at
> >>>> /lib/zi
> >>>> with
> >>>> JSR310's tzdb.
> >>>>
> >>>> Webrev:
> >>>> http://cr.openjdk.java.net/~sherman/8007572/
> >>>>
> >>>> Note:
> >>>> JDK/JRE has been using the time zone data at /lib/zi
> >>>> for
> >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its
> >>>> own
> >>>> time zone data file/format lib/tzdb.jar to provide
> >>>> the
> >>>> time
> >>>> zone data support for its new java.time date-time classes.
> >>>>
> >>>> So we now have two different time zone data files in different
> >>>> formats
> >>>> (though from the same time zone data source, Olson tz data, now
> >>>> the
> >>>> IANA
> >>>> Time Zone Datebase) to support two sets of date-time APIs
> >>>> (java.util
> >>>> date-time classes and java.time date-time classes) in one
> >>>> JDK/JRE,
> >>>> which
> >>>> definitely will add the maintenance burden going forward, given
> >>>> the
> >>>> fact
> >>>> that we will have to update/distribute the latest tzdb data in
> >>>> JDK/JRE
> >>>> periodically [2].
> >>>>
> >>>> Also the current way the time-zone data is being
> >>>> distributed/installed
> >>>> (at /lib.zi, as individual file for each time zone)
> >>>> has
> >>>> been
> >>>> a footprint concern for some configurations, especially the
> >>>> small
> >>>> embedded
> >>>> environment. The JEP151 [3] was originally submitted to propose
> >>>> to
> >>>> store
> >>>> the time-zone data more efficiently into a single compressed
> >>>> file.
> >>>> The
> >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8
> >>>> may
> >>>> replace the "zi" data with the much smaller JSR310 tzdb data
> >>>> file.
> >>>>
> >>>> As indicated in JEP151, current installed "zi" directory
> >>>> probably
> >>>> takes
> >>>> up 1M of disk-space with the 0.5k default
> >>>> file-system-block-size.
> >>>> Even
> >>>> with the proposed "store in one single compressed file"
> >>>> approach,
> >>>> it will
> >>>> still take about 250K space for all tzdb data in "zi" directory.
> >>>> JSR310
> >>>> tzdb data file however is much smaller. It is around 40K for
> >>>> compressed
> >>>> and 100k uncompressed, for the same tz data.
> >>>>
> >>>> The proposed change is to share the JSR310 time zone data
> >>>> tzdb.jar
> >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely
> >>>> (bits
> >>>> to bits compatible) at runtime into the internal data structure
> >>>> that
> >>>> j.u.TimeZone needs for its time zone data functionality/needs.
> >>>>
> >>>> Thanks!
> >>>> -Sherman
> >>>>
> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123
> >>>> [2]
> >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html
> >>>>
> >>>> [3] http://openjdk.java.net/jeps/151
> >
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From roger.riggs at oracle.com  Thu Mar 14 10:42:10 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 14 Mar 2013 13:42:10 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <5141EF7F.7050807@oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
	<5141EF7F.7050807@oracle.com>
Message-ID: <51420BF2.5030602@oracle.com>

Hi,

On 3/14/2013 11:40 AM, Xueming Shen wrote:
> On 3/14/13 7:29 AM, roger riggs wrote:
>> Hi  Sherman,
>>
>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>> is actually disabled for all Chronology subclasses. Is it 
>>> intentional? Given
>>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>>> the singleton) I would assume the Ser delegation might not be 
>>> necessary,
>>> though it might be still desirable to "enforce" the Ser pattern here?
>> Not quite, but still broken.  The writeReplace method can be private but
>> is used only if the Chronology class is Serializable.
>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>
>> The subclasses are serializable and that is triggering the default 
>> serialization.
>>
>> Is there an issue for this?
>
> I think a private writeReplace method don't have an effect on how its 
> serializable
> subclass serializes itself. So I believe the existing 4 jdk Chronology 
> subclasses
> are using the "jdk default mechanism" (not the Ser delegation/proxy), 
> so I was
> asking if it is an intentional design/implementation. For any other 
> potential
> user defined Chronology subclass, does the abstract Chronology have 
> anything
> really need to be "serializable" and via the Ser mechanism? Two 
> possible designs
> here
>
> (1) we want all the Chronology subclasses to be serialized via "Ser" 
> (then it can
> be done via the Chronology.of(...) when read in), then the 
> writeReplace() probably
> should be declared as non-private?
The intent was that Chronology would always handle serialization
and return the same (singleton) instances that are known to Chronology.

To make that work the writeReplace method needs to be "protected final"
and visible to subclasses and not be override-able.

>
> (2) if we don't want to enforce the "Ser" serialization for all its 
> subclasses, then
> the writeReplace() may not need to be defined at all in Chronology?

Roger

>
> -Sherman
>>>
>>> (2) Chronology.initCache() tries to load the Chronology implementation
>>> from the ServiceLoader before initializing/registering the 
>>> built-ins, is it
>>> intentional? If yes, the current implementation as described in (1) may
>>> have an un-desired impact to this design intention. For example, if a
>>> Japanese Chronology in a VM with built-in ja chronology is transferred
>>> to a VM that has a "customized" Japanese Chronology registered, the
>>> current implementation may force to use the built-in (as the Ser 
>>> mechanism
>>> is off/out now), the Chronology.of(id) logic in 
>>> Chronology.readExternal()
>>> will never kick in and the "registered/customized" Japanese chronology
>>> will not be used for the deser-ed chronology.
>> It was intentional that the ServiceLoader defined Chronologies would
>> supercede the built-in ones allowing replacement if as part of 
>> customization.
>> It may deserve more discussion.
>>
>>>
>>> (3) ChronoDateImpl also declares "Serializable", given all its 
>>> subclasses have
>>> their own declaration of Serializable() and the 
>>> writeReplace()/write/read
>>> External(), this might not be necessary?
>> It does seem unnecessary duplication.
>>
>> Roger
>>
>>>
>>> -Sherman
>>
>> -- 
>> Thanks, Roger
>>
>> Oracle Java Platform Group
>>
>> Green Oracle  Oracle is committed 
>> to developing practices and products that help protect the environment
>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From roger.riggs at oracle.com  Thu Mar 14 12:35:31 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 14 Mar 2013 15:35:31 -0400
Subject: [threeten-dev] Serialization of Chronology
Message-ID: <51422683.6000000@oracle.com>

Please review updates to address issues #283 and #279.

#283: Serialization of Chronology
#279 Inconsistent serialization for ISO chronology

Cleaned up serialization for all Chronologies and added tests.
Subclasses are enabled (as is ISOChronology) to use the Ser mechanism of 
Chronology.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/

Thanks, Roger


From xueming.shen at oracle.com  Thu Mar 14 12:33:13 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 14 Mar 2013 12:33:13 -0700
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <51420BF2.5030602@oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
	<5141EF7F.7050807@oracle.com> <51420BF2.5030602@oracle.com>
Message-ID: <514225F9.2090105@oracle.com>

On 03/14/2013 10:42 AM, roger riggs wrote:
> Hi,
>
> On 3/14/2013 11:40 AM, Xueming Shen wrote:
>> On 3/14/13 7:29 AM, roger riggs wrote:
>>> Hi  Sherman,
>>>
>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>> is actually disabled for all Chronology subclasses. Is it intentional? Given
>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>>>> the singleton) I would assume the Ser delegation might not be necessary,
>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>> Not quite, but still broken.  The writeReplace method can be private but
>>> is used only if the Chronology class is Serializable.
>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>
>>> The subclasses are serializable and that is triggering the default serialization.
>>>
>>> Is there an issue for this?
>>
>> I think a private writeReplace method don't have an effect on how its serializable
>> subclass serializes itself. So I believe the existing 4 jdk Chronology subclasses
>> are using the "jdk default mechanism" (not the Ser delegation/proxy), so I was
>> asking if it is an intentional design/implementation. For any other potential
>> user defined Chronology subclass, does the abstract Chronology have anything
>> really need to be "serializable" and via the Ser mechanism? Two possible designs
>> here
>>
>> (1) we want all the Chronology subclasses to be serialized via "Ser" (then it can
>> be done via the Chronology.of(...) when read in), then the writeReplace() probably
>> should be declared as non-private?
> The intent was that Chronology would always handle serialization
> and return the same (singleton) instances that are known to Chronology.
>
> To make that work the writeReplace method needs to be "protected final"
> and visible to subclasses and not be override-able.
>

Something like the attached webrev?

http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono

Do we really to make it "final" to enforce the abstract base class Chronology to
always handle the serialization? Or be liberal to document that this is encouraged,
but not enforced, with a "non-final" Chronology.writeReplace()

Second question leads to my (2) in previous email. With the enforcement of
Chronology.writeReplace()
     ->Ser
         ->Chronology.readExternal()
             ->Chronology.of/of0(id)
                 ->cache.

A Chronology instance may be serialized from a vm default impl to a user-defined
Chronology in other vm, if there is overriding Chronology implementation, however,
a built-in ChronoLocalDate, for example JapaneseDate, is always hard-wired to the
built-in JapaneseChronology, so if you serialize and de-serialize a JapaneseChronology
AND a JapaneseDate into other vm, you may get a user-defined JapaneseChronology
and a built-in JapneseDate with bundled with a built-in JapaneseChronology, something
undesired?

-Sherman



From xueming.shen at oracle.com  Thu Mar 14 13:28:17 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 14 Mar 2013 13:28:17 -0700
Subject: [threeten-dev] Serialization of Chronology
In-Reply-To: <51422683.6000000@oracle.com>
References: <51422683.6000000@oracle.com>
Message-ID: <514232E1.5030900@oracle.com>

The readResolve() in other chronology subclasses are also un-necessary
if we delegate to Ser. The Chronology.readExternal() should guarantee
the singleton via the of() lookup. But we still need to address the built-in
and user-defined override issue.

-Sherman

On 03/14/2013 12:35 PM, roger riggs wrote:
> Please review updates to address issues #283 and #279.
>
> #283: Serialization of Chronology
> #279 Inconsistent serialization for ISO chronology
>
> Cleaned up serialization for all Chronologies and added tests.
> Subclasses are enabled (as is ISOChronology) to use the Ser mechanism of Chronology.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>
> Thanks, Roger
>


From Roger.Riggs at Oracle.com  Thu Mar 14 18:07:34 2013
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 14 Mar 2013 21:07:34 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <514225F9.2090105@oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
	<5141EF7F.7050807@oracle.com> <51420BF2.5030602@oracle.com>
	<514225F9.2090105@oracle.com>
Message-ID: <51427456.6040001@Oracle.com>

Hi Sherman,

Sorry for the race condition, I was trying out a few things...

On 3/14/13 3:33 PM, Xueming Shen wrote:
> On 03/14/2013 10:42 AM, roger riggs wrote:
>> Hi,
>>
>> On 3/14/2013 11:40 AM, Xueming Shen wrote:
>>> On 3/14/13 7:29 AM, roger riggs wrote:
>>>> Hi  Sherman,
>>>>
>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>> Hi,
>>>>>
>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>> is actually disabled for all Chronology subclasses. Is it 
>>>>> intentional? Given
>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to 
>>>>> return
>>>>> the singleton) I would assume the Ser delegation might not be 
>>>>> necessary,
>>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>>> Not quite, but still broken.  The writeReplace method can be 
>>>> private but
>>>> is used only if the Chronology class is Serializable.
>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>>
>>>> The subclasses are serializable and that is triggering the default 
>>>> serialization.
>>>>
>>>> Is there an issue for this?
>>>
>>> I think a private writeReplace method don't have an effect on how 
>>> its serializable
>>> subclass serializes itself. So I believe the existing 4 jdk 
>>> Chronology subclasses
>>> are using the "jdk default mechanism" (not the Ser 
>>> delegation/proxy), so I was
>>> asking if it is an intentional design/implementation. For any other 
>>> potential
>>> user defined Chronology subclass, does the abstract Chronology have 
>>> anything
>>> really need to be "serializable" and via the Ser mechanism? Two 
>>> possible designs
>>> here
>>>
>>> (1) we want all the Chronology subclasses to be serialized via "Ser" 
>>> (then it can
>>> be done via the Chronology.of(...) when read in), then the 
>>> writeReplace() probably
>>> should be declared as non-private?
>> The intent was that Chronology would always handle serialization
>> and return the same (singleton) instances that are known to Chronology.
>>
>> To make that work the writeReplace method needs to be "protected final"
>> and visible to subclasses and not be override-able.
>>
>
> Something like the attached webrev?
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
Yes, same as what I did.
>
> Do we really to make it "final" to enforce the abstract base class 
> Chronology to
> always handle the serialization? Or be liberal to document that this 
> is encouraged,
> but not enforced, with a "non-final" Chronology.writeReplace()

I went with non-final because as final it would prevent subclassing a 
Chronology
that had its own state to serialize, like the HijrahChronology that has 
variants.
It seems inflexible to prevent that from anything but bundled Chronologies.
>
> Second question leads to my (2) in previous email. With the enforcement of
> Chronology.writeReplace()
>     ->Ser
>         ->Chronology.readExternal()
>             ->Chronology.of/of0(id)
>                 ->cache.
>
> A Chronology instance may be serialized from a vm default impl to a 
> user-defined
> Chronology in other vm, if there is overriding Chronology 
> implementation, however,
> a built-in ChronoLocalDate, for example JapaneseDate, is always 
> hard-wired to the
> built-in JapaneseChronology, so if you serialize and de-serialize a 
> JapaneseChronology
> AND a JapaneseDate into other vm, you may get a user-defined 
> JapaneseChronology
> and a built-in JapneseDate with bundled with a built-in 
> JapaneseChronology, something
> undesired?
I suppose there is little benefit from allowing the built-in chronologies to
be overridden and it does open up some potential problems.
To insure consistency, JapaneseDate could use Chronology.of("Japanese") 
to get
the Chronology but that adds very little and will be slower.

If we do away with the override then there should be at least a log
message if the register of the ServiceLoader chronology fails.

Also, note that the synchronization on whether initialization is complete
is based on finding ISOChronology in the HashTable.  That would need
a different mechanism. (Its ok for multiple threads to do the init 
concurrently
only one will win and it avoids a single threaded synchronization.)

Roger

>
> -Sherman
>
>


From patrick.zhang at oracle.com  Fri Mar 15 01:27:43 2013
From: patrick.zhang at oracle.com (patrick zhang)
Date: Fri, 15 Mar 2013 16:27:43 +0800
Subject: [threeten-dev] Please help to review new test cases for
 java.time.Year and java.time.YearMonth
In-Reply-To: <513597AD.8080306@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com>
Message-ID: <5142DB7F.1000507@oracle.com>

Hi Team,

Please help to review new added test case for java.time.Year and 
java.time.YearMonth.
Included apis:

plus(long, TemporalUnit)
minus(long, TemporalUnit)
plus(TemporalAmount)
minus(TemporalAmount)
with(TemporalField, long)
with(TemporalAdjuster)

As past discussion about ChronoUnit.ERAS,  plus(1, ChronoUnit.ERAS) will 
plus 1 on ERA field directly nor plus 1,000,000,000 years.
So it will change 1BCE to 1CE.
For example,
    Year.of(-1).plus(1, ChronoUnit.ERAS) = Year.of(2)
    Year.of(1).minus(1, ChronoUnit.ERAS) = Year.of(0)

Above logic have been checked in plus(long, TemporalUnit) and 
minus(long, TemporalUnit) for Year/YearMonth

webrev:
http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/webrev/

result:
http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYear.jtr
http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYearMonth.jtr

Regards
Patrick

From patrick.zhang at oracle.com  Fri Mar 15 01:30:36 2013
From: patrick.zhang at oracle.com (patrick zhang)
Date: Fri, 15 Mar 2013 16:30:36 +0800
Subject: [threeten-dev] what happened to JapaneseChronology?
In-Reply-To: <514002A0.8010604@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com> <513E8702.2040803@oracle.com>
	<514002A0.8010604@oracle.com>
Message-ID: <5142DC2C.3060706@oracle.com>

Hi,

Any suggestion for this problem?

Regards
Patrick

On 2013-3-13 12:37, Patrick Zhang wrote:
> Hi Team,
>
> What happened to JapaneseChronology? It will not support the later 2 
> eras? It looks it is one new failure and I do not meet it on last week.
> =============
> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.MEIJI, 
> 1, 1, 1));
> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 
> 1, 1, 1));
> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SEIREKI, 
> 1, 1, 1));
> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SHOWA, 
> 1, 1, 1));       //will throw exception
> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.TAISHO, 
> 1, 1, 1));       //will throw exception
> ==============
>
> Exception info:
> ==============
> Exception in thread "main" java.lang.IllegalArgumentException
>     at java.time.chrono.JapaneseDate.of(JapaneseDate.java:256)
>     at 
> java.time.chrono.JapaneseChronology.date(JapaneseChronology.java:166)
>     at Test.f1(Test.java:17)
>     at Test.main(Test.java:5)
> ==============
>
> Regards
> Patrick
>
>

From scolebourne at joda.org  Fri Mar 15 04:43:44 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 15 Mar 2013 11:43:44 +0000
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <51427456.6040001@Oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
	<5141EF7F.7050807@oracle.com> <51420BF2.5030602@oracle.com>
	<514225F9.2090105@oracle.com> <51427456.6040001@Oracle.com>
Message-ID: 

I have no requirement to allow the chronologies to be overridden by
the config file, only for new ones to be added. In fact, allowing
overriding looks like an unecessary risk.

I also have no requirement for the Ser class to be used in the chrono
package, however using it would undoubtably result in smaller
serialized sizes.

Stephen



On 15 March 2013 01:07, Roger Riggs  wrote:
> Hi Sherman,
>
> Sorry for the race condition, I was trying out a few things...
>
>
> On 3/14/13 3:33 PM, Xueming Shen wrote:
>>
>> On 03/14/2013 10:42 AM, roger riggs wrote:
>>>
>>> Hi,
>>>
>>> On 3/14/2013 11:40 AM, Xueming Shen wrote:
>>>>
>>>> On 3/14/13 7:29 AM, roger riggs wrote:
>>>>>
>>>>> Hi  Sherman,
>>>>>
>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>>> is actually disabled for all Chronology subclasses. Is it intentional?
>>>>>> Given
>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to
>>>>>> return
>>>>>> the singleton) I would assume the Ser delegation might not be
>>>>>> necessary,
>>>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>>>>
>>>>> Not quite, but still broken.  The writeReplace method can be private
>>>>> but
>>>>> is used only if the Chronology class is Serializable.
>>>>>
>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>>>
>>>>> The subclasses are serializable and that is triggering the default
>>>>> serialization.
>>>>>
>>>>> Is there an issue for this?
>>>>
>>>>
>>>> I think a private writeReplace method don't have an effect on how its
>>>> serializable
>>>> subclass serializes itself. So I believe the existing 4 jdk Chronology
>>>> subclasses
>>>> are using the "jdk default mechanism" (not the Ser delegation/proxy), so
>>>> I was
>>>> asking if it is an intentional design/implementation. For any other
>>>> potential
>>>> user defined Chronology subclass, does the abstract Chronology have
>>>> anything
>>>> really need to be "serializable" and via the Ser mechanism? Two possible
>>>> designs
>>>> here
>>>>
>>>> (1) we want all the Chronology subclasses to be serialized via "Ser"
>>>> (then it can
>>>> be done via the Chronology.of(...) when read in), then the
>>>> writeReplace() probably
>>>> should be declared as non-private?
>>>
>>> The intent was that Chronology would always handle serialization
>>> and return the same (singleton) instances that are known to Chronology.
>>>
>>> To make that work the writeReplace method needs to be "protected final"
>>> and visible to subclasses and not be override-able.
>>>
>>
>> Something like the attached webrev?
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>
> Yes, same as what I did.
>
>>
>> Do we really to make it "final" to enforce the abstract base class
>> Chronology to
>> always handle the serialization? Or be liberal to document that this is
>> encouraged,
>> but not enforced, with a "non-final" Chronology.writeReplace()
>
>
> I went with non-final because as final it would prevent subclassing a
> Chronology
> that had its own state to serialize, like the HijrahChronology that has
> variants.
> It seems inflexible to prevent that from anything but bundled Chronologies.
>
>>
>> Second question leads to my (2) in previous email. With the enforcement of
>> Chronology.writeReplace()
>>     ->Ser
>>         ->Chronology.readExternal()
>>             ->Chronology.of/of0(id)
>>                 ->cache.
>>
>> A Chronology instance may be serialized from a vm default impl to a
>> user-defined
>> Chronology in other vm, if there is overriding Chronology implementation,
>> however,
>> a built-in ChronoLocalDate, for example JapaneseDate, is always hard-wired
>> to the
>> built-in JapaneseChronology, so if you serialize and de-serialize a
>> JapaneseChronology
>> AND a JapaneseDate into other vm, you may get a user-defined
>> JapaneseChronology
>> and a built-in JapneseDate with bundled with a built-in
>> JapaneseChronology, something
>> undesired?
>
> I suppose there is little benefit from allowing the built-in chronologies to
> be overridden and it does open up some potential problems.
> To insure consistency, JapaneseDate could use Chronology.of("Japanese") to
> get
> the Chronology but that adds very little and will be slower.
>
> If we do away with the override then there should be at least a log
> message if the register of the ServiceLoader chronology fails.
>
> Also, note that the synchronization on whether initialization is complete
> is based on finding ISOChronology in the HashTable.  That would need
> a different mechanism. (Its ok for multiple threads to do the init
> concurrently
> only one will win and it avoids a single threaded synchronization.)
>
> Roger
>
>>
>> -Sherman
>>
>>
>

From scolebourne at joda.org  Fri Mar 15 05:24:30 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 15 Mar 2013 12:24:30 +0000
Subject: [threeten-dev] Please help to review new test cases for
 java.time.Year and java.time.YearMonth
In-Reply-To: <5142DB7F.1000507@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com>
	<512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com>
	<5142DB7F.1000507@oracle.com>
Message-ID: 

looks good to me
Stephen

On 15 March 2013 08:27, patrick zhang  wrote:
> Hi Team,
>
> Please help to review new added test case for java.time.Year and
> java.time.YearMonth.
> Included apis:
>
> plus(long, TemporalUnit)
> minus(long, TemporalUnit)
> plus(TemporalAmount)
> minus(TemporalAmount)
> with(TemporalField, long)
> with(TemporalAdjuster)
>
> As past discussion about ChronoUnit.ERAS,  plus(1, ChronoUnit.ERAS) will
> plus 1 on ERA field directly nor plus 1,000,000,000 years.
> So it will change 1BCE to 1CE.
> For example,
>    Year.of(-1).plus(1, ChronoUnit.ERAS) = Year.of(2)
>    Year.of(1).minus(1, ChronoUnit.ERAS) = Year.of(0)
>
> Above logic have been checked in plus(long, TemporalUnit) and minus(long,
> TemporalUnit) for Year/YearMonth
>
> webrev:
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/webrev/
>
> result:
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYear.jtr
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/Year/TCKYearMonth.jtr
>
> Regards
> Patrick

From roger.riggs at oracle.com  Fri Mar 15 07:52:23 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 15 Mar 2013 10:52:23 -0400
Subject: [threeten-dev] what happened to JapaneseChronology?
In-Reply-To: <5142DC2C.3060706@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com> <513E8702.2040803@oracle.com>
	<514002A0.8010604@oracle.com> <5142DC2C.3060706@oracle.com>
Message-ID: <514335A7.1070205@oracle.com>

Hi Patrick,

The first official day of the SHOWA era is 1, 12, 29  (The month 
numbering does not start at one.)
Similarly, the first official day of TAISHO is 1, 7, 30.

I don't know why the IllegalArgumentException does not have a message.  
(Masayoshi?)
I'm not sure why the tests started failing now unless the leniency changes
have made a difference; though the tests should have been fixed at the 
same time.

It looks like a test bug.

Thanks, Roger



On 3/15/2013 4:30 AM, patrick zhang wrote:
> Hi,
>
> Any suggestion for this problem?
>
> Regards
> Patrick
>
> On 2013-3-13 12:37, Patrick Zhang wrote:
>> Hi Team,
>>
>> What happened to JapaneseChronology? It will not support the later 2 
>> eras? It looks it is one new failure and I do not meet it on last week.
>> =============
>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.MEIJI, 1, 
>> 1, 1));
>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 
>> 1, 1, 1));
>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SEIREKI, 
>> 1, 1, 1));
>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SHOWA, 1, 
>> 1, 1));       //will throw exception
>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.TAISHO, 
>> 1, 1, 1));       //will throw exception
>> ==============
>>
>> Exception info:
>> ==============
>> Exception in thread "main" java.lang.IllegalArgumentException
>>     at java.time.chrono.JapaneseDate.of(JapaneseDate.java:256)
>>     at 
>> java.time.chrono.JapaneseChronology.date(JapaneseChronology.java:166)
>>     at Test.f1(Test.java:17)
>>     at Test.main(Test.java:5)
>> ==============
>>
>> Regards
>> Patrick
>>
>>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From roger.riggs at oracle.com  Fri Mar 15 11:01:28 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 15 Mar 2013 14:01:28 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <51427456.6040001@Oracle.com>
References: <513FA382.3070309@oracle.com> <5141DECF.8010905@oracle.com>
	<5141EF7F.7050807@oracle.com> <51420BF2.5030602@oracle.com>
	<514225F9.2090105@oracle.com> <51427456.6040001@Oracle.com>
Message-ID: <514361F8.6070407@oracle.com>

Hi,

Updated the webrev with removal of unnecessary/unused readResolve methods,
reordered the Chronology.initCache method to ignore duplicate Chronologies
from ServiceLoader.

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/

Included a test fix for the JapaneseDate.of(1,1,1) problem.

Roger


On 3/14/2013 9:07 PM, Roger Riggs wrote:
>
>>>>>
>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>>> is actually disabled for all Chronology subclasses. Is it 
>>>>>> intentional? Given
>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to 
>>>>>> return
>>>>>> the singleton) I would assume the Ser delegation might not be 
>>>>>> necessary,
>>>>>> though it might be still desirable to "enforce" the Ser pattern 
>>>>>> here?
>>>>> Not quite, but still broken.  The writeReplace method can be 
>>>>> private but
>>>>> is used only if the Chronology class is Serializable.
>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324 
>>>>>
>>>>>
>>>>> The subclasses are serializable and that is triggering the default 
>>>>> serialization.
>>>>>
>>>>> Is there an issue for this?
>>>>
>>>> I think a private writeReplace method don't have an effect on how 
>>>> its serializable
>>>> subclass serializes itself. So I believe the existing 4 jdk 
>>>> Chronology subclasses
>>>> are using the "jdk default mechanism" (not the Ser 
>>>> delegation/proxy), so I was
>>>> asking if it is an intentional design/implementation. For any other 
>>>> potential
>>>> user defined Chronology subclass, does the abstract Chronology have 
>>>> anything
>>>> really need to be "serializable" and via the Ser mechanism? Two 
>>>> possible designs
>>>> here
>>>>
>>>> (1) we want all the Chronology subclasses to be serialized via 
>>>> "Ser" (then it can
>>>> be done via the Chronology.of(...) when read in), then the 
>>>> writeReplace() probably
>>>> should be declared as non-private?
>>> The intent was that Chronology would always handle serialization
>>> and return the same (singleton) instances that are known to Chronology.
>>>
>>> To make that work the writeReplace method needs to be "protected final"
>>> and visible to subclasses and not be override-able.
>>>
>>
>> Something like the attached webrev?
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
> Yes, same as what I did.
>>
>> Do we really to make it "final" to enforce the abstract base class 
>> Chronology to
>> always handle the serialization? Or be liberal to document that this 
>> is encouraged,
>> but not enforced, with a "non-final" Chronology.writeReplace()
>
> I went with non-final because as final it would prevent subclassing a 
> Chronology
> that had its own state to serialize, like the HijrahChronology that 
> has variants.
> It seems inflexible to prevent that from anything but bundled 
> Chronologies.
>>
>> Second question leads to my (2) in previous email. With the 
>> enforcement of
>> Chronology.writeReplace()
>>     ->Ser
>>         ->Chronology.readExternal()
>>             ->Chronology.of/of0(id)
>>                 ->cache.
>>
>> A Chronology instance may be serialized from a vm default impl to a 
>> user-defined
>> Chronology in other vm, if there is overriding Chronology 
>> implementation, however,
>> a built-in ChronoLocalDate, for example JapaneseDate, is always 
>> hard-wired to the
>> built-in JapaneseChronology, so if you serialize and de-serialize a 
>> JapaneseChronology
>> AND a JapaneseDate into other vm, you may get a user-defined 
>> JapaneseChronology
>> and a built-in JapneseDate with bundled with a built-in 
>> JapaneseChronology, something
>> undesired?
> I suppose there is little benefit from allowing the built-in 
> chronologies to
> be overridden and it does open up some potential problems.
> To insure consistency, JapaneseDate could use 
> Chronology.of("Japanese") to get
> the Chronology but that adds very little and will be slower.
>
> If we do away with the override then there should be at least a log
> message if the register of the ServiceLoader chronology fails.
>
> Also, note that the synchronization on whether initialization is complete
> is based on finding ISOChronology in the HashTable.  That would need
> a different mechanism. (Its ok for multiple threads to do the init 
> concurrently
> only one will win and it avoids a single threaded synchronization.)
>
> Roger
>

From xueming.shen at oracle.com  Fri Mar 15 12:08:45 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 15 Mar 2013 12:08:45 -0700
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <514361F8.6070407@oracle.com>
References: <513FA382.3070309@oracle.com>
	<5141DECF.8010905@oracle.com>	<5141EF7F.7050807@oracle.com>
	<51420BF2.5030602@oracle.com>	<514225F9.2090105@oracle.com>
	<51427456.6040001@Oracle.com> <514361F8.6070407@oracle.com>
Message-ID: <514371BD.4080808@oracle.com>

The change itself looks fine for me, however I have couple more questions
regarding the Chronology spec and implementation :-)

(1) it appears, compared to Chronology.of(id), the Chronology.ofLocale(locale)
has a slightly different implementation for looking up and loading, it stops after
the look up of CHRONOS_BY_TYPE (built-in and application level service loader),
while the Chronology.of(id) continues go on for the possible candidates from
the ServiceLoad(contextClassLoader). Again, is this intended?

(2) while I understand the intent of looking up a Chronology implementation
via contextClassLoader, but it appears you can then pass around such a context
specific Chronology (and probably the corresponding ChronoDate) around and
to be shared beyond the original thread's "context", is this desirable? or we go
with the enforcement of any Chronology is a global resource, need to be initialized
via the application/system class loader?

-Sherman

On 03/15/2013 11:01 AM, roger riggs wrote:
> Hi,
>
> Updated the webrev with removal of unnecessary/unused readResolve methods,
> reordered the Chronology.initCache method to ignore duplicate Chronologies
> from ServiceLoader.
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>
> Included a test fix for the JapaneseDate.of(1,1,1) problem.
>
> Roger
>
>
> On 3/14/2013 9:07 PM, Roger Riggs wrote:
>>
>>>>>>
>>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>>>> is actually disabled for all Chronology subclasses. Is it intentional? Given
>>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>>>>>>> the singleton) I would assume the Ser delegation might not be necessary,
>>>>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>>>>> Not quite, but still broken.  The writeReplace method can be private but
>>>>>> is used only if the Chronology class is Serializable.
>>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>>>>
>>>>>> The subclasses are serializable and that is triggering the default serialization.
>>>>>>
>>>>>> Is there an issue for this?
>>>>>
>>>>> I think a private writeReplace method don't have an effect on how its serializable
>>>>> subclass serializes itself. So I believe the existing 4 jdk Chronology subclasses
>>>>> are using the "jdk default mechanism" (not the Ser delegation/proxy), so I was
>>>>> asking if it is an intentional design/implementation. For any other potential
>>>>> user defined Chronology subclass, does the abstract Chronology have anything
>>>>> really need to be "serializable" and via the Ser mechanism? Two possible designs
>>>>> here
>>>>>
>>>>> (1) we want all the Chronology subclasses to be serialized via "Ser" (then it can
>>>>> be done via the Chronology.of(...) when read in), then the writeReplace() probably
>>>>> should be declared as non-private?
>>>> The intent was that Chronology would always handle serialization
>>>> and return the same (singleton) instances that are known to Chronology.
>>>>
>>>> To make that work the writeReplace method needs to be "protected final"
>>>> and visible to subclasses and not be override-able.
>>>>
>>>
>>> Something like the attached webrev?
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>> Yes, same as what I did.
>>>
>>> Do we really to make it "final" to enforce the abstract base class Chronology to
>>> always handle the serialization? Or be liberal to document that this is encouraged,
>>> but not enforced, with a "non-final" Chronology.writeReplace()
>>
>> I went with non-final because as final it would prevent subclassing a Chronology
>> that had its own state to serialize, like the HijrahChronology that has variants.
>> It seems inflexible to prevent that from anything but bundled Chronologies.
>>>
>>> Second question leads to my (2) in previous email. With the enforcement of
>>> Chronology.writeReplace()
>>>     ->Ser
>>>         ->Chronology.readExternal()
>>>             ->Chronology.of/of0(id)
>>>                 ->cache.
>>>
>>> A Chronology instance may be serialized from a vm default impl to a user-defined
>>> Chronology in other vm, if there is overriding Chronology implementation, however,
>>> a built-in ChronoLocalDate, for example JapaneseDate, is always hard-wired to the
>>> built-in JapaneseChronology, so if you serialize and de-serialize a JapaneseChronology
>>> AND a JapaneseDate into other vm, you may get a user-defined JapaneseChronology
>>> and a built-in JapneseDate with bundled with a built-in JapaneseChronology, something
>>> undesired?
>> I suppose there is little benefit from allowing the built-in chronologies to
>> be overridden and it does open up some potential problems.
>> To insure consistency, JapaneseDate could use Chronology.of("Japanese") to get
>> the Chronology but that adds very little and will be slower.
>>
>> If we do away with the override then there should be at least a log
>> message if the register of the ServiceLoader chronology fails.
>>
>> Also, note that the synchronization on whether initialization is complete
>> is based on finding ISOChronology in the HashTable.  That would need
>> a different mechanism. (Its ok for multiple threads to do the init concurrently
>> only one will win and it avoids a single threaded synchronization.)
>>
>> Roger
>>


From roger.riggs at oracle.com  Fri Mar 15 12:38:55 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 15 Mar 2013 15:38:55 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <514371BD.4080808@oracle.com>
References: <513FA382.3070309@oracle.com>
	<5141DECF.8010905@oracle.com>	<5141EF7F.7050807@oracle.com>
	<51420BF2.5030602@oracle.com>	<514225F9.2090105@oracle.com>
	<51427456.6040001@Oracle.com> <514361F8.6070407@oracle.com>
	<514371BD.4080808@oracle.com>
Message-ID: <514378CF.2000400@oracle.com>

Hi Sherman,

On 3/15/2013 3:08 PM, Xueming Shen wrote:
> The change itself looks fine for me, however I have couple more questions
> regarding the Chronology spec and implementation :-)
>
> (1) it appears, compared to Chronology.of(id), the 
> Chronology.ofLocale(locale)
> has a slightly different implementation for looking up and loading, it 
> stops after
> the look up of CHRONOS_BY_TYPE (built-in and application level service 
> loader),
> while the Chronology.of(id) continues go on for the possible 
> candidates from
> the ServiceLoad(contextClassLoader). Again, is this intended?
That is an oversight.
>
> (2) while I understand the intent of looking up a Chronology 
> implementation
> via contextClassLoader, but it appears you can then pass around such a 
> context
> specific Chronology (and probably the corresponding ChronoDate) around 
> and
> to be shared beyond the original thread's "context", is this 
> desirable? or we go
> with the enforcement of any Chronology is a global resource, need to 
> be initialized
> via the application/system class loader?
With or without the help of Chronology an application can load
a Chronology via the ServiceLoader and it should be usable.
Regardless of where the application passes the reference it will
continue to provide it own implementations of the Chrono* interfaces.

Using the ContextClassLoader is a convenience and gives a consistent API for
locating Chronologies. Using the ContextClassLoader appears to be the
default for ServiceLoader.load so I don't see an issue there. Whether
a client or server, it should find the Chronology in the provided context.

Is there anything similar in other APIs;  ResourceBundles for example?

Roger

>
> -Sherman
>
> On 03/15/2013 11:01 AM, roger riggs wrote:
>> Hi,
>>
>> Updated the webrev with removal of unnecessary/unused readResolve 
>> methods,
>> reordered the Chronology.initCache method to ignore duplicate 
>> Chronologies
>> from ServiceLoader.
>>
>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>>
>> Included a test fix for the JapaneseDate.of(1,1,1) problem.
>>
>> Roger
>>
>>
>> On 3/14/2013 9:07 PM, Roger Riggs wrote:
>>>
>>>>>>>
>>>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser 
>>>>>>>> mechanism
>>>>>>>> is actually disabled for all Chronology subclasses. Is it 
>>>>>>>> intentional? Given
>>>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 
>>>>>>>> to return
>>>>>>>> the singleton) I would assume the Ser delegation might not be 
>>>>>>>> necessary,
>>>>>>>> though it might be still desirable to "enforce" the Ser pattern 
>>>>>>>> here?
>>>>>>> Not quite, but still broken.  The writeReplace method can be 
>>>>>>> private but
>>>>>>> is used only if the Chronology class is Serializable.
>>>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324 
>>>>>>>
>>>>>>>
>>>>>>> The subclasses are serializable and that is triggering the 
>>>>>>> default serialization.
>>>>>>>
>>>>>>> Is there an issue for this?
>>>>>>
>>>>>> I think a private writeReplace method don't have an effect on how 
>>>>>> its serializable
>>>>>> subclass serializes itself. So I believe the existing 4 jdk 
>>>>>> Chronology subclasses
>>>>>> are using the "jdk default mechanism" (not the Ser 
>>>>>> delegation/proxy), so I was
>>>>>> asking if it is an intentional design/implementation. For any 
>>>>>> other potential
>>>>>> user defined Chronology subclass, does the abstract Chronology 
>>>>>> have anything
>>>>>> really need to be "serializable" and via the Ser mechanism? Two 
>>>>>> possible designs
>>>>>> here
>>>>>>
>>>>>> (1) we want all the Chronology subclasses to be serialized via 
>>>>>> "Ser" (then it can
>>>>>> be done via the Chronology.of(...) when read in), then the 
>>>>>> writeReplace() probably
>>>>>> should be declared as non-private?
>>>>> The intent was that Chronology would always handle serialization
>>>>> and return the same (singleton) instances that are known to 
>>>>> Chronology.
>>>>>
>>>>> To make that work the writeReplace method needs to be "protected 
>>>>> final"
>>>>> and visible to subclasses and not be override-able.
>>>>>
>>>>
>>>> Something like the attached webrev?
>>>>
>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>>> Yes, same as what I did.
>>>>
>>>> Do we really to make it "final" to enforce the abstract base class 
>>>> Chronology to
>>>> always handle the serialization? Or be liberal to document that 
>>>> this is encouraged,
>>>> but not enforced, with a "non-final" Chronology.writeReplace()
>>>
>>> I went with non-final because as final it would prevent subclassing 
>>> a Chronology
>>> that had its own state to serialize, like the HijrahChronology that 
>>> has variants.
>>> It seems inflexible to prevent that from anything but bundled 
>>> Chronologies.
>>>>
>>>> Second question leads to my (2) in previous email. With the 
>>>> enforcement of
>>>> Chronology.writeReplace()
>>>>     ->Ser
>>>>         ->Chronology.readExternal()
>>>>             ->Chronology.of/of0(id)
>>>>                 ->cache.
>>>>
>>>> A Chronology instance may be serialized from a vm default impl to a 
>>>> user-defined
>>>> Chronology in other vm, if there is overriding Chronology 
>>>> implementation, however,
>>>> a built-in ChronoLocalDate, for example JapaneseDate, is always 
>>>> hard-wired to the
>>>> built-in JapaneseChronology, so if you serialize and de-serialize a 
>>>> JapaneseChronology
>>>> AND a JapaneseDate into other vm, you may get a user-defined 
>>>> JapaneseChronology
>>>> and a built-in JapneseDate with bundled with a built-in 
>>>> JapaneseChronology, something
>>>> undesired?
>>> I suppose there is little benefit from allowing the built-in 
>>> chronologies to
>>> be overridden and it does open up some potential problems.
>>> To insure consistency, JapaneseDate could use 
>>> Chronology.of("Japanese") to get
>>> the Chronology but that adds very little and will be slower.
>>>
>>> If we do away with the override then there should be at least a log
>>> message if the register of the ServiceLoader chronology fails.
>>>
>>> Also, note that the synchronization on whether initialization is 
>>> complete
>>> is based on finding ISOChronology in the HashTable.  That would need
>>> a different mechanism. (Its ok for multiple threads to do the init 
>>> concurrently
>>> only one will win and it avoids a single threaded synchronization.)
>>>
>>> Roger
>>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From roger.riggs at oracle.com  Fri Mar 15 13:10:49 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 15 Mar 2013 16:10:49 -0400
Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets
In-Reply-To: <20130312153047.7D7E3480A8@hg.openjdk.java.net>
References: <20130312153047.7D7E3480A8@hg.openjdk.java.net>
Message-ID: <51438049.5040707@oracle.com>

Hi Stephen,

Some additional license text has started appearing in some commits.
Is that intentional?

+ * This file is available under and governed by the GNU General Public
+ * License version 2 only, as published by the Free Software Foundation.
+ * However, the following notice accompanied the original version of this
+ * file:
Thanks, Roger On 3/12/2013 11:28 AM, scolebourne at joda.org wrote:

> Changeset: 72bb5d877b83
> Author:    scolebourne
> Date:      2013-03-12 14:50 +0000
> URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72bb5d877b83
>
> Test Period plus/minus(Period)
>
> ! test/java/time/tck/java/time/TCKPeriod.java
>
> Changeset: 6f798f7dab74
> Author:    scolebourne
> Date:      2013-03-12 14:54 +0000
> URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6f798f7dab74
>
> Enhance and fix eras
>
> Fix range of Japanese and Hijrah, with tests
> Unify Javadoc styles
> Add Javadoc tables for year-of-era where appropriate
>
> ! src/share/classes/java/time/chrono/Era.java
> ! src/share/classes/java/time/chrono/HijrahEra.java
> ! src/share/classes/java/time/chrono/IsoEra.java
> ! src/share/classes/java/time/chrono/JapaneseChronology.java
> ! src/share/classes/java/time/chrono/JapaneseEra.java
> ! src/share/classes/java/time/chrono/MinguoEra.java
> ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
> ! test/java/time/tck/java/time/chrono/TCKHijrahEra.java
> ! test/java/time/tck/java/time/chrono/TCKIsoEra.java
> ! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
> ! test/java/time/tck/java/time/chrono/TCKMinguoEra.java
> ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
>
> Changeset: 97e8eb496b37
> Author:    scolebourne
> Date:      2013-03-12 15:25 +0000
> URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/97e8eb496b37
>
> Fix Javadoc
>
> ! src/share/classes/java/time/temporal/ChronoUnit.java
>
> Changeset: 0e98b03f696a
> Author:    scolebourne
> Date:      2013-03-12 15:25 +0000
> URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e98b03f696a
>
> Fix Javadoc
>
> ! src/share/classes/java/time/Year.java
>
> Changeset: 0dcbfca54160
> Author:    scolebourne
> Date:      2013-03-12 15:26 +0000
> URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0dcbfca54160
>
> Fix and test Year.plus/minus(Period.ofYears(n))
>
> ! src/share/classes/java/time/Period.java
> ! test/java/time/tck/java/time/TCKYear.java
>


From xueming.shen at oracle.com  Fri Mar 15 14:13:22 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 15 Mar 2013 14:13:22 -0700
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <514378CF.2000400@oracle.com>
References: <513FA382.3070309@oracle.com>
	<5141DECF.8010905@oracle.com>	<5141EF7F.7050807@oracle.com>
	<51420BF2.5030602@oracle.com>	<514225F9.2090105@oracle.com>
	<51427456.6040001@Oracle.com> <514361F8.6070407@oracle.com>
	<514371BD.4080808@oracle.com> <514378CF.2000400@oracle.com>
Message-ID: <51438EF2.3090108@oracle.com>

Roger,

I have a "live" related bug/rfe #4619777 for a similar use scenario in my
java.nio.charset area. While the javadoc of CharsetProvider explicitly says
the context class loader will be used to load in the charset provider, our
real implementation actually uses system/application class loader. During
the discussion on whether we should change the implementation to fit the
spec, there is security concern raised from the vuln team that it is "normally"
a "bad" idea to use context class loader in this kinda scenario, given "the
thread context class loader is effectively a mutable static in an unconvincing
disguise, any trusted code trusting the ... would be vulnerable". We still have
not figured out the best solution for #4619777 yet (I understood the benefit
of using the context class loader and the possible limitation of using the
system/application class loader, but we may have to lean toward to change
the spec to fit with the implementation for compatibility and vuln concer),
I'm still thinking :-)

The Chronology use scenario you are trying to achieve might be slightly
different, but it might need a second consideration.

Another "similar" use case is the sun.util.locale.provider.SPILocaleProviderAdapter,
which also does not go with the context class loader, but these are all to
provider "global resource", maybe slightly different to the use scenario you're
trying to provide.

-Sherman

On 03/15/2013 12:38 PM, roger riggs wrote:
> Hi Sherman,
>
> On 3/15/2013 3:08 PM, Xueming Shen wrote:
>> The change itself looks fine for me, however I have couple more questions
>> regarding the Chronology spec and implementation :-)
>>
>> (1) it appears, compared to Chronology.of(id), the Chronology.ofLocale(locale)
>> has a slightly different implementation for looking up and loading, it stops after
>> the look up of CHRONOS_BY_TYPE (built-in and application level service loader),
>> while the Chronology.of(id) continues go on for the possible candidates from
>> the ServiceLoad(contextClassLoader). Again, is this intended?
> That is an oversight.
>>
>> (2) while I understand the intent of looking up a Chronology implementation
>> via contextClassLoader, but it appears you can then pass around such a context
>> specific Chronology (and probably the corresponding ChronoDate) around and
>> to be shared beyond the original thread's "context", is this desirable? or we go
>> with the enforcement of any Chronology is a global resource, need to be initialized
>> via the application/system class loader?
> With or without the help of Chronology an application can load
> a Chronology via the ServiceLoader and it should be usable.
> Regardless of where the application passes the reference it will
> continue to provide it own implementations of the Chrono* interfaces.
>
> Using the ContextClassLoader is a convenience and gives a consistent API for
> locating Chronologies. Using the ContextClassLoader appears to be the
> default for ServiceLoader.load so I don't see an issue there.  Whether
> a client or server, it should find the Chronology in the provided context.
>
> Is there anything similar in other APIs;  ResourceBundles for example?
>
> Roger
>
>>
>> -Sherman
>>
>> On 03/15/2013 11:01 AM, roger riggs wrote:
>>> Hi,
>>>
>>> Updated the webrev with removal of unnecessary/unused readResolve methods,
>>> reordered the Chronology.initCache method to ignore duplicate Chronologies
>>> from ServiceLoader.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>>>
>>> Included a test fix for the JapaneseDate.of(1,1,1) problem.
>>>
>>> Roger
>>>
>>>
>>> On 3/14/2013 9:07 PM, Roger Riggs wrote:
>>>>
>>>>>>>>
>>>>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>>>>>> is actually disabled for all Chronology subclasses. Is it intentional? Given
>>>>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>>>>>>>>> the singleton) I would assume the Ser delegation might not be necessary,
>>>>>>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>>>>>>> Not quite, but still broken.  The writeReplace method can be private but
>>>>>>>> is used only if the Chronology class is Serializable.
>>>>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>>>>>>
>>>>>>>> The subclasses are serializable and that is triggering the default serialization.
>>>>>>>>
>>>>>>>> Is there an issue for this?
>>>>>>>
>>>>>>> I think a private writeReplace method don't have an effect on how its serializable
>>>>>>> subclass serializes itself. So I believe the existing 4 jdk Chronology subclasses
>>>>>>> are using the "jdk default mechanism" (not the Ser delegation/proxy), so I was
>>>>>>> asking if it is an intentional design/implementation. For any other potential
>>>>>>> user defined Chronology subclass, does the abstract Chronology have anything
>>>>>>> really need to be "serializable" and via the Ser mechanism? Two possible designs
>>>>>>> here
>>>>>>>
>>>>>>> (1) we want all the Chronology subclasses to be serialized via "Ser" (then it can
>>>>>>> be done via the Chronology.of(...) when read in), then the writeReplace() probably
>>>>>>> should be declared as non-private?
>>>>>> The intent was that Chronology would always handle serialization
>>>>>> and return the same (singleton) instances that are known to Chronology.
>>>>>>
>>>>>> To make that work the writeReplace method needs to be "protected final"
>>>>>> and visible to subclasses and not be override-able.
>>>>>>
>>>>>
>>>>> Something like the attached webrev?
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>>>> Yes, same as what I did.
>>>>>
>>>>> Do we really to make it "final" to enforce the abstract base class Chronology to
>>>>> always handle the serialization? Or be liberal to document that this is encouraged,
>>>>> but not enforced, with a "non-final" Chronology.writeReplace()
>>>>
>>>> I went with non-final because as final it would prevent subclassing a Chronology
>>>> that had its own state to serialize, like the HijrahChronology that has variants.
>>>> It seems inflexible to prevent that from anything but bundled Chronologies.
>>>>>
>>>>> Second question leads to my (2) in previous email. With the enforcement of
>>>>> Chronology.writeReplace()
>>>>>     ->Ser
>>>>>         ->Chronology.readExternal()
>>>>>             ->Chronology.of/of0(id)
>>>>>                 ->cache.
>>>>>
>>>>> A Chronology instance may be serialized from a vm default impl to a user-defined
>>>>> Chronology in other vm, if there is overriding Chronology implementation, however,
>>>>> a built-in ChronoLocalDate, for example JapaneseDate, is always hard-wired to the
>>>>> built-in JapaneseChronology, so if you serialize and de-serialize a JapaneseChronology
>>>>> AND a JapaneseDate into other vm, you may get a user-defined JapaneseChronology
>>>>> and a built-in JapneseDate with bundled with a built-in JapaneseChronology, something
>>>>> undesired?
>>>> I suppose there is little benefit from allowing the built-in chronologies to
>>>> be overridden and it does open up some potential problems.
>>>> To insure consistency, JapaneseDate could use Chronology.of("Japanese") to get
>>>> the Chronology but that adds very little and will be slower.
>>>>
>>>> If we do away with the override then there should be at least a log
>>>> message if the register of the ServiceLoader chronology fails.
>>>>
>>>> Also, note that the synchronization on whether initialization is complete
>>>> is based on finding ISOChronology in the HashTable.  That would need
>>>> a different mechanism. (Its ok for multiple threads to do the init concurrently
>>>> only one will win and it avoids a single threaded synchronization.)
>>>>
>>>> Roger
>>>>
>>
>
> -- 
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Green Oracle  Oracle is committed to developing practices and products that help protect the environment
>


From roger.riggs at oracle.com  Fri Mar 15 14:28:36 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 15 Mar 2013 17:28:36 -0400
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <51438EF2.3090108@oracle.com>
References: <513FA382.3070309@oracle.com>
	<5141DECF.8010905@oracle.com>	<5141EF7F.7050807@oracle.com>
	<51420BF2.5030602@oracle.com>	<514225F9.2090105@oracle.com>
	<51427456.6040001@Oracle.com> <514361F8.6070407@oracle.com>
	<514371BD.4080808@oracle.com> <514378CF.2000400@oracle.com>
	<51438EF2.3090108@oracle.com>
Message-ID: <51439284.70208@oracle.com>

Ok, I see the point.
Shall I sit my changes til we figure it out or commit and revisit?

(I updated the webrev. 
http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/ )

I think we settled the point to prevent built-in calendars from being 
overridden.

I'm not sure whether the (loadable) Chronologies need to be treated as 
"trusted" or not.
Some mischief can be made by lying about the time but the time basics 
that count
would be ISO.

Roger

On 3/15/2013 5:13 PM, Xueming Shen wrote:
> Roger,
>
> I have a "live" related bug/rfe #4619777 for a similar use scenario in my
> java.nio.charset area. While the javadoc of CharsetProvider explicitly 
> says
> the context class loader will be used to load in the charset provider, our
> real implementation actually uses system/application class loader. During
> the discussion on whether we should change the implementation to fit the
> spec, there is security concern raised from the vuln team that it is 
> "normally"
> a "bad" idea to use context class loader in this kinda scenario, given 
> "the
> thread context class loader is effectively a mutable static in an 
> unconvincing
> disguise, any trusted code trusting the ... would be vulnerable". We 
> still have
> not figured out the best solution for #4619777 yet (I understood the 
> benefit
> of using the context class loader and the possible limitation of using the
> system/application class loader, but we may have to lean toward to change
> the spec to fit with the implementation for compatibility and vuln 
> concer),
> I'm still thinking :-)
>
> The Chronology use scenario you are trying to achieve might be slightly
> different, but it might need a second consideration.
>
> Another "similar" use case is the 
> sun.util.locale.provider.SPILocaleProviderAdapter,
> which also does not go with the context class loader, but these are all to
> provider "global resource", maybe slightly different to the use 
> scenario you're
> trying to provide.
>
> -Sherman
>
> On 03/15/2013 12:38 PM, roger riggs wrote:
>> Hi Sherman,
>>
>> On 3/15/2013 3:08 PM, Xueming Shen wrote:
>>> The change itself looks fine for me, however I have couple more 
>>> questions
>>> regarding the Chronology spec and implementation :-)
>>>
>>> (1) it appears, compared to Chronology.of(id), the 
>>> Chronology.ofLocale(locale)
>>> has a slightly different implementation for looking up and loading, 
>>> it stops after
>>> the look up of CHRONOS_BY_TYPE (built-in and application level 
>>> service loader),
>>> while the Chronology.of(id) continues go on for the possible 
>>> candidates from
>>> the ServiceLoad(contextClassLoader). Again, is this intended?
>> That is an oversight.
>>>
>>> (2) while I understand the intent of looking up a Chronology 
>>> implementation
>>> via contextClassLoader, but it appears you can then pass around such 
>>> a context
>>> specific Chronology (and probably the corresponding ChronoDate) 
>>> around and
>>> to be shared beyond the original thread's "context", is this 
>>> desirable? or we go
>>> with the enforcement of any Chronology is a global resource, need to 
>>> be initialized
>>> via the application/system class loader?
>> With or without the help of Chronology an application can load
>> a Chronology via the ServiceLoader and it should be usable.
>> Regardless of where the application passes the reference it will
>> continue to provide it own implementations of the Chrono* interfaces.
>>
>> Using the ContextClassLoader is a convenience and gives a consistent 
>> API for
>> locating Chronologies. Using the ContextClassLoader appears to be the
>> default for ServiceLoader.load so I don't see an issue there. Whether
>> a client or server, it should find the Chronology in the provided 
>> context.
>>
>> Is there anything similar in other APIs;  ResourceBundles for example?
>>
>> Roger
>>
>>>
>>> -Sherman
>>>
>>> On 03/15/2013 11:01 AM, roger riggs wrote:
>>>> Hi,
>>>>
>>>> Updated the webrev with removal of unnecessary/unused readResolve 
>>>> methods,
>>>> reordered the Chronology.initCache method to ignore duplicate 
>>>> Chronologies
>>>> from ServiceLoader.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>>>>
>>>> Included a test fix for the JapaneseDate.of(1,1,1) problem.
>>>>
>>>> Roger
>>>>
>>>>
>>>> On 3/14/2013 9:07 PM, Roger Riggs wrote:
>>>>>
>>>>>>>>>
>>>>>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser 
>>>>>>>>>> mechanism
>>>>>>>>>> is actually disabled for all Chronology subclasses. Is it 
>>>>>>>>>> intentional? Given
>>>>>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 
>>>>>>>>>> to return
>>>>>>>>>> the singleton) I would assume the Ser delegation might not be 
>>>>>>>>>> necessary,
>>>>>>>>>> though it might be still desirable to "enforce" the Ser 
>>>>>>>>>> pattern here?
>>>>>>>>> Not quite, but still broken.  The writeReplace method can be 
>>>>>>>>> private but
>>>>>>>>> is used only if the Chronology class is Serializable.
>>>>>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The subclasses are serializable and that is triggering the 
>>>>>>>>> default serialization.
>>>>>>>>>
>>>>>>>>> Is there an issue for this?
>>>>>>>>
>>>>>>>> I think a private writeReplace method don't have an effect on 
>>>>>>>> how its serializable
>>>>>>>> subclass serializes itself. So I believe the existing 4 jdk 
>>>>>>>> Chronology subclasses
>>>>>>>> are using the "jdk default mechanism" (not the Ser 
>>>>>>>> delegation/proxy), so I was
>>>>>>>> asking if it is an intentional design/implementation. For any 
>>>>>>>> other potential
>>>>>>>> user defined Chronology subclass, does the abstract Chronology 
>>>>>>>> have anything
>>>>>>>> really need to be "serializable" and via the Ser mechanism? Two 
>>>>>>>> possible designs
>>>>>>>> here
>>>>>>>>
>>>>>>>> (1) we want all the Chronology subclasses to be serialized via 
>>>>>>>> "Ser" (then it can
>>>>>>>> be done via the Chronology.of(...) when read in), then the 
>>>>>>>> writeReplace() probably
>>>>>>>> should be declared as non-private?
>>>>>>> The intent was that Chronology would always handle serialization
>>>>>>> and return the same (singleton) instances that are known to 
>>>>>>> Chronology.
>>>>>>>
>>>>>>> To make that work the writeReplace method needs to be "protected 
>>>>>>> final"
>>>>>>> and visible to subclasses and not be override-able.
>>>>>>>
>>>>>>
>>>>>> Something like the attached webrev?
>>>>>>
>>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>>>>> Yes, same as what I did.
>>>>>>
>>>>>> Do we really to make it "final" to enforce the abstract base 
>>>>>> class Chronology to
>>>>>> always handle the serialization? Or be liberal to document that 
>>>>>> this is encouraged,
>>>>>> but not enforced, with a "non-final" Chronology.writeReplace()
>>>>>
>>>>> I went with non-final because as final it would prevent 
>>>>> subclassing a Chronology
>>>>> that had its own state to serialize, like the HijrahChronology 
>>>>> that has variants.
>>>>> It seems inflexible to prevent that from anything but bundled 
>>>>> Chronologies.
>>>>>>
>>>>>> Second question leads to my (2) in previous email. With the 
>>>>>> enforcement of
>>>>>> Chronology.writeReplace()
>>>>>>     ->Ser
>>>>>>         ->Chronology.readExternal()
>>>>>>             ->Chronology.of/of0(id)
>>>>>>                 ->cache.
>>>>>>
>>>>>> A Chronology instance may be serialized from a vm default impl to 
>>>>>> a user-defined
>>>>>> Chronology in other vm, if there is overriding Chronology 
>>>>>> implementation, however,
>>>>>> a built-in ChronoLocalDate, for example JapaneseDate, is always 
>>>>>> hard-wired to the
>>>>>> built-in JapaneseChronology, so if you serialize and de-serialize 
>>>>>> a JapaneseChronology
>>>>>> AND a JapaneseDate into other vm, you may get a user-defined 
>>>>>> JapaneseChronology
>>>>>> and a built-in JapneseDate with bundled with a built-in 
>>>>>> JapaneseChronology, something
>>>>>> undesired?
>>>>> I suppose there is little benefit from allowing the built-in 
>>>>> chronologies to
>>>>> be overridden and it does open up some potential problems.
>>>>> To insure consistency, JapaneseDate could use 
>>>>> Chronology.of("Japanese") to get
>>>>> the Chronology but that adds very little and will be slower.
>>>>>
>>>>> If we do away with the override then there should be at least a log
>>>>> message if the register of the ServiceLoader chronology fails.
>>>>>
>>>>> Also, note that the synchronization on whether initialization is 
>>>>> complete
>>>>> is based on finding ISOChronology in the HashTable.  That would need
>>>>> a different mechanism. (Its ok for multiple threads to do the init 
>>>>> concurrently
>>>>> only one will win and it avoids a single threaded synchronization.)
>>>>>
>>>>> Roger
>>>>>
>>>
>>
>> -- 
>> Thanks, Roger
>>
>> Oracle Java Platform Group
>>
>> Green Oracle  Oracle is committed 
>> to developing practices and products that help protect the environment
>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From xueming.shen at oracle.com  Fri Mar 15 14:31:36 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 15 Mar 2013 14:31:36 -0700
Subject: [threeten-dev] Some observations of chrono ser
In-Reply-To: <51439284.70208@oracle.com>
References: <513FA382.3070309@oracle.com>
	<5141DECF.8010905@oracle.com>	<5141EF7F.7050807@oracle.com>
	<51420BF2.5030602@oracle.com>	<514225F9.2090105@oracle.com>
	<51427456.6040001@Oracle.com> <514361F8.6070407@oracle.com>
	<514371BD.4080808@oracle.com> <514378CF.2000400@oracle.com>
	<51438EF2.3090108@oracle.com> <51439284.70208@oracle.com>
Message-ID: <51439338.4000601@oracle.com>

On 03/15/2013 02:28 PM, roger riggs wrote:
> Ok, I see the point.
> Shall I sit my changes til we figure it out or commit and revisit?

Sure, you can commit and revisit later. I will try to pull in those
latest jdk8/master stuff after yours.

>
> (I updated the webrev. http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/ )
>
> I think we settled the point to prevent built-in calendars from being overridden.
>
> I'm not sure whether the (loadable) Chronologies need to be treated as "trusted" or not.
> Some mischief can be made by lying about the time but the time basics that count
> would be ISO.
>
> Roger
>
> On 3/15/2013 5:13 PM, Xueming Shen wrote:
>> Roger,
>>
>> I have a "live" related bug/rfe #4619777 for a similar use scenario in my
>> java.nio.charset area. While the javadoc of CharsetProvider explicitly says
>> the context class loader will be used to load in the charset provider, our
>> real implementation actually uses system/application class loader. During
>> the discussion on whether we should change the implementation to fit the
>> spec, there is security concern raised from the vuln team that it is "normally"
>> a "bad" idea to use context class loader in this kinda scenario, given "the
>> thread context class loader is effectively a mutable static in an unconvincing
>> disguise, any trusted code trusting the ... would be vulnerable". We still have
>> not figured out the best solution for #4619777 yet (I understood the benefit
>> of using the context class loader and the possible limitation of using the
>> system/application class loader, but we may have to lean toward to change
>> the spec to fit with the implementation for compatibility and vuln concer),
>> I'm still thinking :-)
>>
>> The Chronology use scenario you are trying to achieve might be slightly
>> different, but it might need a second consideration.
>>
>> Another "similar" use case is the sun.util.locale.provider.SPILocaleProviderAdapter,
>> which also does not go with the context class loader, but these are all to
>> provider "global resource", maybe slightly different to the use scenario you're
>> trying to provide.
>>
>> -Sherman
>>
>> On 03/15/2013 12:38 PM, roger riggs wrote:
>>> Hi Sherman,
>>>
>>> On 3/15/2013 3:08 PM, Xueming Shen wrote:
>>>> The change itself looks fine for me, however I have couple more questions
>>>> regarding the Chronology spec and implementation :-)
>>>>
>>>> (1) it appears, compared to Chronology.of(id), the Chronology.ofLocale(locale)
>>>> has a slightly different implementation for looking up and loading, it stops after
>>>> the look up of CHRONOS_BY_TYPE (built-in and application level service loader),
>>>> while the Chronology.of(id) continues go on for the possible candidates from
>>>> the ServiceLoad(contextClassLoader). Again, is this intended?
>>> That is an oversight.
>>>>
>>>> (2) while I understand the intent of looking up a Chronology implementation
>>>> via contextClassLoader, but it appears you can then pass around such a context
>>>> specific Chronology (and probably the corresponding ChronoDate) around and
>>>> to be shared beyond the original thread's "context", is this desirable? or we go
>>>> with the enforcement of any Chronology is a global resource, need to be initialized
>>>> via the application/system class loader?
>>> With or without the help of Chronology an application can load
>>> a Chronology via the ServiceLoader and it should be usable.
>>> Regardless of where the application passes the reference it will
>>> continue to provide it own implementations of the Chrono* interfaces.
>>>
>>> Using the ContextClassLoader is a convenience and gives a consistent API for
>>> locating Chronologies. Using the ContextClassLoader appears to be the
>>> default for ServiceLoader.load so I don't see an issue there.  Whether
>>> a client or server, it should find the Chronology in the provided context.
>>>
>>> Is there anything similar in other APIs;  ResourceBundles for example?
>>>
>>> Roger
>>>
>>>>
>>>> -Sherman
>>>>
>>>> On 03/15/2013 11:01 AM, roger riggs wrote:
>>>>> Hi,
>>>>>
>>>>> Updated the webrev with removal of unnecessary/unused readResolve methods,
>>>>> reordered the Chronology.initCache method to ignore duplicate Chronologies
>>>>> from ServiceLoader.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/
>>>>>
>>>>> Included a test fix for the JapaneseDate.of(1,1,1) problem.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On 3/14/2013 9:07 PM, Roger Riggs wrote:
>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/12/2013 5:52 PM, Xueming Shen wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> (1) Chronology.writeReplace() is private, so the proxy Ser mechanism
>>>>>>>>>>> is actually disabled for all Chronology subclasses. Is it intentional? Given
>>>>>>>>>>> all JDK subclasses all have readResolve() defined (3 out of 4 to return
>>>>>>>>>>> the singleton) I would assume the Ser delegation might not be necessary,
>>>>>>>>>>> though it might be still desirable to "enforce" the Ser pattern here?
>>>>>>>>>> Not quite, but still broken.  The writeReplace method can be private but
>>>>>>>>>> is used only if the Chronology class is Serializable.
>>>>>>>>>> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#5324
>>>>>>>>>>
>>>>>>>>>> The subclasses are serializable and that is triggering the default serialization.
>>>>>>>>>>
>>>>>>>>>> Is there an issue for this?
>>>>>>>>>
>>>>>>>>> I think a private writeReplace method don't have an effect on how its serializable
>>>>>>>>> subclass serializes itself. So I believe the existing 4 jdk Chronology subclasses
>>>>>>>>> are using the "jdk default mechanism" (not the Ser delegation/proxy), so I was
>>>>>>>>> asking if it is an intentional design/implementation. For any other potential
>>>>>>>>> user defined Chronology subclass, does the abstract Chronology have anything
>>>>>>>>> really need to be "serializable" and via the Ser mechanism? Two possible designs
>>>>>>>>> here
>>>>>>>>>
>>>>>>>>> (1) we want all the Chronology subclasses to be serialized via "Ser" (then it can
>>>>>>>>> be done via the Chronology.of(...) when read in), then the writeReplace() probably
>>>>>>>>> should be declared as non-private?
>>>>>>>> The intent was that Chronology would always handle serialization
>>>>>>>> and return the same (singleton) instances that are known to Chronology.
>>>>>>>>
>>>>>>>> To make that work the writeReplace method needs to be "protected final"
>>>>>>>> and visible to subclasses and not be override-able.
>>>>>>>>
>>>>>>>
>>>>>>> Something like the attached webrev?
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/serChrono
>>>>>> Yes, same as what I did.
>>>>>>>
>>>>>>> Do we really to make it "final" to enforce the abstract base class Chronology to
>>>>>>> always handle the serialization? Or be liberal to document that this is encouraged,
>>>>>>> but not enforced, with a "non-final" Chronology.writeReplace()
>>>>>>
>>>>>> I went with non-final because as final it would prevent subclassing a Chronology
>>>>>> that had its own state to serialize, like the HijrahChronology that has variants.
>>>>>> It seems inflexible to prevent that from anything but bundled Chronologies.
>>>>>>>
>>>>>>> Second question leads to my (2) in previous email. With the enforcement of
>>>>>>> Chronology.writeReplace()
>>>>>>>     ->Ser
>>>>>>>         ->Chronology.readExternal()
>>>>>>>             ->Chronology.of/of0(id)
>>>>>>>                 ->cache.
>>>>>>>
>>>>>>> A Chronology instance may be serialized from a vm default impl to a user-defined
>>>>>>> Chronology in other vm, if there is overriding Chronology implementation, however,
>>>>>>> a built-in ChronoLocalDate, for example JapaneseDate, is always hard-wired to the
>>>>>>> built-in JapaneseChronology, so if you serialize and de-serialize a JapaneseChronology
>>>>>>> AND a JapaneseDate into other vm, you may get a user-defined JapaneseChronology
>>>>>>> and a built-in JapneseDate with bundled with a built-in JapaneseChronology, something
>>>>>>> undesired?
>>>>>> I suppose there is little benefit from allowing the built-in chronologies to
>>>>>> be overridden and it does open up some potential problems.
>>>>>> To insure consistency, JapaneseDate could use Chronology.of("Japanese") to get
>>>>>> the Chronology but that adds very little and will be slower.
>>>>>>
>>>>>> If we do away with the override then there should be at least a log
>>>>>> message if the register of the ServiceLoader chronology fails.
>>>>>>
>>>>>> Also, note that the synchronization on whether initialization is complete
>>>>>> is based on finding ISOChronology in the HashTable.  That would need
>>>>>> a different mechanism. (Its ok for multiple threads to do the init concurrently
>>>>>> only one will win and it avoids a single threaded synchronization.)
>>>>>>
>>>>>> Roger
>>>>>>
>>>>
>>>
>>> -- 
>>> Thanks, Roger
>>>
>>> Oracle Java Platform Group
>>>
>>> Green Oracle  Oracle is committed to developing practices and products that help protect the environment
>>>
>>
>
> -- 
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Green Oracle  Oracle is committed to developing practices and products that help protect the environment
>


From roger.riggs at oracle.com  Fri Mar 15 15:54:17 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 15 Mar 2013 22:54:17 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets
Message-ID: <20130315225533.621C6481AA@hg.openjdk.java.net>

Changeset: 3a47ed8acafb
Author:    rriggs
Date:      2013-03-15 17:04 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3a47ed8acafb

#283 Serialization of Chronology
#279 Inconsistent serialization for ISO chronology

Added protected to Chronology.writeReplace so that all subclasses can
use the default serialization of Chronology.

Chronology does not implement Serializable so it is the subclass choice.
The recommendation is to make subclasses serializable.

WriteReplace is not final so that a subclass can provide its own serialization.

Modified the initialization of Chronologies so that built-in Chronologies
cannot be replaced by ServiceLoader Chronologies.

Corrected Chronology.ofLocale so it checks the ServiceLoader
for the application if the requested calendar type from the
locale is not found from the system initialized Chronologies.

! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! test/java/time/tck/java/time/TestChronology.java
+ test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java

Changeset: 9f3d8852b19d
Author:    rriggs
Date:      2013-03-15 17:08 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9f3d8852b19d

Renamed Test to TCKIsoChronology; it only tested ISO

- test/java/time/tck/java/time/chrono/TCKChronology.java
+ test/java/time/tck/java/time/chrono/TCKIsoChronology.java

Changeset: cfb0e3db42e3
Author:    rriggs
Date:      2013-03-15 17:16 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cfb0e3db42e3

renamed test into chrono package TCKChronology

- test/java/time/tck/java/time/TestChronology.java
+ test/java/time/tck/java/time/chrono/TCKChronology.java


From xueming.shen at oracle.com  Fri Mar 15 20:33:01 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 03:33:01 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 182 new changesets
Message-ID: <20130316040848.949F6481B6@hg.openjdk.java.net>

Changeset: bb97c93e4fd7
Author:    katleman
Date:      2013-02-21 11:13 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bb97c93e4fd7

Added tag jdk8-b78 for changeset 00b7535d743f

! .hgtags

Changeset: 5245b2f1c53d
Author:    ngthomas
Date:      2013-02-21 17:55 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5245b2f1c53d

8008691: Build failure (NEWBUILD=false) on Mac
Reviewed-by: art, anthony

! make/sun/lwawt/FILES_export_macosx.gmk

Changeset: c933505d75c2
Author:    dcherepanov
Date:      2013-02-26 12:54 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c933505d75c2

Merge


Changeset: d967dd39a5ca
Author:    katleman
Date:      2013-02-28 10:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d967dd39a5ca

Added tag jdk8-b79 for changeset c933505d75c2

! .hgtags

Changeset: 5a1ea5bbe10a
Author:    erikj
Date:      2013-02-21 14:14 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5a1ea5bbe10a

8007387: "sed: RE error: illegal byte sequence" when building images on Mac
Reviewed-by: tbell

! makefiles/Images.gmk

Changeset: a287f6a0d46d
Author:    erikj
Date:      2013-02-21 14:16 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a287f6a0d46d

8008451: Make mac builds on 10.8 work on 10.7
Reviewed-by: ohair, ddehaven

! make/common/Defs-macosx.gmk

Changeset: 5d27f8702118
Author:    erikj
Date:      2013-02-21 14:23 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5d27f8702118

8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk
Reviewed-by: tbell, ohair

! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-utils.gmk

Changeset: f0b5b57014b3
Author:    katleman
Date:      2013-02-26 13:23 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f0b5b57014b3

Merge


Changeset: 8d3dbb724859
Author:    katleman
Date:      2013-02-27 13:10 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d3dbb724859

Merge


Changeset: b760d5d4b8d3
Author:    katleman
Date:      2013-02-28 19:30 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b760d5d4b8d3

8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found
Reviewed-by: tbell

! make/common/shared/Defs-utils.gmk

Changeset: dfb40f066c6c
Author:    katleman
Date:      2013-02-28 20:30 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/dfb40f066c6c

Merge


Changeset: d60a95b95f01
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d60a95b95f01

Added tag jdk8-b80 for changeset dfb40f066c6c

! .hgtags

Changeset: 758db1c4c65c
Author:    ehelin
Date:      2013-03-04 15:40 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/758db1c4c65c

8009384: Temporarily disable jstat tests to ease complicated push
Reviewed-by: mchung

! test/ProblemList.txt

Changeset: aee1c6c52b68
Author:    erikj
Date:      2013-03-06 16:15 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/aee1c6c52b68

8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions?
Reviewed-by: tbell

! makefiles/CompileNativeLibraries.gmk

Changeset: da8edcfc19af
Author:    katleman
Date:      2013-03-11 13:42 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/da8edcfc19af

Merge


Changeset: bc0ca8bc4637
Author:    erikj
Date:      2013-03-12 15:17 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bc0ca8bc4637

8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine
Reviewed-by: dholmes, tbell

! make/common/shared/Defs-utils.gmk
! makefiles/Images.gmk

Changeset: c0f8022eba53
Author:    katleman
Date:      2013-03-12 19:19 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c0f8022eba53

Merge


Changeset: 509c45748f3e
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/509c45748f3e

Added tag jdk8-b81 for changeset c0f8022eba53

! .hgtags

Changeset: f6eb212081b2
Author:    jgodinez
Date:      2013-02-14 14:14 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f6eb212081b2

8008173: [parfait] #1173 Uninitialised variable -- TransformHelper.cpp
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/loops/TransformHelper.c

Changeset: 4b11045a9c4c
Author:    jgodinez
Date:      2013-02-18 14:04 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4b11045a9c4c

8005191: [parfait] #384 sun/font/layout/LookupProcessor.cpp Null pointer dereference
Reviewed-by: prr, vadim
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/font/layout/LookupProcessor.cpp

Changeset: 41008f5cef1a
Author:    lana
Date:      2013-02-19 22:10 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/41008f5cef1a

Merge

- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java
- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java

Changeset: d2d7da120c37
Author:    jgodinez
Date:      2013-02-22 11:01 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d2d7da120c37

8006110: pageDialog is showing the swing dialog with DialogTypeSelection.NATIVE
Reviewed-by: bae, prr

! src/share/classes/sun/print/RasterPrinterJob.java

Changeset: 99c1f910abcc
Author:    jgodinez
Date:      2013-02-22 13:20 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/99c1f910abcc

8005796: [parfait] Possible uninitialised variable at jdk/src/share/native/sun/java2d/loops/ByteBinary1Bit.c
Reviewed-by: prr, vadim, flar
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/loops/AnyByteBinary.h
! src/share/native/sun/java2d/loops/ByteIndexed.h
! src/share/native/sun/java2d/loops/IntArgb.h
! src/share/native/sun/java2d/loops/IntArgbBm.h
! src/share/native/sun/java2d/loops/IntArgbPre.h
! src/share/native/sun/java2d/loops/Ushort4444Argb.h
! src/share/native/sun/java2d/loops/UshortIndexed.h

Changeset: 934f5f10107d
Author:    lana
Date:      2013-02-22 11:37 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/934f5f10107d

Merge


Changeset: 4fd6048a78c0
Author:    lana
Date:      2013-02-22 23:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4fd6048a78c0

Merge


Changeset: f3368a3fc023
Author:    bae
Date:      2013-03-05 17:18 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f3368a3fc023

7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo
Reviewed-by: jgodinez, ant

! src/macosx/classes/sun/font/CStrike.java
! src/macosx/classes/sun/font/CStrikeDisposer.java
! src/macosx/native/sun/font/AWTStrike.m

Changeset: fd8810d50c99
Author:    bae
Date:      2013-03-07 14:05 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fd8810d50c99

8005530: [lcms] Improve performance of ColorConverOp for default destinations
Reviewed-by: prr, jgodinez

! make/sun/cmm/lcms/Makefile
! make/sun/cmm/lcms/mapfile-vers
! makefiles/CompileNativeLibraries.gmk
! makefiles/mapfiles/liblcms/mapfile-vers
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/demo/java2d/J2DBench/build.xml
+ src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg
+ src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_medium.jpg
+ src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_small.jpg
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java
+ src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java
! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: 8e9b133dcec9
Author:    lana
Date:      2013-03-12 16:26 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8e9b133dcec9

Merge


Changeset: e6c94a202bfd
Author:    alexsch
Date:      2013-02-15 14:24 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e6c94a202bfd

7173873: JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) will never lead to SE if EXIT_ON_CLOSE is already set
Reviewed-by: malenkov, serb

! src/share/classes/javax/swing/JFrame.java

Changeset: 4bf242def958
Author:    dingxmin
Date:      2013-02-15 15:05 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4bf242def958

8008289: DefaultButtonModel instance keeps stale listeners in html FormView
Reviewed-by: malenkov, alexsch

! src/share/classes/javax/swing/text/html/FormView.java
+ test/javax/swing/text/html/7189299/bug7189299.java

Changeset: 88a83b9e9baa
Author:    kshefov
Date:      2013-02-15 17:46 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/88a83b9e9baa

8005920: After pressing combination Windows Key and M key, the frame, the instruction and the dialog can't be minimized.
Reviewed-by: serb, denis
Contributed-by: Vera Akulova 

! test/java/awt/Modal/WsDisabledStyle/Winkey/Winkey.java

Changeset: 0fe12ecf80b2
Author:    pchelko
Date:      2013-02-19 11:26 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0fe12ecf80b2

8008374: Build failure (NEWBUILD=false) on Mac
Summary: Fixed an old build system failure
Reviewed-by: art, anthony

! make/sun/lwawt/FILES_export_macosx.gmk

Changeset: 5ad0bd367f6d
Author:    kshefov
Date:      2013-02-19 17:26 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5ad0bd367f6d

8008379: TEST_BUG: Fail automatically with java.lang.NullPointerException.
Reviewed-by: serb, anthony

+ test/java/awt/Modal/ModalDialogMultiscreenTest/ModalDialogMultiscreenTest.java

Changeset: a43115c6359d
Author:    kshefov
Date:      2013-02-19 20:00 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a43115c6359d

8006070: TEST_BUG: Up and down the Y coordinate of the mouse position, the selected item doesn't change for the single list.
Reviewed-by: serb, anthony

+ test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html
+ test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java

Changeset: 9bc26b7b8b47
Author:    lana
Date:      2013-02-19 22:23 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9bc26b7b8b47

Merge

- src/share/classes/java/time/PeriodParser.java
- src/share/classes/java/time/calendar/ChronoDateImpl.java
- src/share/classes/java/time/calendar/HijrahChrono.java
- src/share/classes/java/time/calendar/HijrahDate.java
- src/share/classes/java/time/calendar/HijrahDeviationReader.java
- src/share/classes/java/time/calendar/HijrahEra.java
- src/share/classes/java/time/calendar/JapaneseChrono.java
- src/share/classes/java/time/calendar/JapaneseDate.java
- src/share/classes/java/time/calendar/JapaneseEra.java
- src/share/classes/java/time/calendar/MinguoChrono.java
- src/share/classes/java/time/calendar/MinguoDate.java
- src/share/classes/java/time/calendar/MinguoEra.java
- src/share/classes/java/time/calendar/Ser.java
- src/share/classes/java/time/calendar/ThaiBuddhistChrono.java
- src/share/classes/java/time/calendar/ThaiBuddhistDate.java
- src/share/classes/java/time/calendar/ThaiBuddhistEra.java
- src/share/classes/java/time/calendar/package-info.java
- src/share/classes/java/time/format/DateTimeFormatters.java
- src/share/classes/java/time/format/DateTimePrintException.java
- src/share/classes/java/time/temporal/Chrono.java
- src/share/classes/java/time/temporal/ChronoLocalDate.java
- src/share/classes/java/time/temporal/ChronoLocalDateTime.java
- src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java
- src/share/classes/java/time/temporal/ChronoZonedDateTime.java
- src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java
- src/share/classes/java/time/temporal/Era.java
- src/share/classes/java/time/temporal/ISOChrono.java
- src/share/classes/java/time/temporal/ISOEra.java
- src/share/classes/java/time/temporal/ISOFields.java
- src/share/classes/java/time/temporal/MonthDay.java
- src/share/classes/java/time/temporal/OffsetDate.java
- src/share/classes/java/time/temporal/OffsetDateTime.java
- src/share/classes/java/time/temporal/OffsetTime.java
- src/share/classes/java/time/temporal/Ser.java
- src/share/classes/java/time/temporal/SimplePeriod.java
- src/share/classes/java/time/temporal/TemporalAdder.java
- src/share/classes/java/time/temporal/TemporalSubtractor.java
- src/share/classes/java/time/temporal/Year.java
- src/share/classes/java/time/temporal/YearMonth.java
- src/share/classes/sun/util/calendar/TzIDOldMapping.java
- test/java/time/META-INF/services/java.time.temporal.Chrono
- test/java/time/tck/java/time/calendar/CopticChrono.java
- test/java/time/tck/java/time/calendar/CopticDate.java
- test/java/time/tck/java/time/calendar/CopticEra.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDate.java
- test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/calendar/TestHijrahChrono.java
- test/java/time/tck/java/time/calendar/TestJapaneseChrono.java
- test/java/time/tck/java/time/calendar/TestMinguoChrono.java
- test/java/time/tck/java/time/calendar/TestServiceLoader.java
- test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java
- test/java/time/tck/java/time/format/TCKDateTimePrintException.java
- test/java/time/tck/java/time/temporal/TCKISOFields.java
- test/java/time/tck/java/time/temporal/TCKMonthDay.java
- test/java/time/tck/java/time/temporal/TCKOffsetDate.java
- test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java
- test/java/time/tck/java/time/temporal/TCKOffsetTime.java
- test/java/time/tck/java/time/temporal/TCKSimplePeriod.java
- test/java/time/tck/java/time/temporal/TCKYear.java
- test/java/time/tck/java/time/temporal/TCKYearMonth.java
- test/java/time/tck/java/time/temporal/TestChrono.java
- test/java/time/tck/java/time/temporal/TestISOChrono.java
- test/java/time/test/java/time/TestPeriodParser.java
- test/java/time/test/java/time/format/TestDateTimeFormatters.java
- test/java/time/test/java/time/format/TestDateTimePrintException.java
- test/java/time/test/java/time/format/TestPadParserDecorator.java
- test/java/time/test/java/time/format/TestZoneIdParser.java
- test/java/time/test/java/time/temporal/TestISOChronoImpl.java
- test/java/time/test/java/time/temporal/TestMonthDay.java
- test/java/time/test/java/time/temporal/TestOffsetDate.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime.java
- test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java
- test/java/time/test/java/time/temporal/TestOffsetTime.java
- test/java/time/test/java/time/temporal/TestYear.java
- test/java/time/test/java/time/temporal/TestYearMonth.java

Changeset: 73d1efc4710a
Author:    ant
Date:      2013-02-22 15:13 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/73d1efc4710a

8006406: lightweight embedding in other Java UI toolkits
Reviewed-by: serb, anthony, art

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
+ src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java
+ src/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java
+ src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java
+ src/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/peer/FramePeer.java
! src/share/classes/java/awt/peer/WindowPeer.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/HToolkit.java
+ src/share/classes/sun/awt/LightweightFrame.java
! src/share/classes/sun/awt/SunToolkit.java
+ src/share/classes/sun/swing/JLightweightFrame.java
+ src/share/classes/sun/swing/LightweightContent.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/windows/classes/sun/awt/windows/WFramePeer.java
+ src/windows/classes/sun/awt/windows/WLightweightFramePeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_Frame.h
! src/windows/native/sun/windows/awt_Window.h

Changeset: 63bb402d4a6a
Author:    lana
Date:      2013-02-23 19:49 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/63bb402d4a6a

Merge


Changeset: d502cc7bcc3d
Author:    pchelko
Date:      2013-02-25 10:17 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d502cc7bcc3d

8006634: Unify LWCToolkit.invokeAndWait() and sun.awt.datatransfer.ToolkitThreadBlockedHandler
Summary: Changed the logic for the nested event loops and deleted deadlock detection
Reviewed-by: art, denis

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/ApplicationDelegate.m
! src/macosx/native/sun/awt/CClipboard.m
! src/macosx/native/sun/awt/CDropTarget.m
! src/macosx/native/sun/awt/CMenu.m
! src/macosx/native/sun/awt/CMenuBar.m
! src/macosx/native/sun/awt/CMenuItem.m
! src/macosx/native/sun/awt/JavaComponentAccessibility.m
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m

Changeset: e58f0b163f43
Author:    denis
Date:      2013-02-27 19:38 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e58f0b163f43

7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13
Reviewed-by: serb, anthony

! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java

Changeset: bc914b7f0878
Author:    denis
Date:      2013-02-27 20:34 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bc914b7f0878

8009158: Incomplete fix for 7178079
Reviewed-by: serb, anthony

! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java

Changeset: 3dee850e2653
Author:    serb
Date:      2013-02-28 17:04 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3dee850e2653

8008660: Failure in 2D Queue Flusher thread on Mac
Reviewed-by: swingler, bae

! src/macosx/classes/sun/awt/CGraphicsConfig.java
! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/lwawt/macosx/CRobot.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/CRobot.m
! src/macosx/native/sun/awt/LWCToolkit.h
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m

Changeset: 554d0f41a6ab
Author:    serb
Date:      2013-02-28 20:27 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/554d0f41a6ab

8003169: [macosx] JVM crash after disconnecting from projector
Reviewed-by: anthony, alexsch

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/CGraphicsDevice.m

Changeset: 657a02fcaa00
Author:    malenkov
Date:      2013-03-01 14:30 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/657a02fcaa00

7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs
Reviewed-by: alexsch

! src/share/classes/java/beans/PropertyDescriptor.java
! test/java/beans/Introspector/Test7192955.java

Changeset: 5816595a4cdc
Author:    serb
Date:      2013-03-01 15:31 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5816595a4cdc

7194902: [macosx] closed/java/awt/Button/DoubleActionEventTest/DoubleActionEventTest failed since jdk8b49
7181403: Invalid MouseEvent conversion with SwingUtilities.convertMouseEvent
Reviewed-by: malenkov, alexsch

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/share/classes/javax/swing/SwingUtilities.java

Changeset: 4912a9e3a95e
Author:    serb
Date:      2013-03-01 21:50 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4912a9e3a95e

7184945: [macosx] NPE in AquaComboBoxUI since jdk7u6b17, jdk8b47
Reviewed-by: malenkov, alexsch

! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java

Changeset: 91e17a813483
Author:    alexsch
Date:      2013-03-06 19:42 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/91e17a813483

6877495: JTextField and JTextArea does not support supplementary characters
Reviewed-by: serb, alexp

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
+ test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java

Changeset: 7962014b1729
Author:    mcherkas
Date:      2013-03-06 20:10 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7962014b1729

8007295: Reduce number of warnings in awt classes
Reviewed-by: bae, anthony

! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/Menu.java
! src/share/classes/java/awt/MenuBar.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/datatransfer/Clipboard.java
! src/share/classes/java/awt/dnd/DragGestureEvent.java
! src/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/share/classes/java/awt/dnd/DragSource.java
! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/share/classes/java/awt/geom/AffineTransform.java

Changeset: f3ffead3069e
Author:    lana
Date:      2013-03-12 16:28 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f3ffead3069e

Merge


Changeset: 153884b550f0
Author:    chegar
Date:      2013-02-14 13:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/153884b550f0

8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList
Reviewed-by: mcimadamore

! test/ProblemList.txt

Changeset: e57019d2f34a
Author:    mduigou
Date:      2013-02-13 14:50 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e57019d2f34a

8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up
Reviewed-by: mduigou, martin
Contributed-by: Peter Levart 

! src/share/classes/java/util/IdentityHashMap.java

Changeset: 1405ad6afb1e
Author:    bharadwaj
Date:      2013-02-14 11:09 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1405ad6afb1e

8007736: VerifyError for use of static method in interface
Reviewed-by: mchung

! src/share/native/common/check_code.c
+ test/vm/verifier/TestStaticIF.java

Changeset: 1ce1a307cded
Author:    sherman
Date:      2013-02-15 01:17 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1ce1a307cded

8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing
Summary: to use j.t.ZoneId zone name to keep round-trip
Reviewed-by: okutsu

! test/java/util/Calendar/JavatimeTest.java

Changeset: 048637b40787
Author:    chegar
Date:      2013-02-15 11:06 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/048637b40787

8008223: java/net/BindException/Test.java fails rarely
Reviewed-by: khazra, alanb

! test/java/net/BindException/Test.java

Changeset: 7748ffdca16a
Author:    rfield
Date:      2013-02-16 12:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7748ffdca16a

8004970: Implement serialization in the lambda metafactory
Reviewed-by: forax

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/lang/invoke/MethodHandleInfo.java
+ src/share/classes/java/lang/invoke/SerializedLambda.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
+ test/java/lang/invoke/lambda/LambdaSerialization.java

Changeset: 43726ed11fb3
Author:    sherman
Date:      2013-02-17 01:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/43726ed11fb3

8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control
Summary: To remove jdk/make/tools/javazic from the jdk repo
Reviewed-by: alanb

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java

Changeset: ce6a2fcb4c9b
Author:    yhuang
Date:      2013-02-16 21:22 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ce6a2fcb4c9b

8006748: getISO3Country() returns wrong value
Reviewed-by: naoto

! src/share/classes/java/util/LocaleISOData.java

Changeset: bcde0486261e
Author:    dingxmin
Date:      2013-02-18 08:14 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bcde0486261e

6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps
Reviewed-by: alanb

! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
+ test/java/nio/channels/Selector/RacyDeregister.java

Changeset: 49b3d8efd30a
Author:    darcy
Date:      2013-02-19 00:19 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/49b3d8efd30a

8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone
Reviewed-by: mduigou, okutsu

! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/util/TimeZone.java

Changeset: 885bb24f6018
Author:    coffeys
Date:      2013-02-19 14:07 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/885bb24f6018

7197187: Currency.isPastCutoverDate should be made more robust
Reviewed-by: alanb

! src/share/classes/java/util/Currency.java

Changeset: 01b6b0dd2006
Author:    coffeys
Date:      2013-02-19 14:12 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/01b6b0dd2006

8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/net/www/protocol/http/HttpOnly.java

Changeset: 824187de1591
Author:    jzavgren
Date:      2013-02-19 16:19 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/824187de1591

8007609: WinNTFileSystem_md.c should correctly check value returned from realloc
Reviewed-by: alanb, chegar, dholmes

! src/windows/native/java/io/WinNTFileSystem_md.c

Changeset: e20c1c9197bf
Author:    emc
Date:      2013-02-19 17:09 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e20c1c9197bf

8008312: Re-enable MethodParameter tests in JDK
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Parameter.java
! test/java/lang/reflect/Parameter/WithParameters.java

Changeset: af396ec087f4
Author:    naoto
Date:      2013-02-19 10:34 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/af396ec087f4

7092447: Clarify the default locale used in each locale sensitive operation
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java

Changeset: 16efb7ba188f
Author:    mduigou
Date:      2013-02-19 11:56 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/16efb7ba188f

8004561: Additional functional interfaces, extension methods and name changes
Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions.
Reviewed-by: briangoetz, darcy, chegar, dholmes

! src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java
+ src/share/classes/java/util/function/BiConsumer.java
+ src/share/classes/java/util/function/BiFunction.java
+ src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
- src/share/classes/java/util/function/Block.java
+ src/share/classes/java/util/function/BooleanSupplier.java
+ src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
- src/share/classes/java/util/function/DoubleBlock.java
+ src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
+ src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
- src/share/classes/java/util/function/IntBlock.java
+ src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
+ src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
- src/share/classes/java/util/function/LongBlock.java
+ src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
+ src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
+ src/share/classes/java/util/function/ObjDoubleConsumer.java
+ src/share/classes/java/util/function/ObjIntConsumer.java
+ src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
+ src/share/classes/java/util/function/ToDoubleBiFunction.java
+ src/share/classes/java/util/function/ToDoubleFunction.java
+ src/share/classes/java/util/function/ToIntBiFunction.java
+ src/share/classes/java/util/function/ToIntFunction.java
+ src/share/classes/java/util/function/ToLongBiFunction.java
+ src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/function/package-info.java
! test/java/lang/PrimitiveSumMinMaxTest.java

Changeset: 267bca6af07e
Author:    jzavgren
Date:      2013-02-19 15:31 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/267bca6af07e

8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
Reviewed-by: mullan, chegar

! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c

Changeset: ec1a79c3a99c
Author:    ksrini
Date:      2013-02-19 16:49 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ec1a79c3a99c

8008262: pack200 should support MethodParameters - part 2
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/native/com/sun/java/util/jar/pack/bands.cpp
! src/share/native/com/sun/java/util/jar/pack/bands.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! test/tools/pack200/AttributeTests.java
! test/tools/pack200/Utils.java

Changeset: 85a44860f5bb
Author:    lana
Date:      2013-02-19 20:52 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/85a44860f5bb

Merge

- src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java

Changeset: ca43e2761a1d
Author:    ykantser
Date:      2013-02-13 10:24 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ca43e2761a1d

8008089: Delete OS dependent check in JdkFinder.getExecutable()
Reviewed-by: egahlin, alanb

! test/lib/testlibrary/jdk/testlibrary/JdkFinder.java

Changeset: 0a2b308cc82d
Author:    uta
Date:      2013-02-20 16:39 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0a2b308cc82d

8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN)
Summary: the SetHandleInformation arguments list was fixed.
Reviewed-by: alanb

! src/windows/native/java/lang/ProcessImpl_md.c

Changeset: 5772e9edbc4c
Author:    dcubed
Date:      2013-02-20 13:23 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5772e9edbc4c

8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS
Summary: Use more portable pattern counting constructs in test driver.
Reviewed-by: sspitsyn, sla, coleenp

! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh

Changeset: 1da987f0311a
Author:    rfield
Date:      2013-02-21 15:46 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1da987f0311a

8008356: Test LambdaSerialization.java failing
Summary: run in /othervm mode
Reviewed-by: ksrini

! test/java/lang/invoke/lambda/LambdaSerialization.java

Changeset: 03db11a7fb8e
Author:    lana
Date:      2013-02-21 17:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/03db11a7fb8e

Merge


Changeset: 9078c34437ab
Author:    msheppar
Date:      2013-02-21 20:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9078c34437ab

8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests
Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder
Reviewed-by: vinnie, chegar, sherman

! src/share/classes/sun/security/pkcs10/PKCS10.java
! src/share/classes/sun/security/provider/X509Factory.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! src/share/classes/sun/security/x509/X509CertImpl.java
! src/share/classes/sun/tools/jar/Manifest.java
! src/share/classes/sun/tools/jar/SignatureFile.java
! test/javax/security/auth/kerberos/KerberosTixDateTest.java
! test/sun/security/krb5/auto/HttpNegotiateServer.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java

Changeset: c6d77b2b4478
Author:    stefank
Date:      2013-01-22 13:53 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c6d77b2b4478

8006506: Add test for redefining methods in backtraces to java/lang/instrument tests
Reviewed-by: sspitsyn, coleenp

+ test/java/lang/instrument/RedefineMethodInBacktrace.sh
+ test/java/lang/instrument/RedefineMethodInBacktraceAgent.java
+ test/java/lang/instrument/RedefineMethodInBacktraceApp.java
+ test/java/lang/instrument/RedefineMethodInBacktraceTarget.java
+ test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java

Changeset: 0e93015e77f6
Author:    stefank
Date:      2013-01-22 15:25 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0e93015e77f6

7140852: Add test for 7022100
Reviewed-by: sspitsyn, coleenp

+ test/java/lang/instrument/RedefineMethodWithAnnotations.sh
+ test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java
+ test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java
+ test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java
+ test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
+ test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 63fe6a9820b6
Author:    alanb
Date:      2013-02-22 14:04 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/63fe6a9820b6

8008290: (profiles) Startup regression due to additional checking of JAR file manifests
Reviewed-by: lancea, chegar, iris, mchung, sherman

! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/URLClassPath.java

Changeset: 9f9dac5a9e74
Author:    lancea
Date:      2013-02-22 09:29 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9f9dac5a9e74

8008716: address typo in CallableStatement javadocs
Reviewed-by: chegar

! src/share/classes/java/sql/CallableStatement.java

Changeset: 8d8a35ac7d40
Author:    lancea
Date:      2013-02-22 09:58 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d8a35ac7d40

Merge


Changeset: 6f9b3e216b01
Author:    darcy
Date:      2013-02-23 13:32 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6f9b3e216b01

6556996: (ann spec) SuppressWarnings strings should be documented
Reviewed-by: mduigou, chegar, abuckley

! src/share/classes/java/lang/Deprecated.java
! src/share/classes/java/lang/Override.java
! src/share/classes/java/lang/SafeVarargs.java
! src/share/classes/java/lang/SuppressWarnings.java
! src/share/classes/java/lang/annotation/Inherited.java
! src/share/classes/java/lang/annotation/Retention.java
! src/share/classes/java/lang/annotation/Target.java

Changeset: 155095c245b4
Author:    alanb
Date:      2013-02-25 17:17 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/155095c245b4

8008808: Allowed dependencies added by JDK-8008481 no longer required
Reviewed-by: tbell, chegar

! make/tools/src/build/tools/deps/refs.allowed

Changeset: 58f829566fe3
Author:    bchristi
Date:      2013-02-25 14:19 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/58f829566fe3

8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C
Summary: Avoid automated test failure by just exiting when in 'C' locale
Reviewed-by: naoto, ksrini

! test/ProblemList.txt
! test/tools/launcher/I18NJarTest.java

Changeset: 4cf4403c9bf2
Author:    jjg
Date:      2013-02-25 15:08 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4cf4403c9bf2

8008914: Add nashorn to the tl build
Reviewed-by: mr, tbell, jjh
Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com

! make/launchers/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: bc92e4b044e2
Author:    kmo
Date:      2013-02-26 11:05 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bc92e4b044e2

7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor
Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit
Reviewed-by: jrose, twisti

! src/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleInfo.java
! src/share/classes/java/lang/invoke/MethodHandles.java
+ test/java/lang/invoke/7087570/Test7087570.java

Changeset: 5fcecbcefb71
Author:    chegar
Date:      2013-02-26 11:06 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5fcecbcefb71

Merge


Changeset: 77447981db73
Author:    chegar
Date:      2013-02-26 11:18 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/77447981db73

Merge


Changeset: 022cd5adc0fa
Author:    alanb
Date:      2013-02-26 14:16 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/022cd5adc0fa

8008977: profiles build broken by Nashorn build changes
Reviewed-by: chegar

! makefiles/profile-rtjar-includes.txt

Changeset: 5ebc62421717
Author:    rfield
Date:      2013-02-26 10:38 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5ebc62421717

8008770: SerializedLambda incorrect class loader for lambda deserializing class
Summary: current thread's context ClassLoader was used to load class by name, pass class not name in serialization (Thank you Peter Levart for test and prototype. Thank you Sundar and Peter for unofficial reviews)
Reviewed-by: forax

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/SerializedLambda.java
+ test/java/lang/invoke/lambda/LambdaClassLoaderSerialization.java
! test/java/lang/invoke/lambda/LambdaSerialization.java

Changeset: ecd33c6ab12f
Author:    alanb
Date:      2013-02-26 22:39 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ecd33c6ab12f

8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes
Reviewed-by: mduigou

! makefiles/CreateJars.gmk

Changeset: 543be9488e50
Author:    darcy
Date:      2013-02-26 17:01 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/543be9488e50

8009102: Several docs warnings in Project Lambda APIs
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java

Changeset: d623f520557b
Author:    darcy
Date:      2013-02-26 17:38 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d623f520557b

8008279: Remove InvalidContainerAnnotationError.java
Reviewed-by: jfranck

- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/sun/reflect/annotation/AnnotationSupport.java

Changeset: f5416026cdf5
Author:    sundar
Date:      2013-02-27 17:22 +0530
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f5416026cdf5

8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine
Reviewed-by: alanb

! test/javax/script/CauseExceptionTest.java
+ test/javax/script/ExceptionTest.java
! test/javax/script/GetInterfaceTest.java
! test/javax/script/Helper.java
- test/javax/script/RhinoExceptionTest.java
! test/javax/script/StringWriterPrintTest.java
! test/javax/script/Test3.js
! test/javax/script/Test5.java
! test/javax/script/Test5.js
! test/javax/script/Test6.java
! test/javax/script/Test7.js
! test/javax/script/UnescapedBracketRegExTest.java
! test/javax/script/VersionTest.java

Changeset: 13013dedcdfd
Author:    alanb
Date:      2013-02-27 14:24 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/13013dedcdfd

8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present
Reviewed-by: hawtin, mullan, dsamersoff, mchung

! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/sun/security/util/SecurityConstants.java
! test/java/lang/SecurityManager/NoAWT.java

Changeset: 1b3173c326e6
Author:    sundar
Date:      2013-02-27 20:34 +0530
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1b3173c326e6

8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine
Reviewed-by: alanb

! test/sun/tools/jrunscript/CheckEngine.java
! test/sun/tools/jrunscript/jrunscript-DTest.sh
! test/sun/tools/jrunscript/jrunscript-argsTest.sh
! test/sun/tools/jrunscript/jrunscript-cpTest.sh
! test/sun/tools/jrunscript/jrunscript-eTest.sh
! test/sun/tools/jrunscript/jrunscript-fTest.sh
! test/sun/tools/jrunscript/jrunscriptTest.sh
! test/sun/tools/jrunscript/repl.out

Changeset: 093fdf8937bd
Author:    vladidan
Date:      2013-02-22 17:12 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/093fdf8937bd

8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries
Summary: Adding sun.os.abi Java Property support
Reviewed-by: bobv, alanb, dholmes

! makefiles/Images.gmk
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_md.c

Changeset: f4b01f4e8f35
Author:    mduigou
Date:      2013-02-27 11:00 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f4b01f4e8f35

8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167
Reviewed-by: alanb

! src/share/classes/java/util/IdentityHashMap.java
+ test/java/util/Map/ToArray.java

Changeset: 7d272e524768
Author:    chegar
Date:      2013-02-28 12:39 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7d272e524768

8006409: ThreadLocalRandom should dropping padding fields from its serialized form
Reviewed-by: dl, martin, alanb, shade

! src/share/classes/java/util/concurrent/ThreadLocalRandom.java

Changeset: 7246a6e4dd5a
Author:    juh
Date:      2013-02-28 16:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7246a6e4dd5a

8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/OCSP.java

Changeset: def2e05299b7
Author:    xuelei
Date:      2013-03-01 02:34 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/def2e05299b7

7030966: Support AEAD CipherSuites
Reviewed-by: weijun, wetmore, valeriep

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
+ src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: 1652ac7b4bfd
Author:    mullan
Date:      2013-03-01 16:12 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1652ac7b4bfd

8008908: Access denied when invoking Subject.doAsPrivileged()
Summary: wildcard principal names are not processed correctly
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/PolicyFile.java
+ test/sun/security/provider/PolicyFile/WildcardPrincipalName.java
+ test/sun/security/provider/PolicyFile/wildcard.policy

Changeset: 1ca712765acb
Author:    mullan
Date:      2013-03-01 16:15 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1ca712765acb

Merge


Changeset: 30e30ef6077e
Author:    dxu
Date:      2013-03-01 14:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/30e30ef6077e

8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol)
Summary: Fix test failures and update java doc of Files.move
Reviewed-by: alanb, chegar

! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/CopyAndMove.java

Changeset: f08ad5938709
Author:    chegar
Date:      2013-03-02 08:54 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f08ad5938709

8008378: FJP.commonPool support parallelism 0, add awaitQuiescence
Reviewed-by: chegar
Contributed-by: Doug Lea 
, Chris Hegarty 

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
+ test/java/util/concurrent/forkjoin/ThreadLessCommon.java
+ test/java/util/concurrent/forkjoin/ThrowingRunnable.java

Changeset: df76ba760eec
Author:    ksrini
Date:      2013-03-03 20:52 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/df76ba760eec

8007297: [pack200] allow opcodes with InterfaceMethodRefs
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Constants.java
! src/share/classes/com/sun/java/util/jar/pack/Instruction.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/native/com/sun/java/util/jar/pack/constants.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! test/tools/pack200/AttributeTests.java
! test/tools/pack200/InstructionTests.java
! test/tools/pack200/Utils.java

Changeset: 83e847f59fd6
Author:    darcy
Date:      2013-03-04 19:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/83e847f59fd6

8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations
Reviewed-by: jjg

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/reflect/AccessibleObject.java
+ test/java/lang/reflect/OldenCompilingWithDefaults.java

Changeset: 1a2e59d19d3e
Author:    naoto
Date:      2013-03-04 20:46 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1a2e59d19d3e

8004240: Return value from getAdapterPrefence() can be modified
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ test/java/util/Locale/Bug8004240.java

Changeset: 62639ca66ab9
Author:    ewang
Date:      2013-03-05 10:10 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/62639ca66ab9

8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently
Reviewed-by: chegar, alanb

! test/sun/misc/Cleaner/ExitOnThrow.java
! test/sun/misc/Cleaner/exitOnThrow.sh

Changeset: b5bef1f71de6
Author:    jzavgren
Date:      2013-03-05 14:30 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b5bef1f71de6

8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c
Reviewed-by: alanb, chegar, dsamersoff

! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c

Changeset: be79440b8026
Author:    jzavgren
Date:      2013-03-05 09:50 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/be79440b8026

4880778: URL final class has protected methods
Summary: The two set() methods have been defined to be package private.
Reviewed-by: alanb, chegar, khazra

! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLStreamHandler.java

Changeset: f960a34f05ce
Author:    lana
Date:      2013-03-05 11:49 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f960a34f05ce

Merge

! makefiles/Images.gmk

Changeset: 34372bb9115d
Author:    sla
Date:      2013-03-05 19:25 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/34372bb9115d

8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket
Reviewed-by: alanb

! src/share/back/transport.c
! src/share/demo/jvmti/hprof/hprof_init.c
! src/solaris/back/linker_md.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/windows/back/linker_md.c
! src/windows/demo/jvmti/hprof/hprof_md.c

Changeset: 38e1821c4472
Author:    jfranck
Date:      2013-03-06 18:35 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/38e1821c4472

8007808: Missing method: Executable.getAnnotatedReturnType()
Reviewed-by: darcy, forax

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Method.java

Changeset: 14e49a70729a
Author:    martin
Date:      2013-03-06 17:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/14e49a70729a

8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
Summary: Define FILES_m to force use of linker script
Reviewed-by: sherman, alanb, ohair

! make/java/zip/Makefile
! src/share/native/java/util/zip/Inflater.c

Changeset: cf54f6be3e9e
Author:    weijun
Date:      2013-03-07 11:32 +0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cf54f6be3e9e

8009604: old make images failed: JarBASE64Encoder class not found
Reviewed-by: xuelei, wetmore

! make/common/Release.gmk

Changeset: 48b7295f02f8
Author:    chegar
Date:      2013-03-07 10:07 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/48b7295f02f8

6370908: Add support for HTTP_CONNECT proxy in Socket class
Reviewed-by: chegar
Contributed-by: Damjan Jovanovic , Chris Hegarty 

+ src/share/classes/java/net/HttpConnectSocketImpl.java
! src/share/classes/java/net/Socket.java
+ test/java/net/Socket/HttpProxy.java

Changeset: 98cf76df3e6e
Author:    alanb
Date:      2013-03-08 12:03 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/98cf76df3e6e

8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently
Reviewed-by: chegar

+ test/java/lang/invoke/lambda/LUtils.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlTest.java

Changeset: 01908630df14
Author:    alanb
Date:      2013-03-08 19:51 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/01908630df14

8009645: ClassFileTransformer hooks in ClassLoader no longer required
Reviewed-by: mchung, iris

! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/sun/misc/ClassFileTransformer.java

Changeset: e38b46041049
Author:    mduigou
Date:      2013-03-08 15:45 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e38b46041049

8001667: Comparator combinators and extension methods
Reviewed-by: mduigou, briangoetz
Contributed-by: henry.jen at oracle.com

! make/java/java/FILES_java.gmk
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
+ src/share/classes/java/util/Comparators.java
! test/java/util/Collections/ReverseOrder.java
+ test/java/util/ComparatorsTest.java

Changeset: 230bafd05509
Author:    weijun
Date:      2013-03-09 17:27 +0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/230bafd05509

8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid)
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/GSSCredentialImpl.java
! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java
! test/sun/security/krb5/auto/Context.java
+ test/sun/security/krb5/auto/SpnegoLifeTime.java

Changeset: 334ddf3b101f
Author:    coleenp
Date:      2013-03-12 10:35 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/334ddf3b101f

7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions.
Summary: Do not check that the padding bytes are zero if class file format version >=51.
Reviewed-by: dholmes, coleenp, mullan, kvn
Contributed-by: harold.seigel at oracle.com

! src/share/native/common/check_code.c

Changeset: 6379415d8fca
Author:    wetmore
Date:      2013-03-12 15:31 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6379415d8fca

8009925: Back out AEAD CipherSuites temporarily
Reviewed-by: valeriep

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
- src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: 5880bfd30db1
Author:    lana
Date:      2013-03-12 16:40 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5880bfd30db1

Merge

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
- test/javax/script/RhinoExceptionTest.java

Changeset: 72ffb2bc15bb
Author:    lana
Date:      2013-03-12 18:12 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72ffb2bc15bb

Merge

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
! test/ProblemList.txt
- test/javax/script/RhinoExceptionTest.java

Changeset: 66a892bb28b7
Author:    anthony
Date:      2012-10-12 15:51 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/66a892bb28b7

7173145: Improve in-memory representation of splashscreens
Reviewed-by: bae, mschoene

! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c

Changeset: 85bf51db473c
Author:    xuelei
Date:      2012-10-15 07:42 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/85bf51db473c

7192393: Better Checking of order of TLS Messages
Summary: Also reviewed by Andrew Gross
Reviewed-by: weijun

! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java

Changeset: 24a3eb2f0553
Author:    malenkov
Date:      2012-10-15 19:00 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/24a3eb2f0553

7200493: Improve cache handling
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/finder/MethodFinder.java

Changeset: c7c39320bc6c
Author:    rupashka
Date:      2012-10-16 14:13 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c7c39320bc6c

7186948: Improve Swing data validation
Reviewed-by: art, ahgross

! src/share/classes/javax/swing/UIDefaults.java

Changeset: 3c8d0085b094
Author:    ksrini
Date:      2012-10-16 12:29 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3c8d0085b094

7186945: Unpack200 improvement
Reviewed-by: jrose, jjh, mschoene

! src/share/native/com/sun/java/util/jar/pack/jni.cpp

Changeset: 01f67953c057
Author:    ksrini
Date:      2012-10-16 12:35 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/01f67953c057

7186957: Improve Pack200 data validation
Reviewed-by: jrose, jjh, mschoene

! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/native/com/sun/java/util/jar/pack/bands.cpp
! src/share/native/com/sun/java/util/jar/pack/bands.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp

Changeset: b0bf41ba1cf8
Author:    ksrini
Date:      2012-10-16 12:38 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b0bf41ba1cf8

7186946: Refine unpacker resource usage
Reviewed-by: jrose, jjh, mschoene

! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/native/com/sun/java/util/jar/pack/jni.cpp
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp

Changeset: f0bc5a6dff2b
Author:    ksrini
Date:      2012-10-16 16:38 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f0bc5a6dff2b

7200499: Better data validation for options
Reviewed-by: darcy, jjh, mschoene

! src/share/bin/jli_util.h
! src/windows/bin/java_md.c

Changeset: 7e19ab4ff5d3
Author:    ksrini
Date:      2012-10-16 10:56 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7e19ab4ff5d3

7200500: Launcher better input validation
Reviewed-by: darcy, jjh, mschoene

! src/share/bin/parse_manifest.c

Changeset: 62f3270f03fa
Author:    dholmes
Date:      2012-08-22 21:40 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/62f3270f03fa

6776941: Improve thread pool shutdown
Reviewed-by: dl, skoivu

! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java

Changeset: e7cce63bf293
Author:    xuelei
Date:      2012-10-22 07:28 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e7cce63bf293

7192392: Better validation of client keys
Summary: Also reviewed by Andrew Gross
Reviewed-by: vinnie

! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java
! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/share/classes/sun/security/ssl/DHCrypt.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
- src/share/classes/sun/security/util/KeyLength.java
+ src/share/classes/sun/security/util/KeyUtil.java
! test/sun/security/mscapi/ShortRSAKeyWithinTLS.java

Changeset: 091dd6eb30aa
Author:    khazra
Date:      2012-10-22 11:49 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/091dd6eb30aa

7186954: Improve connection performance
Reviewed-by: chegar, skoivu

! src/share/classes/sun/net/httpserver/ChunkedInputStream.java
! src/share/classes/sun/net/www/http/ChunkedInputStream.java

Changeset: c26d42a92bd8
Author:    weijun
Date:      2012-09-19 12:58 +0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c26d42a92bd8

8000210: Improve JarFile code quality
Reviewed-by: ahgross, xuelei, mschoene

! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/sun/security/util/DerIndefLenConverter.java

Changeset: a54b61ae6f12
Author:    mullan
Date:      2012-10-26 15:21 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a54b61ae6f12

7201068: Better handling of UI elements
Reviewed-by: xuelei

! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 71ab8d79c6b4
Author:    asaha
Date:      2012-10-26 10:01 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/71ab8d79c6b4

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/sun/invoke/util/ValueConversions.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: be07910b3fad
Author:    asaha
Date:      2012-10-26 13:48 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/be07910b3fad

Merge


Changeset: e14221289076
Author:    dsamersoff
Date:      2012-10-30 17:05 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e14221289076

8000539: JMX implementation allows invocation of methods of a system class
Summary: Added extra packageAccess check call
Reviewed-by: ahgross, dfuchs
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java

Changeset: 64440cc2ea8b
Author:    mchung
Date:      2012-11-02 16:50 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/64440cc2ea8b

7197546: (proxy) Reflect about creating reflective proxies
Reviewed-by: alanb, jdn, jrose

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy

Changeset: f936be5be1e7
Author:    rupashka
Date:      2012-11-06 15:30 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f936be5be1e7

7200491: Tighten up JTable layout code
Reviewed-by: art, skoivu

! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java

Changeset: 3069b91ff041
Author:    chegar
Date:      2012-11-07 14:26 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3069b91ff041

7201071: InetSocketAddress serialization issue
Reviewed-by: alanb, michaelm, skoivu

! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c
! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c
! src/windows/native/sun/nio/ch/DatagramChannelImpl.c
! test/java/nio/channels/DatagramChannel/SendToUnresolved.java

Changeset: 69fd15e0437d
Author:    smarks
Date:      2012-11-08 15:41 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/69fd15e0437d

7201070: Serialization to conform to protocol
Reviewed-by: dmocek, ahgross, skoivu

! src/share/classes/java/io/ObjectInputStream.java

Changeset: 9097b6ec0ecd
Author:    ksrini
Date:      2012-11-09 14:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9097b6ec0ecd

8002091: tools/launcher/ToolsOpts.java test started to fail since 7u11 b01 on Windows
Reviewed-by: darcy, jjh, mschoene

! src/share/bin/jli_util.h
! src/windows/bin/java_md.c
! test/tools/launcher/ToolsOpts.java

Changeset: 7bc8d5a63d9e
Author:    bagiras
Date:      2012-11-15 23:03 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7bc8d5a63d9e

7192977: Issue in toolkit thread
Reviewed-by: skoivu, rupashka, art

! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/Window.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/sun/applet/AppletPanel.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java

Changeset: 09e2dcd476cf
Author:    bae
Date:      2012-11-16 11:05 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/09e2dcd476cf

8001972: Improve image processing
Reviewed-by: prr, ahgross

! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/ByteInterleavedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/classes/sun/awt/image/ShortInterleavedRaster.java
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/medialib/safe_alloc.h

Changeset: 1b616e1ca09c
Author:    dmocek
Date:      2012-11-19 13:54 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1b616e1ca09c

6563318: RMI data sanitization
Reviewed-by: ahgross, hawtin, mchung, smarks

! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! test/java/rmi/testlibrary/JavaVM.java

Changeset: aa8717a5c9cd
Author:    dmocek
Date:      2012-11-19 15:38 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/aa8717a5c9cd

8001242: Improve RMI HTTP conformance
Reviewed-by: ahgross, mchung, smarks

! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java

Changeset: ecedf46ae7db
Author:    bae
Date:      2012-11-20 11:46 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ecedf46ae7db

8002325: Improve management of images
Reviewed-by: prr, ahgross

! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/image/awt_parseImage.h

Changeset: eda84d5738e3
Author:    denis
Date:      2012-11-26 20:49 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/eda84d5738e3

7186952: Improve clipboard access
Reviewed-by: serb, ahgross

! src/share/classes/java/awt/TextComponent.java
! src/windows/native/sun/windows/awt_TextComponent.cpp
! src/windows/native/sun/windows/awt_TextComponent.h

Changeset: d1668eca22bf
Author:    mchung
Date:      2012-11-26 22:49 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d1668eca22bf

6664509: Add logging context
6664528: Find log level matching its name or value given at construction time
Reviewed-by: alanb, ahgross, jgish, hawtin

! src/share/classes/java/util/logging/Level.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/java/util/logging/SimpleFormatter.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! src/share/lib/security/java.security

Changeset: b8ee2e9ff7e3
Author:    denis
Date:      2012-11-30 15:51 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b8ee2e9ff7e3

7201064: Better dialogue checking
Reviewed-by: serb, skoivu

! src/share/classes/java/awt/Dialog.java

Changeset: 90bbdae7aaa4
Author:    ewendeli
Date:      2013-02-03 23:25 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/90bbdae7aaa4

Merge

! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/java/util/logging/SimpleFormatter.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
- src/share/classes/sun/security/util/KeyLength.java
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/share/native/com/sun/java/util/jar/pack/bands.cpp
! src/share/native/com/sun/java/util/jar/pack/bands.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c
! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c
! src/windows/native/sun/nio/ch/DatagramChannelImpl.c
! test/java/rmi/testlibrary/JavaVM.java

Changeset: cc2057f84eb7
Author:    mchung
Date:      2012-12-05 14:02 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cc2057f84eb7

8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows}
Reviewed-by: alanb, ahgross, mullan

! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 89e43b8940c9
Author:    dsamersoff
Date:      2012-12-07 22:49 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/89e43b8940c9

8000537: Contextualize RequiredModelMBean class
Summary: Contextualize RequiredModelMBean class
Reviewed-by: asaha
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java

Changeset: 7933c80c162a
Author:    denis
Date:      2012-12-12 21:08 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7933c80c162a

8004341: Two JCK tests fails with 7u11 b06
Reviewed-by: serb, skoivu

! src/share/classes/java/awt/Dialog.java

Changeset: ed08394e1a15
Author:    mullan
Date:      2012-12-18 13:48 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ed08394e1a15

8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01
Reviewed-by: vinnie, skoivu, mgrebac, ohair, tbell

! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile

Changeset: 32cd4975d2d6
Author:    mchung
Date:      2013-01-10 19:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/32cd4975d2d6

8005615: Java Logger fails to load tomcat logger implementation (JULI)
Reviewed-by: alanb, ahgross

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/CustomLogManager.java
+ test/java/util/logging/CustomLogManagerTest.java
+ test/java/util/logging/SimpleLogManager.java

Changeset: c0fbd737aef0
Author:    ewendeli
Date:      2013-01-28 11:07 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c0fbd737aef0

8006864: Update java.security-linux to include changes in java.security
Reviewed-by: mchung, mullan

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 12491fa16985
Author:    ewendeli
Date:      2013-02-05 15:35 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/12491fa16985

Merge

! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/java/lang/Class.java
- src/share/classes/sun/security/util/KeyLength.java

Changeset: de419ea8ed8f
Author:    mchung
Date:      2013-01-28 15:53 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/de419ea8ed8f

8006882: Proxy generated classes in sun.proxy package breaks JMockit
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 8effe3b7489d
Author:    dfuchs
Date:      2013-01-30 11:33 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8effe3b7489d

8006446: Restrict MBeanServer access
Reviewed-by: alanb, mchung, darcy, jrose, ahgross, skoivu

! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java
! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java
! src/share/classes/java/lang/management/ManagementFactory.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java

Changeset: ebfb0bb58428
Author:    mchung
Date:      2013-01-24 16:45 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ebfb0bb58428

8004937: Improve proxy construction
Reviewed-by: jrose, ahgross

! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java

Changeset: af11c227a91e
Author:    mchung
Date:      2013-02-05 22:56 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/af11c227a91e

8007393: Possible race condition after JDK-6664509
Reviewed-by: alanb, jgish

! src/share/classes/java/util/logging/LogManager.java

Changeset: 1143bb5e7064
Author:    mchung
Date:      2013-02-07 09:41 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1143bb5e7064

8007611: logging behavior in applet changed
Reviewed-by: alanb, jgish

! src/share/classes/java/util/logging/LogManager.java

Changeset: 5925630b7a7d
Author:    xuelei
Date:      2013-02-07 16:05 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5925630b7a7d

8006777: Improve TLS handling of invalid messages
Reviewed-by: wetmore, ahgross

! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: d57363ff612f
Author:    valeriep
Date:      2013-02-07 16:03 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d57363ff612f

8007688: Blacklist known bad certificate
Summary: Added two known bad certs to the blacklist certs.
Reviewed-by: mullan

! src/share/classes/sun/security/util/UntrustedCertificates.java

Changeset: c18aeb4ca957
Author:    ewendeli
Date:      2013-02-19 21:48 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c18aeb4ca957

Merge

! src/share/bin/parse_manifest.c
! src/share/classes/java/lang/Class.java
- src/share/classes/sun/security/util/KeyLength.java
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! src/share/native/sun/awt/image/awt_parseImage.c
! test/Makefile

Changeset: f7fb3de623ba
Author:    ewendeli
Date:      2013-02-19 21:53 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f7fb3de623ba

Merge


Changeset: f686c8e3c8e0
Author:    ewendeli
Date:      2013-02-25 08:44 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f686c8e3c8e0

Merge

! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/logging/LogManager.java
- src/share/classes/sun/security/util/KeyLength.java
! src/share/native/com/sun/java/util/jar/pack/bands.cpp
! src/share/native/com/sun/java/util/jar/pack/bands.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp

Changeset: e3cac5962e32
Author:    vlivanov
Date:      2013-02-22 03:00 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e3cac5962e32

8006439: Improve MethodHandles coverage
Reviewed-by: jrose, twisti

! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 62be74f35886
Author:    vlivanov
Date:      2013-02-22 03:00 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/62be74f35886

8006179: JSR292 MethodHandles lookup with interface using findVirtual()
Reviewed-by: jrose, twisti

! src/share/classes/java/lang/invoke/DirectMethodHandle.java

Changeset: 9995881dfb4e
Author:    vlivanov
Date:      2013-02-22 02:59 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9995881dfb4e

8006125: Update MethodHandles library interactions
Reviewed-by: jrose

! src/share/classes/sun/reflect/misc/MethodUtil.java

Changeset: 0807820fca96
Author:    vlivanov
Date:      2013-02-22 02:58 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/0807820fca96

8004933: Improve MethodHandle interaction with libraries
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/MethodHandleNatives.java

Changeset: ae1fed8d80e1
Author:    ewendeli
Date:      2013-02-26 06:47 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ae1fed8d80e1

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 5e4c2d7f3b67
Author:    ewendeli
Date:      2013-02-26 20:36 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5e4c2d7f3b67

Merge

! src/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandles.java
- src/share/classes/sun/security/util/KeyLength.java

Changeset: 4d4848124bff
Author:    ewendeli
Date:      2013-02-27 09:28 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4d4848124bff

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 36ff48ae6ffe
Author:    ewendeli
Date:      2013-02-27 18:13 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/36ff48ae6ffe

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 931fb59eae26
Author:    lana
Date:      2013-03-12 19:04 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/931fb59eae26

Merge

! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/lang/Class.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
- src/share/classes/sun/security/util/KeyLength.java
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java

Changeset: 9528e88f8d53
Author:    lana
Date:      2013-03-13 23:39 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9528e88f8d53

Merge

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
! makefiles/CompileNativeLibraries.gmk
! makefiles/Images.gmk
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
- src/share/classes/sun/security/util/KeyLength.java
- test/javax/script/RhinoExceptionTest.java

Changeset: f282190e931a
Author:    lana
Date:      2013-03-14 19:26 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f282190e931a

Merge


Changeset: 72b3f05376f1
Author:    sherman
Date:      2013-03-15 15:55 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/72b3f05376f1

Merge

! .hgtags
! make/java/java/FILES_java.gmk
- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
! makefiles/CreateJars.gmk
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
! src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
- src/share/classes/sun/security/util/KeyLength.java
! test/Makefile
! test/java/util/Calendar/JavatimeTest.java
- test/javax/script/RhinoExceptionTest.java


From xueming.shen at oracle.com  Fri Mar 15 21:42:55 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:42:55 +0000
Subject: [threeten-dev] hg: threeten/threeten/corba: 16 new changesets
Message-ID: <20130316044305.B3556481BA@hg.openjdk.java.net>

Changeset: e41fb1aa0329
Author:    katleman
Date:      2013-02-21 11:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/e41fb1aa0329

Added tag jdk8-b78 for changeset 27d6368ae8ba

! .hgtags

Changeset: 5f3d4a6bdd02
Author:    katleman
Date:      2013-02-28 10:41 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/5f3d4a6bdd02

Added tag jdk8-b79 for changeset e41fb1aa0329

! .hgtags

Changeset: 2a00aeeb466b
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/2a00aeeb466b

Added tag jdk8-b80 for changeset 5f3d4a6bdd02

! .hgtags

Changeset: 0ac9424678e7
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/0ac9424678e7

Added tag jdk8-b81 for changeset 2a00aeeb466b

! .hgtags

Changeset: e725dd195858
Author:    dmeetry
Date:      2013-02-15 01:49 +0400
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/e725dd195858

7199858: Marshal exception is wrong
Reviewed-by: lancea

! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java

Changeset: c528d8ce83f1
Author:    lana
Date:      2013-02-19 20:48 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/c528d8ce83f1

Merge


Changeset: 67ef27b4e16c
Author:    lana
Date:      2013-03-05 11:46 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/67ef27b4e16c

Merge


Changeset: 05386b4610e9
Author:    lana
Date:      2013-03-12 16:38 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/05386b4610e9

Merge


Changeset: 3c73273667ae
Author:    coffeys
Date:      2012-10-30 17:06 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/3c73273667ae

8000631: Restrict access to class constructor
Reviewed-by: alanb, ahgross

! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk
! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java
! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java
! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java
! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java
! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java
! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java
! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java
+ src/share/classes/sun/corba/JavaCorbaAccess.java
+ src/share/classes/sun/corba/SharedSecrets.java

Changeset: 80882eae6279
Author:    ngmr
Date:      2012-10-30 17:15 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/80882eae6279

8000540: Improve IIOP type reuse management
Reviewed-by: alanb, ahgross, coffeys

! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java

Changeset: 0ca1fc7c5f44
Author:    mbankal
Date:      2012-12-17 07:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/0ca1fc7c5f44

7141694: Improving CORBA internals
Reviewed-by: coffeys, ahgross

! src/share/classes/com/sun/corba/se/spi/orb/ORB.java

Changeset: f4f39d873b9a
Author:    coffeys
Date:      2012-11-06 15:50 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/f4f39d873b9a

7201066: Change modifiers on unused fields
Reviewed-by: alanb, skoivu

! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java
! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java
! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java

Changeset: 59bff16bc0bf
Author:    ewendeli
Date:      2013-02-19 21:44 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/59bff16bc0bf

Merge

- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java

Changeset: 996bd5fd0941
Author:    ewendeli
Date:      2013-02-25 07:21 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/996bd5fd0941

Merge

- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java

Changeset: 7341134e52ff
Author:    lana
Date:      2013-03-12 18:16 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/7341134e52ff

Merge

- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java

Changeset: 48e1bc77004d
Author:    lana
Date:      2013-03-14 19:33 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/corba/rev/48e1bc77004d

Merge



From xueming.shen at oracle.com  Fri Mar 15 21:42:32 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:42:32 +0000
Subject: [threeten-dev] hg: threeten/threeten: 28 new changesets
Message-ID: <20130316044234.382F1481B9@hg.openjdk.java.net>

Changeset: 91d35211e744
Author:    katleman
Date:      2013-02-21 11:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/91d35211e744

Added tag jdk8-b78 for changeset fd1a5574cf68

! .hgtags

Changeset: 85b5b4cc388c
Author:    katleman
Date:      2013-02-28 10:41 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/85b5b4cc388c

Added tag jdk8-b79 for changeset 91d35211e744

! .hgtags

Changeset: ab82853d3365
Author:    erikj
Date:      2013-02-21 14:16 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/ab82853d3365

8008451: Make mac builds on 10.8 work on 10.7
Reviewed-by: ohair, ddehaven

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: d3e3d5b06f45
Author:    ohair
Date:      2013-02-23 10:47 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/d3e3d5b06f45

8004712: build-infra: Move user guide from web pages to repository
Summary: Just the initial work, will need more changes.
Reviewed-by: tbell

! README
! README-builds.html

Changeset: 2778e6576e21
Author:    katleman
Date:      2013-02-26 13:23 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/2778e6576e21

Merge


Changeset: 0adf9c626bb1
Author:    katleman
Date:      2013-02-28 20:29 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/0adf9c626bb1

Merge


Changeset: 907a926d3c96
Author:    erikj
Date:      2013-03-04 16:45 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/907a926d3c96

8004352: build-infra: Limit JOBS on large machines
Reviewed-by: mduigou

! common/autoconf/build-performance.m4
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
! common/autoconf/help.m4
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/spec.gmk.in
! common/makefiles/JavaCompilation.gmk
! common/makefiles/Main.gmk

Changeset: cd7f2c7e2a0e
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/cd7f2c7e2a0e

Added tag jdk8-b80 for changeset 907a926d3c96

! .hgtags

Changeset: 52741ab7c601
Author:    erikj
Date:      2013-03-06 10:50 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/52741ab7c601

8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions?
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/autoconf/toolchain_windows.m4

Changeset: 235854886494
Author:    katleman
Date:      2013-03-11 13:41 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/235854886494

Merge


Changeset: 145dbc56f931
Author:    tbell
Date:      2013-03-12 22:08 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/145dbc56f931

8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk
Reviewed-by: katleman

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain_windows.m4

Changeset: 0dc28db6525f
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/0dc28db6525f

Added tag jdk8-b81 for changeset 145dbc56f931

! .hgtags

Changeset: ecc8fda8f187
Author:    darcy
Date:      2013-02-19 00:24 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/ecc8fda8f187

8008435: Fix new build to include jdk.Supported in ct.sym
Reviewed-by: erikj

! common/makefiles/javadoc/NON_CORE_PKGS.gmk

Changeset: eca3bce3d151
Author:    lana
Date:      2013-02-19 20:48 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/eca3bce3d151

Merge


Changeset: c641268c4532
Author:    mduigou
Date:      2013-02-20 17:56 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/c641268c4532

8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com
Reviewed-by: darcy

! make/scripts/webrev.ksh

Changeset: b70196e01c53
Author:    lana
Date:      2013-02-21 17:39 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/b70196e01c53

Merge


Changeset: 5b0b6ef58dbf
Author:    jjg
Date:      2013-02-25 15:08 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/5b0b6ef58dbf

8008914: Add nashorn to the tl build
Reviewed-by: mr, tbell, jjh
Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com

! Makefile
! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk
! common/makefiles/MakeBase.gmk
! make/Defs-internal.gmk
! make/jdk-rules.gmk
! make/sanity-rules.gmk
! make/scripts/hgforest.sh

Changeset: e065107437b9
Author:    alanb
Date:      2013-02-26 14:08 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/e065107437b9

8008978: nashorn-rules.gmk missing
Reviewed-by: alanb
Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com

+ make/nashorn-rules.gmk

Changeset: cb0ac8979caa
Author:    tbell
Date:      2013-02-26 09:25 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/cb0ac8979caa

8009019: Updates to generated-configure.sh required for 8008914
Reviewed-by: sundar, jlaskey, jjg

! common/autoconf/generated-configure.sh

Changeset: a9c8a32d09f9
Author:    martin
Date:      2013-03-05 13:16 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/a9c8a32d09f9

8006988: build-infra: Configure fails if 'cl' is in path on linux
Summary: Respect user CC and CXX environment variables; use cl iff on windows
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: c022bc48b7ed
Author:    lana
Date:      2013-03-05 11:46 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/c022bc48b7ed

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: c4901c0e0579
Author:    lana
Date:      2013-03-05 15:09 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/c4901c0e0579

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 929e2461818b
Author:    dholmes
Date:      2013-03-05 22:45 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/929e2461818b

8009529: Fix for 8006988 missed closed configure changes
Reviewed-by: mr

! common/autoconf/generated-configure.sh

Changeset: b35d986ff276
Author:    mduigou
Date:      2013-03-06 08:37 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/b35d986ff276

8009162: root repo "make test" target should run against image
Reviewed-by: alanb, martin, erikj

! common/makefiles/Main.gmk

Changeset: 980ccff2d4f5
Author:    lana
Date:      2013-03-12 16:38 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/980ccff2d4f5

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 22b9a31a92eb
Author:    lana
Date:      2013-03-13 23:21 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/22b9a31a92eb

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: a69761ae281b
Author:    lana
Date:      2013-03-14 19:33 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/a69761ae281b

Merge


Changeset: 7cb3f925a9a2
Author:    sherman
Date:      2013-03-15 15:31 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/rev/7cb3f925a9a2

Merge



From xueming.shen at oracle.com  Fri Mar 15 21:44:38 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:44:38 +0000
Subject: [threeten-dev] hg: threeten/threeten/hotspot: 112 new changesets
Message-ID: <20130316044823.7B9A9481BB@hg.openjdk.java.net>

Changeset: db3359133cdd
Author:    katleman
Date:      2013-02-21 11:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/db3359133cdd

Added tag jdk8-b78 for changeset d5e12e7d2f71

! .hgtags

Changeset: 57b81d6c3641
Author:    amurillo
Date:      2013-02-15 13:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/57b81d6c3641

8008286: new hotspot build - hs25-b20
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 7adae9244bc8
Author:    mgronlun
Date:      2013-02-13 11:23 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/7adae9244bc8

8007312: null check signal semaphore in os::signal_notify windows
Reviewed-by: dholmes, sla

! src/os/windows/vm/os_windows.cpp

Changeset: 2394a89e89f4
Author:    rbackman
Date:      2013-02-13 09:46 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2394a89e89f4

8008088: SA can hang the VM
Reviewed-by: mgronlun, sla, dholmes

! agent/src/os/bsd/libproc_impl.c
! agent/src/os/bsd/libproc_impl.h
! agent/src/os/bsd/ps_proc.c
! agent/src/os/linux/libproc_impl.c
! agent/src/os/linux/libproc_impl.h
! agent/src/os/linux/ps_proc.c

Changeset: 49618582fc5b
Author:    sla
Date:      2013-02-14 13:08 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/49618582fc5b

8004840: Jstack seems to output unnecessary information in 7u9
Reviewed-by: dholmes, coleenp, sspitsyn, rbackman

! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java
! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java

Changeset: 3a531d40ad93
Author:    acorn
Date:      2013-02-14 14:33 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/3a531d40ad93

8007736: VerifyError for static method in interface
Reviewed-by: dholmes, acorn
Contributed-by: bharadwaj.yadavalli at oracle.com

! src/share/vm/classfile/verifier.cpp
+ test/runtime/8007736/TestStaticIF.java

Changeset: e7e9e08147fc
Author:    mikael
Date:      2013-02-14 12:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/e7e9e08147fc

8007639: Workaround for ccache in vm.make is incorrect
Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o
Reviewed-by: dholmes, erikj

! make/bsd/makefiles/vm.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make

Changeset: 5d5c577296fd
Author:    sla
Date:      2013-02-15 08:54 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5d5c577296fd

8008102: SA on OS X does not stop the attached process
Reviewed-by: dholmes, rbackman

! agent/src/os/bsd/MacosxDebuggerLocal.m

Changeset: f35f1fbab3e1
Author:    sla
Date:      2013-02-15 10:08 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f35f1fbab3e1

Merge


Changeset: dc1de5e78a85
Author:    dsamersoff
Date:      2013-02-15 10:29 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/dc1de5e78a85

Merge


Changeset: f82bcc429e8c
Author:    sla
Date:      2013-02-18 10:43 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f82bcc429e8c

8007901: SA: Don't read flag values as constants
Reviewed-by: dholmes, mikael

! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: b5e3ec9c69fa
Author:    sla
Date:      2013-02-18 12:49 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b5e3ec9c69fa

8007779: os::die() on solaris should generate core file
Reviewed-by: dholmes, rbackman

! src/os/solaris/vm/os_solaris.cpp

Changeset: 5cd2fac2ae70
Author:    hseigel
Date:      2013-02-19 08:51 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5cd2fac2ae70

6749267: Signal handler should save/restore errno
Summary: Save errno before processing signal, then restore it.
Reviewed-by: acorn, sspitsyn

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp

Changeset: 56c364daccc3
Author:    emc
Date:      2013-02-19 11:36 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/56c364daccc3

8007153: Ensure that MethodParameters API works properly with RedefineClasses
Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called
Reviewed-by: coleenp, sspitsyn

! src/share/vm/oops/method.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 1048edb5434a
Author:    coleenp
Date:      2013-02-19 13:33 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1048edb5434a

Merge


Changeset: 20fff74158eb
Author:    sspitsyn
Date:      2013-02-20 08:51 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/20fff74158eb

Merge


Changeset: bbc7936779f9
Author:    brutisso
Date:      2013-02-14 09:11 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/bbc7936779f9

8006398: Add regression tests for deprectated GCs
Reviewed-by: ehelin, jwilhelm, jmasa

! test/TEST.ROOT
+ test/gc/startup_warnings/TestCMS.java
+ test/gc/startup_warnings/TestCMSIncrementalMode.java
+ test/gc/startup_warnings/TestCMSNoIncrementalMode.java
+ test/gc/startup_warnings/TestDefNewCMS.java
+ test/gc/startup_warnings/TestG1.java
+ test/gc/startup_warnings/TestIncGC.java
+ test/gc/startup_warnings/TestParNewCMS.java
+ test/gc/startup_warnings/TestParNewSerialOld.java
+ test/gc/startup_warnings/TestParallelGC.java
+ test/gc/startup_warnings/TestParallelScavengeSerialOld.java
+ test/gc/startup_warnings/TestSerialGC.java

Changeset: fd7b3770c77e
Author:    tamao
Date:      2013-02-14 14:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/fd7b3770c77e

8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy
Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy.
Reviewed-by: jmasa
Contributed-by: Tao Mao 

! src/share/vm/memory/collectorPolicy.cpp

Changeset: ccc57295818b
Author:    johnc
Date:      2013-02-19 16:22 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ccc57295818b

8006628: NEED_TEST for JDK-8002870
Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads.
Reviewed-by: jmasa, johnc
Contributed-by: Filipp Zhinkin 

+ test/gc/8000311/Test8000311.java

Changeset: b9c5e46bf915
Author:    johnc
Date:      2013-02-20 12:52 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b9c5e46bf915

8008188: Add regression test for 8005875
Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd  Thread.print" against itself. Without the fix for 8005875 the test will crash.
Reviewed-by: brutisso

+ test/gc/TestG1ZeroPGCTJcmdThreadPrint.java

Changeset: 5741d3fc502d
Author:    brutisso
Date:      2013-02-21 13:13 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5741d3fc502d

Merge


Changeset: c59b7900a2bd
Author:    roland
Date:      2013-02-18 09:06 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/c59b7900a2bd

8007959: Use expensive node logic for more math nodes
Summary: use expensive node logic for other more math nodes.
Reviewed-by: kvn

! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/subnode.hpp

Changeset: 514efad5e81a
Author:    drchase
Date:      2013-02-18 14:29 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/514efad5e81a

8008180: Several tests in compiler/5091921 need more time to run
Summary: Added an explicit timeouts.
Reviewed-by: kvn, twisti

! test/compiler/5091921/Test6850611.java
! test/compiler/5091921/Test6890943.java
! test/compiler/5091921/Test6905845.java
! test/compiler/5091921/Test6992759.java

Changeset: a2bc322ca273
Author:    drchase
Date:      2013-02-18 15:08 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a2bc322ca273

7102300: performance warnings cause results diff failure in Test6890943
Summary: Strip lines matching the performance warning from the output before diff.
Reviewed-by: kvn

! test/compiler/5091921/Test6890943.sh

Changeset: ad736b4683b4
Author:    kvn
Date:      2013-02-18 16:47 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ad736b4683b4

8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob"
Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future.
Reviewed-by: roland, twisti

! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp
+ test/compiler/8004867/TestIntAtomicCAS.java
+ test/compiler/8004867/TestIntAtomicOrdered.java
+ test/compiler/8004867/TestIntAtomicVolatile.java
+ test/compiler/8004867/TestIntUnsafeCAS.java
+ test/compiler/8004867/TestIntUnsafeOrdered.java
+ test/compiler/8004867/TestIntUnsafeVolatile.java

Changeset: 2e4b16122164
Author:    vlivanov
Date:      2013-02-21 06:29 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2e4b16122164

Merge


Changeset: 579f6adb7f51
Author:    jprovino
Date:      2013-02-05 13:32 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/579f6adb7f51

8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer
Summary: A warning message should be displayed if these options are used with the Minimal VM.
Reviewed-by: dholmes, dsamersoff

! src/share/vm/runtime/arguments.cpp

Changeset: 9e2da96f9976
Author:    bpittore
Date:      2013-02-08 16:08 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/9e2da96f9976

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 6c2da81297c5
Author:    kvn
Date:      2013-02-12 09:54 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/6c2da81297c5

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 84a926fe53d0
Author:    bpittore
Date:      2013-01-24 13:27 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/84a926fe53d0

8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands
Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice
Reviewed-by: roland, vladidan

! src/share/vm/c1/c1_LIR.cpp

Changeset: cf9a2071eeac
Author:    jprovino
Date:      2013-02-14 11:07 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/cf9a2071eeac

8006878: Some non-existent GC source files are in the minimalVM exclude list.
Summary: cmsPermGen.cpp, psPermGen.cpp have been removed.  yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice.
Reviewed-by: dholmes, jmasa

! make/excludeSrc.make
! src/share/vm/utilities/yieldingWorkgroup.cpp

Changeset: 1605eef8e11e
Author:    jprovino
Date:      2013-02-14 11:08 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1605eef8e11e

8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS
Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm.
Reviewed-by: dholmes, cjplummer

! src/share/vm/runtime/arguments.cpp

Changeset: 9c7d0948523f
Author:    jprovino
Date:      2013-02-15 14:42 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/9c7d0948523f

Merge


Changeset: 1ba18258caa4
Author:    bpittore
Date:      2013-02-15 21:53 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1ba18258caa4

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: abf488c22e09
Author:    bpittore
Date:      2013-02-20 23:29 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/abf488c22e09

Merge


Changeset: 2af22eb04623
Author:    vladidan
Date:      2013-02-21 09:08 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/2af22eb04623

Merge


Changeset: ed96c6015470
Author:    vladidan
Date:      2013-02-21 11:39 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ed96c6015470

Merge


Changeset: 555ec35a2507
Author:    amurillo
Date:      2013-02-22 10:02 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/555ec35a2507

Merge


Changeset: 6691814929b6
Author:    amurillo
Date:      2013-02-22 10:02 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/6691814929b6

Added tag hs25-b20 for changeset 555ec35a2507

! .hgtags

Changeset: 5d395eb2626f
Author:    katleman
Date:      2013-02-28 10:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5d395eb2626f

Added tag jdk8-b79 for changeset 6691814929b6

! .hgtags

Changeset: be1fbee20765
Author:    amurillo
Date:      2013-02-22 10:12 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/be1fbee20765

8008692: new hotspot build - hs25-b21
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1b0dc9f87e75
Author:    mgerdin
Date:      2013-02-19 18:45 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1b0dc9f87e75

8006753: fix failed for JDK-8002415 White box testing API for HotSpot
Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue
Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn

! make/Makefile
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/vm.make
- make/bsd/makefiles/wb.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/vm.make
- make/linux/makefiles/wb.make
! make/solaris/makefiles/defs.make
! make/solaris/makefiles/vm.make
- make/solaris/makefiles/wb.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
- make/windows/makefiles/wb.make
- src/share/tools/whitebox/sun/hotspot/WhiteBox.java
- src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java
! src/share/vm/runtime/arguments.cpp
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/runtime/NMT/AllocTestType.java
! test/runtime/NMT/PrintNMTStatistics.java
! test/runtime/NMT/SummarySanityCheck.java
! test/sanity/WBApi.java
! test/serviceability/ParserTest.java
+ test/testlibrary/ClassFileInstaller.java
+ test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
+ test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: 4c1d8002ffb1
Author:    hseigel
Date:      2013-02-20 07:16 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/4c1d8002ffb1

8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp
Summary: Delete the questionable source code because it is for no-longer supported versions of Linux.
Reviewed-by: mikael, coleenp

! src/os/linux/vm/os_linux.cpp

Changeset: b861c8af2510
Author:    hseigel
Date:      2013-02-20 07:42 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b861c8af2510

Merge

- make/bsd/makefiles/wb.make
- make/linux/makefiles/wb.make
- make/solaris/makefiles/wb.make
- make/windows/makefiles/wb.make
- src/share/tools/whitebox/sun/hotspot/WhiteBox.java
- src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: b6d5b3e50379
Author:    dcubed
Date:      2013-02-20 19:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b6d5b3e50379

6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly
Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors.
Reviewed-by: dcubed, dholmes, coleenp, acorn
Contributed-by: ron.durbin at oracle.com

! src/share/vm/utilities/debug.cpp

Changeset: fc64254f5579
Author:    zgu
Date:      2013-02-21 07:50 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/fc64254f5579

8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days
Summary: Added NULL pointer check for arena size record
Reviewed-by: sspitsyn, dholmes

! src/share/vm/services/memSnapshot.cpp

Changeset: 5ed317b25e23
Author:    sla
Date:      2013-02-22 10:03 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5ed317b25e23

7165259: Remove BugSpot
Reviewed-by: coleenp, mgronlun

! agent/make/Makefile
- agent/make/bugspot.bat
! agent/make/marks_notes.html
! agent/src/os/win32/windbg/sawindbg.cpp
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java
! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js
- agent/src/share/native/jvmdi/sa.cpp
- agent/src/share/native/jvmdi/sa.dsp
- agent/src/share/native/jvmdi/sa.dsw
- agent/src/share/native/jvmdi/sa.hpp
! make/sa.files

Changeset: f16e75e0cf11
Author:    coleenp
Date:      2013-02-22 08:36 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f16e75e0cf11

8000797: NPG: is_pseudo_string_at() doesn't work
Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings).  Clean up JVM_CONSTANT_Object and unused flags.
Reviewed-by: sspitsyn, jrose

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/utilities/constantTag.cpp
! src/share/vm/utilities/constantTag.hpp

Changeset: 94478a033036
Author:    sspitsyn
Date:      2013-02-22 10:16 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/94478a033036

Merge

- agent/make/bugspot.bat
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java
- agent/src/share/native/jvmdi/sa.cpp
- agent/src/share/native/jvmdi/sa.dsp
- agent/src/share/native/jvmdi/sa.dsw
- agent/src/share/native/jvmdi/sa.hpp
- make/bsd/makefiles/wb.make
- make/linux/makefiles/wb.make
- make/solaris/makefiles/wb.make
- make/windows/makefiles/wb.make
- src/share/tools/whitebox/sun/hotspot/WhiteBox.java
- src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java
! src/share/vm/runtime/arguments.cpp

Changeset: ec2eddfed950
Author:    rbackman
Date:      2013-02-26 14:09 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ec2eddfed950

8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity
Reviewed-by: kvn, sla

! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/frame_x86.cpp

Changeset: 77f9b6d0126e
Author:    sspitsyn
Date:      2013-02-27 12:20 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/77f9b6d0126e

Merge

- agent/make/bugspot.bat
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java
- agent/src/share/native/jvmdi/sa.cpp
- agent/src/share/native/jvmdi/sa.dsp
- agent/src/share/native/jvmdi/sa.dsw
- agent/src/share/native/jvmdi/sa.hpp
- make/bsd/makefiles/wb.make
- make/linux/makefiles/wb.make
- make/solaris/makefiles/wb.make
- make/windows/makefiles/wb.make
- src/share/tools/whitebox/sun/hotspot/WhiteBox.java
- src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: 0598674c0056
Author:    jwilhelm
Date:      2013-02-21 11:16 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/0598674c0056

8008314: Unimplemented() Atomic::load breaks the applications
Summary: jlong atomics isn't fully implemented om all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed.
Reviewed-by: dholmes, dlong

! src/share/vm/runtime/atomic.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp

Changeset: 96c885895d22
Author:    johnc
Date:      2013-02-22 11:01 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/96c885895d22

8007221: G1: concurrent phase durations do not state the time units ("secs")
Summary: Add timer units to concurrent marking phases where the units were missing.
Reviewed-by: jmasa, ysr

! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp

Changeset: 9a8ee5301f33
Author:    brutisso
Date:      2013-02-26 11:52 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/9a8ee5301f33

Merge


Changeset: f1fb03a251e9
Author:    poonam
Date:      2013-02-21 23:58 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f1fb03a251e9

8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED
Reviewed-by: brutisso, johnc
Contributed-by: vladimir.kempik at oracle.com

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: fd32b88a87e9
Author:    poonam
Date:      2013-02-23 17:40 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/fd32b88a87e9

Merge


Changeset: 9289a00709b5
Author:    poonam
Date:      2013-02-26 08:58 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/9289a00709b5

Merge


Changeset: b685ca4f4fb9
Author:    ehelin
Date:      2013-02-20 16:41 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b685ca4f4fb9

8008536: Add HotSpot support for printing class loader statistics for JMap
Reviewed-by: sla, brutisso

+ agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java
- agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java

Changeset: 3d3379aab292
Author:    ehelin
Date:      2013-02-26 22:31 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/3d3379aab292

Merge

- agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java

Changeset: 9a094d29af19
Author:    ehelin
Date:      2013-02-06 07:48 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/9a094d29af19

8004924: NPG: jmap -heap output should contain ClassMetaspaceSize value
Reviewed-by: stefank, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
+ test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java

Changeset: b5e03c8ead49
Author:    brutisso
Date:      2013-02-28 09:01 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b5e03c8ead49

Merge

- agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java

Changeset: 6931f425c517
Author:    roland
Date:      2013-02-25 14:13 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/6931f425c517

8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution
Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store.
Reviewed-by: kvn

! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/phaseX.cpp
+ test/compiler/8007294/Test8007294.java

Changeset: 706c919d3b56
Author:    roland
Date:      2013-02-26 12:18 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/706c919d3b56

8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376
Summary: GetAndSetP's MachNode should capture bottom type.
Reviewed-by: kvn

! src/share/vm/adlc/formssel.cpp
+ test/compiler/8007722/Test8007722.java

Changeset: a00ed9736260
Author:    drchase
Date:      2013-02-26 15:38 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a00ed9736260

8007776: Test6852078.java timeouts
Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed.
Reviewed-by: kvn

! test/compiler/6852078/Test6852078.java

Changeset: 133bf557ef77
Author:    iignatyev
Date:      2013-02-27 05:58 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/133bf557ef77

8007439: C2: adding successful message of inlining
Reviewed-by: kvn, vlivanov

! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/parse.hpp

Changeset: b02157cd249f
Author:    vlivanov
Date:      2013-02-27 08:03 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b02157cd249f

Merge


Changeset: 338da89b2592
Author:    vlivanov
Date:      2013-02-28 15:31 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/338da89b2592

Merge


Changeset: df5396524152
Author:    amurillo
Date:      2013-03-01 04:45 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/df5396524152

Merge

- agent/make/bugspot.bat
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java
- agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java
- agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java
- agent/src/share/native/jvmdi/sa.cpp
- agent/src/share/native/jvmdi/sa.dsp
- agent/src/share/native/jvmdi/sa.dsw
- agent/src/share/native/jvmdi/sa.hpp
- make/bsd/makefiles/wb.make
- make/linux/makefiles/wb.make
- make/solaris/makefiles/wb.make
- make/windows/makefiles/wb.make
- src/share/tools/whitebox/sun/hotspot/WhiteBox.java
- src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: 4a198b201f3c
Author:    amurillo
Date:      2013-03-01 04:45 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/4a198b201f3c

Added tag hs25-b21 for changeset df5396524152

! .hgtags

Changeset: fbda7e1dee9a
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/fbda7e1dee9a

Added tag jdk8-b80 for changeset 4a198b201f3c

! .hgtags

Changeset: 7f482030ff64
Author:    amurillo
Date:      2013-03-01 04:58 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/7f482030ff64

8009226: new hotspot build - hs25-b22
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1f9994892f89
Author:    stefank
Date:      2013-02-21 17:22 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1f9994892f89

8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive
Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders.
Reviewed-by: coleenp, acorn
Contributed-by: Stefan Karlsson , Erik Helin 

! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/classLoaderData.inline.hpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/systemDictionary.cpp

Changeset: 3c9db54c2660
Author:    mikael
Date:      2013-02-26 08:54 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/3c9db54c2660

8008081: Print outs do not have matching arguments
Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function
Reviewed-by: sla, dholmes

! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/services/memReporter.cpp
! src/share/vm/utilities/numberSeq.cpp

Changeset: 05f2fc6b4ea7
Author:    dholmes
Date:      2013-02-27 04:58 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/05f2fc6b4ea7

Merge


Changeset: 96bd4772ec62
Author:    kevinw
Date:      2013-02-27 14:02 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/96bd4772ec62

8008807: SA: jstack crash when target has mismatched bitness (Linux)
Reviewed-by: rbackman, sla, poonam

! agent/src/os/linux/LinuxDebuggerLocal.c

Changeset: 698b615a1cde
Author:    kevinw
Date:      2013-02-27 16:40 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/698b615a1cde

Merge


Changeset: 651919d134f7
Author:    kevinw
Date:      2013-02-27 22:40 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/651919d134f7

7178741: SA: jstack -m produce UnalignedAddressException in output (Linux)
Reviewed-by: poonam, sla

! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java

Changeset: 5ee250974db9
Author:    dcubed
Date:      2013-02-27 15:00 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5ee250974db9

8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address
Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock.
Reviewed-by: sla, acorn

! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/threadService.cpp

Changeset: a140cd925462
Author:    dcubed
Date:      2013-02-28 05:55 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a140cd925462

Merge


Changeset: 63e54c37ac64
Author:    simonis
Date:      2013-02-27 09:40 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/63e54c37ac64

8008959: Fix non-PCH build on Linux, Windows and MacOS X
Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files.
Reviewed-by: coleenp, stefank, dholmes

! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.hpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/os_windows.inline.hpp
! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp
! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp
! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp
! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp
! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp
! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp

Changeset: a506ac816f14
Author:    coleenp
Date:      2013-02-27 07:35 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a506ac816f14

Merge


Changeset: 143973ced9ab
Author:    coleenp
Date:      2013-02-28 18:37 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/143973ced9ab

Merge


Changeset: 3e83d69c19db
Author:    dcubed
Date:      2013-03-01 15:59 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/3e83d69c19db

Merge


Changeset: a252e688abcf
Author:    jmasa
Date:      2013-02-01 17:02 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/a252e688abcf

7189971: Implement CMSWaitDuration for non-incremental mode of CMS
Reviewed-by: jmasa, johnc, ysr
Contributed-by: michal at frajt.eu

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 0624b9d81255
Author:    ehelin
Date:      2013-03-04 13:01 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/0624b9d81255

8004172: Update jstat counter names to reflect metaspace changes
Reviewed-by: stefank, jmasa

! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp

Changeset: 27714220e50e
Author:    johnc
Date:      2013-03-04 12:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/27714220e50e

8007036: G1: Too many old regions added to last mixed GC
Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich .
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: d778bb46a9a5
Author:    erikj
Date:      2013-03-04 22:39 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/d778bb46a9a5

8008451: Make mac builds on 10.8 work on 10.7
Reviewed-by: jcoomes, ohair

! make/bsd/makefiles/gcc.make

Changeset: c71e15057f1d
Author:    stefank
Date:      2013-03-07 14:29 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/c71e15057f1d

Merge


Changeset: 7369298bec7e
Author:    collins
Date:      2013-02-27 20:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/7369298bec7e

7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option
Summary: Small changes to hotspot tests to remove  "-server" and replace with ${TESTVMOPTS}
Reviewed-by: kvn

! test/compiler/6431242/Test.java
! test/compiler/6589834/Test_ia32.java
! test/compiler/6636138/Test1.java
! test/compiler/6636138/Test2.java
! test/compiler/6795161/Test.java
! test/compiler/6946040/TestCharShortByteSwap.java
! test/compiler/7068051/Test7068051.sh
! test/compiler/8000805/Test8000805.java

Changeset: 5cf033ff06c4
Author:    bpittore
Date:      2013-03-01 14:06 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5cf033ff06c4

Merge


Changeset: af5ac43f06e9
Author:    jprovino
Date:      2013-03-07 10:46 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/af5ac43f06e9

Merge


Changeset: 0b8f9c8d2617
Author:    jiangli
Date:      2013-03-07 10:39 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/0b8f9c8d2617

Merge


Changeset: 40b7c6b800ab
Author:    morris
Date:      2013-03-01 14:26 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/40b7c6b800ab

8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m
Summary: Fix unitialized variable and return value.
Reviewed-by: kvn

! agent/src/os/bsd/MacosxDebuggerLocal.m

Changeset: bf06968a8a00
Author:    morris
Date:      2013-03-04 13:15 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/bf06968a8a00

8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value
Summary: safety checks for non-Apple thread time functions
Reviewed-by: kvn

! src/os/bsd/vm/os_bsd.cpp

Changeset: c40fbf634c90
Author:    morris
Date:      2013-03-05 04:24 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/c40fbf634c90

8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp
Summary: fix null pointer
Reviewed-by: kvn

! src/share/vm/runtime/frame.cpp

Changeset: 571076d3c79d
Author:    shade
Date:      2013-03-05 04:24 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/571076d3c79d

8009120: Fuzz instruction scheduling in HotSpot compilers
Reviewed-by: kvn, vlivanov

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp

Changeset: 4f553e24b3b5
Author:    vlivanov
Date:      2013-03-05 08:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/4f553e24b3b5

Merge


Changeset: 872b3feace55
Author:    morris
Date:      2013-03-05 18:03 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/872b3feace55

8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp
Summary: fix null pointer
Reviewed-by: kvn, coleenp

! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: 8651f608fea4
Author:    roland
Date:      2013-03-06 10:28 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/8651f608fea4

8009460: C2compiler crash in machnode::in_regmask(unsigned int)
Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link
Reviewed-by: kvn

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/macro.cpp

Changeset: ff55877839bc
Author:    kvn
Date:      2013-03-06 12:25 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/ff55877839bc

8009472: Print additional information for 8004640 failure
Summary: dump nodes and types in 8004640 case.
Reviewed-by: roland

! src/share/vm/opto/compile.hpp
! src/share/vm/opto/memnode.cpp

Changeset: bdb602473679
Author:    morris
Date:      2013-03-07 14:46 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/bdb602473679

Merge

! src/os/bsd/vm/os_bsd.cpp

Changeset: b5bd25d55994
Author:    morris
Date:      2013-03-07 18:03 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b5bd25d55994

Merge


Changeset: dd6350b4abc4
Author:    amurillo
Date:      2013-03-08 08:10 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/dd6350b4abc4

Merge


Changeset: 65b797426a3b
Author:    amurillo
Date:      2013-03-08 08:10 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/65b797426a3b

Added tag hs25-b22 for changeset dd6350b4abc4

! .hgtags

Changeset: f1629878512f
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/f1629878512f

Added tag jdk8-b81 for changeset 65b797426a3b

! .hgtags

Changeset: b95ad0610fef
Author:    asaha
Date:      2012-10-26 09:27 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b95ad0610fef

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
- make/solaris/reorder.sh
- src/cpu/sparc/vm/dump_sparc.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
- src/cpu/zero/vm/dump_zero.cpp
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
- src/share/vm/ci/ciArrayKlassKlass.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
! src/share/vm/compiler/compilerOracle.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
- src/share/vm/memory/dump.cpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.hpp
- src/share/vm/oops/constMethodKlass.cpp
- src/share/vm/oops/constMethodKlass.hpp
- src/share/vm/oops/constMethodOop.cpp
- src/share/vm/oops/constMethodOop.hpp
- src/share/vm/oops/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 77443715ec55
Author:    kamg
Date:      2012-11-05 17:03 -0500
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/77443715ec55

8001307: Modify ACC_SUPER behavior
Summary: Disallow non-virtual calls even when ACC_SUPER is absent.
Reviewed-by: kvn, acorn

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/runtime/globals.hpp

Changeset: b5cb079ecaa4
Author:    ewendeli
Date:      2013-02-03 22:43 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/b5cb079ecaa4

Merge

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 1cabf9c80e84
Author:    ewendeli
Date:      2013-02-19 21:45 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/1cabf9c80e84

Merge

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: d4a32a6f8c82
Author:    ewendeli
Date:      2013-02-25 07:22 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/d4a32a6f8c82

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 11d5942ef9c7
Author:    lana
Date:      2013-03-12 18:22 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/11d5942ef9c7

Merge

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 5ee744831dcb
Author:    lana
Date:      2013-03-14 19:26 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/hotspot/rev/5ee744831dcb

Merge



From xueming.shen at oracle.com  Fri Mar 15 21:51:18 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:51:18 +0000
Subject: [threeten-dev] hg: threeten/threeten/jaxp: 9 new changesets
Message-ID: <20130316045143.E6A9E481BC@hg.openjdk.java.net>

Changeset: 58fa065dd5d6
Author:    katleman
Date:      2013-02-21 11:13 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/58fa065dd5d6

Added tag jdk8-b78 for changeset 00958c5a7070

! .hgtags

Changeset: 4873a0499bc3
Author:    katleman
Date:      2013-02-28 10:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/4873a0499bc3

Added tag jdk8-b79 for changeset 58fa065dd5d6

! .hgtags

Changeset: ef3495555a4c
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/ef3495555a4c

Added tag jdk8-b80 for changeset 4873a0499bc3

! .hgtags

Changeset: 94000590f01f
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/94000590f01f

Added tag jdk8-b81 for changeset ef3495555a4c

! .hgtags

Changeset: f4898ff0aff1
Author:    joehw
Date:      2012-12-12 15:19 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/f4898ff0aff1

8001235: Improve JAXP HTTP handling
Reviewed-by: lancea, skoivu

! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java

Changeset: 3206516132e8
Author:    ewendeli
Date:      2013-02-19 21:45 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/3206516132e8

Merge


Changeset: 46ce56a4e40f
Author:    ewendeli
Date:      2013-02-25 07:22 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/46ce56a4e40f

Merge


Changeset: 8a0cb78fefbc
Author:    lana
Date:      2013-03-12 18:22 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/8a0cb78fefbc

Merge


Changeset: d5a58291f09a
Author:    lana
Date:      2013-03-14 19:33 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxp/rev/d5a58291f09a

Merge



From xueming.shen at oracle.com  Fri Mar 15 21:52:02 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:52:02 +0000
Subject: [threeten-dev] hg: threeten/threeten/jaxws: 4 new changesets
Message-ID: <20130316045212.E4AFE481BD@hg.openjdk.java.net>

Changeset: 70d8658d2a30
Author:    katleman
Date:      2013-02-21 11:13 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/70d8658d2a30

Added tag jdk8-b78 for changeset 391de4c992d1

! .hgtags

Changeset: b0224010e2f0
Author:    katleman
Date:      2013-02-28 10:42 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/b0224010e2f0

Added tag jdk8-b79 for changeset 70d8658d2a30

! .hgtags

Changeset: c88bb21560cc
Author:    katleman
Date:      2013-03-07 11:17 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/c88bb21560cc

Added tag jdk8-b80 for changeset b0224010e2f0

! .hgtags

Changeset: d8d8032d02d7
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jaxws/rev/d8d8032d02d7

Added tag jdk8-b81 for changeset c88bb21560cc

! .hgtags


From xueming.shen at oracle.com  Fri Mar 15 21:52:40 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sat, 16 Mar 2013 04:52:40 +0000
Subject: [threeten-dev] hg: threeten/threeten/langtools: 60 new changesets
Message-ID: <20130316045523.4FBE9481BE@hg.openjdk.java.net>

Changeset: 56dfafbb9e1a
Author:    katleman
Date:      2013-02-21 11:13 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/56dfafbb9e1a

Added tag jdk8-b78 for changeset af8417e590f4

! .hgtags

Changeset: a8227c617684
Author:    katleman
Date:      2013-02-28 10:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/a8227c617684

Added tag jdk8-b79 for changeset 56dfafbb9e1a

! .hgtags

Changeset: ed69d087fdfd
Author:    katleman
Date:      2013-03-07 11:18 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/ed69d087fdfd

Added tag jdk8-b80 for changeset a8227c617684

! .hgtags

Changeset: 58289451d9ed
Author:    katleman
Date:      2013-03-14 15:00 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/58289451d9ed

Added tag jdk8-b81 for changeset ed69d087fdfd

! .hgtags

Changeset: 63872da94576
Author:    darcy
Date:      2013-02-13 23:05 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/63872da94576

8001457: New tests needed for library-side changes for repeating annotations
Reviewed-by: darcy
Contributed-by: sonali.goel at oracle.com

! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java
+ test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java
+ test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java
+ test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java

Changeset: 88286a36bb34
Author:    mchung
Date:      2013-02-14 09:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/88286a36bb34

8006225: tools/jdeps/Basic.java failes with AssertionError
Reviewed-by: alanb

+ src/share/classes/com/sun/tools/jdeps/Analyzer.java
! src/share/classes/com/sun/tools/jdeps/Archive.java
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! test/tools/jdeps/Basic.java

Changeset: 040f02711b73
Author:    jjg
Date:      2013-02-15 08:28 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/040f02711b73

8007052: javap should include the descriptor for a method in verbose mode
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/ClassWriter.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/Options.java
+ test/tools/javap/DescriptorTest.java

Changeset: 0baaae675b19
Author:    mcimadamore
Date:      2013-02-15 16:28 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/0baaae675b19

8006749: compiler does not allow Object protected methods to be used in lambda
Summary: Check.checkFunctionalInterface should take into account 'fake' override
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/lambda/LambdaConv26.java

Changeset: f6e667f52af4
Author:    mcimadamore
Date:      2013-02-15 16:28 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/f6e667f52af4

8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract
Summary: Missing abstractness check on super rmethod references
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/MethodReference62.java
+ test/tools/javac/lambda/MethodReference62.out

Changeset: 4ff468de829d
Author:    mcimadamore
Date:      2013-02-15 16:29 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/4ff468de829d

8007462: Fix provisional applicability for method references
Summary: Add speculative arity-based check to rule out potential candidates when stuck reference is passed to method
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java
+ test/tools/javac/lambda/TargetType60.java
+ test/tools/javac/lambda/TargetType60.out

Changeset: 3cd997b9fd84
Author:    mcimadamore
Date:      2013-02-15 16:30 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/3cd997b9fd84

8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures
Summary: Bad check in Types.interfaceCandidates
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/FunctionalInterfaceAnno02.java

Changeset: 186023614cd3
Author:    mcimadamore
Date:      2013-02-15 16:31 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/186023614cd3

8007427: Annotation element as '_' gives compiler error instead of a warning
8007401: Write test to check for generation of warnings when '_' is used as an identifier
Summary: Extended identifier production not used in annotation values
Reviewed-by: jjg
Contributed-by: sonali.goel at oracle.com

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/lambda/IdentifierTest.java
+ test/tools/javac/lambda/IdentifierTest.out

Changeset: 258c72fa7fa2
Author:    mcimadamore
Date:      2013-02-15 16:37 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/258c72fa7fa2

Merge


Changeset: da2f7dd53915
Author:    mcimadamore
Date:      2013-02-15 18:13 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/da2f7dd53915

8008309: TargetType60 fails because of bad golden file
Summary: bad golden file
Reviewed-by: jjg

! test/tools/javac/lambda/TargetType60.out

Changeset: 9fb4f223a90d
Author:    jjg
Date:      2013-02-15 11:26 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/9fb4f223a90d

8008313: 8007052 breaks test/tools/javap/MethodParameters.java
Reviewed-by: darcy

! test/tools/javap/MethodParameters.java

Changeset: f1f605f85850
Author:    rfield
Date:      2013-02-15 18:40 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/f1f605f85850

8004969: Generate $deserializeLambda$ method
8006763: super in method reference used in anonymous class - ClassFormatError is produced
8005632: Inner classes within lambdas cause build failures
8005653: Lambdas containing inner classes referencing external type variables do not correctly parameterize the inner classes
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/util/Names.java
+ test/tools/javac/lambda/LambdaInnerTypeVarArgs.java
+ test/tools/javac/lambda/LambdaInnerTypeVarReflect.java
+ test/tools/javac/lambda/MethodReference61.java

Changeset: 2620c953e9fe
Author:    vromero
Date:      2013-02-18 14:33 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/2620c953e9fe

6563143: javac should issue a warning for overriding equals without hashCode
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java
+ test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java
+ test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out
! test/tools/javac/diags/examples.not-yet.txt

Changeset: 87884cd0fea3
Author:    jjg
Date:      2013-02-18 14:29 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/87884cd0fea3

8008339: Test TargetAnnoCombo.java is broken
Reviewed-by: jjh

! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java

Changeset: 011cf7e0a148
Author:    darcy
Date:      2013-02-19 00:31 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/011cf7e0a148

8008267: Add @Supported annotation to com.sun.source types
Reviewed-by: jjg

! src/share/classes/com/sun/source/doctree/AttributeTree.java
! src/share/classes/com/sun/source/doctree/AuthorTree.java
! src/share/classes/com/sun/source/doctree/BlockTagTree.java
! src/share/classes/com/sun/source/doctree/CommentTree.java
! src/share/classes/com/sun/source/doctree/DeprecatedTree.java
! src/share/classes/com/sun/source/doctree/DocCommentTree.java
! src/share/classes/com/sun/source/doctree/DocRootTree.java
! src/share/classes/com/sun/source/doctree/DocTree.java
! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java
! src/share/classes/com/sun/source/doctree/EndElementTree.java
! src/share/classes/com/sun/source/doctree/EntityTree.java
! src/share/classes/com/sun/source/doctree/ErroneousTree.java
! src/share/classes/com/sun/source/doctree/IdentifierTree.java
! src/share/classes/com/sun/source/doctree/InheritDocTree.java
! src/share/classes/com/sun/source/doctree/InlineTagTree.java
! src/share/classes/com/sun/source/doctree/LinkTree.java
! src/share/classes/com/sun/source/doctree/LiteralTree.java
! src/share/classes/com/sun/source/doctree/ParamTree.java
! src/share/classes/com/sun/source/doctree/ReferenceTree.java
! src/share/classes/com/sun/source/doctree/ReturnTree.java
! src/share/classes/com/sun/source/doctree/SeeTree.java
! src/share/classes/com/sun/source/doctree/SerialDataTree.java
! src/share/classes/com/sun/source/doctree/SerialFieldTree.java
! src/share/classes/com/sun/source/doctree/SerialTree.java
! src/share/classes/com/sun/source/doctree/SinceTree.java
! src/share/classes/com/sun/source/doctree/StartElementTree.java
! src/share/classes/com/sun/source/doctree/TextTree.java
! src/share/classes/com/sun/source/doctree/ThrowsTree.java
! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java
! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java
! src/share/classes/com/sun/source/doctree/ValueTree.java
! src/share/classes/com/sun/source/doctree/VersionTree.java
! src/share/classes/com/sun/source/doctree/package-info.java
! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java
! src/share/classes/com/sun/source/tree/AnnotationTree.java
! src/share/classes/com/sun/source/tree/ArrayAccessTree.java
! src/share/classes/com/sun/source/tree/ArrayTypeTree.java
! src/share/classes/com/sun/source/tree/AssertTree.java
! src/share/classes/com/sun/source/tree/AssignmentTree.java
! src/share/classes/com/sun/source/tree/BinaryTree.java
! src/share/classes/com/sun/source/tree/BlockTree.java
! src/share/classes/com/sun/source/tree/BreakTree.java
! src/share/classes/com/sun/source/tree/CaseTree.java
! src/share/classes/com/sun/source/tree/CatchTree.java
! src/share/classes/com/sun/source/tree/ClassTree.java
! src/share/classes/com/sun/source/tree/CompilationUnitTree.java
! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java
! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java
! src/share/classes/com/sun/source/tree/ContinueTree.java
! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java
! src/share/classes/com/sun/source/tree/EmptyStatementTree.java
! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java
! src/share/classes/com/sun/source/tree/ErroneousTree.java
! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java
! src/share/classes/com/sun/source/tree/ExpressionTree.java
! src/share/classes/com/sun/source/tree/ForLoopTree.java
! src/share/classes/com/sun/source/tree/IdentifierTree.java
! src/share/classes/com/sun/source/tree/IfTree.java
! src/share/classes/com/sun/source/tree/ImportTree.java
! src/share/classes/com/sun/source/tree/InstanceOfTree.java
! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java
! src/share/classes/com/sun/source/tree/LabeledStatementTree.java
! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java
! src/share/classes/com/sun/source/tree/LineMap.java
! src/share/classes/com/sun/source/tree/LiteralTree.java
! src/share/classes/com/sun/source/tree/MemberReferenceTree.java
! src/share/classes/com/sun/source/tree/MemberSelectTree.java
! src/share/classes/com/sun/source/tree/MethodInvocationTree.java
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/ModifiersTree.java
! src/share/classes/com/sun/source/tree/NewArrayTree.java
! src/share/classes/com/sun/source/tree/NewClassTree.java
! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java
! src/share/classes/com/sun/source/tree/ParenthesizedTree.java
! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java
! src/share/classes/com/sun/source/tree/ReturnTree.java
! src/share/classes/com/sun/source/tree/Scope.java
! src/share/classes/com/sun/source/tree/StatementTree.java
! src/share/classes/com/sun/source/tree/SwitchTree.java
! src/share/classes/com/sun/source/tree/SynchronizedTree.java
! src/share/classes/com/sun/source/tree/ThrowTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/tree/TryTree.java
! src/share/classes/com/sun/source/tree/TypeCastTree.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/source/tree/UnaryTree.java
! src/share/classes/com/sun/source/tree/UnionTypeTree.java
! src/share/classes/com/sun/source/tree/VariableTree.java
! src/share/classes/com/sun/source/tree/WhileLoopTree.java
! src/share/classes/com/sun/source/tree/WildcardTree.java
! src/share/classes/com/sun/source/tree/package-info.java
! src/share/classes/com/sun/source/util/DocTreeScanner.java
! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/source/util/JavacTask.java
! src/share/classes/com/sun/source/util/Plugin.java
! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/SourcePositions.java
! src/share/classes/com/sun/source/util/TaskEvent.java
! src/share/classes/com/sun/source/util/TaskListener.java
! src/share/classes/com/sun/source/util/TreePath.java
! src/share/classes/com/sun/source/util/TreePathScanner.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/source/util/package-info.java
! src/share/classes/com/sun/tools/javac/Main.java
! src/share/classes/com/sun/tools/javac/Server.java

Changeset: dc8b7aa7cef3
Author:    vromero
Date:      2013-02-19 17:53 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/dc8b7aa7cef3

8006212: javac, convert jtreg tests from shell script to java
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java
+ test/tools/apt/Basics/CheckAptIsRemovedTest.java
- test/tools/apt/Basics/NullAPF.java
- test/tools/apt/Basics/apt.sh
- test/tools/apt/verifyVariables.sh
+ test/tools/javac/4846262/CheckEBCDICLocaleTest.java
- test/tools/javac/4846262/Test.java
- test/tools/javac/4846262/Test.out
- test/tools/javac/4846262/Test.sh
+ test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java
- test/tools/javac/6302184/T6302184.sh
+ test/tools/javac/ClassPathTest/ClassPathTest.java
- test/tools/javac/ClassPathTest/ClassPathTest.sh
- test/tools/javac/ClassPathTest/ClassPathTest1.java
- test/tools/javac/ClassPathTest/ClassPathTest2.java
- test/tools/javac/ClassPathTest/ClassPathTest3.java
- test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java
- test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java
- test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java
+ test/tools/javac/ExtDirs/ExtDirTest.java
- test/tools/javac/ExtDirs/ExtDirTest_1.java
- test/tools/javac/ExtDirs/ExtDirTest_2.java
- test/tools/javac/ExtDirs/ExtDirTest_3.java
- test/tools/javac/ExtDirs/ExtDirs.sh
- test/tools/javac/MissingInclude.java
- test/tools/javac/MissingInclude.sh
+ test/tools/javac/MissingInclude/MissingIncludeTest.java
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java
+ test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java
- test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java
+ test/tools/javac/T5090006/AssertionFailureTest.java
- test/tools/javac/T5090006/T5090006.java
- test/tools/javac/T5090006/compiler.sh
- test/tools/javac/constDebug/ConstDebug.java
- test/tools/javac/constDebug/ConstDebug.sh
+ test/tools/javac/constDebug/ConstDebugTest.java
- test/tools/javac/fatalErrors/NoJavaLang.java
- test/tools/javac/fatalErrors/NoJavaLang.out
- test/tools/javac/fatalErrors/NoJavaLang.sh
+ test/tools/javac/fatalErrors/NoJavaLangTest.java
- test/tools/javac/innerClassFile/Driver.sh
+ test/tools/javac/innerClassFile/InnerClassFileTest.java
- test/tools/javac/innerClassFile/x/B.java
- test/tools/javac/innerClassFile/x/C.java
- test/tools/javac/innerClassFile/y/Main.java
- test/tools/javac/innerClassFile/y/R1.java
- test/tools/javac/innerClassFile/y/R2.java
- test/tools/javac/innerClassFile/y/R3.java
- test/tools/javac/javazip/A.java
+ test/tools/javac/javazip/JavaZipTest.java
- test/tools/javac/javazip/Test.sh
- test/tools/javac/javazip/bad/B.java
- test/tools/javac/javazip/good/B.java
+ test/tools/javac/lib/ToolBox.java
+ test/tools/javac/links/LinksTest.java
- test/tools/javac/links/T.java
- test/tools/javac/links/b/B.java
- test/tools/javac/links/links.sh
+ test/tools/javac/newlines/NewLineTest.java
- test/tools/javac/newlines/Newlines.sh
+ test/tools/javac/stackmap/StackMapTest.java
- test/tools/javac/stackmap/T4955930.java
- test/tools/javac/stackmap/T4955930.sh
! test/tools/javac/unicode/SupplementaryJavaID6.java
- test/tools/javac/unicode/SupplementaryJavaID6.sh
+ test/tools/javah/6257087/T6257087.java
- test/tools/javah/6257087/foo.java
- test/tools/javah/6257087/foo.sh
- test/tools/javah/6257087/foo_bar.h
- test/tools/javah/ConstMacroTest.sh
- test/tools/javah/MissingParamClassException.java
- test/tools/javah/MissingParamClassTest.sh
- test/tools/javah/ParamClassTest.java
- test/tools/javah/SubClassConsts.java
- test/tools/javah/SubClassConsts.out
- test/tools/javah/SubClassConsts.win
- test/tools/javah/SuperClassConsts.java
+ test/tools/javah/T4942232/MissingParamClassTest.java
+ test/tools/javah/constMacroTest/ConstMacroTest.java
+ test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java
+ test/tools/javap/4866831/PublicInterfaceTest.java
- test/tools/javap/NotPackagePrivateInterface.java
- test/tools/javap/PublicInterfaceTest.sh
- test/tools/javap/pathsep.sh
+ test/tools/javap/stackmap/StackmapTest.java
- test/tools/javap/stackmap/T6271292.java
- test/tools/javap/stackmap/T6271292.out
- test/tools/javap/stackmap/T6271292.sh

Changeset: 9345394ac8fe
Author:    ksrini
Date:      2013-02-19 17:19 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/9345394ac8fe

8006948: Update javac for MethodParameters format change
Reviewed-by: ksrini, forax
Contributed-by: eric.mccorkle at oracle.com

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Changeset: 4cf6e84f844f
Author:    lana
Date:      2013-02-19 20:53 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/4cf6e84f844f

Merge


Changeset: 267225edc1fe
Author:    strarup
Date:      2013-02-20 15:47 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/267225edc1fe

8006582: Test for parameter names feature
Reviewed-by: jjg, darcy, emc

- test/tools/javac/MethodParameters.java
+ test/tools/javac/MethodParameters/AnnotationTest.java
+ test/tools/javac/MethodParameters/AnonymousClass.java
+ test/tools/javac/MethodParameters/AttributeVisitor.java
+ test/tools/javac/MethodParameters/ClassFileVisitor.java
+ test/tools/javac/MethodParameters/Constructors.java
+ test/tools/javac/MethodParameters/EnumTest.java
+ test/tools/javac/MethodParameters/InstanceMethods.java
+ test/tools/javac/MethodParameters/LambdaTest.java
+ test/tools/javac/MethodParameters/LocalClassTest.java
+ test/tools/javac/MethodParameters/MemberClassTest.java
+ test/tools/javac/MethodParameters/ReflectionVisitor.java
+ test/tools/javac/MethodParameters/StaticMethods.java
+ test/tools/javac/MethodParameters/Tester.java
+ test/tools/javac/MethodParameters/UncommonParamNames.java
+ test/tools/javac/MethodParametersTest.java

Changeset: d686d8a7eb78
Author:    mcimadamore
Date:      2013-02-21 15:19 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d686d8a7eb78

8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler
Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/LambdaConv27.java

Changeset: 3a39d123d33a
Author:    mcimadamore
Date:      2013-02-21 15:21 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/3a39d123d33a

8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply
Summary: DiagnosticFilter used during speculative attribution is too broad
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
+ test/tools/javac/lambda/speculative/MissingError.java
+ test/tools/javac/lambda/speculative/MissingError.out

Changeset: f4fdd53f8b3e
Author:    mcimadamore
Date:      2013-02-21 15:23 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/f4fdd53f8b3e

8005183: Missing accessor for constructor reference pointing to private inner class ctor
Summary: Compiler should add bridges when translating private constructor reference
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/MethodReference63.java

Changeset: 7ac9242d2ca6
Author:    mcimadamore
Date:      2013-02-21 15:25 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/7ac9242d2ca6

8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated
Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/TargetType64.java

Changeset: 9f0ec00514b6
Author:    mcimadamore
Date:      2013-02-21 15:26 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/9f0ec00514b6

8007461: Regression: bad overload resolution when inner class and outer class have method with same name
Summary: Fix regression in varargs method resolution introduced by bad refactoring
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/resolve/Pos.java
+ test/tools/javac/resolve/tests/InnerOverOuter.java

Changeset: 3fef0cae83b3
Author:    mcimadamore
Date:      2013-02-21 15:27 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/3fef0cae83b3

8008444: Inherited generic functional descriptors are merged incorrectly
Summary: Missing call to Types.createMethodWithThrownTypes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/LambdaConv25.java
+ test/tools/javac/lambda/LambdaConv25.out

Changeset: cd7340a84bb8
Author:    rfield
Date:      2013-02-21 14:43 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/cd7340a84bb8

8008405: Now that metafactory is in place, add javac lambda serialization tests
Summary: Tests part of original langtools serialization review.
Reviewed-by: mcimadamore

+ test/tools/javac/T8004969.java
+ test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java
+ test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java

Changeset: dabb36173c63
Author:    ksrini
Date:      2013-02-21 12:23 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/dabb36173c63

8008658: Four new method param jtreg tests fail in nightly tests
Reviewed-by: jjg, ksrini, mcimadamore
Contributed-by: eric.mccorkle at oracle.com

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! test/tools/javac/MethodParameters/EnumTest.java
! test/tools/javac/MethodParameters/LocalClassTest.java
! test/tools/javac/MethodParameters/MemberClassTest.java

Changeset: 6118072811e5
Author:    lana
Date:      2013-02-21 17:49 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/6118072811e5

Merge

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties

Changeset: 8e82e4f225e4
Author:    mcimadamore
Date:      2013-02-22 13:31 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/8e82e4f225e4

8008337: Write test to check for compiler error when static method in interface is called via super()
Reviewed-by: mcimadamore
Contributed-by: sonali.goel at oracle.com

+ test/tools/javac/lambda/StaticMethodNegTest.java
+ test/tools/javac/lambda/StaticMethodNegTest.out

Changeset: 94e67bed460d
Author:    mcimadamore
Date:      2013-02-22 18:19 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/94e67bed460d

8008708: Regression: separate compilation causes crash in wildcards inference logic
Summary: Invalid use of WildcardType.bound in Types.removeWildcards
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/separate/Foo.java
+ test/tools/javac/lambda/separate/Test.java

Changeset: ccbe7ffdd867
Author:    jjg
Date:      2013-02-24 11:36 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/ccbe7ffdd867

7112427: The doclet needs to be able to generate JavaFX documentation.
Reviewed-by: jjg
Contributed-by: jan.valenta at oracle.com

! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
+ src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/PropertyWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertyGetterTaglet.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertySetterTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
+ test/com/sun/javadoc/testJavaFX/C.java
+ test/com/sun/javadoc/testJavaFX/D.java
+ test/com/sun/javadoc/testJavaFX/TestJavaFX.java
! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java

Changeset: bd49e0304281
Author:    vromero
Date:      2013-02-26 09:04 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/bd49e0304281

8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java
! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out

Changeset: 133a0a0c2cbc
Author:    mcimadamore
Date:      2013-02-28 14:00 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/133a0a0c2cbc

8008723: Graph Inference: bad graph calculation leads to assertion error
Summary: Dependencies are not propagated correctly through merged nodes during inference graph initialization
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/lambda/TargetType65.java

Changeset: 332f23993353
Author:    mcimadamore
Date:      2013-02-28 14:05 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/332f23993353

8008813: Structural most specific fails when method reference is passed to overloaded method
Summary: Bad logic for checking most specific method reference type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/lambda/MostSpecific08.java

Changeset: 08782b8b03ce
Author:    mcimadamore
Date:      2013-02-28 14:05 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/08782b8b03ce

8008537: Missing method reference lookup error when unbound search finds a static method
Summary: Static-ness check should be applied after member reference resolution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
+ test/tools/javac/diags/examples/StaticMethodInUnboundLookup.java
! test/tools/javac/lambda/MethodReference22.java
! test/tools/javac/lambda/MethodReference22.out
! test/tools/javac/lambda/MethodReference28.out
! test/tools/javac/lambda/MethodReference51.out
! test/tools/javac/lambda/TargetType60.java
! test/tools/javac/lambda/TargetType60.out

Changeset: 6f988040a1c8
Author:    jjg
Date:      2013-03-01 10:47 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/6f988040a1c8

8008949: javadoc stopped copying doc-files
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
+ test/com/sun/javadoc/testDocFiles/TestDocFiles.java
+ test/com/sun/javadoc/testDocFiles/pkg/Test.java
+ test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt

Changeset: 69cd2bfd4a31
Author:    mcimadamore
Date:      2013-03-05 14:04 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/69cd2bfd4a31

8004962: Code generation crash with lambda and local classes
Summary: Translation info should be propagated from LambdaToMethod to Lower
Reviewed-by: jjg, rfield

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/lambda/LambdaCapture07.java

Changeset: d2a98dde7ecc
Author:    mcimadamore
Date:      2013-03-05 14:12 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d2a98dde7ecc

8009227: Certain diagnostics should not be deferred
Summary: Add new diagnostic flag to mark non deferrable diagnostics
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/lambda/abort/CompletionFailure.java

Changeset: a708c5f1da06
Author:    mcimadamore
Date:      2013-03-05 14:16 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/a708c5f1da06

8009154: Missing cast in method reference bridge leads to NoSuchMethodError
Summary: Missing cast in generated method reference bridge
Reviewed-by: rfield, jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/MethodReference65.java

Changeset: 12202e6ab78a
Author:    mcimadamore
Date:      2013-03-05 14:19 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/12202e6ab78a

8009129: Illegal access error when calling method reference
Summary: Javac generates method handle referencing non public type
Reviewed-by: jjg, rfield

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/NotDefPublicCantAccessFragment.java
+ test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/p/C.java
+ test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java
+ test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out
+ test/tools/javac/lambda/inaccessibleMref01/p1/C.java
+ test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java
+ test/tools/javac/lambda/inaccessibleMref02/p1/C.java

Changeset: 188a07a0a7a0
Author:    lana
Date:      2013-03-05 11:51 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/188a07a0a7a0

Merge


Changeset: d0178bd8125c
Author:    mcimadamore
Date:      2013-03-06 15:29 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d0178bd8125c

8009299: Javac crashes when compiling method reference to static interface method
Summary: Assertion in Check.checMethod is too strict
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
+ test/tools/javac/lambda/MethodReference66.java

Changeset: 8a78243291ef
Author:    mcimadamore
Date:      2013-03-06 15:33 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/8a78243291ef

8009459: Wrong behavior of diamond finder with source level 7
Summary: Diamond finder doesn't take into account different inference behaviors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/diamond/6939780/T6939780.java
+ test/tools/javac/generics/diamond/6939780/T6939780_7.out
+ test/tools/javac/generics/diamond/6939780/T6939780_8.out
- test/tools/javac/generics/diamond/T6939780.java
- test/tools/javac/generics/diamond/T6939780.out

Changeset: c98b3e96c726
Author:    mcimadamore
Date:      2013-03-06 15:33 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/c98b3e96c726

8009391: Synthetic name of serializable lambda methods should not contain negative numbers
Summary: Use hex representation of method signature hashcode to avoid negative numbers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: 3806171b52d8
Author:    vromero
Date:      2013-03-07 10:04 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/3806171b52d8

8009138: javac, equals-hashCode warning tuning
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/6563143/EqualsHashCodeWarningTest.java
+ test/tools/javac/6563143/EqualsHashCodeWarningTest.out
- test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java
- test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out

Changeset: 823fb9229724
Author:    vromero
Date:      2013-03-07 10:12 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/823fb9229724

8009170: Regression: javac generates redundant bytecode in assignop involving arrays
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java
+ test/tools/javac/8009170/RedundantByteCodeInArrayTest.java

Changeset: a02c3ddc182b
Author:    rfield
Date:      2013-03-07 08:26 -0800
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/a02c3ddc182b

8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/GenericMethodRefImplClass.java

Changeset: c61add6bf8ac
Author:    vromero
Date:      2013-03-11 15:35 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/c61add6bf8ac

6181889: Empty try/finally results in bytecodes being generated
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T6181889/EmptyFinallyTest.java

Changeset: d0ae21e3a382
Author:    rfield
Date:      2013-03-11 10:02 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/d0ae21e3a382

8009742: Bad lambda name for lambda in a static initializer or ctor
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/SerializedLambdaInInit.java

Changeset: fbb6e470079d
Author:    ohrstrom
Date:      2013-03-11 19:03 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/fbb6e470079d

8009843: sjavac should accept -cp as synonym for -classpath
Reviewed-by: jjg

! src/share/classes/com/sun/tools/sjavac/Main.java

Changeset: 7fe9b9d29095
Author:    jfranck
Date:      2013-03-12 11:16 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/7fe9b9d29095

8005205: tests missing bugid for repeating annotation change
Reviewed-by: jjg, ssides

! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java

Changeset: 6db9a3b1a93f
Author:    mcimadamore
Date:      2013-03-12 16:02 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/6db9a3b1a93f

8008540: Constructor reference to non-reifiable array should be rejected
8008539: Spurious error when constructor reference mention an interface type
8008538: Constructor reference accepts wildcard parameterized types
Summary: Overhaul of Check.checkConstructorRefType
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/lambda/MethodReference38.out
+ test/tools/javac/lambda/MethodReference64.java
+ test/tools/javac/lambda/MethodReference64.out

Changeset: 5ddecb91d843
Author:    mcimadamore
Date:      2013-03-12 16:02 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/5ddecb91d843

8009545: Graph inference: dependencies between inference variables should be set during incorporation
Summary: Move all transitivity checks into the incorporation round
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType28.out

Changeset: f427043f8c65
Author:    jfranck
Date:      2013-03-12 17:39 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/f427043f8c65

7196531: Duplicate error messages on repeating annotations
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
+ test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java
+ test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out
! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out
! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out

Changeset: 39f8eb897ec6
Author:    lana
Date:      2013-03-12 16:43 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/39f8eb897ec6

Merge

- test/tools/apt/Basics/NullAPF.java
- test/tools/apt/Basics/apt.sh
- test/tools/apt/verifyVariables.sh
- test/tools/javac/4846262/Test.java
- test/tools/javac/4846262/Test.out
- test/tools/javac/4846262/Test.sh
- test/tools/javac/6302184/T6302184.sh
- test/tools/javac/ClassPathTest/ClassPathTest.sh
- test/tools/javac/ClassPathTest/ClassPathTest1.java
- test/tools/javac/ClassPathTest/ClassPathTest2.java
- test/tools/javac/ClassPathTest/ClassPathTest3.java
- test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java
- test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java
- test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java
- test/tools/javac/ExtDirs/ExtDirTest_1.java
- test/tools/javac/ExtDirs/ExtDirTest_2.java
- test/tools/javac/ExtDirs/ExtDirTest_3.java
- test/tools/javac/ExtDirs/ExtDirs.sh
- test/tools/javac/MethodParameters.java
- test/tools/javac/MissingInclude.java
- test/tools/javac/MissingInclude.sh
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java
- test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java
- test/tools/javac/T5090006/T5090006.java
- test/tools/javac/T5090006/compiler.sh
- test/tools/javac/constDebug/ConstDebug.java
- test/tools/javac/constDebug/ConstDebug.sh
- test/tools/javac/fatalErrors/NoJavaLang.java
- test/tools/javac/fatalErrors/NoJavaLang.out
- test/tools/javac/fatalErrors/NoJavaLang.sh
- test/tools/javac/generics/diamond/T6939780.java
- test/tools/javac/generics/diamond/T6939780.out
- test/tools/javac/innerClassFile/Driver.sh
- test/tools/javac/innerClassFile/x/B.java
- test/tools/javac/innerClassFile/x/C.java
- test/tools/javac/innerClassFile/y/Main.java
- test/tools/javac/innerClassFile/y/R1.java
- test/tools/javac/innerClassFile/y/R2.java
- test/tools/javac/innerClassFile/y/R3.java
- test/tools/javac/javazip/A.java
- test/tools/javac/javazip/Test.sh
- test/tools/javac/javazip/bad/B.java
- test/tools/javac/javazip/good/B.java
- test/tools/javac/links/T.java
- test/tools/javac/links/b/B.java
- test/tools/javac/links/links.sh
- test/tools/javac/newlines/Newlines.sh
- test/tools/javac/stackmap/T4955930.java
- test/tools/javac/stackmap/T4955930.sh
- test/tools/javac/unicode/SupplementaryJavaID6.sh
- test/tools/javah/6257087/foo.java
- test/tools/javah/6257087/foo.sh
- test/tools/javah/6257087/foo_bar.h
- test/tools/javah/ConstMacroTest.sh
- test/tools/javah/MissingParamClassException.java
- test/tools/javah/MissingParamClassTest.sh
- test/tools/javah/ParamClassTest.java
- test/tools/javah/SubClassConsts.java
- test/tools/javah/SubClassConsts.out
- test/tools/javah/SubClassConsts.win
- test/tools/javah/SuperClassConsts.java
- test/tools/javap/NotPackagePrivateInterface.java
- test/tools/javap/PublicInterfaceTest.sh
- test/tools/javap/pathsep.sh
- test/tools/javap/stackmap/T6271292.java
- test/tools/javap/stackmap/T6271292.out
- test/tools/javap/stackmap/T6271292.sh

Changeset: 825da6847791
Author:    lana
Date:      2013-03-14 19:33 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/langtools/rev/825da6847791

Merge



From roger.riggs at oracle.com  Sat Mar 16 09:46:21 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Sat, 16 Mar 2013 12:46:21 -0400
Subject: [threeten-dev] Static methods in interfaces
Message-ID: <5144A1DD.8080004@oracle.com>

fyi,

The updates that Sherman did from the JDK 8 repository should have resolved
the issues with the verifier when using static methods in interfaces.
My trivial example program worked ok.

Roger


From scolebourne at joda.org  Sat Mar 16 14:55:25 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 16 Mar 2013 21:55:25 +0000
Subject: [threeten-dev] Static methods in interfaces
In-Reply-To: <5144A1DD.8080004@oracle.com>
References: <5144A1DD.8080004@oracle.com>
Message-ID: 

Unfortunately, when I pulled all the repos, I can now not build the
jdk images. Different errors, including this one:

## Starting nashorn
/bin/sh: line 0: cd:
/cygdrive/c/dev/threeten/jdk8_310/ojdk/nashorn/makefiles: No such file
or directory
/cygdrive/c/dev/threeten/jdk8_310/ojdk//common/makefiles/Main.gmk:125:
recipe for target `nashorn-only' failed
make: *** [nashorn-only] Error 1

My patch for static methods should still be reasonably valid
https://gist.github.com/jodastephen/4691683

Stephen



On 16 March 2013 16:46, roger riggs  wrote:
> fyi,
>
> The updates that Sherman did from the JDK 8 repository should have resolved
> the issues with the verifier when using static methods in interfaces.
> My trivial example program worked ok.
>
> Roger
>

From xueming.shen at oracle.com  Sat Mar 16 21:09:12 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 16 Mar 2013 21:09:12 -0700
Subject: [threeten-dev] Static methods in interfaces
In-Reply-To: 
References: <5144A1DD.8080004@oracle.com>
	
Message-ID: <514541E8.8020004@oracle.com>

The threeten control repo does not have nashorn repo, yet :-( I will 
need to have someone
help to put it in, before that happens, you might want to just clone a 
nashorn repo from
the jdk8 master control repo and put it under threeten control repo.

Iris, my guess is that myself can't create/clone a nashorn repo on the 
server side and we
need your help to clone one from the jdk8 master, right?

-Sherman

On 3/16/13 2:55 PM, Stephen Colebourne wrote:
> Unfortunately, when I pulled all the repos, I can now not build the
> jdk images. Different errors, including this one:
>
> ## Starting nashorn
> /bin/sh: line 0: cd:
> /cygdrive/c/dev/threeten/jdk8_310/ojdk/nashorn/makefiles: No such file
> or directory
> /cygdrive/c/dev/threeten/jdk8_310/ojdk//common/makefiles/Main.gmk:125:
> recipe for target `nashorn-only' failed
> make: *** [nashorn-only] Error 1
>
> My patch for static methods should still be reasonably valid
> https://gist.github.com/jodastephen/4691683
>
> Stephen
>
>
>
> On 16 March 2013 16:46, roger riggs  wrote:
>> fyi,
>>
>> The updates that Sherman did from the JDK 8 repository should have resolved
>> the issues with the verifier when using static methods in interfaces.
>> My trivial example program worked ok.
>>
>> Roger
>>


From scolebourne at joda.org  Sun Mar 17 05:18:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 17 Mar 2013 12:18:26 +0000
Subject: [threeten-dev] Static methods in interfaces
In-Reply-To: <514541E8.8020004@oracle.com>
References: <5144A1DD.8080004@oracle.com>
	
	<514541E8.8020004@oracle.com>
Message-ID: 

Thanks, that compiles now.
I plan to push the static methods in chrono patch previously seen.
Stephen

On 17 March 2013 04:09, Xueming Shen  wrote:
> The threeten control repo does not have nashorn repo, yet :-( I will need to
> have someone
> help to put it in, before that happens, you might want to just clone a
> nashorn repo from
> the jdk8 master control repo and put it under threeten control repo.
>
> Iris, my guess is that myself can't create/clone a nashorn repo on the
> server side and we
> need your help to clone one from the jdk8 master, right?
>
> -Sherman
>
>
> On 3/16/13 2:55 PM, Stephen Colebourne wrote:
>>
>> Unfortunately, when I pulled all the repos, I can now not build the
>> jdk images. Different errors, including this one:
>>
>> ## Starting nashorn
>> /bin/sh: line 0: cd:
>> /cygdrive/c/dev/threeten/jdk8_310/ojdk/nashorn/makefiles: No such file
>> or directory
>> /cygdrive/c/dev/threeten/jdk8_310/ojdk//common/makefiles/Main.gmk:125:
>> recipe for target `nashorn-only' failed
>> make: *** [nashorn-only] Error 1
>>
>> My patch for static methods should still be reasonably valid
>> https://gist.github.com/jodastephen/4691683
>>
>> Stephen
>>
>>
>>
>> On 16 March 2013 16:46, roger riggs  wrote:
>>>
>>> fyi,
>>>
>>> The updates that Sherman did from the JDK 8 repository should have
>>> resolved
>>> the issues with the verifier when using static methods in interfaces.
>>> My trivial example program worked ok.
>>>
>>> Roger
>>>
>

From scolebourne at joda.org  Sun Mar 17 06:08:15 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sun, 17 Mar 2013 13:08:15 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Add static from() methods
	to Chrono	interfaces
Message-ID: <20130317130843.6302D481F9@hg.openjdk.java.net>

Changeset: 156c0d2d2aec
Author:    scolebourne
Date:      2013-03-17 13:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/156c0d2d2aec

Add static from() methods to Chrono interfaces

Fixes #203

! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/Chronology.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java


From roger.riggs at oracle.com  Sun Mar 17 11:38:35 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Sun, 17 Mar 2013 14:38:35 -0400
Subject: [threeten-dev] updated repos
In-Reply-To: <514541E8.8020004@oracle.com>
References: <5144A1DD.8080004@oracle.com>
	
	<514541E8.8020004@oracle.com>
Message-ID: <51460DAB.2010203@oracle.com>

I updated (on Saturday) two of my repo work areas using only 
/get_source.sh
and it populated with nashorn.  Followed by configure; make clean; make
without any special handling.

fyi, Roger



On 3/17/2013 12:09 AM, Xueming Shen wrote:
> The threeten control repo does not have nashorn repo, yet :-( I will 
> need to have someone
> help to put it in, before that happens, you might want to just clone a 
> nashorn repo from
> the jdk8 master control repo and put it under threeten control repo.
>
> Iris, my guess is that myself can't create/clone a nashorn repo on the 
> server side and we
> need your help to clone one from the jdk8 master, right?
>
> -Sherman
>
> On 3/16/13 2:55 PM, Stephen Colebourne wrote:
>> Unfortunately, when I pulled all the repos, I can now not build the
>> jdk images. Different errors, including this one:
>>
>> ## Starting nashorn
>> /bin/sh: line 0: cd:
>> /cygdrive/c/dev/threeten/jdk8_310/ojdk/nashorn/makefiles: No such file
>> or directory
>> /cygdrive/c/dev/threeten/jdk8_310/ojdk//common/makefiles/Main.gmk:125:
>> recipe for target `nashorn-only' failed
>> make: *** [nashorn-only] Error 1
>>
>> My patch for static methods should still be reasonably valid
>> https://gist.github.com/jodastephen/4691683
>>
>> Stephen
>>
>>
>>
>> On 16 March 2013 16:46, roger riggs  wrote:
>>> fyi,
>>>
>>> The updates that Sherman did from the JDK 8 repository should have 
>>> resolved
>>> the issues with the verifier when using static methods in interfaces.
>>> My trivial example program worked ok.
>>>
>>> Roger
>>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From masayoshi.okutsu at oracle.com  Sun Mar 17 21:26:58 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 18 Mar 2013 13:26:58 +0900
Subject: [threeten-dev] what happened to JapaneseChronology?
In-Reply-To: <514335A7.1070205@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com> <513E8702.2040803@oracle.com>
	<514002A0.8010604@oracle.com> <5142DC2C.3060706@oracle.com>
	<514335A7.1070205@oracle.com>
Message-ID: <51469792.9000709@oracle.com>

On 3/15/2013 11:52 PM, roger riggs wrote:
> Hi Patrick,
>
> The first official day of the SHOWA era is 1, 12, 29  (The month 
> numbering does not start at one.)

12-25 is the first day of Showa.

> Similarly, the first official day of TAISHO is 1, 7, 30.
>
> I don't know why the IllegalArgumentException does not have a 
> message.  (Masayoshi?)

Currently, private JapaneseDate.of calls the Japanese calendar 
implementation in a sun package to validate the given date. The sun 
package implementation returns true if the Japanese date is valid, or 
false otherwise. There's no information beyond an invalid date specified 
by the arguments. Do you think the method should report which parameters 
may be invalid? If so, could you file an issue for that? It's not simple 
to report invalid parameters due to some possibilities. For example, 
era, year, or month+day-of-month (outside of 12-25 to 12-31) may be 
wrong with Showa 1.01.01, and era, year, month, or month+day-of-month 
may be wrong with Taisho 1.01.01.

> I'm not sure why the tests started failing now unless the leniency 
> changes
> have made a difference; though the tests should have been fixed at the 
> same time.

My fix to the sun private Japanese calendar implementation for 
formatting may have affected?

Masayoshi

>
> It looks like a test bug.
>
> Thanks, Roger
>
>
>
> On 3/15/2013 4:30 AM, patrick zhang wrote:
>> Hi,
>>
>> Any suggestion for this problem?
>>
>> Regards
>> Patrick
>>
>> On 2013-3-13 12:37, Patrick Zhang wrote:
>>> Hi Team,
>>>
>>> What happened to JapaneseChronology? It will not support the later 2 
>>> eras? It looks it is one new failure and I do not meet it on last week.
>>> =============
>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.MEIJI, 
>>> 1, 1, 1));
>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 
>>> 1, 1, 1));
>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SEIREKI, 
>>> 1, 1, 1));
>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SHOWA, 
>>> 1, 1, 1));       //will throw exception
>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.TAISHO, 
>>> 1, 1, 1));       //will throw exception
>>> ==============
>>>
>>> Exception info:
>>> ==============
>>> Exception in thread "main" java.lang.IllegalArgumentException
>>>     at java.time.chrono.JapaneseDate.of(JapaneseDate.java:256)
>>>     at 
>>> java.time.chrono.JapaneseChronology.date(JapaneseChronology.java:166)
>>>     at Test.f1(Test.java:17)
>>>     at Test.main(Test.java:5)
>>> ==============
>>>
>>> Regards
>>> Patrick
>>>
>>>
>


From patrick.zhang at oracle.com  Sun Mar 17 22:39:03 2013
From: patrick.zhang at oracle.com (Patrick Zhang)
Date: Mon, 18 Mar 2013 13:39:03 +0800
Subject: [threeten-dev]  Can not build binaries from jsr310 repo
In-Reply-To: <5142DB7F.1000507@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <5142DB7F.1000507@oracle.com>
Message-ID: <5146A877.5060407@oracle.com>

Hi Shereman & Roger,

It looks there is something wrong when I try to build binaries from 
jsr310 repo.
=============
/usr/bin/gcc  -g -O2   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused 
-Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN   -DNDEBUG 
-DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-internal"' 
-D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. 
-I/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/CClassHeaders 
-I../../../src/solaris/javavm/export 
-I../../../src/share/javavm/export    -DTHIS_FILE='".files_compiled"' 
-Xlinker -O1 -Xlinker -version-script=mapfile-vers  
-Wl,--hash-style=both -Xlinker -z -Xlinker origin -Xlinker -rpath 
-Xlinker \$ORIGIN  -Xlinker -z -Xlinker defs 
-L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386 
-Wl,-soname=libverify.so   -shared -o 
/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so 
/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o 
/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_format.o 
-L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/server 
-ljvm  -lc
/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o: 
In function `verify_method':
/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify/../../../src/share/native/common/check_code.c:992: 
undefined reference to `JVM_IsVMGeneratedMethodIx'
collect2: ld returned 1 exit status
gmake[3]: *** 
[/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so] 
Error 1
gmake[3]: Leaving directory 
`/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify'
gmake[2]: *** [all] Error 1
gmake[2]: Leaving directory 
`/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java'
gmake[1]: *** [all] Error 1
gmake[1]: Leaving directory 
`/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make'
gmake: *** [openjdk] Error 2
==============

The same error happens in RE build job also. All Hudson jobs fail today.
http://rehudson.us.oracle.com/cgi-bin/buildview.cgi?user=&buildname=jdk8-jsr310&submit=by+build+name&debug=On

Regards
Patrick

From roger.riggs at oracle.com  Mon Mar 18 10:24:51 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 18 Mar 2013 13:24:51 -0400
Subject: [threeten-dev] what happened to JapaneseChronology?
In-Reply-To: <51469792.9000709@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <51359FF4.70202@oracle.com>
	<513AE160.3050603@oracle.com> <513E8702.2040803@oracle.com>
	<514002A0.8010604@oracle.com> <5142DC2C.3060706@oracle.com>
	<514335A7.1070205@oracle.com> <51469792.9000709@oracle.com>
Message-ID: <51474DE3.6000803@oracle.com>

Hi Masayoshi,

On 3/18/2013 12:26 AM, Masayoshi Okutsu wrote:
...
>>
>> I don't know why the IllegalArgumentException does not have a 
>> message.  (Masayoshi?)
>
> Currently, private JapaneseDate.of calls the Japanese calendar 
> implementation in a sun package to validate the given date. The sun 
> package implementation returns true if the Japanese date is valid, or 
> false otherwise. There's no information beyond an invalid date 
> specified by the arguments. Do you think the method should report 
> which parameters may be invalid? If so, could you file an issue for 
> that? It's not simple to report invalid parameters due to some 
> possibilities. For example, era, year, or month+day-of-month (outside 
> of 12-25 to 12-31) may be wrong with Showa 1.01.01, and era, year, 
> month, or month+day-of-month may be wrong with Taisho 1.01.01.
It could have been implemented against the threeten range methods that 
should
produce the same valid/invalid result and have appropriate information 
to report.
In any case, the ValueRanges for the day should reflect the exact range 
of dates at
the beginning and end of the eras.  I don't know if there is a test for 
that.

BTW,  issue 272 DAY_OF_YEAR definition for non-ISO Chronology 

needs your concurrence to proceed.

Thanks, Roger


>
>> I'm not sure why the tests started failing now unless the leniency 
>> changes
>> have made a difference; though the tests should have been fixed at 
>> the same time.
>
> My fix to the sun private Japanese calendar implementation for 
> formatting may have affected?
>
> Masayoshi
>
>>
>> It looks like a test bug.
>>
>> Thanks, Roger
>>
>>
>>
>> On 3/15/2013 4:30 AM, patrick zhang wrote:
>>> Hi,
>>>
>>> Any suggestion for this problem?
>>>
>>> Regards
>>> Patrick
>>>
>>> On 2013-3-13 12:37, Patrick Zhang wrote:
>>>> Hi Team,
>>>>
>>>> What happened to JapaneseChronology? It will not support the later 
>>>> 2 eras? It looks it is one new failure and I do not meet it on last 
>>>> week.
>>>> =============
>>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.MEIJI, 
>>>> 1, 1, 1));
>>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 
>>>> 1, 1, 1));
>>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SEIREKI, 
>>>> 1, 1, 1));
>>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.SHOWA, 
>>>> 1, 1, 1));       //will throw exception
>>>> System.out.println(JapaneseChronology.INSTANCE.date(JapaneseEra.TAISHO, 
>>>> 1, 1, 1));       //will throw exception
>>>> ==============
>>>>
>>>> Exception info:
>>>> ==============
>>>> Exception in thread "main" java.lang.IllegalArgumentException
>>>>     at java.time.chrono.JapaneseDate.of(JapaneseDate.java:256)
>>>>     at 
>>>> java.time.chrono.JapaneseChronology.date(JapaneseChronology.java:166)
>>>>     at Test.f1(Test.java:17)
>>>>     at Test.main(Test.java:5)
>>>> ==============
>>>>
>>>> Regards
>>>> Patrick
>>>>
>>>>
>>
>

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From xueming.shen at oracle.com  Mon Mar 18 10:42:43 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 18 Mar 2013 10:42:43 -0700
Subject: [threeten-dev] updated repos
In-Reply-To: <51460DAB.2010203@oracle.com>
References: <5144A1DD.8080004@oracle.com>
	
	<514541E8.8020004@oracle.com> <51460DAB.2010203@oracle.com>
Message-ID: <51475213.1060005@oracle.com>

Not sure what happened...but yes, with "sh get_source.sh" now you get a nashorn
directory at top, and even the "old" build works fine on my local linux machine now
(with one werror fatal failure, but it is easy to just commit the werror fatal setting)

-Sherman

On 3/17/2013 11:38 AM, roger riggs wrote:
> I updated (on Saturday) two of my repo work areas using only /get_source.sh
> and it populated with nashorn.  Followed by configure; make clean; make
> without any special handling.
>
> fyi, Roger
>
>
>
> On 3/17/2013 12:09 AM, Xueming Shen wrote:
>> The threeten control repo does not have nashorn repo, yet :-( I will need to have someone
>> help to put it in, before that happens, you might want to just clone a nashorn repo from
>> the jdk8 master control repo and put it under threeten control repo.
>>
>> Iris, my guess is that myself can't create/clone a nashorn repo on the server side and we
>> need your help to clone one from the jdk8 master, right?
>>
>> -Sherman
>>
>> On 3/16/13 2:55 PM, Stephen Colebourne wrote:
>>> Unfortunately, when I pulled all the repos, I can now not build the
>>> jdk images. Different errors, including this one:
>>>
>>> ## Starting nashorn
>>> /bin/sh: line 0: cd:
>>> /cygdrive/c/dev/threeten/jdk8_310/ojdk/nashorn/makefiles: No such file
>>> or directory
>>> /cygdrive/c/dev/threeten/jdk8_310/ojdk//common/makefiles/Main.gmk:125:
>>> recipe for target `nashorn-only' failed
>>> make: *** [nashorn-only] Error 1
>>>
>>> My patch for static methods should still be reasonably valid
>>> https://gist.github.com/jodastephen/4691683
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 16 March 2013 16:46, roger riggs  wrote:
>>>> fyi,
>>>>
>>>> The updates that Sherman did from the JDK 8 repository should have resolved
>>>> the issues with the verifier when using static methods in interfaces.
>>>> My trivial example program worked ok.
>>>>
>>>> Roger
>>>>
>>
>
> -- 
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Green Oracle  Oracle is committed to developing practices and products that help protect the environment
>


From scolebourne at joda.org  Mon Mar 18 15:09:19 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Mon, 18 Mar 2013 22:09:19 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130318220954.7092F48229@hg.openjdk.java.net>

Changeset: a8343f55bd69
Author:    scolebourne
Date:      2013-03-18 21:23 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a8343f55bd69

Move static methods from Adjusters to TemporalAdjuster

Due to a compiler bug this was somewhat frustrating
The public methods have been moved to the correct location
The implementation (as lambdas) has to be on a separate class for now
See #188

! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
+ src/share/classes/java/time/temporal/TemporalAdjusters.java
! src/share/classes/java/time/temporal/package-info.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/TestIsoChronology.java
! test/java/time/tck/java/time/chrono/TestHijrahChronology.java
! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
! test/java/time/tck/java/time/chrono/TestMinguoChronology.java
! test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
+ test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java

Changeset: 44f12351ced0
Author:    scolebourne
Date:      2013-03-18 22:07 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/44f12351ced0

Move public methods on Queries to TemporalQuery

Hide Queries class
Fixes #172

! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/Parsed.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
! src/share/classes/java/time/temporal/TemporalAmount.java
+ src/share/classes/java/time/temporal/TemporalQueries.java
! src/share/classes/java/time/temporal/TemporalQuery.java
! src/share/classes/java/time/temporal/package-info.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKIsoChronology.java
! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java


From scolebourne at joda.org  Mon Mar 18 15:16:42 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 18 Mar 2013 22:16:42 +0000
Subject: [threeten-dev] Static methods
Message-ID: 

I've pushed changes to remove Adjusters and Queries classes in favour
of static methods in the interfaces.
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a8343f55bd69
http://hg.openjdk.java.net/threeten/threeten/jdk/rev/44f12351ced0

I pushed it, as they were big/complex changes that were a pain to do
and I didn't want them caught up in merging (plus we've all agreed on
the principle of the changes AFAIK).

However, my limited IDE setup doesn't check any code other than
java.time, so I'm sure I've broken the codebase. Could I ask you
Roger/Sherman to find and fix the bits that I couldn't?

thanks
Stephen

From patrick.zhang at oracle.com  Mon Mar 18 17:36:08 2013
From: patrick.zhang at oracle.com (Patrick Zhang)
Date: Tue, 19 Mar 2013 08:36:08 +0800
Subject: [threeten-dev] Can not build binaries from jsr310 repo
In-Reply-To: <5146A877.5060407@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com> <512F148D.1060508@oracle.com>
	<513597AD.8080306@oracle.com> <5142DB7F.1000507@oracle.com>
	<5146A877.5060407@oracle.com>
Message-ID: <5147B2F8.7060004@oracle.com>

Hi,

I still can not build it successfully...

Regards
Patrick

On 3/18/13 1:39 PM, Patrick Zhang wrote:
> Hi Shereman & Roger,
>
> It looks there is something wrong when I try to build binaries from 
> jsr310 repo.
> =============
> /usr/bin/gcc  -g -O2   -fno-strict-aliasing -fPIC -W -Wall  
> -Wno-unused -Wno-parentheses -fno-omit-frame-pointer 
> -D_LITTLE_ENDIAN   -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX 
> -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE 
> -D_REENTRANT -I. 
> -I/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/CClassHeaders 
> -I../../../src/solaris/javavm/export 
> -I../../../src/share/javavm/export    -DTHIS_FILE='".files_compiled"' 
> -Xlinker -O1 -Xlinker -version-script=mapfile-vers  
> -Wl,--hash-style=both -Xlinker -z -Xlinker origin -Xlinker -rpath 
> -Xlinker \$ORIGIN  -Xlinker -z -Xlinker defs 
> -L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386 
> -Wl,-soname=libverify.so   -shared -o 
> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so 
> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o 
> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_format.o 
> -L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/server 
> -ljvm  -lc
> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o: 
> In function `verify_method':
> /net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify/../../../src/share/native/common/check_code.c:992: 
> undefined reference to `JVM_IsVMGeneratedMethodIx'
> collect2: ld returned 1 exit status
> gmake[3]: *** 
> [/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so] 
> Error 1
> gmake[3]: Leaving directory 
> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify'
> gmake[2]: *** [all] Error 1
> gmake[2]: Leaving directory 
> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java'
> gmake[1]: *** [all] Error 1
> gmake[1]: Leaving directory 
> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make'
> gmake: *** [openjdk] Error 2
> ==============
>
> The same error happens in RE build job also. All Hudson jobs fail today.
> http://rehudson.us.oracle.com/cgi-bin/buildview.cgi?user=&buildname=jdk8-jsr310&submit=by+build+name&debug=On 
>
>
> Regards
> Patrick

From roger.riggs at oracle.com  Mon Mar 18 20:00:01 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Tue, 19 Mar 2013 03:00:01 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Update references to
	Queries to	TemporalQuery
Message-ID: <20130319030022.E59794823B@hg.openjdk.java.net>

Changeset: fefa808fe472
Author:    rriggs
Date:      2013-03-18 22:59 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fefa808fe472

Update references to Queries to TemporalQuery

! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java


From masayoshi.okutsu at oracle.com  Tue Mar 19 02:44:01 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 19 Mar 2013 18:44:01 +0900
Subject: [threeten-dev] Review request: pattern letters changes for
	LDML/CLDR compatibility
Message-ID: <51483361.6020202@oracle.com>

Hi,

Here are additional changes for more LDML/CLDR compatibility with the 
pattern letters. The latest LDML spec is available at:

http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table

- "E" and "EE" are the same thing as "EEE". (Number is no longer 
supported with 'E'.)

- "cc" is no longer valid. Only "c" is valid as Number.

- 6-letter 'E', 'e', and 'c' are accepted and treated as short style.

- Only one letter 'F' is accepted.

- Up to 2 letters of 'd', 'H', 'h','K', 'k', 'm', and 's' are accepted.

- Up to 3 letters of 'D' are accepted.

I haven't touched the time zone related pattern letters.

Webrev:
http://cr.openjdk.java.net/~okutsu/310/patterns1/webrev.00/

Thanks,
Masayoshi

p.s. Feel free to rewrite the spec part with better wording. :-)

From scolebourne at joda.org  Tue Mar 19 08:10:09 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 19 Mar 2013 15:10:09 +0000
Subject: [threeten-dev] Review request: pattern letters changes for
 LDML/CLDR compatibility
In-Reply-To: <51483361.6020202@oracle.com>
References: <51483361.6020202@oracle.com>
Message-ID: 

+1
Stephen

On 19 March 2013 09:44, Masayoshi Okutsu  wrote:
> Hi,
>
> Here are additional changes for more LDML/CLDR compatibility with the
> pattern letters. The latest LDML spec is available at:
>
> http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
>
> - "E" and "EE" are the same thing as "EEE". (Number is no longer supported
> with 'E'.)
>
> - "cc" is no longer valid. Only "c" is valid as Number.
>
> - 6-letter 'E', 'e', and 'c' are accepted and treated as short style.
>
> - Only one letter 'F' is accepted.
>
> - Up to 2 letters of 'd', 'H', 'h','K', 'k', 'm', and 's' are accepted.
>
> - Up to 3 letters of 'D' are accepted.
>
> I haven't touched the time zone related pattern letters.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/310/patterns1/webrev.00/
>
> Thanks,
> Masayoshi
>
> p.s. Feel free to rewrite the spec part with better wording. :-)

From scolebourne at joda.org  Tue Mar 19 09:26:39 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 19 Mar 2013 16:26:39 +0000
Subject: [threeten-dev] Can not build binaries from jsr310 repo
In-Reply-To: <5147B2F8.7060004@oracle.com>
References: <50EFCCF6.50300@oracle.com>
	
	<50F3C896.6050503@oracle.com> <50FB8F50.1030004@oracle.com>
	
	<50FCE5E4.2040007@oracle.com> <5108BD08.8000903@oracle.com>
	<5108C1AB.1070000@oracle.com> <5108C7C4.2080903@oracle.com>
	<512343C3.70805@oracle.com> <5123470A.4060406@oracle.com>
	<512F0E7D.5070208@oracle.com>
	<512F148D.1060508@oracle.com> <513597AD.8080306@oracle.com>
	<5142DB7F.1000507@oracle.com> <5146A877.5060407@oracle.com>
	<5147B2F8.7060004@oracle.com>
Message-ID: 

I had to clone nashorn from
http://hg.openjdk.java.net/jdk8/jdk8/nashorn alongside the jdk folder,
and then configure/make from scratch.
Stephen


On 19 March 2013 00:36, Patrick Zhang  wrote:
> Hi,
>
> I still can not build it successfully...
>
> Regards
> Patrick
>
>
> On 3/18/13 1:39 PM, Patrick Zhang wrote:
>>
>> Hi Shereman & Roger,
>>
>> It looks there is something wrong when I try to build binaries from jsr310
>> repo.
>> =============
>> /usr/bin/gcc  -g -O2   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>> -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN   -DNDEBUG
>> -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-internal"'
>> -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I.
>> -I/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/CClassHeaders
>> -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export
>> -DTHIS_FILE='".files_compiled"' -Xlinker -O1 -Xlinker
>> -version-script=mapfile-vers  -Wl,--hash-style=both -Xlinker -z -Xlinker
>> origin -Xlinker -rpath -Xlinker \$ORIGIN  -Xlinker -z -Xlinker defs
>> -L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386
>> -Wl,-soname=libverify.so   -shared -o
>> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so
>> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o
>> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_format.o
>> -L/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/server
>> -ljvm  -lc
>>
>> /net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/tmp/java/verify/obj/check_code.o:
>> In function `verify_method':
>>
>> /net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify/../../../src/share/native/common/check_code.c:992:
>> undefined reference to `JVM_IsVMGeneratedMethodIx'
>> collect2: ld returned 1 exit status
>> gmake[3]: ***
>> [/net/sqenfs-1/export1/comp/jsn/users/patrick/jdkoutput_new/lib/i386/libverify.so]
>> Error 1
>> gmake[3]: Leaving directory
>> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java/verify'
>> gmake[2]: *** [all] Error 1
>> gmake[2]: Leaving directory
>> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make/java'
>> gmake[1]: *** [all] Error 1
>> gmake[1]: Leaving directory
>> `/net/sqenfs-1/export1/comp/jsn/users/patrick/threeten/jdk/make'
>> gmake: *** [openjdk] Error 2
>> ==============
>>
>> The same error happens in RE build job also. All Hudson jobs fail today.
>>
>> http://rehudson.us.oracle.com/cgi-bin/buildview.cgi?user=&buildname=jdk8-jsr310&submit=by+build+name&debug=On
>>
>> Regards
>> Patrick

From masayoshi.okutsu at oracle.com  Wed Mar 20 01:27:16 2013
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Wed, 20 Mar 2013 08:27:16 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: More changes for
	LDML/CLDR compatibility	changes with pattern letters.
Message-ID: <20130320082740.98BBA4828D@hg.openjdk.java.net>

Changeset: 483ee6c117d4
Author:    okutsu
Date:      2013-03-20 17:26 +0900
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/483ee6c117d4

More changes for LDML/CLDR compatibility changes with pattern letters.

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java


From scolebourne at joda.org  Thu Mar 21 06:40:37 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Thu, 21 Mar 2013 13:40:37 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 7 new changesets
Message-ID: <20130321134228.AF823482E7@hg.openjdk.java.net>

Changeset: 651fb9ce9eb3
Author:    scolebourne
Date:      2013-03-21 10:24 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/651fb9ce9eb3

Add Period/Duration.from(TemporalAmount)

Fixes #285

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Period.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKPeriod.java

Changeset: c46ed88b168e
Author:    scolebourne
Date:      2013-03-21 10:30 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c46ed88b168e

Move location of between() method within the file

Simple factories should be before complex ones

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Period.java
! test/java/time/tck/java/time/TCKDuration.java

Changeset: d3c38464e284
Author:    scolebourne
Date:      2013-03-21 11:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/d3c38464e284

Refactor temporal accessor class to method

Sets up privately what #287 proposes should be public

! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/chrono/Chronology.java

Changeset: 3f93b60b87bd
Author:    scolebourne
Date:      2013-03-21 13:11 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3f93b60b87bd

Better Javadoc for pattern letters

Define builder in terms of method calls
Minor simplification of formatter docs

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java

Changeset: a19e0b4b7093
Author:    scolebourne
Date:      2013-03-21 13:14 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/a19e0b4b7093

Update formatter builder to ensure that # is properly reserved

! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java

Changeset: 5280a0b575ba
Author:    scolebourne
Date:      2013-03-21 13:23 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5280a0b575ba

Fix pattern letters Y and F and enhance comments

Pattern letter Y is ISO week-based-year (not perfect, but better than before)
Pattern letter F was wrong and is now fixed
See #64

! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java

Changeset: 7e8235e9c684
Author:    scolebourne
Date:      2013-03-21 13:39 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7e8235e9c684

Swap pattern letters w and W

Fixes #284

! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java


From roger.riggs at oracle.com  Thu Mar 21 07:10:42 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Thu, 21 Mar 2013 14:10:42 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130321141127.C06DC482E9@hg.openjdk.java.net>

Changeset: df2713fb811d
Author:    rriggs
Date:      2013-03-21 10:02 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/df2713fb811d

#276 Rename ZoneId OLD_IDS field to use SHORT_IDs in their names

! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/util/TimeZone.java
! test/java/time/tck/java/time/TCKZoneId.java

Changeset: 891c2e24fd07
Author:    rriggs
Date:      2013-03-21 10:10 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/891c2e24fd07

Merge

! src/share/classes/java/time/ZoneId.java


From scolebourne at joda.org  Thu Mar 21 08:09:09 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Thu, 21 Mar 2013 15:09:09 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Better Javadoc for short
	zone IDs
Message-ID: <20130321150921.C7D64482EB@hg.openjdk.java.net>

Changeset: 4563bcbe5ecd
Author:    scolebourne
Date:      2013-03-21 15:08 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4563bcbe5ecd

Better Javadoc for short zone IDs

! src/share/classes/java/time/ZoneId.java


From scolebourne at joda.org  Thu Mar 21 11:33:05 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Thu, 21 Mar 2013 18:33:05 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Ensure that ZDT.with(ODT)
	and ZDT.with(OT)	behave well
Message-ID: <20130321183339.74FF4482F2@hg.openjdk.java.net>

Changeset: dd1ee17fb096
Author:    scolebourne
Date:      2013-03-21 18:31 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/dd1ee17fb096

Ensure that ZDT.with(ODT) and ZDT.with(OT) behave well

Treat ODT/OT as LDT-based, not Instant-based
This reduces meaning of setting Offset in ZDT to switching in DST overlap
Fixes #267

! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/ZonedDateTime.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKZonedDateTime.java


From scolebourne at joda.org  Fri Mar 22 10:56:03 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Fri, 22 Mar 2013 17:56:03 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130322175702.A2E7048349@hg.openjdk.java.net>

Changeset: 334fb273b554
Author:    scolebourne
Date:      2013-03-21 18:47 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/334fb273b554

Javadoc typo

! src/share/classes/java/time/LocalDate.java

Changeset: 7b12a9321cb1
Author:    scolebourne
Date:      2013-03-22 17:54 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7b12a9321cb1

Chrono date classes - Minor fixes, TODOs and Javadoc

! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java


From xueming.shen at oracle.com  Fri Mar 22 13:22:36 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 22 Mar 2013 13:22:36 -0700
Subject: [threeten-dev] Localized GMT offset
Message-ID: <514CBD8C.7020006@oracle.com>

Hi,

I have not tried the "localized" resource for GMT yet (Masayoshi suggested
there are such l10n resources in JDK, but few in CLDR data...), just wonder
if this is the approach we want to go with to be"CLDR compatible" for zone
pattern letters Z[4, 5] and O[1, 4]

http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/

-Sherman

From scolebourne at joda.org  Fri Mar 22 15:09:39 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 22 Mar 2013 22:09:39 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <514CBD8C.7020006@oracle.com>
References: <514CBD8C.7020006@oracle.com>
Message-ID: 

My interpretation of CLDR is that there is a single "localized offset"
format. So I would expect that the new method on the formatter builder
would be appendLocalizedOffset() where the format is derived entirely
from localization data (gmtOffset, gmtZeroOffset and hourFormat).
http://www.unicode.org/reports/tr35/tr35-dates.html#Primary_Zones
http://www.unicode.org/cldr/charts/by_type/patterns.timezones.html#c394dccbd6c2e2d

The GMT/UTC/UT prefixes are ZoneId forms, not directly related to
offset printing and not really relevant here

Stephen


On 22 March 2013 20:22, Xueming Shen  wrote:
> Hi,
>
> I have not tried the "localized" resource for GMT yet (Masayoshi suggested
> there are such l10n resources in JDK, but few in CLDR data...), just wonder
> if this is the approach we want to go with to be"CLDR compatible" for zone
> pattern letters Z[4, 5] and O[1, 4]
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/
>
> -Sherman

From xueming.shen at oracle.com  Fri Mar 22 15:54:29 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 22 Mar 2013 15:54:29 -0700
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: 
References: <514CBD8C.7020006@oracle.com>
	
Message-ID: <514CE125.6000805@oracle.com>

The difficulty here is that those prefixes are not part of the JSR310 offset "zone" name,
but regional zone name. And now we are talking about they are actually part of the
offset formats, when if "localized". This is one the reason I suggested, maybe, just
maybe those prefixes should be part of the offset "zone" names during the conf call.

Anyway to treat it as a single "localizedOffset" form might be an alternative, just
ignore above possible issue. But I don't think currently there is such "localization data"
clearly defined in JDK and exists in JDK/CLDR data. Maybed we can skip this one for
now and only add ZZZZZ for 8?

Sherman

On 03/22/2013 03:09 PM, Stephen Colebourne wrote:
> My interpretation of CLDR is that there is a single "localized offset"
> format. So I would expect that the new method on the formatter builder
> would be appendLocalizedOffset() where the format is derived entirely
> from localization data (gmtOffset, gmtZeroOffset and hourFormat).
> http://www.unicode.org/reports/tr35/tr35-dates.html#Primary_Zones
> http://www.unicode.org/cldr/charts/by_type/patterns.timezones.html#c394dccbd6c2e2d
>
> The GMT/UTC/UT prefixes are ZoneId forms, not directly related to
> offset printing and not really relevant here
>
> Stephen
>
>
> On 22 March 2013 20:22, Xueming Shen  wrote:
>> Hi,
>>
>> I have not tried the "localized" resource for GMT yet (Masayoshi suggested
>> there are such l10n resources in JDK, but few in CLDR data...), just wonder
>> if this is the approach we want to go with to be"CLDR compatible" for zone
>> pattern letters Z[4, 5] and O[1, 4]
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/
>>
>> -Sherman


From scolebourne at joda.org  Fri Mar 22 16:07:46 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 22 Mar 2013 23:07:46 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <514CE125.6000805@oracle.com>
References: <514CBD8C.7020006@oracle.com>
	
	<514CE125.6000805@oracle.com>
Message-ID: 

The prefixes in the CLDR "localized GMT offset" have nothing to do
with the ZoneId and its prefixes. Nothing at all. (Sorry, but I think
you've got confused between what CLDR is specifying and our ZoneId)

The CLDR localized GMT offset is only concerned with outputting a
ZoneOffset, in whatever style the localized data defines (typically a
prefix or suffix).

I can understand how it might be easy to confuse our ZoneId offset
prefixes with CLDR text that looks similar, but the two are very
different. See the two links I sent to see how the output is based
solely on the offset and localization data.

To get the CLDR data (which doesn't look especially complete) would be
an additional task for Oracle I suspect. Especially, as you'd have to
parse a format like "XXX {0}" and substitute the "{0}" for the
hour/minute part.

Leaving this for a later release would be perfectly reasonable option.
Stephen

On 22 March 2013 22:54, Xueming Shen  wrote:
> The difficulty here is that those prefixes are not part of the JSR310 offset
> "zone" name,
> but regional zone name. And now we are talking about they are actually part
> of the
> offset formats, when if "localized". This is one the reason I suggested,
> maybe, just
> maybe those prefixes should be part of the offset "zone" names during the
> conf call.
>
> Anyway to treat it as a single "localizedOffset" form might be an
> alternative, just
> ignore above possible issue. But I don't think currently there is such
> "localization data"
> clearly defined in JDK and exists in JDK/CLDR data. Maybed we can skip this
> one for
> now and only add ZZZZZ for 8?
>
> Sherman
>
>
> On 03/22/2013 03:09 PM, Stephen Colebourne wrote:
>>
>> My interpretation of CLDR is that there is a single "localized offset"
>> format. So I would expect that the new method on the formatter builder
>> would be appendLocalizedOffset() where the format is derived entirely
>> from localization data (gmtOffset, gmtZeroOffset and hourFormat).
>> http://www.unicode.org/reports/tr35/tr35-dates.html#Primary_Zones
>>
>> http://www.unicode.org/cldr/charts/by_type/patterns.timezones.html#c394dccbd6c2e2d
>>
>> The GMT/UTC/UT prefixes are ZoneId forms, not directly related to
>> offset printing and not really relevant here
>>
>> Stephen
>>
>>
>> On 22 March 2013 20:22, Xueming Shen  wrote:
>>>
>>> Hi,
>>>
>>> I have not tried the "localized" resource for GMT yet (Masayoshi
>>> suggested
>>> there are such l10n resources in JDK, but few in CLDR data...), just
>>> wonder
>>> if this is the approach we want to go with to be"CLDR compatible" for
>>> zone
>>> pattern letters Z[4, 5] and O[1, 4]
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/
>>>
>>> -Sherman
>
>

From scolebourne at joda.org  Fri Mar 22 16:47:28 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 22 Mar 2013 23:47:28 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <514CEAB8.3000304@oracle.com>
References: <514CBD8C.7020006@oracle.com>
	
	<514CE125.6000805@oracle.com>
	
	<514CEAB8.3000304@oracle.com>
Message-ID: 

On 22 March 2013 23:35, Xueming Shen  wrote:
> Maybe I did not describe it clearly, my apology. I meant, according to the
> CLDR, gmtFormat is the "localized format" for offset, with the default
> pattern for English as GMT {0}, in which the {0} should be replaced by
> the offset pattern. Which means in "localized" format, English included,
> the format for a offset is "GMT {0}" (or other prefix + offset}, but JSR310
> offset id is {0} only and the format defined  is also the {0} part only.
> Personally I feel it is a little inconsistent. I think j.u.TZ has the
> GMT+hh:mm
> as well for the offset.

This is the difference between the value type (data) and the formatted output.

310:
ZoneOffset - an offset from GMT/UTC
ZoneId - a way of finding some rules

In both cases, the toString() method is simply outputting something
that is (a) appropriate and (b) fully defines the object.

JDK:
TimeZone - a way of finding some rules

Now, it just so happens that there is a TimeZone/ZoneId identifier
that consists of "GMT" followed by the offset. But that identifier
could also be "One hour behind Greenwich" - its just an identifier.

Completely separately, it maps onto a text format.

Because the text format and identifier are similar, it can get
confusing. But there is no inconsistency that I can see.

The "localized GMT offset" format is *only* concerned with ZoneOffset
printing in 310 terms, not ZoneId printing. Thus, these three
ZonedDateTime objects would print the same:
 ZonedDateTime.of(2012, 6, 30, 12, 0, 0, 0, ZoneId.of("+01:00"));
 ZonedDateTime.of(2012, 6, 30, 12, 0, 0, 0, ZoneId.of("GMT+01:00"));
 ZonedDateTime.of(2012, 6, 30, 12, 0, 0, 0, ZoneId.of("UTC+01:00"));
all three would print "GMT+1" (short) or "GMT_01:00" (long) in English.

The ZoneId identifier is completely irrelevant.

> I agreed that we may just need a "appendLocalizedOffset(style)" for this
> and then just leave everything to the localized resource data from the
> installed data...

Yes, the only variable is SHORT vs LONG. Everything else is from the
locale data.

Stephen

From scolebourne at joda.org  Fri Mar 22 17:00:02 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sat, 23 Mar 2013 00:00:02 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130323000054.EC18148366@hg.openjdk.java.net>

Changeset: ff323cc246ce
Author:    scolebourne
Date:      2013-03-22 23:52 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ff323cc246ce

Parsed class should be package scoped

! src/share/classes/java/time/format/Parsed.java

Changeset: 85e20e0d4bcc
Author:    scolebourne
Date:      2013-03-22 23:58 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/85e20e0d4bcc

Make Chrono comparators into static methods

xxxOrder() method naming matches String, Collections and Comparators
timeLineOrder() seemed to best describe why these methods exist

! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/Chronology.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java


From scolebourne at joda.org  Sat Mar 23 05:03:06 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sat, 23 Mar 2013 12:03:06 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets
Message-ID: <20130323120444.293BF48374@hg.openjdk.java.net>

Changeset: 400c0f2d450e
Author:    scolebourne
Date:      2013-03-23 10:20 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/400c0f2d450e

Rename toString(formatter) to format(formatter)

Move to more appropriate location in file for changed method name

! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZonedDateTime.java

Changeset: de87239d50f5
Author:    scolebourne
Date:      2013-03-23 11:08 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/de87239d50f5

Remove tck annotations and organize imports

! test/java/time/tck/java/time/AbstractDateTimeTest.java
! test/java/time/tck/java/time/TCKClock.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
! test/java/time/tck/java/time/TestIsoChronology.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/chrono/TestHijrahChronology.java
! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
! test/java/time/tck/java/time/chrono/TestMinguoChronology.java
! test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java

Changeset: 4de3cd025cb1
Author:    scolebourne
Date:      2013-03-23 11:41 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4de3cd025cb1

Remove implementation annotations and organize imports

! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/TestClock_System.java
! test/java/time/test/java/time/TestDuration.java
! test/java/time/test/java/time/TestLocalDate.java
! test/java/time/test/java/time/TestLocalDateTime.java
! test/java/time/test/java/time/TestLocalTime.java
! test/java/time/test/java/time/TestMonthDay.java
! test/java/time/test/java/time/TestOffsetDateTime.java
! test/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/java/time/test/java/time/TestPeriod.java
! test/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java
! test/java/time/test/java/time/chrono/TestServiceLoader.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/java/time/test/java/time/format/MockIOExceptionAppendable.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
! test/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/java/time/test/java/time/format/TestReducedParser.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/format/TestSettingsParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java
! test/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/time/format/ZoneName.java
! test/java/time/test/java/time/temporal/MockFieldValue.java
! test/java/time/test/java/time/temporal/TestChronoField.java
! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java
! test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
! test/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/java/time/test/java/util/TestFormatter.java

Changeset: b4eac9aa8d78
Author:    scolebourne
Date:      2013-03-23 11:52 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b4eac9aa8d78

Remove duplicate test classes and fix package

! test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
+ test/java/time/tck/java/time/chrono/TestChronoZonedDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java

Changeset: 24d9dc426fc2
Author:    scolebourne
Date:      2013-03-23 11:57 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/24d9dc426fc2

Rename test classes to have standard TCK prefix

! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java < test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java < test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java < test/java/time/tck/java/time/chrono/TestChronoZonedDateTime.java
+ test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
+ test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java

Changeset: 417478b55589
Author:    scolebourne
Date:      2013-03-23 12:01 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/417478b55589

Move test classes to correct package

+ test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
+ test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java


From scolebourne at joda.org  Sat Mar 23 16:51:47 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sat, 23 Mar 2013 23:51:47 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 6 new changesets
Message-ID: <20130323235319.20CEB48381@hg.openjdk.java.net>

Changeset: 2e4430ba7ca3
Author:    scolebourne
Date:      2013-03-23 20:37 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2e4430ba7ca3

Fix broken Javadoc links

! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java

Changeset: 854d5072e350
Author:    scolebourne
Date:      2013-03-23 20:58 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/854d5072e350

Fix Javadoc example

! src/share/classes/java/time/chrono/Chronology.java

Changeset: 62415a6667e3
Author:    scolebourne
Date:      2013-03-23 20:58 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/62415a6667e3

Remove class that should have been deleted with static methods change

- src/share/classes/java/time/temporal/Adjusters.java

Changeset: bd72e70738a5
Author:    scolebourne
Date:      2013-03-23 21:19 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bd72e70738a5

Add Chronology.dateEpochDay()

! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! test/java/time/tck/java/time/chrono/CopticChronology.java
! test/java/time/tck/java/time/chrono/TCKChronology.java

Changeset: 1b2b2b458ca7
Author:    scolebourne
Date:      2013-03-23 21:38 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/1b2b2b458ca7

Avoid relying on year zero in parsing

This allows Hijrah to parse proleptic-month

! src/share/classes/java/time/chrono/Chronology.java

Changeset: 380463e521ca
Author:    scolebourne
Date:      2013-03-23 23:34 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/380463e521ca

Add Javadoc

Also rearrange methods to match superclass order

! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java


From scolebourne at joda.org  Sun Mar 24 17:25:10 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Mon, 25 Mar 2013 00:25:10 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix and test periodUntil
Message-ID: <20130325002532.3714A48395@hg.openjdk.java.net>

Changeset: f985c43b1560
Author:    scolebourne
Date:      2013-03-25 00:24 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f985c43b1560

Fix and test periodUntil

Fixes #290

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDateTime.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
! test/java/time/test/java/time/temporal/TestChronoUnit.java


From xueming.shen at oracle.com  Mon Mar 25 11:51:10 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 25 Mar 2013 11:51:10 -0700
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: 
References: <514CBD8C.7020006@oracle.com>		<514CE125.6000805@oracle.com>		<514CEAB8.3000304@oracle.com>
	
Message-ID: <51509C9E.5070608@oracle.com>

Try again,

http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed 

Does it fit the requirement?

-Sherman

From xueming.shen at oracle.com  Mon Mar 25 14:15:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Mon, 25 Mar 2013 21:15:16 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk:
	Updated	java/util/Calendar/JavatimeTest.java for updated
	ZoneId's	old_short_ids
Message-ID: <20130325211559.5A984483B8@hg.openjdk.java.net>

Changeset: ed4578052769
Author:    sherman
Date:      2013-03-25 14:14 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ed4578052769

Updated java/util/Calendar/JavatimeTest.java for updated ZoneId's old_short_ids

! test/java/util/Calendar/JavatimeTest.java


From xueming.shen at oracle.com  Mon Mar 25 15:59:57 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 25 Mar 2013 15:59:57 -0700
Subject: [threeten-dev] Possible regression?
In-Reply-To: <51505644.7030106@oracle.com>
References: <51505644.7030106@oracle.com>
Message-ID: <5150D6ED.7000303@oracle.com>

Okutsu-san,

Here is the webrev for this "regression".

http://cr.openjdk.java.net/~sherman/jdk8_threeten/zif_null/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html

Thanks,
-Sherman

On 03/25/2013 06:51 AM, Masayoshi Okutsu wrote:
> Hi Sherman,
>
> Does test/closed/java/util/TimeZone/TimeZoneRegression.java pass in your environment?
> Test4159922 fails with an NPE in my repo.
>
> $ /export/disk1/okutsu/jdk8.310/jdk/build/linux-i586/bin/java TimeZoneRegression  Test4159922 -nothrow -verbose
> TimeZoneRegression {
>   Test4159922 {
>     Uncaught exception thrown in test method Test4159922
> java.lang.RuntimeException: Invalid binary time-zone data: TZDB:null, version: 2012i
>     at sun.util.calendar.ZoneInfoFile.getZoneInfo0(ZoneInfoFile.java:130)
>     at sun.util.calendar.ZoneInfoFile.getZoneInfo(ZoneInfoFile.java:102)
>     at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:589)
>     at java.util.TimeZone.getTimeZone(TimeZone.java:566)
>     at java.util.TimeZone.getTimeZone(TimeZone.java:531)
>     at TimeZoneRegression.Test4159922(TimeZoneRegression.java:581)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:487)
>     at IntlTest.run(IntlTest.java:107)
>     at TimeZoneRegression.main(TimeZoneRegression.java:15)
> Caused by: java.lang.NullPointerException
>     at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:276)
>     at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:932)
>     at sun.util.calendar.ZoneInfoFile.getZoneInfo0(ZoneInfoFile.java:112)
>     ... 11 more
>   } FAILED
>
> I'm making a lot of changes to resources area. I might have broke something...
>
> Masayoshi
>


From masayoshi.okutsu at oracle.com  Mon Mar 25 16:04:23 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 26 Mar 2013 08:04:23 +0900
Subject: [threeten-dev] Possible regression?
In-Reply-To: <5150D6ED.7000303@oracle.com>
References: <51505644.7030106@oracle.com> <5150D6ED.7000303@oracle.com>
Message-ID: <5150D7F7.7000103@oracle.com>

Looks good to me.

Masayoshi

On 3/26/2013 7:59 AM, Xueming Shen wrote:
> Okutsu-san,
>
> Here is the webrev for this "regression".
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/zif_null/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html 
>
>
> Thanks,
> -Sherman
>
> On 03/25/2013 06:51 AM, Masayoshi Okutsu wrote:
>> Hi Sherman,
>>
>> Does test/closed/java/util/TimeZone/TimeZoneRegression.java pass in 
>> your environment?
>> Test4159922 fails with an NPE in my repo.
>>
>> $ /export/disk1/okutsu/jdk8.310/jdk/build/linux-i586/bin/java 
>> TimeZoneRegression  Test4159922 -nothrow -verbose
>> TimeZoneRegression {
>>   Test4159922 {
>>     Uncaught exception thrown in test method Test4159922
>> java.lang.RuntimeException: Invalid binary time-zone data: TZDB:null, 
>> version: 2012i
>>     at 
>> sun.util.calendar.ZoneInfoFile.getZoneInfo0(ZoneInfoFile.java:130)
>>     at sun.util.calendar.ZoneInfoFile.getZoneInfo(ZoneInfoFile.java:102)
>>     at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:589)
>>     at java.util.TimeZone.getTimeZone(TimeZone.java:566)
>>     at java.util.TimeZone.getTimeZone(TimeZone.java:531)
>>     at TimeZoneRegression.Test4159922(TimeZoneRegression.java:581)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>     at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>     at java.lang.reflect.Method.invoke(Method.java:487)
>>     at IntlTest.run(IntlTest.java:107)
>>     at TimeZoneRegression.main(TimeZoneRegression.java:15)
>> Caused by: java.lang.NullPointerException
>>     at 
>> java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:276)
>>     at 
>> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:932)
>>     at 
>> sun.util.calendar.ZoneInfoFile.getZoneInfo0(ZoneInfoFile.java:112)
>>     ... 11 more
>>   } FAILED
>>
>> I'm making a lot of changes to resources area. I might have broke 
>> something...
>>
>> Masayoshi
>>
>


From xueming.shen at oracle.com  Mon Mar 25 16:34:14 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Mon, 25 Mar 2013 23:34:14 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk:
	Updated	src/share/classes/sun/util/calendar/ZoneInfoFile.java
	for null	handling
Message-ID: <20130325233435.7409F483BC@hg.openjdk.java.net>

Changeset: 04370b9e326c
Author:    sherman
Date:      2013-03-25 16:33 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/04370b9e326c

Updated src/share/classes/sun/util/calendar/ZoneInfoFile.java for null handling

! src/share/classes/sun/util/calendar/ZoneInfoFile.java


From Roger.Riggs at Oracle.com  Mon Mar 25 18:23:19 2013
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 25 Mar 2013 21:23:19 -0400
Subject: [threeten-dev] WeekBasedYear fields
Message-ID: <5150F887.9020204@Oracle.com>

Please Review:

Issue 64 notes that to correctly support CLDR "Y" and "w", new fields
are needed that operate correctly for Week and Year of WeekBasedYear.
This webrev implements additions fields in WeekFields.

http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/

An additional factory for creating Dates from YearOfWeekBasedYear,
WeekOfWeekBasedYear and DayOfWeek plus a chronology.

Roger


From scolebourne at joda.org  Tue Mar 26 04:17:21 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Mar 2013 11:17:21 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <51509C9E.5070608@oracle.com>
References: <514CBD8C.7020006@oracle.com>
	
	<514CE125.6000805@oracle.com>
	
	<514CEAB8.3000304@oracle.com>
	
	<51509C9E.5070608@oracle.com>
Message-ID: 

I think we're on the right lines here.

I think that TextStyle makes more sense than FormatStyle, but does
CLDR have an opinion?

Some descriptive text about pattern letter O and Z needs adding to
DateTimeFormatter.class Javadoc.

The text in the table should be "localized zone-offset" not
"zone-offset prefixed"

Is there any way to re-use the main offset ID internal class to avoid
the duplicated code?

You've included seconds in the format/parse when CLDR does not. I
think tats the right choice, but its worth noting.

TCKOffsetPrinterParser, TCKDateTimeFormatterBuilder and
TestDateTimeFormatterBuilder should have an invalid pattern for 6 Z.

thanks
Stephen


On 25 March 2013 18:51, Xueming Shen  wrote:
> Try again,
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed
> 
>
> Does it fit the requirement?
>
> -Sherman

From scolebourne at joda.org  Tue Mar 26 05:57:03 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Mar 2013 12:57:03 +0000
Subject: [threeten-dev] [threeten-develop] WeekBasedYear fields
In-Reply-To: <5150F887.9020204@Oracle.com>
References: <5150F887.9020204@Oracle.com>
Message-ID: 

"The rules for addition add the number of week-based-years to the
existing value for the week-based-year field. If the resulting
week-based-year only has 52 weeks, then the date will be in week 1 of
the following week-based-year."

This isn't the right behaviour (or is a bad description). Addition
should retain the value of the week and day-of-week. The special case
is if the base week has the value 53 but the result of the calculation
is a week-based-year which has only 52 weeks. In that case, the result
would indeed be in the first week of the following year.

References to "yearOfWeekBasedYear " should be just "weekBasedYear".
Notably, this affects the public method name.

Comment text "This unit is an immutable and thread-safe singleton."
should be "This field is an immutable and thread-safe singleton."

The comment text "week based year" should be dash linked  "week-based-year".

The range of week-based-year is not necessarily the same as the range
of year. It needs to be confirmed.

Comment text "This represents concept of the count" should be This
represents the concept of the count.

My skim of the algorithms looks OK

thanks
Stephen


On 26 March 2013 01:23, Roger Riggs  wrote:
> Please Review:
>
> Issue 64 notes that to correctly support CLDR "Y" and "w", new fields
> are needed that operate correctly for Week and Year of WeekBasedYear.
> This webrev implements additions fields in WeekFields.
>
> http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/
>
> An additional factory for creating Dates from YearOfWeekBasedYear,
> WeekOfWeekBasedYear and DayOfWeek plus a chronology.
>
> Roger
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>

From xueming.shen at oracle.com  Tue Mar 26 11:08:57 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 26 Mar 2013 11:08:57 -0700
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: 
References: <514CBD8C.7020006@oracle.com>		<514CE125.6000805@oracle.com>		<514CEAB8.3000304@oracle.com>		<51509C9E.5070608@oracle.com>
	
Message-ID: <5151E439.5050806@oracle.com>

On 03/26/2013 04:17 AM, Stephen Colebourne wrote:
> I think we're on the right lines here.
>
> I think that TextStyle makes more sense than FormatStyle, but does
> CLDR have an opinion?

I picked FormatStyle mostly because (1) the "appendLocalized()" uses FormatStyle
and (2) FormatStyle has a "long" instead of the "full" in text style. I don't have a
strong feeling about this one, either works fine with me.

> Some descriptive text about pattern letter O and Z needs adding to
> DateTimeFormatter.class Javadoc.

Added. Those got lost during merging...

> The text in the table should be "localized zone-offset" not
> "zone-offset prefixed"

Fixed.

> Is there any way to re-use the main offset ID internal class to avoid
> the duplicated code?

I might be possible, but it appears to make the implementation a little messy, so
I go with the "clean" and separate one.

> You've included seconds in the format/parse when CLDR does not. I
> think tats the right choice, but its worth noting.
>

it appears CLDR also specifies the "optional second" in both long and short forms, just
not listed in example.

*Localized GMT format:*A constant, specific offset from GMT (or UTC), which may be in a translated form. There are two styles for this. The first is used when there is an explicit non-zero offset from GMT; this style is specified by the  element and  element. The long format always uses 2-digit hours field and minutes field, with optional 2-digit seconds field. The short format is intended for the shortest representation and uses hour fields without leading zero, with optional 2-digit minutes and seconds fields. The digits used for hours, minutes and seconds fields in this format are the locale's default decimal digits:

    * "GMT+03:30" (long)
    * "GMT+3:30" (short)
    * "UTC-03.00" (long)
    * "UTC-3" (short)
    * "????????+03:30" (long)



> TCKOffsetPrinterParser, TCKDateTimeFormatterBuilder and
> TestDateTimeFormatterBuilder should have an invalid pattern for 6 Z.
>
updated.

Latest webrev
http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/

thanks,
-Sherman



From roger.riggs at oracle.com  Tue Mar 26 11:50:29 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 26 Mar 2013 14:50:29 -0400
Subject: [threeten-dev] Cleanup of raw types
Message-ID: <5151EDF5.8030903@oracle.com>

Hi,

Please review this cleanup of java flagging of raw types and redundant 
casts.

http://cr.openjdk.java.net/~rriggs/webrev-raw-types-163/

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


From roger.riggs at oracle.com  Tue Mar 26 12:07:18 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Tue, 26 Mar 2013 19:07:18 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets
Message-ID: <20130326190829.AE1F1483E7@hg.openjdk.java.net>

Changeset: fa31bb71cd13
Author:    rriggs
Date:      2013-03-25 13:53 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fa31bb71cd13

Correct start of SHOWA

! test/java/time/tck/java/time/chrono/TestJapaneseChronology.java

Changeset: df9fd3c2a034
Author:    rriggs
Date:      2013-03-25 13:54 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/df9fd3c2a034

correct informative value in exception

! src/share/classes/java/time/temporal/TemporalAccessor.java

Changeset: cdb65552ad0e
Author:    rriggs
Date:      2013-03-26 13:13 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cdb65552ad0e

#64 Implement YearOfWeekOfYear and WeekOfWeekOfYear for "Y" and "w".
In WeekFields, added localized fields for Week and Year of WeekBasedYear.

! src/share/classes/java/time/temporal/WeekFields.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java

Changeset: 401e834a0ce8
Author:    rriggs
Date:      2013-03-26 14:55 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/401e834a0ce8

minor javadoc cleanup

! src/share/classes/java/time/temporal/WeekFields.java

Changeset: 3c802fc2d1df
Author:    rriggs
Date:      2013-03-26 15:06 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3c802fc2d1df

Merge

- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java


From scolebourne at joda.org  Tue Mar 26 12:10:28 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Mar 2013 19:10:28 +0000
Subject: [threeten-dev] Cleanup of raw types
In-Reply-To: <5151EDF5.8030903@oracle.com>
References: <5151EDF5.8030903@oracle.com>
Message-ID: 

Looks good to me
Stephen

On 26 March 2013 18:50, roger riggs  wrote:
> Hi,
>
> Please review this cleanup of java flagging of raw types and redundant
> casts.
>
> http://cr.openjdk.java.net/~rriggs/webrev-raw-types-163/
>
> --
> Thanks, Roger
>
> Oracle Java Platform Group
>
> Green Oracle  Oracle is committed to
> developing practices and products that help protect the environment
>

From scolebourne at joda.org  Tue Mar 26 12:20:28 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Mar 2013 19:20:28 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <5151E439.5050806@oracle.com>
References: <514CBD8C.7020006@oracle.com>
	
	<514CE125.6000805@oracle.com>
	
	<514CEAB8.3000304@oracle.com>
	
	<51509C9E.5070608@oracle.com>
	
	<5151E439.5050806@oracle.com>
Message-ID: 

On 26 March 2013 18:08, Xueming Shen  wrote:
>> I think we're on the right lines here.
>>
>> I think that TextStyle makes more sense than FormatStyle, but does
>> CLDR have an opinion?
>
> I picked FormatStyle mostly because (1) the "appendLocalized()" uses
> FormatStyle
> and (2) FormatStyle has a "long" instead of the "full" in text style. I
> don't have a
> strong feeling about this one, either works fine with me.

I think that TextStyle is better, as I could foresee a future CLDR
change where there are different formats for standalone offsets.

I also think that you shouldn't refer to prefixes, as CLDR allows the
localized format to be "{0} GMT".
Otherwise looks good.
Stephen

From roger.riggs at oracle.com  Tue Mar 26 12:50:43 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Tue, 26 Mar 2013 19:50:43 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130326195116.1BDB2483ED@hg.openjdk.java.net>

Changeset: bf46149114e4
Author:    rriggs
Date:      2013-03-26 15:39 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bf46149114e4

#163  Address [rawtypes] errors from javac
Added  to Chronology methods returning ChronoLocalDate and ChronoLocalDateTime.
Removed some redundant casts the compiler complained about.

! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java

Changeset: c1aaa0bb2518
Author:    rriggs
Date:      2013-03-26 15:50 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c1aaa0bb2518

Merge

! src/share/classes/java/time/temporal/WeekFields.java


From xueming.shen at oracle.com  Tue Mar 26 13:00:29 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 26 Mar 2013 13:00:29 -0700
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: 
References: <514CBD8C.7020006@oracle.com>		<514CE125.6000805@oracle.com>		<514CEAB8.3000304@oracle.com>		<51509C9E.5070608@oracle.com>		<5151E439.5050806@oracle.com>
	
Message-ID: <5151FE5D.2070008@oracle.com>

Webrev has bee updated as suggested.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/

thanks,
-Sherman

On 03/26/2013 12:20 PM, Stephen Colebourne wrote:
> On 26 March 2013 18:08, Xueming Shen  wrote:
>>> I think we're on the right lines here.
>>>
>>> I think that TextStyle makes more sense than FormatStyle, but does
>>> CLDR have an opinion?
>> I picked FormatStyle mostly because (1) the "appendLocalized()" uses
>> FormatStyle
>> and (2) FormatStyle has a "long" instead of the "full" in text style. I
>> don't have a
>> strong feeling about this one, either works fine with me.
> I think that TextStyle is better, as I could foresee a future CLDR
> change where there are different formats for standalone offsets.
>
> I also think that you shouldn't refer to prefixes, as CLDR allows the
> localized format to be "{0} GMT".
> Otherwise looks good.
> Stephen


From scolebourne at joda.org  Tue Mar 26 13:07:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 26 Mar 2013 20:07:26 +0000
Subject: [threeten-dev] Localized GMT offset
In-Reply-To: <5151FE5D.2070008@oracle.com>
References: <514CBD8C.7020006@oracle.com>
	
	<514CE125.6000805@oracle.com>
	
	<514CEAB8.3000304@oracle.com>
	
	<51509C9E.5070608@oracle.com>
	
	<5151E439.5050806@oracle.com>
	
	<5151FE5D.2070008@oracle.com>
Message-ID: 

Looks good to me
Stephen

On 26 March 2013 20:00, Xueming Shen  wrote:
> Webrev has bee updated as suggested.
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/
>
> thanks,
> -Sherman
>
>
> On 03/26/2013 12:20 PM, Stephen Colebourne wrote:
>>
>> On 26 March 2013 18:08, Xueming Shen  wrote:
>>>>
>>>> I think we're on the right lines here.
>>>>
>>>> I think that TextStyle makes more sense than FormatStyle, but does
>>>> CLDR have an opinion?
>>>
>>> I picked FormatStyle mostly because (1) the "appendLocalized()" uses
>>> FormatStyle
>>> and (2) FormatStyle has a "long" instead of the "full" in text style. I
>>> don't have a
>>> strong feeling about this one, either works fine with me.
>>
>> I think that TextStyle is better, as I could foresee a future CLDR
>> change where there are different formats for standalone offsets.
>>
>> I also think that you shouldn't refer to prefixes, as CLDR allows the
>> localized format to be "{0} GMT".
>> Otherwise looks good.
>> Stephen
>
>

From xueming.shen at oracle.com  Tue Mar 26 13:37:11 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 26 Mar 2013 20:37:11 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Added format support for
	"localized gmt	offset"
Message-ID: <20130326203732.68E80483EE@hg.openjdk.java.net>

Changeset: 3f0cc323b907
Author:    sherman
Date:      2013-03-26 13:36 -0700
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/3f0cc323b907

Added format support for "localized gmt offset"

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java


From scolebourne at joda.org  Wed Mar 27 08:45:55 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Wed, 27 Mar 2013 15:45:55 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 3 new changesets
Message-ID: <20130327154703.9C2544841A@hg.openjdk.java.net>

Changeset: 75dcc9912599
Author:    scolebourne
Date:      2013-03-26 18:08 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/75dcc9912599

Better documentation for stand-alone text styles

! src/share/classes/java/time/format/TextStyle.java

Changeset: 6808dacc53ab
Author:    scolebourne
Date:      2013-03-27 15:43 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/6808dacc53ab

Additional periodUntil tests

! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java

Changeset: 49ff00fae5d8
Author:    scolebourne
Date:      2013-03-27 15:44 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/49ff00fae5d8

Merge



From scolebourne at joda.org  Thu Mar 28 02:17:12 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Thu, 28 Mar 2013 09:17:12 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130328091901.E54C748459@hg.openjdk.java.net>

Changeset: b66dbfa1d4b9
Author:    scolebourne
Date:      2013-03-27 22:06 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b66dbfa1d4b9

Fix test case data provider reference

! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java

Changeset: e404506a2284
Author:    scolebourne
Date:      2013-03-27 22:08 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e404506a2284

Refactor style provider

Remove DateTimeFormatStyleProvider and inline into builder
Class was not provding value over inlined methods

- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java


From roger.riggs at oracle.com  Thu Mar 28 12:49:51 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 28 Mar 2013 15:49:51 -0400
Subject: [threeten-dev] Review or DateTimeFormatter 'Y' and 'w'
Message-ID: <51549EDF.4050705@oracle.com>

Please review updates to DateTimeFormatter* to implement
CLDR behavior for pattern letters 'Y' and 'w'.

Hooked the WeekFields for WeekBasedYear to the corresponding pattern 
letters.
Added tests, updated the javadoc/spec.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/

Thanks, Roger


From scolebourne at joda.org  Fri Mar 29 05:52:48 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 29 Mar 2013 12:52:48 +0000
Subject: [threeten-dev] [threeten-develop] Review or DateTimeFormatter
	'Y' and 'w'
In-Reply-To: <51549EDF.4050705@oracle.com>
References: <51549EDF.4050705@oracle.com>
Message-ID: 

DateTimeFormatterBuilder - the comment lines beneath the map of fields
(line 1662) should be updated to say what Y does
"310 - w, W and Y are localized forms matching LDML"

DateTimeFormatterBuilder - The comments are wrong for u, y and Y for 4
letters, as the code uses EXCEEDS_PAD, not NORMAL
shoud be "yyyy    4      appendValue(ChronoField.YEAR_OF_ERA, 4, 19,
SignStyle.EXCEEDS_PAD);"

DateTimeFormatterBuilder - The toString() in the printer-parser now
has the same text for e and c. I didn't have a problem with the old
style, although the new style is probably clearer.

TCKWeekFields, line 492 has incorrect indentation

These are all minor things, so I'm happy for direct push without
further review if you want.
thanks
Stephen



On 28 March 2013 19:49, roger riggs  wrote:
> Please review updates to DateTimeFormatter* to implement
> CLDR behavior for pattern letters 'Y' and 'w'.
>
> Hooked the WeekFields for WeekBasedYear to the corresponding pattern
> letters.
> Added tests, updated the javadoc/spec.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/
>
> Thanks, Roger
>
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>

From roger.riggs at oracle.com  Fri Mar 29 06:58:22 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 29 Mar 2013 13:58:22 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets
Message-ID: <20130329135918.29223484BC@hg.openjdk.java.net>

Changeset: f5c2a5c95092
Author:    rriggs
Date:      2013-03-29 09:52 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f5c2a5c95092

Implement 'Y' and 'w' to hook DateTimeFormatter to WeekFields for WeekBasedYear.
Add test for formatting and parsing.

Related to:
#64 Decide on formatting pattern letters
#186 WeekFields.weekOfYear at end of year/month

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java

Changeset: 8ad0149a793d
Author:    rriggs
Date:      2013-03-29 09:57 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8ad0149a793d

Merge

- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java


From roger.riggs at oracle.com  Sat Mar 30 11:23:28 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Sat, 30 Mar 2013 18:23:28 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Updated test to validate
	match between	GregorianCalendar and LocalDate with WeekFields
Message-ID: <20130330182407.761C5484DB@hg.openjdk.java.net>

Changeset: 65ef607593b0
Author:    rriggs
Date:      2013-03-30 14:23 -0400
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/65ef607593b0

Updated test to validate match between GregorianCalendar and LocalDate with WeekFields

! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java


From scolebourne at joda.org  Sat Mar 30 16:50:08 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sat, 30 Mar 2013 23:50:08 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: 7 new changesets
Message-ID: <20130330235141.4B00A484DE@hg.openjdk.java.net>

Changeset: 59e04ccae26f
Author:    scolebourne
Date:      2013-03-29 22:46 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/59e04ccae26f

Fix Javadoc bug

! src/share/classes/java/time/zone/ZoneOffsetTransition.java

Changeset: 280bb6f14495
Author:    scolebourne
Date:      2013-03-29 23:46 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/280bb6f14495

Document that LDT/ZoneId are more important than offset in ZDT

! src/share/classes/java/time/ZonedDateTime.java

Changeset: e57f716427c4
Author:    scolebourne
Date:      2013-03-30 19:32 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e57f716427c4

Remove unused code

! src/share/classes/java/time/format/DateTimeFormatter.java

Changeset: 4c195490d2dd
Author:    scolebourne
Date:      2013-03-30 23:36 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4c195490d2dd

Fix Javadoc bug

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java

Changeset: 999f123d8687
Author:    scolebourne
Date:      2013-03-30 23:38 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/999f123d8687

Make better use of zone/chronology

Throw exceptions when used incorrectly
Otherwise use them as best as possible

! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java

Changeset: 569031ace043
Author:    scolebourne
Date:      2013-03-30 23:39 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/569031ace043

Define impact of formatter zone/chronology during parsing

Adjusting result based on the zone/chronology would be complex and error prone
Better to leave zone/chronology during parse as defaults
See #268

! src/share/classes/java/time/format/DateTimeFormatter.java

Changeset: 233c0c38543c
Author:    scolebourne
Date:      2013-03-30 23:49 +0000
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/233c0c38543c

Merge



From scolebourne at joda.org  Sat Mar 30 18:27:03 2013
From: scolebourne at joda.org (scolebourne at joda.org)
Date: Sun, 31 Mar 2013 01:27:03 +0000
Subject: [threeten-dev] hg: threeten/threeten/jdk: Add tests for whether
	generics works
Message-ID: <20130331012730.13DB8484E0@hg.openjdk.java.net>

Changeset: 47ffbd852f88
Author:    scolebourne
Date:      2013-03-31 02:26 +0100
URL:       http://hg.openjdk.java.net/threeten/threeten/jdk/rev/47ffbd852f88

Add tests for whether generics works

! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
+ test/java/time/test/java/time/chrono/TestChronoLocalDate.java