JavaOne 2011 - Days 1 and 2 (Sunday/Monday)

Hi all,

So I'm at JavaOne and it's been an interesting first couple of days!  I'm live tweeting a number of live announcements and insights but I thought I'd try to round-up my experiences so far on Days 1 and 2.

Apologies for anyone/thing I've missed - it's been a whirlwind! 

Sunday


My Walk

I started the day with an interesting walk from my apartment to "The Zone".  First thing that struck me was the vast numbers of homeless people on the streets, really sad to see and not what I expected from San Fran at all.  They say that Britain is a broken society, I think I'm seeing worse here in San Fran.

JUG Leaders Brunch

The JUG Leaders and Java Champions brunch was the first thing up on Sunday morning.  It was fantastic to put names to faces (a bunch of us only knew each other from the mailing list) and of course to see familiar friendly faces including Stephen Chin, Bruno Souza, Fabiane Nardon, Kirk Pepperdine, Stephan Janssen and many more! Oracle gave us a briefing on what was going to be announced in the keynotes, one of the focuses being on Java FX 2.0. I'm still personally not sure whether it's going to be 'too little, too late' given the rise of HTML5, but then again I'm not heavily involved in the UI space.

User Group Sunday

The rest of Sunday was spent with the JUG leaders and other community members for a bunch of Open Conference style sessions.  It's always good to discuss the issues that we all commonly face, thanks to John Yeary for organising.

The Duke awards were presented that evening outside in the Mason Street tent/cafe area and LJC's Trisha Gee accepted a Duke innovation award for the Disruptor framework that her company (LMAX) has been working on.  The Zero Turnaround guys also picked up their well deserved award for JRebel.

The evening ended with us meeting up with Charles Nutter and some of the other JRuby crowd at the Glassfish party in the Thirsty Bear, it never hurts to get free beer! Was also nice to see Dan Hardiker and a certain Mr Gosling there.

Monday

The Good

1. Oracle's stance and genuine efforts with the community.

• The Duke awards on Sunday night
• The free coffee and beer
• Featuring non Oracle speakers on the JavaOne front page
• The technical content of the overall program being determined in conjunction with a community committee.
• Their community interviews
• And more!

Credit goes to all of the Oracle team behind this including Nichole Scott, Sharat Chandar, Mark Reinhold, Henrik Stahl, Adam Messinger, Mary-Lou, Tori Weildt, Dalibor, Donald and many more!

2. Parts of the Keynote were really good.  Mark Reinhold was very clear explaining Java 7 and 8, the Java FX 2.0 demo with the Kinect controlled Duke went down well and they involved the JRuby guys to explain invokedynamic and what it means for non-Java languages.

3. The Mason Street area and the hangout spaces in the hotels are pretty cool

4. Attendance was way up from last year, real buzz about the place, it's pretty clear that the Java platform is going through an upsurge, exciting to see.

5.  JCP matters again.  We had lots of people turning up to the JCP events, buoyed by the results of JSR-348 (step one in reforming the JCP) with lots of feedback and interactive Q&A.  Even the public EC meeting was packed out!  I was on the panel for a number of these events and was really happy with the amount of interest and feedback, especially considering they're effectively non-technical sessions.

6. Good talks on Lambda (Alex Buckley) and Jigsaw (Mark Reinhold) for Java 8 from experts who actually engaged the audience!

7. The O'Reilly cocktail party, was able to talk shop with fellow authors and catch up with friends from OSCON such as Laurel Ruma, Sarah Novotny and the rest of the O'Reilly crew.

The Indifferent

1. Oracle have tried their best with "The Zone", but the fact remains that running around the 3 hotels is still fairly difficult and trying to find certain rooms inside the hotels also leaves attendees missing out on their events.  I haven't put this into "The Bad" section as the sign posting and extra helpers made it bearable (just).

2. The speakers room was very small and has limited WiFi signal, Oracle, please talk to the OSCON folks on their set-up!

3. Getting my photo taken in an alleyway in the rain for a tech magazine - us developers don't usually make good models, as was proven today!

4. Some of the even rooms are still small and pokey and seem to be stuck in a basement level (Parc55 in particular)

The Bad

1.  The WiFi constantly drops in and out, ruining some presenters demos and causing immense frustration for attendees.  Lessons need to be learned from some of the European conferences such as Devoxx and FOSDEM.  Hoping this improves tomorrow.

2. The Intel part of the keynote.  Caused the entire keynote to be late (they rambled on), was boring (some pretty hokey bar/line graphs) and the its content was better suited to OOW as opposed to JavaOne.

Phew - busy days so far, looking forward to sleep :-)

Cheers,
Martijn

My Interview with MyFear

I was humbled to be interviwed as part of MyFear's Java Hero's series - If you want to know some of my motivations then go here

The OpenJDK as the default Java on Linux

Hi All,  (this post is x-posted to the java7developer blog and the ljc blog)

Recently I've received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it :-)

Background

Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source "Operating System Distributor License for Java" (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle's Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve 'official Java' for all of us. 

I want the Oracle version!

Linux users who need to use the proprietary parts of the Oracle JDK 6 or Oracle JDK 7 binaries can of course as usual simply get the gratis download at http://oracle.com/java under the same terms as users on other platforms. However, if it is due to a 'bug' that is discovered I strongly encourage those users to submit a bug report to the OpenJDK project, so that any issues can be fixed for all of us.

Opinions and further questions are welcome!

Thanks,

Martijn

JavaOne schedule

Here is my JavaOne schedule:  I can't mimic the nice colouring that Steve On Java has, but hey :-).


Please note the JCP EC meeting is open and free for all to join (Sunday 15:45) - we need the voice of the community there, so come along!


I'll actually be speaking at:

• 30440 - Java User Groups and the JCP (Sunday 14:30)
• 23647 - JCP and the Developer Community (Monday 11:00)
• 23641 - Meet the Executive Committee Candidates (Monday 1900)
• 23645 - Lightning Talks: JSRs in Progress (Wednesday 0830)
• 25303 - The Diabolical Developer (Redux)  (Wednesday 1500)
• 25303 - The Diabolical Developer (Redux) - repeat!  (Wednesday 1630)
• 37780 - Java Community Keynote (Thursday 0845)

Let me know if you want to catch up!  I'll be fairly flexible about turning up to most sessions, the benefit of attending a conference like JavaOne is as much isn't catching up with friends an colleagues as much as anything else :-)

The Data Grid JSR Backlash and why you should support the JCP reforms

The recent backlash against Red Hat's data grid JSR proposal sparked an interest as I know the JCP is going under reform right now.

For those of you who have missed the debates, here's some background reading for you:

• http://bit.ly/gDrtP3,
• http://bit.ly/eeOWWF
• http://bit.ly/hKiNg1

So, here are my thoughts on the subject!

Technical merits

On technical merit the JSR proposal certainly seems sound enough to be a solid starting point for discussion (I'm no expert mind you).

Open standards are good

It's a laudable goal to standardise this space, and Red Hat have got my support on that front. Just like vendor lock-in was bad for databases and app servers, it's also bad for developers and users of data grids.

This area is potentially worth Billions and so I can understand why some vendors may be reluctant to form an open std around it, but really, it's a good thing! I believe the vendors should be competing on performance and other factors, not basic get and put type API calls.

Where the proposal went wrong

Politically, Red Hat went about this in an unusual way, hence the backlash. Sadly, that sort of backlash can be enough to sink a JSR before it even sets sail.

I was a surprised that an organisation with so much JCP experience presented this JSR without the usual pre-collaboration that typically goes on in these cases. So I dug a little deeper to find out why Red Hat had gone about it this way.

The root cause

Without knowing all of the ins and outs, the new data grid JSR was proposed partly because of Red Hat's frustration with trying to get JSR-107 (data caching) back to an active state (it's been an inactive JSR for some time).

A std caching API (JSR-107) would be a natural base for any agreements around standardising any further data grid APIs on top of that.

Red Hat (and others?) had tried to re-vitalise the JSR-107 Expert Group to get the JSR re-opened, ratified and released. That would've been a great start, as it meant that there would be collaboration amongst the same vendors that are then needed for a subsequent data grid JSR.

Why did that attempt fail?

We don't really know. Unfortunately nobody on the outside can confirm what was/is going on as the JSR-107 mailing list is closed to the public!

This is the crux of the problem with the existing JCP rules, in that 'open standards' are being decided behind closed doors. Thankfully Patrick Curran is working on changing this (see! Oracle isn't always evil ;p).

So what happens next?

By raising the new JSR, Red Hat has gotten their desired result of getting JSR-107 moving again to complete the caching work. It's a shame that they were seemingly forced into this stance.  We'd all much rather see deliberate community collaboration, it's certainly not a model of how we want to see inactive JSRs moving again!

Red Hat's intentions are almost certainly completely honourable, but as some of the other vendor's stated, the raising of the new data grid JSR came across as a great surprise and was therefore not as welcomed as it could have been.


So, JSR-107 will go ahead, but it'll take some amount of bridge mending before data grid JSR gets off the ground.

Lets avoid this in the future and support Patrick Curran's JCP reforms!

Cheers,
Martijn

OSGi - Are we there yet?

A few nights ago John Stevenson (@jR0cket) and I were fortunate enough to be taken through a explanation of OSGi by some of its key proponents: Neil Barlett (@njbarlett), Zoe Slattery (@zoe_slattery) and Alasdair Nottingham.

I have certainly battled JAR hell and have also experienced problems with keeping web and enterprise applications isolated from each other (manipulating parent delegation and CLASSPATHs anyone?). This has been throughout my Java career (~10 years now), but I had never investigated OSGi properly as an alternative. Why? Because I never spent the time investigating OSGi properly and I was under the strong impression that it was better suited for IDE, App Server and tooling development as opposed to application development.

So after a good couple of hours of discussion I came out with a greater appreciation for OSGi and the following conclusions.

The Good

OSGi's core principles are pretty sound

OSGi is a sound solution for modularity, it clearly breaks the developer away from the artificial JAR model of 'modularity' and instead gets you to think about what Java packages you are dependent on. Through some simple metadata information in your manifest file you can specify the packages that you are dependent on (including a version range). For example, your test code may rely on the org.junit.core package within JUnit. Normally you would reference the entire JAR, but with OSGi you can reference just the package org.junit.core, as well as the version range that you want (e.g. 4.7.1 to 4.8.2). That package can then be supplied by any bundle (which still uses the JAR construct) which 'exports' it. You can probably already envision that a much smaller bundle can be provided than the default large JUnit JAR file.

OSGi actually encourages you to design better APIs

For those following the various clean code or software craftsmanship movements will appreciate the fact that by utilising OSGi, the developer is actually encouraged to think about splitting their public API into loosely coupled 'bundles'. The analogy here is that of Maven, which although polarises developers, does encourage them to use a correct build life cycle (clean, compile, test, package, environmentalise). good API developers should certainly look at supporting OSGi in order to help them designed better APIs

OSGi is relatively easy to get started with

You can start with an existing application and simply provide the OSGi bundle information in the manifest file for that JAR. You will tend to find that a vast majority of the dependencies already have OSGi bundle versions and it is not difficult to swap to an OSGi based build using Maven or Ant. In fact, as OSGi is already a well established technology it probably pays to have an OSGi bundled version of any project artifacts you produce. The tooling is adequate on most major IDEs (especially Eclipse) although the OSGi community would still like to see improvements in this area.

What the OSGi alliance is working on improving

A common/std tool for deploying OSGi applications to runtime environments

OSGi does have a std API for deployments, but this does mean that developers need to implement a deployment mechanism for deploying their apps to runtime environments. Most modern application servers do have OSGi container support, but the deployment mechanism is arguably different each time. This is an area that the OSGi alliance is working on and hopefully some standard tooling around this standard will come out soon. Although it seems like a small usability gap for OSGi, my guess is that this is a real adoption blocker.

Like Java apps in general, OSGi bundles are not Linux/UNIX distro friendly

A major complaint from Linux and UNIX distros over the years has been the fact that Java is not installed according to their packaging standards. Java is also an relatively large installation, which is the source for further criticism. Whilst OSGi certainly helps with the size aspect of Java-based programs, as it is also a late-binding runtime container it does not lend itself to the static, early binding packaging systems that the distros use.

As John pointed out, the existing Iced Tea (OenJDK) project does already produce bundle data that looks a good deal like OSGi bundle data:

Looking into the meta-data of the openjdk-6-jdk package, you can see there is a lot of scope for using OSGi style information.

Package: openjdk-6-jdk
Priority: extra
Section: devel
Installed-Size: 34100
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: OpenJDK Team <openjdk@lists.launchpad.net>
Architecture: amd64
Source: openjdk-6
Version: 6b20-1.9-0ubuntu1
Provides: java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk
Depends: openjdk-6-jre (>= 6b20-1.9-0ubuntu1), libc6 (>= 2.4), libx11-6, zlib1g (>= 1:1.1.4)
Recommends: libxt-dev
Suggests: openjdk-6-demo, openjdk-6-source, visualvm
Conflicts: openjdk-6-jre (<< 6b17~pre3-1), openjdk-6-jre-headless (<< 6b17~pre3-1)
Description: OpenJDK Development Kit (JDK)

However, this does need to be investigated further and perhaps if OSGi and project Jigsaw can interoperate and some tooling is built then I could see bundles being deployed according to distribution standards. This would help Java and OSGi applications gain even more acceptance amongst the Linux/UNIX community. This leas us onto the Jigsaw issue...

The (Potentially) Ugly

Project Jigsaw (Java modularity) is coming as part of JDK 8 and at this stage is not going to work hand-in-hand with OSGi. It is not beyond the realms of possibility that the two will interoperate cleanly in the future and I'm hopeful that the two communities can continue to find common areas despite their fundamentally different approaches.

However, if they do not come together in some simple to use form then it is likely that the Java modularisation space will be fragmented which will only harm the end developer, end user and the Java ecosystem.

You can read more on this topic on a blog post by my co-author for "The Well-Grounded Java Developer" Ben Evans. This post has also been cross posted to the LJC blog.

So are we there yet?

For mainstream adoption by application developers, probably not _yet_. But I think when the tooling gap is closed and as more application developers release OSGi apps, it might just become a de-facto standard for modularity in Java apps. However, there still remains the looming specter of Jigsaw integration/interoperability. There have been signs of the two sides discussing how they can meet in the middle, lets hope that continues.

Cheers,
Martijn

Bit of a hiatus

Hi all,

With "The Well-Grounded Java Developer" deadlines approaching and my arms starting to feel the strain I'll be taking a break from writing any blog posts for a few months.  Not that it's been real busy here anyhow, but I thought you should know :-).

Cheers,
Martijn

JBoss - separating application logs without using monolithic jboss-log4j.xml

A minor irritant we've discovered in implementing applications for Jboss AS is that that the logging configuration for applications has to go through their monolithic jboss-log4j.xml file.

So we've managed to find a work-around (after some investigation of the Jboss class loaders and some trial and error).  This technique has been confirmed for jboss-eap-4.3 and jboss-4.2.3.GA but will likely work for other versions.

If you want to have split application logs and have that log4j.xml based configuration separated out (e.g. Not have it all in the jboss-log4j.xml file) then you can do the following.

1.) Your WAR/EAR must contain log4j-1.2.16.jar. It must be 1.2.16 or later as earlier versions don't work.

2.) The class loading for that WAR or EAR must have its java2ParentDelegation=false. So for example the jboss-app.xml file will look something like this:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE jboss-app PUBLIC

      "-//JBoss//DTD J2EE Application 1.4//EN"

      "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">

<jboss-app>

  <loader-repository>${your domain}:archive=${your app name}.ear

    <loader-repository-config>java2ParentDelegation=false</loader-repository-config>

  </loader-repository>

</jboss-app>

Now this means that the WAR/EAR will use the log4j-1.2.16.jar for logging within its own classloader, i.e. It will not use Jboss's log4j.jar library (and therefore the jboss-log4j.xml won't be used).

3.) In the MANIFEST.MF file in your WAR/EAR archive you need to set a Class-Path: entry that shows the location (directory) where the log4j.xml file that you want to use will reside. For example if your EAR file is deployed in the deploy directory, your Class-Path reference might be something like this:

Class-Path: ../conf/log/${application name}/

4.) Your log4j.xml file should just be an ordinary one, with no references to any special jboss classes. However, it will have an appender with the specifc name for the log file for the application you want to log for, e.g.

  <appender name="${module.name}" class="org.apache.log4j.RollingFileAppender">

    <param name="File" value="${jboss.server.home.dir}/log/${module.name}.log"/>

    <param name="Threshold" value="INFO"/>

    <param name="Append" value="true"/>

    <param name="MaxFileSize" value="2MB"/>

    <param name="MaxBackupIndex" value="20"/>

    <layout class="org.apache.log4j.PatternLayout">

      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>

    </layout>

  </appender>

5.) OPTIONAL: You can still have all of your logging also go to the shared central $JBOSS_HOME/${instance}/log/server.log file by adding the following to your log4j.xml file:

  <appender name="all" class="org.apache.log4j.RollingFileAppender">

    <param name="File" value="${jboss.server.home.dir}/log/server.log"/>

    <param name="Threshold" value="INFO"/>

    <param name="Append" value="true"/>

    <param name="MaxFileSize" value="2MB"/>

    <param name="MaxBackupIndex" value="20"/>

    <layout class="org.apache.log4j.PatternLayout">

      <param name="ConversionPattern" value="%d{yyyyMMdd HH:mm:ss.SSS} %-5p [%t] %C{1}.%M(): %x %m%n"/>

    </layout>

  </appender>

I've updated the Jboss community wiki with this information (thanks for pointing out the location Jaikiran!).

Dependency Injection in Java 7

Hi all,


So apart from recovering from a long bout of the stomach flu, enjoying good food again at a "Come dine with me" night (our parents would be so proud) and planning a rush trip to Vegas I've managed to get out a first draft of the Dependency Injection chapter for the Well Grounded Java 7 Developer.


Java 7 unifies some of the basic standards that the various Dependency Injection frameworks (Spring, Guice, PicoContainer etc) have, making it easier for developers to move between the frameworks as needed.


A reminder of what DI is with regards to Java[1]

The javax.inject package specifies a means for obtaining objects in such a way as to maximize re-usability, testability and maintainability compared to traditional approaches such as constructors, factories, and service locators (e.g., JNDI). This process, known as Dependency Injection, is beneficial to most nontrivial applications.

So without further preamble, here's a short section from the chapter, let me know what you think!

Inject annotation

The @Inject annotation interface can be used in three places to indicate where you'd like a dependency to be injected.  Below are the types of members that can be injected, in the order that they are processed at runtime:

1.   Constructors

2.   Methods

3.   Fields

You can annotate a constructor with @Inject and expect its parameters to be provided at runtime by your configured IoC container e.g:

@Inject public MurmurMessage(Header header, Content content)

{

    this.header = header;

    this.content = content;

}

In this case both the Header and Content parameters would be injected at runtime.  The specification allows for 0+ parameters to be injected for constructors, so injecting a zero-parameter constructor is still valid.

WARNING As per the specification there can only be one constructor in a class with an @Inject annotation, this makes sense as the JRE would not be able to decide which injected constructor took precedence.

You can annotate a method with @Inject and like a constructor, expect its 0+ number of parameters to be injected at runtime.  There are some restrictions in that injected methods cannot be declared abstract and cannot declare type parameters of their own[1].  The short code sample below demonstrates the use of @Inject with a setter method, a common technique when using Dependency Injection.

@Inject public void setContent(Content content)

{

    this.content = content;

}

This technique of method parameter injection is especially powerful when it comes to providing service methods with the resources they need to do their job.  For example you could pass a DAO argument to a finder service method that was tasked to retrieve some data.

TIP It has become a default best-practice to use constructor injection for setting mandatory dependencies for a class and to used setter injection for non-mandatory dependencies, e.g. fields that already have sensible defaults.

It is also possible to inject fields (as long as they are not final), however the practice is not common.  The syntax again is quite simple.

public class MurmurMessenger

{

    @Inject private MurmurMessage murmurMessage;

    ...

}

You can read further about the @Inject annotation in the Javadoc, where you can discover some nuances about what types of values can be injected and how circular dependencies are dealt with.

Cheers,

Martijn

A related Java Code Geeks Article

---

[1] http://atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html.
[1]  By this we mean you can't do  http://download.oracle.com/javase/tutorial/extra/generics/methods.html.

A Little Directory love

Hi all,

So my next little snippet also comes from Chapter 2 of the book where we deal with the new NIO.2 (Non-Blocking I/O 2) APIs being introduced to Java 7.  In particular I'm showing a small code snippet to showcase some of the new support for directories that Java 7 has.  The code sample certainly needs a little tidy-up by using the new Automatic Resource Management (ARM) features in Java 7, but for now the example will suffice.


Dealing with Directories

The java.nio.file.DirectoryStream interface and its implementing classes allow you to:

• Iterate over entries in a directory.
• Deal with large directory structures.
• Filter entries whilst processing using regular expressions and MIME based content detection.
• Walk the tree structure in order to perform recursive move, copy, delete operations.

A common use case here is to list entries in a directory, e.g. Java source files as shown by the listing below.

DirectoryStream stream = null;

try
{

    // Define the directory
    Path dir = Paths.get("c:\\workspace");

    // Declare a filtering stream
    stream = dir.newDirectoryStream("*.java");

    // List each .java file in that directory

    for (Path entry: stream)
    {
        System.out.println(entry.getName());
    }
}
catch (IOException e)
{

    // Poor man's exception handling
    e.printStackTrace();
}

As you can see, with the new Java 7 APIs this particular task is much simpler than it used to be and this theme is prevalent in the rest of the NIO.2 APIs.

There are several other use cases which we will show case in the "NIO.2 in action" section.as well as on our upcoming website (to be revealed later).


So are we there yet?  In terms of File and Directory interaction in Java 7 there's certainly a massive improvement, so I'll say "Yes" once Java 7 is released.

Cheers,

Martijn

The Well Grounded Java 7 Developer

Hi all,

I've obviously not posted for quite some time and here is the reason why.....

It's been a long time coming, but I'm very happy to announce that Ben Evans and I have been contracted to write "The Well  Grounded Java 7 Developer" for Manning publications.  We've been spending the last month frantically getting the first few chapters out and a whole host of other book related activities, but now that I'm in full chapter writing mode I'll be adding regular posts to this blog.

A majority of my future posts will focus on interesting areas in this book and firstly I'd like to show a reworked extract from the new Date and Time API section.

Modeling Date and Time

The new API models time as a sequence of consecutive instants separated by fixed durations[1].  Java 7 maps these concepts directly on to classes, here's a more detailed explanation:

• The javax.time.Instant class represents a specific point on a discrete time-line e.g. January 23rd, 1996 at 09:00:00,0 UTC, the day that Java 1.0 was released.

• The javax.time.Duration class represents a section of elapsed time in nanoseconds, e.g. The 400 nanoseconds it takes for a PIC12C672-04 Microchip to execute an instruction set.

So as you can imagine, any point of time can be modeled by simply applying a Duration (positive or negative) to a starting Instant.

...

...

Calendering

With regards to calendaring, the main Calendar is ISOChronology, but other calendars such as CopticChronology and ThaiBuddhistChronology are supported.  The Chronology interface can be extended from to provide other implementations.

...

...

Timezone support

Timezone support is also provided via three core classes:

• LocalDateTime – Represents date/time without an offset or a time zone.

• OffsetDateTime - Represents date/time with an offset but not time zone.

• ZonedDateTime - Represents date/time with an offset and a time zone.

...

...

---

[1]               This phrase is almost 100% uplifted from an excellent early primer article by Jesse Farnham, see  http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html for details

---

The book will be loaded with more in depth explanations and of course plenty of code samples.  If you're interested in becoming a reviewer then please let me know!

The Modern Java Developer

Hi all,

Here's a brief synopsis that a colleague of mine (Ben Evans) and I have been thinking about for sometime, and we're curious to hear your feedback if you think you'd like to hear about some of the themes within this synopsis at the 2nd LJC Unconference.

"The role of the Java developer is undergoing a period of immense change - challenges such as manycore processors, new approaches to concurrency and a wealth of new languages (including functional and dynamic) on the JVM are redefining the nature of Java projects. The core SE/EE APIs have been supplemented by a large and growing body of additional material and technologies which the developer must know.

Some of the upcoming new Java 7 features - including closures, invokedynamic and standardised dependency injection tackle some of these challenges.  But it's not just core language updates that matter anymore, there's also been a change in the modern Java project lifecycle with a host of common tools and practices a developer will now be expected to encounter (largely borrowed from the Agile world).  Lastly, there are new JVM languages which are gaining in popularity and which the developers may expect to encounter on future projects."

Do people agree with the synopsis above?  Are they finding their Java projects changing to a new model?

Feel free to debate as I believe we're definitely not there yet!

Exciting projects on the go!

Hi all,

This is another mainly Java/Technology related post, although it's more of an overview of what I'm up to.  This is as much to do with getting it sorted in my head as anything else but people have asked what I'm involved in, so here goes:

1.) Reviewing an upcoming book on the Hudson Build Server (a favourite build tool of mine).  I'm definitely behind on helping out on this one, I really need a few solid hours of quiet time to review the material produced to date.

2.) Reviewing an upcoming book on Java 6 certification.  I'm trying to learn as much about the book review process as possible before hopefully co-authoring my own, so that's my main motivation for this one.  I'm still on the fence about certification, I dislike most of it but if it encourages people to study then that's not all bad.

3.) Negotiating (along with a colleague) a book deal with a big tech book publisher, we're getting closer to some sort of a deal I think!  This is the big exciting one for me, I've always wanted to try an author part of book if not an entire one so I really hope we can make this happen.

4.) Moderating on the Javaranch, which is going through a bit of an SEO overhaul at the moment.  I'm also hopefully getting my wife ("a most excellent Graphic Designer" and that's definitely not just according to me) to help give it a facelift.

5.) Community leading two open source projects (PCGen and Ikasan EIP).  These I wish I could spend a few extra regular hours on a week.  PCGen was the project that lead me into Open Source in the first place and the community spirit is just freakin awesome.  No matter how many times I take sabbaticals away from it, I always miss it far too much and just have to go back :).

Ikasan is the new kid on the block that I'm trying to turn into a "successful open source project" as part of my day job.  It's got a great deal of potential, but I need to spend a good deal more time with the community in order to realise it.

6.) Co-organising the London Java Community and the London Graduate and Undergraduate Development Community which currently involves helping organise an Unconference for the LJC and an not yet announced talk for the GDC.

7.) Writing several talks for conferences (sssh it's a secret)

With several of items above, I work with some pretty amazing and motivated people and that's why I pretty much stay involved, it's just plain fun and rewarding to boot!

So there you have it, my tech related life in a nutshell :).

Cheers,

Martijn

As an aside, I spotted the statement "If you want something done, give it to a busy person" on the web a couple of days ago while I was lying in bed nursing a bout of the man flu (which my wife was ever so patient with).  I realised that it holds pretty darn true for all of psychotically busy friends and colleagues that I know, they always seem the most organised and on to it.

Java Experiments

Hi all,

So I've been frantically packing and moving over the last week which means once more I have a pithy excuse to have posted as regularly as I promised, my bad!

Again this is a Java posting, so a warning to those adverse to seeing source code!

I ran across another common misunderstanding with Java for those first developing with it (and indeed for some more experienced developers!).  This was also highlighted in a recent TheDailyWTF article.  The mis-understanding is explained in the code below and is often asked about as an interview or certification question.

Thanks to Scott Selikoff, (I co-opted his code example).

package org.martijnverburg.experiments;

/**

 * This class runs experiments to prove various pass by value 

 * and pass by reference rules in the JDK

 *

 * The use of System.out.println is generally frowned 
 * upon, but I'll forgive myself in this case.

 * 
 * This probably should be a nice Unit test, many 
 * apologies!

 *

 * @author Martijn Verburg (aka karianna)

 */

public class PassByValuePassByReferenceExperiments
{

  /**

   * Fire off the experiments

   *

   * @param args - Not used

   */

  public static void main(String[] args)

  {

    PassByValuePassByReferenceExperiments test = new PassByValuePassByReferenceExperiments();

    test.changeValueOfObjectPassedIn();

  }

  /**

   * This method challenges a false assumption whereby the 
   * developer may think that when they pass an object reference 
   * into a method as an argument, then change the value of 
   * that object in the method, that the reference they hold 
   * onto in the calling method retains that changed value.
   *

   * TODO:  The explanation above isn't the clearest English, 
   * try to tidy that up later.
   *
   * If you misunderstand how this works in Java you may expect
   * to see the result as:

   * 

   * 10

   * 10

   *

   * The actual output of this experiment is:

   * 

   * 10

   * 3

   */

   private void changeValueOfObjectPassedIn()

   {

     Integer x = new Integer(3);
     changeX(x);
     System.out.println("Value of x is = [" + x + "]);

   }

  /**

   * The key concept here is the the Integer x declared 
   * in the argument list for the method is a local copy 
   * of the original reference.  So when you alter its value, 
   * you're only altering the local version, which incidentally 
   * falls out of scope when the method ends.

   */

   private void changeX(Integer x)

   {

     x = new Integer(10);
     System.out.println("Value of x is = [" + x + "]);
   }

}

So are we there yet?  Sadly no, all to often developers forget the fundamental rules like this and for new developers this concept can be especially confusing.


But although some developers might look down upon those who don't have the fundamentals memorised, I actually feel that it can be OK to be a bit forgetful or hazy, after all you can't remember it all!  I say that with the proviso that you should actively engage in improving your fundamentals knowledge, writing tiny test cases/experiments like the above code can be a very helpful aid.