threeten

>>> 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.
>>
>> Can you confirm that the existing development process will stay the
>> same?  Notably JSR 310 is currently operating under version 2.7 of the
>> JCP Rules, even though in practice I think we're conforming to 2.8
>> standards, as agreed in JSR 348.  Will technical discussion continue
>> to operate on a public mailing list and will contributions continue to
>> be accepted via github pull requests, or some equally accessible
>> means?
>
> The current intention is as follows:
>
> - There will probably need to be another EDR, so that would be
> targetted at mid-year.
> - Up until the EDR, the process will be as it currently is, with
> GitHub, pull requests and public mailing list
> - Beyond the EDR, the project will probably move to a sandbox OpenJDK
> repo (Mecurial) for integration with the JDK
> - The sandbox repo will then get merged into the main OpenJDK repo

Sounds good.

> My intention is that all discussion should continue to be on public
> mailing lists, and information about significant private discussions
> be forwarded to the public lists. As time progresses, there will
> clearly be a move to OpenJDK processes.
>
> I haven't looked into the 2.7/2.8 JCP rules issue. Not moving is less
> effort for me.

I think the big issues from my point of view are already covered since
this JSR is being run like an open source project, so there's probably
no real need to switch over from a paperwork point of view.

regards,

  Richard

On 2/2/2012 4:53 PM, Stephen Colebourne wrote:
> Formatting and parsing using SimpleDateFormat and java.util.Formatter
> would be in the core.My expectation is that most serious enterprise
> users (not space constrained) would switch across to the newer
> formatter API in the 2nd module.
Why not include the new formatter API in core, and mark SImpleDateFormat 
deprecated? It would give people a bit more of a nudge to migrate if the 
new formatter is in core.

David

> 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.

Thanks for keeping everyone on the list informed Stephen.

> 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).

I don't really agree with splitting the formatting out of the core
API.  Having said that if one assumes that Jigsaw modules will be as
easy to install as maven modules then its not the end of the world.
Is there a plan for replacing the 'toString()' methods that take a 310
Formatter?  They presumably wouldn't be able to exist since they would
require a dependency on the second module.

One of the most major issues to my mind is that the current 310 API
has a really simple approach to concurrent use - its immutable
everywhere.  One of the most commonly cited pitfalls of the
SimpleDateFormat is its lack of thread safety.  This means that your
concurrency approach is probably, "Don't worry about concurrent access
on date/time values - unless you plan on printing them to a string or
reading them out of a string at which point you'll need to design a
thread-unsafe access pattern."  Looking at the SimpleDateFormat class
there doesn't seem to be any easy, backwards compatible, modifications
that could introduce thread safety.  Is there any idea on improving
this situation?

> 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

This seems like it would make it harder to write custom calendaring
systems.  Is this the extent of the limitations imposed by removing
these concepts?

> 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.

Can you confirm that the existing development process will stay the
same?  Notably JSR 310 is currently operating under version 2.7 of the
JCP Rules, even though in practice I think we're conforming to 2.8
standards, as agreed in JSR 348.  Will technical discussion continue
to operate on a public mailing list and will contributions continue to
be accepted via github pull requests, or some equally accessible
means?

regards,

  Richard

Hi,

In all likely hood, most developers will not be working on minimum footprint
machines and will have the entire JDK at their disposal, so the module 
boundaries
are not an issue. For the developers working on size constrained devices
some tradeoffs must be made so it can fit. With any fixed footprint 
budget choices
need to  be made between the various alternatives, for example, wanting 
the latest
fork-join package, better date/time formatting or <insert your favorite 
new api>.

The discussion with Stephen was to identify a partitioning in which the
essentials of the API could be provided without the whole API.  If it can
all be in one module great, if not, it is not so monolithic that it 
would have
to be redesigned or worse.

As for deprecating SimpleDateFormat, the JDK has a process for that.
It takes a couple of releases.  But I expect backward compatibility and
being able to run existing applications would defer actually removing it
a very long time.  The API should encourage using the new API  and
also provide a bridge from existing applications and libraries.

Roger


On 2/2/12 7:57 PM, David Momper wrote:
> On 2/2/2012 4:53 PM, Stephen Colebourne wrote:
>> Formatting and parsing using SimpleDateFormat and java.util.Formatter
>> would be in the core.My expectation is that most serious enterprise
>> users (not space constrained) would switch across to the newer
>> formatter API in the 2nd module.
> Why not include the new formatter API in core, and mark SimpleDateFormat
> deprecated? It would give people a bit more of a nudge to migrate if the
> new formatter is in core.
>
> David
>

>> 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).
>
> I don't really agree with splitting the formatting out of the core
> API.  Having said that if one assumes that Jigsaw modules will be as
> easy to install as maven modules then its not the end of the world.
> Is there a plan for replacing the 'toString()' methods that take a 310
> Formatter?  They presumably wouldn't be able to exist since they would
> require a dependency on the second module.

Oracle's intention is that for most enterprise developers there will
be a single mega-module called "jdk". As such, most enterprise
developers won't need to know that much about the split between the
"core" and "non core". As such, I don't think its much of a problem.
Think of it as designing a solution that scales down to small phones,
but if you do use it on a small phone you have a worse formatting API.

>> 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
>
> This seems like it would make it harder to write custom calendaring
> systems.  Is this the extent of the limitations imposed by removing
> these concepts?

Removing DateProvider and TimeProvider also restricted the ability to
integrate other APIs (like Joda-Time). I don't think this is a big
deal, particularly as the providers had many of the downside of Scala
implicits in terms of silent and deadly conversion of types (which
results in code that doesn't do what it looks like it does).

Stephen

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

On 3 February 2012 12:09, Brian Harris <brianfromoregon@...> wrote:
> 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?

Well OffsetDate clearly has a meaning. Its a reference to a whole day
occurring at an offset from UTC. And it has the opposite use case to
that described for OffsetTime, that is storing a LocalTime and an
optional OffsetDate that combine to form an ODT.

To remove would make the pattern of classes incomplete for a
combination that is logically valid. In my view, that makes it harder
for users to understand the pattern, whether or not it is widely used.

Stephen

Hi Richard,

I wasn't specifically addressing the split, rather this chain of discussion. Just reacting to Stephen's statement that the conversion will get harder, I'm suggesting that it will be such a common use case, that the obvious scenario should be made very easy.

>>> As part of this, 
>>> some concepts will probably disappear entirely:
>>> - CalendricalMatcher
>>> - InstantProvider
>>> - PeriodProvider

>> I find the java.util.Date <-> 310 types conversion APIs to not be user 
>> friendly, is that the intention to discourage converting?

> The conversion is likely to get harder with the loss of InstantProvider. I'm not sure there are any easy solutions there.

-----Original Message-----
From: Richard Warburton [mailto:richard.warburton@...] 
Sent: Thursday, February 02, 2012 7:51 PM
To: threeten-develop@...
Subject: Re: [threeten-develop] JSR-310 face to face meeting with Oracle

> Conversion back and forth between java.util.Date (or Calendar) and a reasonable subset of JSR-310 types will probably be one of the most common use cases for a decade or more in code, as programmers get the old types out of some library or legacy portion of the code and convert them, or has to pass them as methods to legacy code and libraries. By not providing a clear, standard way to do the conversion will just make everyone have to re-invent the wheel over and over again, and probably do it poorly in many cases.

This has been discussed on the mailing list before.  My interpretation was that there were several available options - any of which can be chosen once a consensus arises.  Perhaps I've misunderstood your point, but I don't understand how the API split affects this situation.  If anything having core 310 classes in the core JDK Module gives us more options, since it means that the utility methods can be provided on the old API.

regards,

  Richard

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
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-dev2
_______________________________________________
threeten-develop mailing list
threeten-develop@...
https://lists.sourceforge.net/lists/listinfo/threeten-develop