JSR-310 Method Naming Survey Results

Latest blog post of Jim writing for the London Java Community can be found at the following link.

What’s the point in a TCK, and why should you care?

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

• E-Mail
• 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 blogpost

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)

Where: 

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

About JSR-310 - A New Java Date/Time API

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 1, 2007 although you think this is the date you actually need to subtract 1900 to get the true representation
//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

String str = fm.format(cal);

Joda Time

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

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.

Getting Involved

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.

Conclusion

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.

Jim Gough

Please post all comments on the LJC blog.

A cURL drop-in replacement for simplexml_load_file()

When using shared hosting (such as that provided by Dreamhost, Servage, etc.), the very nature of multiple users hosting from a single server (without their own virtual machine) means that a number of concessions have to be made in order to keep the service secure. At the "obvious" end of this spectrum are OS-level measures such as blocking root access, disabling useradd etc., but there are also myriad additional concerns that arise when configuring PHP (and other server-side scripting environments) for use in a shared hosting environment.

In the case of PHP, common measures include disabling functions that allow for file execution (exec, system, proc_open, etc.), turning register_globals and enable_dl off and, the focus of this post, disabling certain functions that allow remote files to be loaded from a URL. This can be achieved by setting allow_url_fopen (or, less stringently, allow_url_include) to false in the server's php.ini file. The main problem this presents for users of shared hosting is that this setting can only be set in php.ini (and can't, therefore, be modified at runtime using ini_set()). The implications of setting allow_url_fopen to false are fairly wide-ranging, as it disables all access to remote files through "URL-aware fopen wrappers", which includes anything that calls include(), include_once(), require() and require_once() with a remote URL.

In a recent project we were working on, we were hit by this problem during testing. The problem actually stemmed from our use of simplexml_load_file(), which makes use of an fopen wrapper internally. Happily, the client URL (cURL) library was installed and functional on the shared hosting, so we were able to write a simple replacement using cURL and simplexml_load_string():

$url = "http://example.com/remote.xml";

if (ini_get('allow_url_fopen')) {

$xml = simplexml_load_file($url);

} else {

// Setup a cURL request

$curl_request = curl_init($url);

curl_setopt($curl_request, CURLOPT_HEADER, false);

curl_setopt($curl_request, CURLOPT_RETURNTRANSFER, true);

// Execute the cURL request

$raw_xml = curl_exec($curl_request);

// ...Check for errors from cURL...

$xml = simplexml_load_string($raw_xml);

}

The code is (hopefully!) self-explanatory, with the possible exception of the (fairly minimal) cURL options. Setting CURLOPT_HEADER to false omits the HTTP headers from the returned output, whilst setting CURLOPT_RETURNTRANSFER to true causes curl_exec() to return the response as a string rather than outputting it directly. Finally, the handling of cURL errors is a topic unto itself, but the error number from the last cURL operation can be obtained using the curl_errno() function, passing in the cURL handle returned from curl_init().

Java 7 Launch Event

Thursday the 7th of July saw one of the largest milestones in Java's recent history, the much anticipated launch of Java 7. My initial reaction was it didn't seem that long since Java 6 was launched, however it was almost 5 years ago, the technical equivalent of when dinosaurs still roamed the Earth.

I think it would be naive to assume that nothing has happened during the reign of Java 6, in fact it's quite the opposite. The first step towards a better Java was the open sourcing of the JDK, giving developers the opportunity to fix and work directly on the platform. Although I don't have a direct quote, at the LJC Open Conference in November 2010 it was stated that between the first version of Java 6 and the latest there was a performance gain of over 50%. In Java 6.14 we saw the introduction of the G1 Garbage Collector, another revolutionary change to the options that developers have in terms of tuning and performance. Politically Java has changed hands and governance, passing from Sun to Oracle, and people have their opinions on what this means for Java.

Up until Thursday I was very skeptical about where Oracle might go with Java and how that would change the language I have built my career on. Which brings me to the launch day itself, this began with a webcast held across the world by Oracle. If you missed the webcast you can view it here. We got to hear from some of the senior developers on the Java project, and also from community speakers from all corners of the globe. For the London Java Community, it was an absolute honor and pleasure to see a small group of users that has now risen almost 1800 members, represented by Ben Evans. I really enjoyed the webcast and thank Adrian Woodhead at lastfm for their hospitality in hosting the webcast for other members of the LJC. That gesture of sharing is something that was also not far from the content of Oracle's talk, as many people appreciate one of the biggest successes of Java is us - The Community. The value of this has certainly not been underestimated by Oracle and this was evident from the content of the webcast. So what do I think the main themes were to take away from the talk and the event?

• Java 7 is an evolutionary release not an revolutionary release - Mark Reinhold stated that one of the best things about Java 7 is the fact it is shipping.
• Increase in stability
• Increase in performance
• Increase in maintainability
• ...Although not said explicitly, the feel of the community is Java 8 is definitely not as far away as the gap was from 6 to 7.

For the event there was then kind hospitality at the Oracle offices, with people from across the community together with a definite buzz and excitement in the room about Java once more.

What is new in Java 7? This could be an entire post/book in itself and each individual improvement could be gone into in great detail. I'll attempt to pick out a few key points below and give links for more information. I'd also recommend reading Mark Reinhold's blog. The best summary of the below I have read so far is in Java 7 developer MEAP, by Ben Evans and Martijn Verburg.

• JSR 292 Invoke Dynamic
• This is one of the major steps that we are seeing towards a change in the way that we view Java. What even is Java? I think we are seeing a separation of Java the language and the Java Virtual Machine. Strictly speaking, it's not really the Java VM now, but just the VM. Highlighted by the gentleman in the video wearing a Python jacket over a Java T-Shirt, the VM is now home to many dynamic languages. Invoke Dynamic is another step towards the multi-language support for the JVM. Simply put it supports the invocation of allows a non-Java call to be made and for the linkage to be determined at runtime... OK that wasn't so simple, but you can read more about the project here.
• JSR 334 Project Coin
• Project coin are all about small changes to the Java language to make life easier for daily use of the Java programming language. A few of my personal favorites are:
• Ability to switch on String! Finally, it's only taken 15 years.
• Diamond Operator, no longer do you need to declare the generic expression on the right hand side if they are present on the left: 
• Old Way: List<String> myFingersAlreadyHurt = new ArrayList<String>();
• New Way: List<String> jsr334SavedMyFingers = new ArrayList<>();
• try-with-resources - lets get rid of some boiler plate code
• You can find the full list here.
• Better Unicode Support
• Not too excited about this because it's not a problem I run into. However, from speaking to a few people about this at the event - this was going to save them a lot of hassle.
• JSR 203: NIO.2 and File System
• Finally, we have a decent API for interacting with Files and a scalable approach to asynchronous I/O.
• I'm not an expert on the rest of this JSR yet, so might be worth having a read here if you want to know more.
• JSR 166y Fork Join Framework
• Doug Lea and his concurrency experts have created the Fork Join Framework. This allows for concurrent tasks that involve splitting a larger programmatic problem into smaller blocks of computation i.e. Merge Sort a nice framework in which to operate. The ForkJoinPool uses workers to perform the tasks placed upon it, which are also capable of stealing tasks from other workers if they are no longer busy.

I think the next few months in the Java community will be exciting ones, with July being very much the month of Cloud and is Java the right language for the cloud? For those in London that haven't been along to a Java event yet, please come along and join us on meetup.com and join us at our developer pub session to get involved in the discussion.

Moonlighting as a Company Director......

...and so it begins! 3 years ago we were sat in the finest drinking establishment in central London, Walkers of Whitehall, in the 2 leather wing back chairs in an old bank vault. In these chairs our first business ideas as a duo, two friends from school and A-Level Computing, started to take shape. Our first idea was huge, it was a novel concept that would (and still has the potential) to shake up the entertainment industry for a night out in London. We left the pub after 8 hours of brainstorming through the day, the bar went from empty to packed to us the last patrons in there. We produced some Google docs together for a proposal of what we would plan to do, the software we would develop and the plan for how it could all work. There were several problems:

• High Risk - The idea involved a high level of personal and financial risk and we would have to be involved in starting the business from scratch including obtaining funding.
• Bad Timing - The recession was upon us, literally. Many people I knew had lost their job and I felt I had to fight for mine without additional distractions.
• Location - I was about to move to New York for several months and Rich was living in Switzerland, what seemed like great ideas would have to be shelved.

About a year ago, we returned to the same pub and sat down to talk about potential future plans. At the time I was ready to leave my job for something new, and naturally the conversation progressed into ideas for the future. It was then we had the idea to create StackThread Software Ltd, unlike the previous idea for a start up this would be both risk free and involve minimal investment other than our own time. iPhone and smartphone technology was specifically something that we both found appealing and diverse enough from our day-to-day roles to be interesting to do in our spare time. This also gave us the risk free start up and access to a wide user base to try out working together and producing software. Application 1 was coined at this time, we thought it would take around 5 hours to develop, it has probably taken more like 12 full days and a total of 10 months to get the concept into a polished version.

The reason this took so long, wasn't down to the application development itself, but the other factors which if you aren't careful can stop a start up dead in its tracks. Specifically if you already have a full time job:

1. Approvals - usually if the firm you work for is larger than medium size you are going to require compliance based approval from the firm first. This involves forms, questions and more forms. 
2. Register a company - this is relatively easy to do in the UK, but the forms are very specific. We made several school boy errors on our forms - one date missed, one Ltd missed off the name on applying for a limited company form.
3. Register with the Apple Developer Program. This isn't too bad if you can find a fax machine, the process took us around 10 days. In order to perform this step you need to have completed both 1 and 2. 
4. Open a bank account. In order to do this you need to have done 1 and 2. We are still waiting for this step to complete, and still waiting for a phone call back from one bank who state they help businesses we asked for their help 14 days ago.
5. Configuration - You're registered on the Developer Program yay! Not quite done yet, you have to setup the team give them the access required and also link in the bank account to the legal contracts etc. We're here now waiting for 4 to finish.
6. Release the application - So now the main problem we have is we only got an on device version last week, so performance testing is ongoing.
7. Tax - Still need to think about this.

So the company account is down £80, with the registration and company fees paid and we're not even sure if Apple will accept the concepts we have as acceptable applications. Still it's only £40 each!

The process we've been through has taught me several things that having always worked in large companies I'd definitely never have known or experienced. If you're planning to do a start up, pick something that you enjoy and can see your spare time going in to. Right now we have 2 nights a week on average coding over Skype and weekend meet ups every month in London or Basel. We also have our first international conference in Prague in 2 weeks. Laptops in the pub! The next part goes without saying, only go into business with someone you get along with. If you're doing application development you're going to be spending a lot of time talking and working together. You're going to be wrong a lot and right a lot too, balance and banter is key.

Our main aim is to have fun building high quality products and a business from nothing to a successful entity. For the first year our aim is to build a portfolio of iPhone and iPad based applications, potentially expanding out into web based solutions where necessary. We're already starting to see interest from people asking what we're doing and even interested in asking us to develop applications for them. All in all, it looks like it will be one hell of a year!!