You are currently browsing the category archive for the ‘JSR-310’ category.
As part of the London Java Communities efforts to help out in JSR-310 efforts, we have been working with Stephen Colebourne to gather the feedback of the community on method naming conventions that would potentially be used in the upcoming implementation. After all, it is hoped that everyone in the Java world writing systems using dates will be potentially using the API from Java 8 onwards.
The intention of this blog post is to publicise the results and to encourage you to participate in the discussion. We are at the crossroads of finalising design and adapting the already comprehensive implementation to match the requirements. Please join us on the mailgroup and continue the discussion: mail group
There are 9 public questions that will be broken down into the general responses. The response has been immense, and behalf of everyone involved with the project I’d like to take this opportunity to thank you for your participation. The total number of surveys received was 1824. These results will contribute towards steering the API changes discussed on the mailing list.
The statistics below are summary statistics for the main categories, a full CSV of all anonymous responses is available here.
1. It is planned to have an enum for the month-of-year (January to December). What should this class be called?
- 89.21% chose the format Month – eg. Month.APRIL.
- 8.55% chose the format MonthOfYear – eg. MonthOfYear.APRIL.
- 2.24% gave an alternate response.
2. There will be a class representing a date on its own (no time, or time-zone). Thinking about this class, what set of methods would you prefer to use.
- 51.07% chose getYear(), getMonth(), getDay(), getDayOfYear(), getDayOfWeek().
- 37.30% chose getYear(), getMonth(), getDayOfMonth(), getDayOfYear(), getDayOfWeek().
- 9.44% chose getYear(), getMonthOfYear(), getDayOfMonth(), getDayOfYear(), getDayOfWeek().
- 2.19% gave an alternate response.
3. Thinking specifically about getDay() vs getDayOfMonth(), which of these statements do you agree with? (This was a select multiple question)
- 23.81% chose if I saw getDay() I would assume it was day-of-month.
- 20.33% chose I would quickly learn that getDay() meant day-of-month.
- 19.88% chose while it is longer, getDayOfMonth() is a lot clearer.
- 16.63% chose getDay() is not clear without reading Javadoc.
- 15.83% chose getDayOfMonth() is too long.
- 3.52% gave an alternate response.
4. There will be a class representing a time-of-day on its own (no date, or time-zone). Thinking about this class, what set of methods would you prefer to use?
- 72.44% chose getHour(), getMinute(), getSecond(), getNano().
- 13.30% chose getHour(), getMinute(), getSecond(), getNanoOfSecond().
- 8.04% chose getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond().
- 6.23% gave an alternate response.
- 58.29% chose only have a method returning the enum, with the int value available via a method on the enum.
- 12.31% chose getMonthValue() returns an int; getMonth() returns an enum.
- 8.11% chose getMonth() returns an int; getMonthOfYear() returns an enum.
- 7.08% chose only have a method returning the int, removing the enum from the API.
- 7.08% chose getMonthInt() returns an int; getMonth() returns an enum.
- 3.91% chose getMonthOfYear() returns an int; getMonth() returns an enum.
- 3.22% gave an alternate response.
|6.1 Shortest possible||20.45%
|6.2 Pattern based||31.36%
|6.3 Clear when read||65.61%
|6.6 Quick to write||17.15%
|6.8 Balance of short and clear||48.93%
|6.9 No need to read Javadoc||32.15%
- 41.48% chose never.
- 36.34% chose occasionally.
- 22.18% chose frequently.
9. How much experience do you have with Java?
- 69.95% chose more than 5 years.
- 22.94% chose 2-5 years.
- 4.62% chose less than 2 years.
- 2.48% chose Java is not my main language.
- Simon Maple
- Richard Warburton
- Somay Nakhal
- Ben Evans
- James Gough
- Martijn Verburg
- Trish Gee
- Mike Barker
(Tasks in Bold)
- Welcome Somay Nakhal to the Committee!
- We need to start having formal agendas before each meeting (MV to create next one)
- We’d like to have a venue with free WiFi for all (TG to investigate possibilities)
- Hosted at Goldman Sachs in Jersey City, USA
- Good to put names to faces, made following JSR-348 WG meeting run more easily
- LJC ‘Adopt a JSR’ program was well received
- Lots of support for JSR-310
- Main issue was about ballot stuffing. The PMO will investigate and act appropriately if there is evidence of suspicious voting.
- SE and ME committees will merge (partly as ME committee rarely makes quorum).
- 24 seats + chair is the new target, down from 32 today, ‘extra’ seats will die a natural death.
- Java ME
- Hardware baseline – so price point drops over time? In our opinion this does not match what the industry is doing.
- Code line is currently based off 1.4.2, they’re proposing to do an ME7, base lined against SE 7 but with some features (like invokedynamic) will be removed.
- ME seems to be heading towards the embedded space.
- ME for SE developers LJC session by Oracle to help us gain insight into this area of standards (MV to organise).
- ‘Adopt a JSR program’ is vital. We shall proceed by:
- Update java.net with our JCP status (MB to follow up)
- Blog about JSPA signature (BE to post)
- Producing a Glossary of Terms (TG to update wiki)
- Push out the ‘Adopt a JSR Program’ post (RW)
- Give Richard access to LJC blog (MV)
- Forward post to JUG leaders list during JavaOne once done (MV)
- Send out details of our java.net page to committee (MV)
- At the next JCP meeting, review our JCP/JSR Content on java.net (all of us)
- Adopt a JSR Logo – CC licensed Duke needs you (MV)
- Blog post on TCKs etc (JG)
- Volunteer Cat herding (JG)
- Next step is to start the TCK planning stage (JG)
- Contact threeten mailing list (JG)
- Workshop on TCK at Open Conference (JG)
- Get Oracle involved – Roger Riggs – (BE)
- Looking for adoptees, get Spec lead to send out a description (MV)
JSR-350 (session state enhancement)
- Adopt a JSR – Introduce Madhu Konda and SN (BE)
- Investigation, talk to Jeff Trent (and his upcoming replacement) (SN)
JSR-351 - Identity Management
- Contact spec lead for further clarification of JSR (BE)
As part of the London Java Community’s Adopt a JSR program, I took on the role of increasing awareness on JSR-310. JSR-310 is the proposed solution for improving the current data and time system within Java. For more information on JSR-310 please view this previous blog post. Following introducing JSR-310 to the London Java Community I have also become involved in planning a potential TCK (Technology Compatibility Kit) for JSR-310. When I first began the task I asked myself a few questions, which I will aim to answer in this blog post. The format of the post will be in questions and answer, so the reader can quickly skip through the topics they are not interested in. There will also be some more extended points within the post on the work we are currently undertaking as part of the London Java Community to contribute to the TCK for JSR-310.
Why should general Java developers care about JSR-310 and the TCK?
Most developers have used the current date APIs that are available in Java. They’re difficult to use, often lead to unexpected results and have a general confusion about them. JSR-310 aims to address these problems and ensure a better system for the future of Java. If contributions are not made by the community and Java developers this important JSR will miss the deadline for Java 8. My aim is to help get this through to Java 8 and I’m looking for as many people in the community to enable us to get there. Please feel free to contact me for more information:
- Twitter @goughjam
What is a TCK? What are the terms that surround the JCP on this topic?
Before you can appreciate the reason for a TCK the first step is understanding the separation of concerns between the JSR (Java Specification Request) and the RI (Reference Implementation). The JSR has the purpose of stipulating the exact requirements of an implementation and is effectively the basis for the JavaDoc style interfaces, rather than getting bogged down in the implementation details. The reference implementation’s job is to be the code that fulfills the requirements, it should do no more and no less than what is required from the specification. The job of the TCK is to mediate the specification against the actual implementations, keeping in mind that there might be more that one implementation for a specific JSR.
What’s the difference between unit testing and TCK testing? What do both address? Is there any overlap?
The purpose of a TCK is to test the “conformance” of an implementation against a JSR, but it’s more than just that. It is a suite of tools, a test framework and documentation to allow someone to take the JSR and understand how the implementation must behave to pass the kit. Unit tests are internal to the reference implementation and are not necessarily going to provide the full suite and documented nature of a TCK. Is there opportunity for reuse, definitely! However the unit tests that might be reused from an existing implementation need to be selected with care. The tests should only be testing the specification rather than any specific functionality that could be internal to an implementation. In the example of ThreeTen the strategy will be to view the JSR Early Draft Review independently from the code base that already exists to ensure a high quality TCK is created.
What makes up a TCK?
As mentioned the TCK is suite of tools to allow an implementer to create a successful reference implementation. It also requires careful planning, this is the phase we are landing in now for JSR-310. We will be looking over the coming weeks to produce the following plans; project, test, integration, documentation and QA plans. The previous sentence is quite work heavy to look at on first glance and immediately it’s clear to see that the TCK is a project and application in itself.
The TCK needs to have the concept of conformance rules. These rules will measure the success of whether the implementation conforms to the specification. The test suite is a collection of conformance tests. The TCK should also allow the identification of methods that might be outside of the JSR, additional methods should cause the test to fail with a detailed description of the failure.
Because this is a piece of software what will be used by other developers, the error messages that are generated from the TCK need to be logical and clear as to why that test failed. Reporting and good user feedback is part of this framework.
Following the completion of a JSR the TCK doesn’t end, it should enter a maintenance phase. It is possible that over time errors will be spotted in the TCK and this needs to managed over time.
What resources are required to build a TCK?
People! People from the community and experts from the Java ecosystem. However, before this can be done we need to ensure that the planning phase is well underway before the actual development can take place. For people interested in ThreeTen and JSR-310 please familiarise yourself with the following documents and websites:
- The JSR Specification
- ThreeTen Documentation
- ThreeTen on GitHub
- How to build a TCK
- Lightning talk introduction
- About a new date time API
How long is it going to take?
It depends on the number of test cases that are identified, this will be part of the planning phase. A potential formula directly from the How to build a TCK document:
(A-Num × CovBreadth ÷ DevRate) × NumEng = Test Development Time (in weeks)
- A-Num is the number of testable assertions defined by the specification.
- CovBreadth is the coverage breadth goal. For example, 0.75 for 75% breadth coverage.
- (Note that the ideal practice is to thoroughly test all elements which requires 100% breadth and depth coverage. Assertion breadth coverage of only 75% means that assertion testing is incomplete.)
- DevRate is the test development rate. According to Sun’s experience a typical test development rate is approximately 12.5 test cases per week for a test developer to write, document, and debug assertion test cases (including simple test framework development).
- NumEng is the number of engineers writing tests.
I will use the above to estimate a back of the envelope time frame for the TCK and the preparation.
How can you get involved?
We are looking for volunteers to help us build the TCK implementation and that effort will be increasing over the next few weeks. If you are interested or would like to know any more information please drop me an E-Mail. There are many levels at which you can be involved with a project like this, it might be that you’d like to write some technical documentation, or actually get stuck into the code. Whatever challenge you are looking for, we look forward to having you on board.
At the LJC we’re trying to democratize the future development of the Java platform. The development of Java is run through the Java Community Process – which splits up changes to the platform into Java Specification Requests (JSRs). A JSR is a specification for a set of related changes to Java, and there are a lot of them. As an organisation that is trying to bring the wider developer community into the standards process in order to inform the decsion making process, improve the standard and innovate the platform we’re promoting the ‘Adopt a JSR’ program.
The idea behind Adopt a JSR is that you, a Java ecosystem enthusiast, can contribute to a JSR by following its progress, helping out on an expert group or informing the wider community of its progress and evangelising its benefits. You can take your industrial expertise and help progress Java in a direction that benefits you and the wider community. The LJC are a voting member on the JCP and can help facilitate any ideas or suggestions that you may have on the matter, so if you want to know more about how to get involved, please contact the LJC’s JCP Committee.
At present there are several JSRs that we’re seeking participation for.
- Date and Time (JSR 310) - the upcoming improvements to the Date and Time Api are requiring a TCK. James Gough (@goughjam) is helping coordinate the LJC’s effots here.
- Java Message Service 2.0 (JSR 343) – the next version of the important JMS standard is currently being developed. The LJC is in contact with Tim Fox and Colin Crist, who are working on this project.
- Bean Validation 1.1 (JSR 349) – a new maintenance release for Bean Validation. Do you use Bean Validation and want to help improve it?
- Session State Management (JSR 350) – introduces an API that will offer a modular system for dealing with State management, generalising some of the ideas from the HttpSession State object. Somay Nakhal is interested in helping out with this proposal.
Of course if you want to work on something else, or even propose a new JSR yourself, then don’t hesistate to contact us. We’ll also be documeting our progress on our wiki.
Perhaps you’re tired of some problem within Java that you’re always encountering. Perhaps you’re trying to give back to a community that has helped you grow as a developer. Perhaps you just want to contribute in a meaningful way to an important and influential platform. Whatever your motives, its time to contribute because Java needs you.
Recently, the London Java Community was elected onto the JCP (Java Community Process) board. The JCP is the mechanism for developing standard technical specifications for Java technology. The London Java Community’s membership on the board enables us to deliver content on upcoming and in-progress Java Specification Requests (JSRs) back to our growing community. It also gives us the unique opportunity to engage people working on the JSR projects and developers who have expressed an interest in contributing. We’re currently trailing the process of adopting a JSR. Although the process has not yet been fully defined, the first example we have selected is JSR-310, an improvement to the Java date system. Last month I presented a lightning talk on the topic of JSR-310 and Java Dates. This blog post will go into detail on some of the current limitations of dates in Java and will discuss how you can get involved in the ThreeTen project. The London Java Community JCP group believes this is an important JSR and will lead to an improvement to all developers using Java. If you are interested in finding out more about the LJC/LCP committee please contact @kittylyst on twitter, or drop me an email for more information.
Dates are a critical part of most software applications. Data models that represent something in the real world nearly always depend on timings or times of occurrence. Originally, Java had the Date class. There are a number of good discussions that have documented the limitations of the original Java Date class. One of the largest issues is that dates are mutable and therefore not thread safe, leading to an immediate issue surrounding scaling out applications that make use of Dates. Furthermore, Date is a DateTime, but confusingly there are also wrappers around Date in java.sql package for this. The functionality in Date and sql.Date are so similar that, especially for new developers, it can be unclear when and where to use each. Finally, there is no support for TimeZones in Java Dates, so building systems running in different regions and converting back to a centralised TimeZone was very complicated before the introduction of the Calendar class.
The Calendar class was added to the language later for TimeZone support and for more complex date problems. The problem with calendar was that it was still mutable, and formatting a date directly from a calendar was impossible – once again pushing the developer to understand the exact details of each implementation and when to use each.
The following code example is from a presentation given at JavaOne several years ago which highlights the above in one code fragment. A simple and readable piece of code shows 6 different bugs:
//Bug 2, 12 dates are indexed from 0 so, in this instance, 12 is out of bounds
Date date = new Date(2007, 12, 13, 16, 40);
//Bug 3, The timezone isn’t the ISO standard and requires and underscore to be correct
TimeZone zone = TimeZone.getInstance(“Asia/HongKong”);
//Bug 4, can’t create a Calendar from a date, you need to use a static instance of and then apply the date
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat(“HH:mm Z”);
//Bug 5 and 6, can’t format on a calendar or a calendar object like this
Joda Time introduced several new key concepts into the Date arena that make working with Date and Times far simpler from a programmer perspective.
- Instant – There is a Joda-Time class of “Instant”. “DateTime” is also an instant, but one that adds getters for the human fields. DateTime is immutable and therefore thread safe. Immediately we have a good replacement for Date.
- Interval – An interval is a time measured from one instant to the another. The limitation here is that both end points are in the same Chronology and TimeZone.
- Duration – Duration is simply an amount of time measured in milliseconds, no timezone or chronology applies to a duration
- Period – A period of time time defined in terms of fields. This is a really useful feature for working with dates from a human aspect. Whilst machines represent underlying dates in long numbers, we still split things down into months, days and hours. Consider saying “one month from now” in February and then saying the thing same in May. Even though the month is the same, the underlying number of days varies. Periods allow the programmer to specify this kind of logic without having to convert to seconds and then add these to the value of the object.
- Chronology – From the developer perspective, a chronology is under-the-hood and is the calculation engine which holds the complex calendar rules. In most cases this, is is ignored as most users will be using ISO Chronology.
- TimeZones – A representation of the TimeZone held within a DateTimeZone class.
JSR-310 builds on many of the concepts that were introduced in Joda Time. However, to have the most robust implementation available for Java, there are some key issues in Joda Time that had to be addressed in JSR 310. So Joda Time is not without its flaws, but this doesn’t mean it shouldn’t be used; it’s currently the best production ready system there is. Stephen Colebourne covers this in his blog.
Human and Machine Timelines – I was born on 29th September 2005, this is a human representation – a Java representation is the number of milliseconds since 1970-01-01T00:00Z. JSR 310 separates the concepts out in the underlying implementation to make intent clear.
Pluggable Chronology – This can introduce unexpected state to the system by its pluggable nature. Consider calling the month of the day, you could get 13 if the chronology was incorrectly set. It is likely that people don’t check this before they make the call. Keeping these things separate is good programming practice leading to better unit testing and fewer curve balls when debugging problems later.
Nulls – The treatment of null values is always up for debate, nulls could be treated as the epoch, rather than a null value. Having this fuzzy behaviour could lead to bugs where you simply didn’t realise that you had passed a null by hiding errors. JSR-310 will seek to treat nulls as exactly that, and not assume they are the epoch.
Internal Implementation – Most user interacting with dates may not realise the depth of the implementation that is required around such a system, for example most people will use standard chronologies and calculations with dates. However, the internal computations are complex, especially when coupled with chronologies and the human machine timelines. Ensuring this architecture is production standard for all users is not a simple task.
In JSR 310 some key decisions were made to move Joda Time forward by reworking some of the design concepts. What the user sees in the Joda time API is the tip of the iceberg. A lot had to change in order to have these design considerations in place.
The main issue that might compromise the inclusion into Java 8 will be around the TCK testing suite, which is likely to be required in addition to the unit tests provided with the current ThreeTen implementation.
The ThreeTen project (the reference implementation of JSR-310) is now on GitHub, so contributions can be made and pulled into the project. ThreeTen is developed entirely in the open and there are still a number of things to be done. Contributions around documentation, testing and performance optimisations are currently up for grabs. One such example would be working out the best way to derive the OffsetDateTime from an instant.
Getting involved is as easy as entering a few git commands and joining the mail group.
JSR 310 is currently one of the key JSRs and any additional community support should help ensure that the project enters the earliest version of Java possible.