OffsetDate is the only class I have a problem with, not OffsetDateTime
or OffsetTime. Is there a use case for OffsetDate besides this XML
schema compatibility?
On Thu, Feb 2, 2012 at 6:56 PM, Douglas Surber
<douglas.surber@...> wrote:
> JDBC requires OffsetDateTime as that is what is specified in the SQL
> standard. Oracle JDBC requires ZonedDateTime as Oracle supports it as
> a proprietary extension.
>
> Douglas
>
>
> At 12:14 PM 2/2/2012, Brian Harris wrote:
>>Is this split an evolution of Roger's earlier post "Threeten API
>>adoption" where he proposed a refactoring of the API to separate
>>basic
>>and advanced usage, or is there interest in a separate
>>basic/advanced
>>split within the core/secondary modules?
>>
>>The OffsetDate class still bugs me, do you remain that it's
>>necessary
>>for XML schema spec compatibility? If that's the only use case can
>>you
>>stuff it in some xml package so it's hidden from everyone else?
>>
>>I find the java.util.Date <-> 310 types conversion APIs to not be
>>user
>>friendly, is that the intention to discourage converting?
>>
>>Brian
>>
>>On Thu, Feb 2, 2012 at 12:28 PM, Stephen Colebourne
>><scolebourne@...> wrote:
>> > On Tuesday and Wednesday this week, I met with Oracle (Roger
>> Riggs,
>> > Brian Goetz, Sherman Shen) to discuss how to proceed with JSR-310
>> to
>> > achieve the JDK 8 target.
>> >
>> > The two-day discussion was wide ranging and touched on every part
>> of
>> > the current API. As such, it is hard to describe every last
>> detail of
>> > what we talked about, but I'll attempt a summary.
>> >
>> > Oracle has a desire to modularize the JDK, and as part of that,
>> there
>> > is a goal for the core JDK module to be small. It appears that a
>> good
>> > approach would be for the core parts of JSR-310 to be in the most
>> core
>> > JDK module, while other more advanced features would be in a
>> secondary
>> > JDK module. Users would have the choice to depend only on the
>> core
>> > (such as in the embedded space), or on the whole JDK (or other
>> choices
>> > in-between, chosen on a whole-module basis.)
>> >
>> > To make this happen, it was necessary to discuss how the current
>> > code-base could be split up. Bear in mind that the core module
>> will
>> > not be able to have any direct dependencies on the secondary
>> module.
>> >
>> > The working model for the split is as follows (ie, all subject to
>> change):
>> > Core
>> > - Instant, Duration
>> > - LocalDate,LocalTime, LocalDateTime
>> > - OffsetDate,OffsetTime, OffsetDateTime
>> > - MonthOfYear, DayOfWeek, AmPmOfDay
>> > - ZonedDateTime
>> > - ZoneId, ZoneOffset, new time zone package
>> > - the old time zone code and new time zone code unified
>> internally
>> > - DateAdjuster
>> > - Period
>> > - Clock
>> >
>> > Secondary
>> > - Formatting (printing/parsing)
>> > - Low-level framework (CalendricalRule, DateTimeRule, PeriodUnit,
>> resolvers etc)
>> > - DateTimeField(s)
>> > - PeriodField(s)
>> > - Global calendar systems - ChronologyDate<EthopicChronology>
>> > - Historic Gregorian/Julian calendar system
>> > - Year, YearMonth, MonthDay
>> >
>> > Third-party jar (not in the JDK)
>> > - UTC/TAI, TimeSource (all leapsecs and time-scale code)
>> > - QuarterOfYear
>> >
>> > As part of this split, it is apparent that formatting is not in
>> the
>> > core. Oracle expressed a strong desire to extend the capabilities
>> of
>> > the existing SimpleDateFormat and java.util.Formatter (printf)
>> classes
>> > to support the new 310 core types. Given this, the 310 formatting
>> API
>> > becomes the "better" formatting API, used if you care about
>> immutable
>> > formatters, or printing/parsing other calendar systems or more
>> complex
>> > use cases (and have access to the additional module).
>> >
>> > A key part of the separation will be the removal from the core of
>> > clutter, however I intend to make sure that this does not result
>> in
>> > the gutting of usability for more advanced use cases. As part of
>> this,
>> > some concepts will probably disappear entirely:
>> > - CalendricalMatcher
>> > - InstantProvider
>> > - PeriodProvider
>> >
>> > No doubt there will be other changes as the details are worked
>> > through. For early adopters this is unfortunate, but I have to
>> place
>> > inclusion in the JDK at a higher priority than maintaining any
>> kind of
>> > compatability with the current source-base. That said, the main
>> APIs
>> > of the main classes is likely to stay roughly the same, even if
>> in
>> > another package.
>> >
>> > The final JSR product will be fully integrated in the JDK, and as
>> such
>> > will only run on JDK 8. A reasonable backport to JDK 6/7 will be
>> > needed, although the classes may be in a different package name
>> in the
>> > backport.
>> >
>> > There was also discssion of various points of process. I expect
>> to be
>> > nominating Oracle as a co-spec lead in the near future, which
>> should
>> > aid the process of JDK integration. Expect to see more
>> participation
>> > from Roger, Sherman and other Oracle particpants as time
>> progresses.
>> >
>> > I'm happy to answer questions on any of the points above, or
>> anything
>> > else, and I suspect that those questions may be a better way of
>> > teasing out how the discussion went than me writing a very long
>> email
>> > ;-)
>> >
>> > Stephen
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Keep Your Developer Skills Current with LearnDevNow!
>> > The most comprehensive online learning library for Microsoft
>> developers
>> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
>> CSS3, MVC3,
>> > Metro Style Apps, more. Free future releases when you subscribe
>> now!
>> > http://p.sf.net/sfu/learndevnow-d2d
>> > _______________________________________________
>> > threeten-develop mailing list
>> > threeten-develop@...
>> > https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>>------------------------------------------------------------------------------
>>Keep Your Developer Skills Current with LearnDevNow!
>>The most comprehensive online learning library for Microsoft
>>developers
>>is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
>>MVC3,
>>Metro Style Apps, more. Free future releases when you subscribe now!
>>http://p.sf.net/sfu/learndevnow-d2d
>>_______________________________________________
>>threeten-develop mailing list
>>threeten-develop@...
>>https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> threeten-develop mailing list
> threeten-develop@...
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
|