Home > devoxx > JavaPolis 2007 – Day four

JavaPolis 2007 – Day four

Second day of the conference and I just have time to write about it (so much beer and socialization in this year’s JavaPolis). To be honest I didn’t attend the Flex talk, I only went there for the new Parleys site. It is built using Flex and it has several advanced Web 2.0 features. I won’t spoil the secret, wait till it’s released (now it’s in beta). Around January they will announce that they need some beta testers so if you’re interested keep an eye on the Parley web site.

Second talk I went into was the Java Persistence 2.0 API (JSR-317) by Linda Demichiel.The new JPA 2.0 was introduced as part of EJB 3.0 (JSR-220). The current JPA is still in the 1.0 release which has several issues and ambiguities (like optional functionality that was left as vendor specific to implement). The purpose of the new JSR is to solidify the standard and clarify all open issues.

The JSR 317 is still work in progress.

Among the things they will introduce is

  • a more flexible modeling and mapping with
  • ordered lists
  • collections of basic types
  • support for embedded types.
  • Multi-levels of embedables.
  • @OrderBy and @OrderColumn annotations.
  • New maps’ functionality in 2.0 version
    • a map key can be a basic type, an embedable and an entity
    • same applies for a map value.
  • new@Access annotation that will specify non-default behaviour. Classes in a hierarchy can have different access types.
  • It’s still under discussion whether to have
    • a table per concrete class
    • an inheritance mapping
    • and orphan deletion (it’s optional in the JPA 1.0 version).
  • Expanded query capabilities in order to improve the query language.
  • Specify what happens in un-fetched entities/relationships
  • Extended persistence context.
  • Bean Validation (JSR-303)
  • Other proposed functionality
    • More flexible modeling.
    • Expanded O/R mapping.
    • QL extensions.
  • Better portability, aligning with emerging JSRs.

Next presentation was the “Closures Controversy” by Joshua Bloch. This talk was given instead of the Effective Java Reloaded talk and was purely speaker’s opinions expressed not Google’s. To be honest I wasn’t familiar with the closures syntax at all and didn’t understand several of the features Joshua was talking about, but the closures sure makes the Java syntax ugly. I cannot comment on any other parts since the presentation consisted mainly of closures examples taken from the BGGA. So better study the BGGA spec and find out yourself.

Next session was JavaPosse live by Dick Wall and Carl Quinn (wearing these weird hats lol) with the remote help (via Skype) of Tor Norbye and Joel Nuxxol. They presented the usual JavaPosse news straight from JavaPolis.

Next talk was JSR-310, Date and Time API by Stephen Colebourne (also author of Joda time). The idea is simple, the current date and time API has several misleading features (months start from zero, year starts from 1900 etc) and Stephan in this JSR suggests a way to overcome these issues.

The JSR-310 is a very open process. It has public mailing lists, a public wiki and SVN repository and a public bug & features request database. Therefore anyone can participate.

The JSR suggests a few things:

  • The date should be immutable. This gives several advantages. it cannot be changed after it’s created, it is thread-safe and it can be a singleton.
  • Should use the builder pattern in order to create a date.
  • We should have fewer sub/superclasses.
  • Have only one class of date that wil be called Instance.
  • The interval of time can be represented as an Interval class.
  • The duration of time as a Duration class.
  • The format of the time should follow the ISO-8601 format: {date}T{time}{offset}. For this we can have
    • LocalDate
    • LocalTime
    • LocalOffset
  • With regards to the bullet point above we can have one class for each combination, like LocalDateTime or OffsetDate.
  • The date can be split down into year, month of year and day of month. Each one of them can be represented as a different class.
  • There should be a Resolver class that can resolve invalid dates such as 30th of February as well as DST changes.
  • We should use the strategy pattern for the resolver.
  • Integration with existing classes should be done via interfaces. We can change the current date & time classes to implement the same interfaces like ReadableDate (java.sql.Date implements ReadableDate).
  • All new classes do not reference any of the old JDK classes.
  • In XML we define similar connections, for instance:
    • xs:date corresponds to ReadableDate
    • xs:gYearMonth to ReadableYearMont
  • We implement several classes to handle specific dates. Each class should implement ReadableDate.
    • HebrewDate
    • JapaneseDate
    • BrazilianDate
    • etc.

For those who use Joda time and they want to move from existing Joda implementation will require to do a few changes.

Last talk for today was The Java Puzzlers with Joshua Bloch and Neal Gafter. They run through several java gotchas and demonstrated how easy it is to fool the Java programmer. I don’t have the code slides wiht me so I will go quickly through the dos and donts

  • The remove method in the Set interface does not work with generics since it still takes an object as parameter.
  • Hash code and equals methods of URL are broken. Use URI instead.
  • JUnit does not support concurrency. It can throw exceptions that are never seen. If you are testing threads always pass the exception to the test framework*.
  • Add try... catch around assert methods.
  • Auto-boxing happens when you least expect. Try to avoid it.
  • Order of executing static statement does matter.
  • Use primitive boolean instead of object Boolean.
  • Never use a Boolean to return true, false or null (I don’t know).
  • InputStream‘s skip() method does not guarantee to skip all data.
  • In general if an APi is broker wrap it to something that hides the brokeness and behaves better.
  • Math.abs() does not guarantee a positive value since Integer.MIN_VALUE == Integer.MAX_VALUE.
  • Do not mix data types.
  • Silent”widening” is lossy and dangerous.
  • Almost never use float. Only use it if you have an array with huge amounts of floats.
  • Overloading is dangerous.

* Define some error handling in the tearDown method

volatile Exception ex;
volatile Error error;
...
tearDown()
{
if (error != null) throw error;
if (ex != null) throw ex;
}

Advertisements
Categories: devoxx
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: