You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(64) |
May
(62) |
Jun
(33) |
Jul
(61) |
Aug
(75) |
Sep
(61) |
Oct
(124) |
Nov
(18) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(42) |
Feb
(19) |
Mar
(12) |
Apr
(34) |
May
(10) |
Jun
(4) |
Jul
(23) |
Aug
(24) |
Sep
(12) |
Oct
(48) |
Nov
(36) |
Dec
(48) |
2004 |
Jan
(26) |
Feb
(19) |
Mar
(21) |
Apr
(14) |
May
(9) |
Jun
(19) |
Jul
(44) |
Aug
(46) |
Sep
(27) |
Oct
(23) |
Nov
(30) |
Dec
(46) |
2005 |
Jan
(17) |
Feb
(36) |
Mar
(31) |
Apr
(53) |
May
(27) |
Jun
(20) |
Jul
(17) |
Aug
(48) |
Sep
(88) |
Oct
(55) |
Nov
(20) |
Dec
(50) |
2006 |
Jan
(36) |
Feb
(59) |
Mar
(39) |
Apr
(14) |
May
(19) |
Jun
(26) |
Jul
(54) |
Aug
(50) |
Sep
(19) |
Oct
(19) |
Nov
(37) |
Dec
(25) |
2007 |
Jan
(31) |
Feb
(33) |
Mar
(16) |
Apr
(9) |
May
(20) |
Jun
(30) |
Jul
(6) |
Aug
(48) |
Sep
(8) |
Oct
(20) |
Nov
(15) |
Dec
(21) |
2008 |
Jan
(49) |
Feb
(12) |
Mar
(31) |
Apr
(10) |
May
(25) |
Jun
(23) |
Jul
(22) |
Aug
(15) |
Sep
(27) |
Oct
(27) |
Nov
(28) |
Dec
(20) |
2009 |
Jan
(14) |
Feb
(7) |
Mar
(34) |
Apr
(10) |
May
(14) |
Jun
(2) |
Jul
(25) |
Aug
(8) |
Sep
(14) |
Oct
(17) |
Nov
(7) |
Dec
(15) |
2010 |
Jan
(4) |
Feb
(35) |
Mar
(21) |
Apr
(31) |
May
(1) |
Jun
(13) |
Jul
(28) |
Aug
(14) |
Sep
(19) |
Oct
(6) |
Nov
(15) |
Dec
(15) |
2011 |
Jan
(29) |
Feb
(12) |
Mar
(8) |
Apr
(21) |
May
(40) |
Jun
(12) |
Jul
(24) |
Aug
(19) |
Sep
(29) |
Oct
(21) |
Nov
(18) |
Dec
(30) |
2012 |
Jan
(10) |
Feb
(18) |
Mar
(19) |
Apr
(16) |
May
(15) |
Jun
(12) |
Jul
(9) |
Aug
(3) |
Sep
(16) |
Oct
(11) |
Nov
(8) |
Dec
|
2013 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
(7) |
Jun
(8) |
Jul
(20) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stephen C. <sco...@jo...> - 2013-09-05 10:15:06
|
As I indicated in the previous response, the Chronology class works correctly with serialization using readObject() to return a correctly instantiated singleton. If EJB doesn't work properly with serialization, then there isn't a lot I can do. ie. I won't be working on it. If you investigate it and discover why readObject() isn't being called, or some other patch, I'll be happy to take a look. Stephen On 5 September 2013 10:16, Matthias Schäfer <mat...@fu...> wrote: > Hello guys! > > I stumbled over an existing issue that LocalDateTime can't traverse EJB > calls (some information is lost). > I found the following thread on the mailing list: > http://joda-interest.219941.n2.nabble.com/LocalDateTime-not-able-to-traverse-EJB-calls-td5589383.html, > which is the same problem (but already 3 years old). > I'm using Joda Time 2.3 and the issue still exists. Are there any plans to > fix it? Or can somebody point me in the correct direction to fix it? It's > not (really) feasible for me to replace all LocalDateTime instances with > DateTime instances (and I don't know the consequences of doing so). > > Currently LocalDateTime looses the following information: > > Inside iChronology (an instance of org.joda.time.chrono.ISOChronology) : > > iDayOfWeek > iDayOfMonth > iDayOfYear > iWeekOfWeekyear > > Unfortunately this will render the LocalDateTime instance useless as many > methods will throw a NullPointerException. > > One (possible) workaround I've discovered would be the following: > > public LocalDateTime getSomeDate() { > > return new LocalDateTime(someDate.getLocalMillis()); > > } > > So even if someDate is "corrupted", it will return a "properly initialized" > date. But this is far away from a good solution.. > > > Any help is very much appreciated > > Kind Regards > > Matthias > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Matthias S. <mat...@fu...> - 2013-09-05 09:40:43
|
Hello guys! I stumbled over an existing issue that LocalDateTime can't traverse EJB calls (some information is lost). I found the following thread on the mailing list: http://joda-interest.219941.n2.nabble.com/LocalDateTime-not-able-to-traverse-EJB-calls-td5589383.html, which is the same problem (but already 3 years old). I'm using Joda Time 2.3 and the issue still exists. Are there any plans to fix it? Or can somebody point me in the correct direction to fix it? It's not (really) feasible for me to replace all LocalDateTime instances with DateTime instances (and I don't know the consequences of doing so). Currently LocalDateTime looses the following information: Inside iChronology (an instance of org.joda.time.chrono.ISOChronology) : - iDayOfWeek - iDayOfMonth - iDayOfYear - iWeekOfWeekyear Unfortunately this will render the LocalDateTime instance useless as many methods will throw a NullPointerException. One (possible) workaround I've discovered would be the following: public LocalDateTime getSomeDate() { return new LocalDateTime(someDate.getLocalMillis()); } So even if someDate is "corrupted", it will return a "properly initialized" date. But this is far away from a good solution.. Any help is very much appreciated Kind Regards Matthias |
From: Jörg S. <Joe...@sc...> - 2013-08-27 10:11:31
|
Hello, we tried to upgrade from joda-time 2.1 to 2.3, but we get now NPEs, because our DateTimeFormatter instance suddenly has no longer a printer: ================= %< ================= DateTimeFormatter FORMATTER = new DateTimeFormatterBuilder() .appendMonthOfYear(2) .appendOptional( new DateTimeFormatterBuilder().appendLiteral('-').toParser()) .appendDayOfMonth(2) .toFormatter(); assertNotNull(FORMATTER.getPrinter()); ================= %< ================= A test with version 2.2 reveals the same problem. Reverting to 2.1 let our unit tests pass. I could not see anything directly related to this new behavior in the release notes, so I assume a regression or was there an intentional change? - Jörg |
From: Stephen C. <sco...@jo...> - 2013-08-25 20:28:46
|
I previously used to host multiple versions of the Javadoc. I've now settled on only having the latest online, because it greatly simplifies the task of building the website. Stephen On 25 August 2013 20:03, Arend v. Reinersdorff <ar...@ar...> wrote: > I see. > > I suppose "currently" means the Javadocs will divert from the 2.3 release > sooner or later? > > > > > On Sun, Aug 25, 2013 at 8:14 PM, Stephen Colebourne <sco...@jo...> > wrote: >> >> Maven tags the Javadoc as being 2.4 SNAPSHOT, but it is currently the >> same as 2.3 >> Stephen >> >> On 25 August 2013 12:38, Arend v. Reinersdorff <ar...@ar...> wrote: >> > Hi, >> > >> > I found the Javadocs for Joda-Time 2.2 and 2.4-SNAPSHOT online. But not >> > for >> > the current release 2.3. Are they available yet? >> > >> > Regards, >> > Arend >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Introducing Performance Central, a new site from SourceForge and >> > AppDynamics. Performance Central is your source for news, insights, >> > analysis and resources for efficient Application Performance Management. >> > Visit us today! >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Joda-interest mailing list >> > Jod...@li... >> > https://lists.sourceforge.net/lists/listinfo/joda-interest >> > >> >> >> ------------------------------------------------------------------------------ >> Introducing Performance Central, a new site from SourceForge and >> AppDynamics. Performance Central is your source for news, insights, >> analysis and resources for efficient Application Performance Management. >> Visit us today! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Arend v. R. <ar...@ar...> - 2013-08-25 19:03:41
|
I see. I suppose "currently" means the Javadocs will divert from the 2.3 release sooner or later? On Sun, Aug 25, 2013 at 8:14 PM, Stephen Colebourne <sco...@jo...>wrote: > Maven tags the Javadoc as being 2.4 SNAPSHOT, but it is currently the > same as 2.3 > Stephen > > On 25 August 2013 12:38, Arend v. Reinersdorff <ar...@ar...> wrote: > > Hi, > > > > I found the Javadocs for Joda-Time 2.2 and 2.4-SNAPSHOT online. But not > for > > the current release 2.3. Are they available yet? > > > > Regards, > > Arend > > > > > > > ------------------------------------------------------------------------------ > > Introducing Performance Central, a new site from SourceForge and > > AppDynamics. Performance Central is your source for news, insights, > > analysis and resources for efficient Application Performance Management. > > Visit us today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > _______________________________________________ > > Joda-interest mailing list > > Jod...@li... > > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Stephen C. <sco...@jo...> - 2013-08-25 18:15:10
|
Maven tags the Javadoc as being 2.4 SNAPSHOT, but it is currently the same as 2.3 Stephen On 25 August 2013 12:38, Arend v. Reinersdorff <ar...@ar...> wrote: > Hi, > > I found the Javadocs for Joda-Time 2.2 and 2.4-SNAPSHOT online. But not for > the current release 2.3. Are they available yet? > > Regards, > Arend > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Arend v. R. <ar...@ar...> - 2013-08-25 11:51:27
|
Hi, I found the Javadocs for Joda-Time 2.2 and 2.4-SNAPSHOT online. But not for the current release 2.3. Are they available yet? Regards, Arend |
From: Stephen C. <sco...@jo...> - 2013-08-24 07:14:23
|
The upgrade notes you linked to specify that time zone data 2013d is used. You need to figure out if the Israel change is in there or not. Its probably quickest just to upgrade the jar file and write a unit test. If you need to update the time-zone data manually, the maven build will do so. http://www.joda.org/joda-time/tz_update.html Stephen On 24 August 2013 06:21, Peddi, Radhika (Radhika) <rp...@av...> wrote: > Hi, > > > > This is Radhika from Avaya. > > > > Currently we are using joda-time-1.5.2.jar file. This year Israel daylight > saving is extended in October. Due to this we require a new joda-time.jar > file to fix this issue. Is new Joda-time-2.3 jar covered this? I have gone > through http://www.joda.org/joda-time/upgradeto230.html. However I have not > find any relevant information for Israel daylight saving change. > > > > I found that ant build is removed from 2.2. We are using ant build till now. > So is there any way for us to build joda jar file after replacing the new > time zones? > > Thanks & Regards, > > Radhika Peddi|Avaya India Pvt. Ltd.| > Wing 'A', Level -5, Tower-11, Cybercity, Magarpatta City, Hadapsar | Pune, > 411028|India > > Voice +91 20 4101 8311| Email: rp...@av... > > [ Please consider the environment before printing this email ] > > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Peddi, R. (Radhika) <rp...@av...> - 2013-08-24 05:21:36
|
Hi, This is Radhika from Avaya. Currently we are using joda-time-1.5.2.jar file. This year Israel daylight saving is extended in October. Due to this we require a new joda-time.jar file to fix this issue. Is new Joda-time-2.3 jar covered this? I have gone through http://www.joda.org/joda-time/upgradeto230.html. However I have not find any relevant information for Israel daylight saving change. I found that ant build is removed from 2.2. We are using ant build till now. So is there any way for us to build joda jar file after replacing the new time zones? Thanks & Regards, Radhika Peddi|Avaya India Pvt. Ltd.| Wing 'A', Level -5, Tower-11, Cybercity, Magarpatta City, Hadapsar | Pune, 411028|India Voice +91 20 4101 8311| Email: rpeddi<mailto:rp...@av...>@avaya.com [ Please consider the environment before printing this email ] |
From: Stephen C. <sco...@jo...> - 2013-08-22 10:48:27
|
The upgrade notes you linked to specify that time zone data 2013d is used. You need to figure out if the Israel change is in there or not. Its probably quickest just to upgrade the jar file and write a unit test. If you need to update the time-zone data manually, the maven build will do so. http://www.joda.org/joda-time/tz_update.html Stephen On 22 August 2013 11:00, Radhika <rp...@av...> wrote: > Hi, > > This is Radhika from Avaya. > > Currently we are using joda-time-1.5.2.jar file. This year Israel daylight > saving is extended in October. Due to this we require a new joda-time.jar > file to fix this issue. Is new Joda-time-2.3 jar covered this? I have gone > through http://www.joda.org/joda-time/upgradeto230.html. However I have not > find any relevant information for Israel daylight saving change. > > I found that ant build is removed from 2.2. We are using ant build till now. > So is there any way for us to build joda jar file after replacing the new time > zones? > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: Radhika <rp...@av...> - 2013-08-22 10:05:15
|
Hi, This is Radhika from Avaya. Currently we are using joda-time-1.5.2.jar file. This year Israel daylight saving is extended in October. Due to this we require a new joda-time.jar file to fix this issue. Is new Joda-time-2.3 jar covered this? I have gone through http://www.joda.org/joda-time/upgradeto230.html. However I have not find any relevant information for Israel daylight saving change. I found that ant build is removed from 2.2. We are using ant build till now. So is there any way for us to build joda jar file after replacing the new time zones? |
From: Stephen C. <sco...@jo...> - 2013-08-16 16:13:59
|
I suspect that few if any people have actually tried to implement their own fields. In theory, you just need your own DurationFieldType and DurationField. There is no need for your own Chronlogy. The DurationField does the actual work of calculation. You can probably do all the calculations simply by calling on to the month field of the chronology you are given (multiplying everything by 3). Stephen On 15 August 2013 11:44, Przemysław Sokół <fal...@gm...> wrote: > I'm trying to supply my application with my own DurationFieldType - > QuarterDurationFieldType - that will represent a quarter of a year. In the > Javadoc I've found that: > > "If required, you can create your own field, for example a quarters. You > must create a subclass of DurationFieldType that defines the field type. > This class returns the actual calculation engine from getField(Chronology)." > source: > http://joda-time.sourceforge.net/apidocs/org/joda/time/DurationFieldType.html > > I've done so, but I'm a little bit confused of how to implement it right. > Should I implement my own Chronology or just a DurationField (for the sake > of getField's returned value)? Also, I'm not quite sure where and how should > I specify how long the single quarter lasts. Should it be rather calculated > using milliseconds or derived from year and month data somehow? > > Thank you for help in advance. > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Przemysław S. <fal...@gm...> - 2013-08-15 10:44:37
|
I'm trying to supply my application with my own DurationFieldType - QuarterDurationFieldType - that will represent a quarter of a year. In the Javadoc I've found that: "If required, you can create your own field, for example a quarters. You must create a subclass of DurationFieldType that defines the field type. This class returns the actual calculation engine from getField(Chronology)." source: http://joda-time.sourceforge.net/apidocs/org/joda/time/DurationFieldType.html I've done so, but I'm a little bit confused of how to implement it right. Should I implement my own Chronology or just a DurationField (for the sake of getField's returned value)? Also, I'm not quite sure where and how should I specify how long the single quarter lasts. Should it be rather calculated using milliseconds or derived from year and month data somehow? Thank you for help in advance. |
From: Stephen C. <sco...@jo...> - 2013-07-27 07:17:09
|
This is a well known warning in m2e. I believe that the latest versions don't have it, or a have a way to turn it off. There is certainly the ability to right click on the warning and turn it off. Basicially it means that m2e doesn't know what the exec plugin is doing. Stephen On 26 July 2013 21:22, Caleb Tillman <cal...@gm...> wrote: > Hi > > I am trying to familiarize myself with the joda-time code base and am > running into a build problem. Eclipse is giving me the following error in > the pom.xml file: > >> Plugin execution not covered by lifecycle configuration: >> org.codehaus.mojo:exec-maven-plugin:1.2.1:java (execution: default, phase: >> compile) > > > and the log file is giving: > >> 2013-07-26 10:42:17,305 [ModalContext] WARN >> o.e.m.i.discovery.MavenDiscovery - CatalogItem >> org.eclipse.m2e.discovery.lifecyclemapping.m2e-subclipse does not contain >> lifecycle mapping metadata > > > Are any of you using Eclipse/STS? If so, have you ran into this problem? > > Thank you for your time. > > Caleb Tillman > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Caleb T. <cal...@gm...> - 2013-07-26 20:22:12
|
Hi I am trying to familiarize myself with the joda-time code base and am running into a build problem. Eclipse is giving me the following error in the pom.xml file: Plugin execution not covered by lifecycle configuration: > org.codehaus.mojo:exec-maven-plugin:1.2.1:java (execution: default, phase: > compile) and the log file is giving: 2013-07-26 10:42:17,305 [ModalContext] WARN > o.e.m.i.discovery.MavenDiscovery - CatalogItem > org.eclipse.m2e.discovery.lifecyclemapping.m2e-subclipse does not contain > lifecycle mapping metadata Are any of you using Eclipse/STS? If so, have you ran into this problem? Thank you for your time. Caleb Tillman |
From: roger r. <rog...@or...> - 2013-07-12 13:50:44
|
Hi, I read the code that the assignment is of the value returned by "toFormatter()". In this "fluent" style each of the intermediates is an instance on which the next method is executed. The assignment is not done until after 'toFormatter()' completes. Roger On 7/12/2013 9:37 AM, Nils Kilden-Pedersen wrote: > On Fri, Jul 12, 2013 at 8:05 AM, roger riggs <rog...@or... > <mailto:rog...@or...>> wrote: > > I don't see a functional issue with this; > > > You need to study the Java memory model then. > > The DateTimeFormatter created by each thread will have exactly the > same > behavior and semantics. > The caller gets an instance that preforms as required. > > > No, that's not guaranteed with the current code. > > > dt is just a cache to improve performance. > > The only condition at risk is the two calls to dateTime() do not > return > the same (==) instance. > > > No, the risk is that a second concurrent thread gets a reference to > the not yet completed object, which can cause unpredictable behavior. > > > From the callers point of view what other observable behavior > might be > different? > > > It's a possible race condition and the memory model allows re-ordering > of operations, so anything could go wrong, from an Exception to plain > wrong formatting. > > > Roger > > > > On 7/12/2013 5:27 AM, Stephen Colebourne wrote: > > You may be right, although neither volatile nor synchronized are > appealing here. > > Please raise an issue on GitHub > > Stephen > > > > On 12 July 2013 10:19, Lin Wang <sup...@gm... > <mailto:sup...@gm...>> wrote: > >> The javadoc of ISODateTimeFormat class says it's thread-safe > and immutable. > >> The static fields are lazily initialized. However it seems it's > not done in > >> a thread-safe manner. > >> > >> For example, dt is lazily initialized in > >> public static DateTimeFormatter dateTime() { > >> if (dt == null) { > >> dt = new DateTimeFormatterBuilder() > >> .append(date()) > >> .append(tTime()) > >> .toFormatter(); > >> } > >> return dt; > >> } > >> > >> When there are two threads both inside this method, is it > possible that one > >> thread sees an unsafely published non-null dt value due to cache > >> incoherence? > >> > >> Did I miss something? > >> > >> > ------------------------------------------------------------------------------ > >> See everything from the browser to the database with AppDynamics > >> Get end-to-end visibility with application monitoring from > AppDynamics > >> Isolate bottlenecks and diagnose root cause in seconds. > >> Start your free trial of AppDynamics Pro today! > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Joda-interest mailing list > >> Jod...@li... > <mailto:Jod...@li...> > >> https://lists.sourceforge.net/lists/listinfo/joda-interest > >> > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from > AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Joda-interest mailing list > > Jod...@li... > <mailto:Jod...@li...> > > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > <mailto:Jod...@li...> > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: Nils Kilden-P. <ni...@gm...> - 2013-07-12 13:38:14
|
On Fri, Jul 12, 2013 at 8:05 AM, roger riggs <rog...@or...> wrote: > I don't see a functional issue with this; > You need to study the Java memory model then. > The DateTimeFormatter created by each thread will have exactly the same > behavior and semantics. > The caller gets an instance that preforms as required. > No, that's not guaranteed with the current code. > > dt is just a cache to improve performance. > > The only condition at risk is the two calls to dateTime() do not return > the same (==) instance. > No, the risk is that a second concurrent thread gets a reference to the not yet completed object, which can cause unpredictable behavior. > > From the callers point of view what other observable behavior might be > different? > It's a possible race condition and the memory model allows re-ordering of operations, so anything could go wrong, from an Exception to plain wrong formatting. > > Roger > > > > On 7/12/2013 5:27 AM, Stephen Colebourne wrote: > > You may be right, although neither volatile nor synchronized are > appealing here. > > Please raise an issue on GitHub > > Stephen > > > > On 12 July 2013 10:19, Lin Wang <sup...@gm...> wrote: > >> The javadoc of ISODateTimeFormat class says it's thread-safe and > immutable. > >> The static fields are lazily initialized. However it seems it's not > done in > >> a thread-safe manner. > >> > >> For example, dt is lazily initialized in > >> public static DateTimeFormatter dateTime() { > >> if (dt == null) { > >> dt = new DateTimeFormatterBuilder() > >> .append(date()) > >> .append(tTime()) > >> .toFormatter(); > >> } > >> return dt; > >> } > >> > >> When there are two threads both inside this method, is it possible that > one > >> thread sees an unsafely published non-null dt value due to cache > >> incoherence? > >> > >> Did I miss something? > >> > >> > ------------------------------------------------------------------------------ > >> See everything from the browser to the database with AppDynamics > >> Get end-to-end visibility with application monitoring from AppDynamics > >> Isolate bottlenecks and diagnose root cause in seconds. > >> Start your free trial of AppDynamics Pro today! > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Joda-interest mailing list > >> Jod...@li... > >> https://lists.sourceforge.net/lists/listinfo/joda-interest > >> > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Joda-interest mailing list > > Jod...@li... > > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: roger r. <rog...@or...> - 2013-07-12 13:05:47
|
I don't see a functional issue with this; The DateTimeFormatter created by each thread will have exactly the same behavior and semantics. The caller gets an instance that preforms as required. dt is just a cache to improve performance. The only condition at risk is the two calls to dateTime() do not return the same (==) instance. From the callers point of view what other observable behavior might be different? Roger On 7/12/2013 5:27 AM, Stephen Colebourne wrote: > You may be right, although neither volatile nor synchronized are appealing here. > Please raise an issue on GitHub > Stephen > > On 12 July 2013 10:19, Lin Wang <sup...@gm...> wrote: >> The javadoc of ISODateTimeFormat class says it's thread-safe and immutable. >> The static fields are lazily initialized. However it seems it's not done in >> a thread-safe manner. >> >> For example, dt is lazily initialized in >> public static DateTimeFormatter dateTime() { >> if (dt == null) { >> dt = new DateTimeFormatterBuilder() >> .append(date()) >> .append(tTime()) >> .toFormatter(); >> } >> return dt; >> } >> >> When there are two threads both inside this method, is it possible that one >> thread sees an unsafely published non-null dt value due to cache >> incoherence? >> >> Did I miss something? >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Joda-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |
From: Stephen C. <sco...@jo...> - 2013-07-12 09:28:14
|
You may be right, although neither volatile nor synchronized are appealing here. Please raise an issue on GitHub Stephen On 12 July 2013 10:19, Lin Wang <sup...@gm...> wrote: > The javadoc of ISODateTimeFormat class says it's thread-safe and immutable. > The static fields are lazily initialized. However it seems it's not done in > a thread-safe manner. > > For example, dt is lazily initialized in > public static DateTimeFormatter dateTime() { > if (dt == null) { > dt = new DateTimeFormatterBuilder() > .append(date()) > .append(tTime()) > .toFormatter(); > } > return dt; > } > > When there are two threads both inside this method, is it possible that one > thread sees an unsafely published non-null dt value due to cache > incoherence? > > Did I miss something? > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > |
From: Lin W. <sup...@gm...> - 2013-07-12 09:19:14
|
The javadoc of ISODateTimeFormat class says it's thread-safe and immutable. The static fields are lazily initialized. However it seems it's not done in a thread-safe manner. For example, dt is lazily initialized in public static DateTimeFormatter dateTime() { if (dt == null) { dt = new DateTimeFormatterBuilder() .append(date()) .append(tTime()) .toFormatter(); } return dt; } When there are two threads both inside this method, is it possible that one thread sees an unsafely published non-null dt value due to cache incoherence? Did I miss something? |
From: Stephen C. <sco...@jo...> - 2013-07-11 06:31:38
|
On 11 July 2013 04:33, Charles Oliver Nutter <he...@he...> wrote: > That sounds good. So... > > joda-timezone-2013z.jar would be: joda-time-tzdb-2013z.jar > /org.joda.time.tzdb-verzion.txt OR /org/joda/time/tzdb-version.txt? (I > prefer latter, or in tz namespace) > /org.joda.time.tzdb-2013z.zip OR /org/joda/time/tzdb-2013z.zip? > (latter, or in tz namespace) /org/joda/time/tz/tzdb-version.txt /org/joda/time/tz/tzdb-2013z.zip > Loading TZ data scans tzdb-version.txt resources, looks for greatest > version, opens up zip from CL resources and loads TZ data. Yes >Failing > that, it loads shipped data from tz.data namespace (or should we > structure that the same way with the same .txt?) Ideally, the data shipped in Joda-Time itself would just be the same format as that in the separate tzdv jar with its own tzdb-version.txt and zip. > I can structure the new jar as agreed (above, with clarifications) and > prepare it. You can add me to sonatype or push it yourself once I have > it ready. > > The scanning is going to be less complex if we have a versioned .zip > to load tzdata from, so it may not take as long to impl (I'm just > juggling a few things at once right now). Sounds good. thanks Stephen |
From: Charles O. N. <he...@he...> - 2013-07-11 03:34:50
|
On Wed, Jul 10, 2013 at 2:04 PM, Stephen Colebourne <sco...@jo...> wrote: > I think it may be best to have a zip file tagged with the version > inside the jar file. So the jar file only contains the text file and > the zip file. That sounds good. So... joda-timezone-2013z.jar would be: /org.joda.time.tzdb-verzion.txt OR /org/joda/time/tzdb-version.txt? (I prefer latter, or in tz namespace) /org.joda.time.tzdb-2013z.zip OR /org/joda/time/tzdb-2013z.zip? (latter, or in tz namespace) Loading TZ data scans tzdb-version.txt resources, looks for greatest version, opens up zip from CL resources and loads TZ data. Failing that, it loads shipped data from tz.data namespace (or should we structure that the same way with the same .txt?) > groupId: joda-time > artifactId: joda-time-tzdb > version: tzdb version number > > The trouble is that I only want the new format of jar suitable for > smart loading to be pushed there, rather than a jar that overrides on > the classpath. > > Oh, and only I can push to sonatype OSS at the moment. I can structure the new jar as agreed (above, with clarifications) and prepare it. You can add me to sonatype or push it yourself once I have it ready. The scanning is going to be less complex if we have a versioned .zip to load tzdata from, so it may not take as long to impl (I'm just juggling a few things at once right now). - Charlie |
From: Stephen C. <sco...@jo...> - 2013-07-10 18:04:42
|
On 10 July 2013 18:21, Charles Oliver Nutter <he...@he...> wrote: > A question arises... > > I assume we want the compiled data to be structured the same as it is > now, in separate files. So then...once we've found the most recent > tzdb-version file, how to proceed? > > * Data files tagged with version as well; load data files + version appended. > * Data files named as today; use tzdata-version.txt classloader URL > base to load them. > * Something else. I think it may be best to have a zip file tagged with the version inside the jar file. So the jar file only contains the text file and the zip file. >>> You should be able to fork JodaOrg/joda-time on GitHub to your own >>> namespace and work there. That works because you'll need to edit >>> joda-time itself to do the resource file searching. >>> >>> If you need a separate repo to fork from for the time zone db file >>> publishing, I can sort that. > > On second thought...in the interest of time, I'd like to get JRuby off > the current tzdata setup and on to the actual artifact. Can we sort > out a repo, artifact, and release for the data first, and I'll work in > the smart loading after that? groupId: joda-time artifactId: joda-time-tzdb version: tzdb version number The trouble is that I only want the new format of jar suitable for smart loading to be pushed there, rather than a jar that overrides on the classpath. Oh, and only I can push to sonatype OSS at the moment. Stephen |
From: Charles O. N. <he...@he...> - 2013-07-10 17:22:01
|
On Wed, Jul 10, 2013 at 12:38 PM, Charles Oliver Nutter <he...@he...> wrote: > On Wed, Jul 10, 2013 at 12:16 PM, Stephen Colebourne > <sco...@jo...> wrote: >> I think the resource should be "org.joda.time.tz.tzdb-version.txt" >> It would contain the version, such as "2013c". >> That would link to > > Got it. A question arises... I assume we want the compiled data to be structured the same as it is now, in separate files. So then...once we've found the most recent tzdb-version file, how to proceed? * Data files tagged with version as well; load data files + version appended. * Data files named as today; use tzdata-version.txt classloader URL base to load them. * Something else. >> You should be able to fork JodaOrg/joda-time on GitHub to your own >> namespace and work there. That works because you'll need to edit >> joda-time itself to do the resource file searching. >> >> If you need a separate repo to fork from for the time zone db file >> publishing, I can sort that. On second thought...in the interest of time, I'd like to get JRuby off the current tzdata setup and on to the actual artifact. Can we sort out a repo, artifact, and release for the data first, and I'll work in the smart loading after that? - Charlie |
From: Charles O. N. <he...@he...> - 2013-07-10 16:39:41
|
On Wed, Jul 10, 2013 at 12:16 PM, Stephen Colebourne <sco...@jo...> wrote: > I think the resource should be "org.joda.time.tz.tzdb-version.txt" > It would contain the version, such as "2013c". > That would link to Got it. >> Perhaps someone could spin up a repo in JodaOrg where I can start >> pushing this stuff? > > You should be able to fork JodaOrg/joda-time on GitHub to your own > namespace and work there. That works because you'll need to edit > joda-time itself to do the resource file searching. > > If you need a separate repo to fork from for the time zone db file > publishing, I can sort that. Probably not necessary. If I need to have a separate repo for the tzdata artifact (for maven purposes, probably) I'll let you know. - Charlie |