Yay! I've successfully navigated the long drawn out process of releasing code from Apache, and Commons-IO 1.1 is now available for download.
(For those of you wondering, Apache demands way more security checks and file updating than a sourceforge release. Thats why, I try and avoid being release manager at Jakarta Commons if possible.)
Anyway, enough of my whining... just go and get the new release! It makes coding any kind of simple IO just a whole lot easier!
I was coding in commons lang earlier tonight when I found one of my test cases wasn't passing. It took a few minutes to realise my stupid error. So here's the test! Can you spot it too???
public int readToken(char[] chars, int start) {
int pos = start;
while (pos < chars.length) {
if (chars[pos++] == '"') {
return pos;
}
}
return start++;
}
(By the way, there are lots of possible errors here like NPE and this is a very simplified version of the actual method, however somewhere here is a particular 'weird' error.
Did you find it?
Its the return statement. You might think on glancing at the code that the method would return the value of start plus one. But it doesn't. It returns the value of start, as the ++ occurs after the return statement. Obvious really - yet in a non-obvious way. The fix of course is to do return ++start; ;-).
(Sorry if you got it straight away, but it amused me for a minute or two...)
It took a while, but version 1.1 of Joda-Time, the replacement for JDK Date and Calendar, has been released!
This release does fix a few bugs, however these were mostly relatively minor. It does however include a number of useful new methods and usability enhancements. For example:
And stay tuned for announcements about Hibernate and JSP integration!
Full details can be found on the website.
Oh, and if anyone wants to help develop another calendar systems, such as Hebrew, Islamic, Chinese, etc. then please contact me!!!
The problem is that the Java class libraries have changed between JDK1,3 and 1.4 (and so on). Each change provides the potential to break the build.
For example, in JDK1.4 a new method was added to StringBuffer - append(StringBuffer). In itself, this was not newsworthy. However, this method overloads (not overrides!) other methods, notably append(Object).
If you compile using JDK1.4, and you are appending a StringBuffer to a StringBUffer, javac will choose the nice JDK1.4 append(StringBuffer) method. When you use this JAR on JDK1.3 however, you will get a NoSuchMethodError (not Exception!). This is because overloaded methods are bound into the bytecode at compile time.
Oh, and that 'use 1.3 bytecodes' flag in javac? Well that makes no difference. It just avoids writing bad bytecodes, and doesn't check for valid methods.
I'm writing this because it has come up twice recently on commons-dev. Firstly, during the release of Jelly 1.0, where it took quite some effort to convince people of the problem. Secondly, during ongoing work on Email 1.0, where exactly this issue occurred.
The only safe solution is to:
Its not a maven issue per se, but maven does require a higher JDK to run itself than most of the libraries I release. Now, I am told that maven can build using a different JDK version to that which it runs on (maven.compile.executable). Well, great if that works. But, I'm not sure that I trust it to actually do all the necessary steps.
Hence my appoach - all compilation steps are done with ant. All website steps are done with maven. Just using the right tool for the right problem in my book.
And its a bit like that with Joda-Time. v1.0 is done and out in the wild. There was quite a bit of positive feedback, but I've no idea how popular it really was because Sourceforge statistics are up the spout.
The main question then becomes well what next? v1.1 would be the obvious answer, but I need to gather some energy to add more code. And until and unless I get feedback on Joda-Time in use its difficult to know what people are missing.
The other possible direction is a JSR. Various people have suggested this, but I am a little skeptical. JDOM, Jade (scientific units) and Groovy haven't exactly been good indicators of what JSRs do to open source projects.
So, what do people reading this think. Are you not using Joda-Time because its not in the JDK? Is a JSR a good direction to go? Have you got your own ideas for what java.time should look like?
Full details can be found on the website. However, let me draw out a few key features:
- Easy to Use - Calendar makes accessing 'normal' dates difficult, due to the lack of simple methods. Joda-Time has straightforward field accessors. And the index of January is 1!
- Extensible - Joda-Time supports multiple calendar systems via a plugin mechanism, which is much more extensible than the subclasses of Calendar. Currently supported calendars are ISO8601, GregorianJulian, Buddhist (Thai) and Coptic.
- Comprehensive - Joda-Time includes classes for datetimes, dates without times, times without dates, intervals and time periods.
- Advanced formatting - An advanced and extensible formatting mechanism is included, allowing input and output to string in a thread-safe manner.
- Well documented. There is documentation in the form of a quick and full user guide, plus reference pages, FAQs and javadoc.
- Tested. There is good test coverage, see the website, providing an assurance of quality.
- Built in security. Advanced operations that could prove a security risk (like changing the current time) are protected by standard JDK security.
And if you learn best by an example:
public boolean isRentalOverdue(DateTime datetimeRented) {
Period rentalPeriod = Period.days(2);
return datetimeRented.plus(rentalPeriod).isBeforeNow()
}
public boolean isJoinedInLastThreeMonths(DateTime datetimeJoined) {
Interval last3Months = new Interval(Period.months(3), new DateTime());
return last3Months.contains(datetimeJoined);
}
public boolean isBirthdayInLeapYear(YearMonthDay dateOfBirth) {
return dateOfBirth.year().isLeap();
}
So, now its released, what next? Well I hope that some of you reading this will want to help add some other calendar systems, such as Hebrew, Islamic, Chinese, etc. Any takers?
The plan is to get a few days feedback on 0.99, remove the deprecated methods, then release as 1.0 next week (and definitely before the end of February).
By the way, if you used version 0.98, you'll need to read the release notes, as there were a few last minute changes between 0.98 and 0.99. But I'm determined to let nothing stop 1.0 ;-)
Oh, and if you want to help out by developing another calendar system, Hebrew, Islamic, Chinese, Thai, Japanese,... just drop me a line !