Skip to main content
This revision made October 25, 2011 23:14, by rwarburton

JSR 310 - new Date and Time API for Java

The LJC is getting involved in JSR-310 as we believe it's a vital technology for the Java language as software increasingly needs to be date, time and time zone aware in a safe immutable manner.

JSR in a Nutshell

Date and Calendar do not provide adequate functionality for day to day Java developers. JSR-310 addresses this with an implementation based on hard won lessons from JodaTime. For more information on JSR-310 please see the links below and this London Java Community Blog Post

LJC Goals

  1. To assist the threeten project in meeting the Technology Compatibility Kit (TCK) requirements of this JSR, a major milestone to having JSR-310 accepted as part of the Java language.
  2. Promote the ThreeTen implementation and provide pathways for members to get involved in either writing tests on the TCK project or getting involved in the ThreeTen implementation.

LJC Volunteers

We are looking for volunteers within the London Java Community and beyond to help us with our efforts, please contact either of the leads below if you are interested.

Proposed TCK Strategy

  1. Provide a method of running a TCK test suite against an arbitrary jar.
  2. Provide a method of specifying which TestNG tests are part of the TCK.
  3. Specify TestNG tests that are TCK appropriate from the current testsuite.
  4. Write any additional tests that are necessary in order to completely specify the API (It might be the case that this isn't necessary since you already have a lot of tests and test coverage)

Step 1

Source code is available at GitHub and we intend to continue development in the open. We've added a new ant target for testing TCK acceptance. So if you've compiled the latest version of the existing source code, then in order to run the TCK against it you would execute:

   ant -Dtck.implementation=build/threeten-0.6.3.jar tck

You can substitute any arbitrary jar as the 'tck.implementation' variable and it tests against the classes in that jar.

Step 2

We are using TestNG's group feature to specify what tests we want to use as part of the TCK. Currently the 'tck' ant target, only runs tests that are annotated as being part of the 'tck' group from the existing ThreeTen unit tests. So if you want to make a unit test part of tck acceptance you annotated it with:

   @Test(groups={"tck"})

We've currently annotated a single test with the annotation, but that's just to make sure that it works, rather than a comment on what is tck-appropriate or not.

Step 3

This step involves annotating all appropriate TestNG tests with the aforementioned group. We are yet to completely formalise the guidelines on what should be appropriate or not, here are some heuristics:

  • The public api is contained within the compiled jar at "build/threeten-*.*.*.jar". Any TCK tests should be only on methods that are publicly accessible. You will get a linktime error if you try to run the ant 'tck' command against a non-public api class, but you still need to be careful to not accidentally test implementation-specific methods.
  • Don't test methods that are private to classes.
  • Don't rely on invariants that encapsulated within classes.

There is a work-allocation table on Step 3 of the Volunteering page.

Some Legal information on submitting to the TCK

Please note that to submit work to the JCP you will need to have a JSPA countersigned by your employer for legal reasons. The LJC/JCP is currently working on providing some guidance on this, but until then the full detail is here.

Further links and information

Difference compared to previous revision
@Test(groups={"tck"}) We've currently annotated a single test with the annotation, but that's just to make sure that it works, rather than a comment on what is tck-appropriate or not. '''Step 3''' =JSR 310 - new Date and Time API for Java= The LJC is getting involved in JSR-310 as we believe it's a vital technology for the Java language as software increasingly needs to be date, time and time zone aware in a safe immutable manner. ... We've currently annotated a single test with the annotation, but that's just to make sure that it works, rather than a comment on what is tck-appropriate or not. TheThis next steps w step invoill blvese to work o an notaddting theall annpprotpriatione Tes totNG tests whic tests with the aforementionedh are TCK, group. We andare yet to completely formalise either rthe guidemovlinges orn what should be adaptappropringate or not, here are some heuristics: * tests w The publhich areic api implemes contained withntation spin the compecific.iled Tjar at "build/thehreeten-*.*.*.jar".re is A nony dTCK tests should oubtbe als onlyo going on methods to be that arthe scoe publicly accessible.pe t Youo writ will get a linktie more testsme error if you try to run t for the TCK. Jhe ant 'tck' coamemmand against a s andnon-public Rapi ichclardss, wbut you still workneed t ono be ca creareful tio ngot a docum accidentallyent tha test wt impill be hlementation-ostspecific methods. * Don'ted on thi tests Wiki methodsto tr thackt are priva thte to classes. * Don't rely on invariante tests that peos that encapsulated within classes. There is a work-allocatiople are workingn table on wion Sthinep 3 of the [[JSR-310Volunt the nexeering|Volunt fewteering]] wpageeks. '''Some Legal information on submitting to the TCK'''
 
 
Close
loading
Please Confirm
Close