Java 8 Time - choosing the right object

In the last blog post, we looked at the java.time library’s Instant and Duration objects in Java 8. In this second post, we’ll get an overview of some of the other objects within the java.time libraries.

The Instant object is defined in the JavaDocs as “An instantaneous point on the time-line.” There are other objects, related to the Instant, that might also be useful to us – in particular LocalDateTime, LocalDate and LocalTime and ZonedDateTime.

I’ll ignore LocalDate and LocalTime for the moment, and consider LocalDateTime, ZonedDateTime and Instant... all three of these appear to be quite similar, so it’s worth understanding how each differs.

What's the time?

A good starting place is to instantiate each object type with it’s now() method, to get the current time, and to print these out to the console to see what the print formats look like.. the code to do this is shown here, with the output below:

Instant instNow = Instant.now();
LocalDateTime ldtNow = LocalDateTime.now();
ZonedDateTime zdtNow = ZonedDateTime.now();
System.out.println(instNow);
System.out.println(ldtNow);
System.out.println(zdtNow);

2014-12-01T15:18:31.094Z
2014-12-01T15:18:31.109
2014-12-01T15:18:31.152Z[Europe/London]


Ignoring the nano second differences, the formats are interesting. The first, the Instant tells us that this code was ran at 3.18pm on 1st December 2014. The letter z at the end stands for Zulu time, which is also known as GMT (Grenwich Mean Time) or UTC (which stands for Coordinated Universal Time… I don’t know why it’s not abbreviated to CUT – I’ll leave you go to go searching on Wikipedia if you want to know more about this!) So the first item, the Instant, is 3.18pm on 1st December 2014 UTC.

The second result is the local date time – that’s a representation of my current time, which is 3.18pm on 1st December 2014, that's what my computer clock and calendar say. And the third item is the zoned date time, where we can again see that it’s 3.18pm on 1st December 2014, London time.

This all looks very neat because I’m in the UK, where the timezone is GMT (at least in Winter)… what would have happened if I was somewhere else in the world?

Well here’s what a person in Abu Dhabi who tried the same exercise would find...

2014-12-01T15:18:31.094Z
2014-12-01T19:18:31.109
2014-12-01T19:18:31.152+04:00[Asia/Muscat]


So now we can see that the Instant is the same point on the timescale as the person in London found, but their LocalDateTime was the time their clock shows (4 hours later than the person in London’s clock) and the ZonedDateTime matches the LocalDateTime but it has the time-zone embedded in.

Let’s dig a little deeper into the definitions of these objects…

An Instant is an actual point in time, expressed using UTC – a universal time scale. A ZonedDateTime is an actual point in time, but in a specific area of the world... so if you know the timezone you can convert reliably from an Instant to a ZonedDateTime. A LocalDateTime is a representation of the concept of a date and time, but doesn’t actually correspond to an actual point in time… or rather it can only be converted into an actual point in time if we ADD IN a timezone.

Although LocalDateTime objects don’t necessarily correspond to an actual point in time, you can still do all the “date mathematics” you might want to with them, such as adding or subtracting days, minutes or nanoseconds.

Ok so how is this useful?

If you’re writing code that is going to manipulate dates, you now have a choice of what to use. In the United Kingdom, our clocks go forward for an hour in the summer, (known as daylight saving) so at some times in the year we are effectively operating at GMT and sometimes it’s GMT+1.

This could cause confusion on the dates the clocks go back an hour from GMT+1 to GMT... the change happens at 2am – this year it was on Sunday October 26th. What this means is that if I looked at my digital clock, the minutes on Sunday 26th October changed like this…

01:58
01:59
01:00
01:01


As a result, the time 01:30am happened twice on 26th October…. At least as far as my clock is concerned. But my clock operates on LocalDateTime (or it would if it were running Java) – if I had an InstantClock it would have looked like this:

00:58
00:59
01:00
01:01


And if had a ZonedDateTime clock it might have looked like this:

01:58 BST
01:59 BST
01:00 GMT
01:01 GMT


(BST stands for British Summer Time – it’s another way of saying GMT+1)

Now let’s suppose we were writing code that was going to run a critical piece of functionality each night at 1.30am. For example, maybe we are a bank, and it’s at 1.30am that our function starts that is going to calculate the daily interest on every customer's account. It would be important not to use a LocalDateTime object for this code, as it might run twice on 26th October (and not at all on 30th March 2014, the date that the clocks skipped an hour). In this example, I’d want to use an Instant - I want my critical process to run at fixed times on the time-line.

In fact if I was coding up a system for a bank, that was recording every transaction in every account, I’d probably want to store the date and time for each transaction as an Instant object… that way I know exactly when it happened…. And because bank transactions can occur between countries, it makes sense to know the date and time of each transaction based on UTC, and then translate that into a local date and time for each country’s reports.

So if we go on to write another piece of code that details, for example, the number of transactions by hour while the bank was open each day, for this we would want to use the ZonedDateTime object, to query transactions between fixed times in each location… this can tell us how many transactions occurred between 9am and 10am LOCAL time (the first hour of opening) in each country.

LocalDate and LocalTime

As you might suspect from their names these objects store a date or a time in isolation… and in fact a LocalDateTime is actually a combination of LocalDate and LocalTime… and the LocalDateTime object has a toLocalDate() and toLocalTime() method to easily extract each component.

Now I think these are particularly useful, well LocalDate is. I often find I want to compare 2 dates ignoring their time values. I’ve traditionally used the Apache Commons DateUtils library in the past to help with this – it has a truncatedCompareTo method which allows you to say compare 2 dates but only consider (for example) the date part, or only consider the year and month.

Now you might think that you could do this with the Instant objects... consider this code for example:

Instant instant1 = Instant.parse("2014-12-01T16:01:13.419Z");
Instant instant2 = Instant.parse("2014-12-17T15:17:22.305Z");
System.out.println(Duration.between(instant1,instant2).toDays());

Here we have two dates - the 1st December at 4.01pm, and the 17th December at 3.17pm. I'd like to know how many days there are between these two dates, ignoring the times. The answer should be 17 less 1 = 16.

However the output from my println is... 15. The reason is that there are actually 15 days, 23 hours and 43 minutes between these two dates and our .toDays() method tells us that's 15 days - it ignores the hours and minutes.

So how do we find out the real number of days, ignoring the time?

Well here's some code that will do this:

Instant instant1 = Instant.parse("2014-12-01T16:01:13.419Z");
Instant instant2 = Instant.parse("2014-12-17T15:17:22.305Z");
LocalDate d1 = LocalDateTime.ofInstant(instant1, ZoneId.systemDefault()).toLocalDate();
LocalDate d2 = LocalDateTime.ofInstant(instant2, ZoneId.systemDefault()).toLocalDate();
System.out.println(Period.between(d1,d2).getDays());

In this code, we're taking 2 different Instant objects, converting them into LocalDate objects (note that we need to first convert them to LocalDateTimes... and I've just used the system default's time zone for the conversion), and then looking at how many days there are between the two local dates. We get the answer we're looking for - 16.

But this introduces another new object - that of the Period. When we compared 2 Instants in the previous blog post, we used the Duration object - well if you try and compare 2 LocalDates with a Duration object you'll find it will compile but you'll get a rather horrible looking UnsupportedTemporalTypeException.

So I guess we need to finish by understanding what the Period object is...

Periods or Durations

Well the official definition is that whereas the Duration object works with time - that is hours, minutes and seconds, whereas a Period object works with dates - or rather years, months and days. In reality I find you can forget this and just remember that if you're working with LocalDate you must use Period, if you're working with Instant, LocalDateTime, or ZonedDateTime use Duration.

Admittedly it's not that simple (nothing is really with Java Time) - there's a rather interesting note in the JavaDocs that says that a Duration of 1 day will always be 24 hours, but a period of 1 day might be 23, 24 or 25 hours due to the impacts of daylight saving time changes.

Confused? yes I am too - I guess until we have all been building lots of code that manipulate dates we won't be completely familiar with which is the best object type to use and when, but I do at least get a sense that the structure of java.time is comprehensive. So far I haven't found any aspect of date manipulation or date mathematics that I can't do with java.time, although it can sometimes take what feels like quite a lot of effort.

So has Java finally come up with a replacement for Date that works? Well I want to say yes... It's a cautious yes for now but if I'm honest, I like what I'm using!

Do the new Java 8 Date and Time objects make 3rd party date libraries redundant?

This is the first of two blog posts which are a follow up to Virtual Pair Programmers’ popular Java Fundamentals training course. This course was written with Java 7, and while everything in the course is still valid for Java 8, I thought a blog post about dates and times was worthwhile.

There are other changes in Java 8, although I’d say that these don’t affect the fundamentals. The biggest change is the introduction of lambda expressions, and I’m currently working on an “Advanced Java” course for Virtual Pair Programmers, which will cover this amongst other topics…. more on that later!

In the Java Fundamentals course, we say that the Date library in Java has always been a messy affair, and that while the GregorianCalendar object can be useful, if you need to do any kind of date manipulation in Java, you probably will be using an external library. In the course we JodaTime which seems to be the go-to library for most developers.

However Java 8 introduces some new date and time functionality, through the new java.time library, so I thought I’d take a look and see whether this might now make JodaTime redundant. In this post we’ll look at how to manipulate dates and times in Java 8, and in the following post we’ll explore in more detail some of the different objects within the Java 8 date and time libraries.

Manipulating Dates with java.time

So our starting point for this post is the most common operation I find myself writing code for when it comes to working with dates… and that is comparing two dates to see if they’re the same. When I teach this to new programmers, I sometimes use the following example, as a way to practice date manipulation:

Imagine that there’s a secret date that we’re trying to find out. We know it’s between 1st January 2000 and 31st December 2020.

To find out what the secret date is, we can only ask the question in the format “how does it compare to, 16th November 2012 at 6.15am”?, and we’ll get the answer “the secret date is before, after or matches that date”.

The implementation of this comparison question in JodaTime is really simple – we use the DateTime object to store the date, and use the compareTo function to compare 2 dates.  This simple method does the job:

 public int compareDate(DateTime sampleDate) {
  return sampleDate.compareTo( new DateTime(2012, 11, 16,6,15));
 }

The method takes a date and time (sampleDate) as a parameter and returns a +1 if the date and time we supply is after the date we’re looking for (the secret date), a 0 if it matches, or a -1 if the date and time we supply is before the date we’re looking for.

So the work is, given that we can only ask this question, how do we find out what the secret date is?

To find the answer, we play a game. We know that 1st Jan 2000 is before the secret date, and 31st December 2020 is after it. So let’s pick a date in the middle – say 1st January 2010, and ask the question for that date. The answer comes back “the secret date is after 1st January 2010”.

Now we know the date lies between 1st January 2010 and 31st December 2020. So we’ll try a date between those two – perhaps 1st January 2015.

We get the answer that the secret date is before 1st January 2015, so we now know it falls between 1st January 2010 and 1st January 2015.

We can keep repeating this - choosing a date between our known upper and lower limits, and revising one of those limits each time until we find the date. Here’s the code that does this and the output it produces:

import org.joda.time.DateTime;

public class Main {

 public static int compareDate(DateTime sampleDate) {
  return sampleDate.compareTo( new DateTime(2012, 11, 16,06,15));
 }
 
 public static void main(String[] args) {

  DateTime lower = new DateTime(2000,1,01,0,0);
  DateTime higher = new DateTime(2020,12,31,23,59);

  int result = 100;
  int steps = 0;
  DateTime foundDate = new DateTime(); 
  
  while (result != 0) {
   int difference = (int) ((higher.getMillis() - lower.getMillis()) / 2000);
   foundDate = lower.plusSeconds(difference); 
   result = compareDate(foundDate);
  
   if (result == -1) {
    lower = foundDate;
   }
   else if (result == 1) {
    higher = foundDate;
   }
   steps++;
  }
  
  System.out.println("Found date " + foundDate + " in " + steps + " steps.");
 }

}

Found date 2012-11-16T06:15:00Z in 29 steps. 

 I think this is a useful exercise for students new to JodaTime as it shows us:

• how to compare two dates (using compareTo), 
• how to determine the length of time between two dates (using getMillis), and 
• how to add time to a date (using plusSeconds). 

In a full lesson we would explore the other options to add days or weeks rather than seconds, but you get the idea. We cover a number of the main things that people tend to want to do with dates in 1 simple exercise.

 So let’s now suppose we have Java 8 and are not allowed to use JodaTime – does the new Java 8 Time library allow us to achieve this task?

 Well the good news is that the answer is yes, and in fact the code is almost identical to what we have above. The two key objects we need are:

• java.time.Instant – this represents a Date and Time* – we'll consider that the equivalent to our JodaTime DateTime object, and 
• java.time.Duration – this static object has a between() method which can give us the difference between two Instants, and a toMillis() function which converts that difference to milliseconds… 

 Here’s the new code… the output is identical to the JodaTime version!

import java.time.Duration;
import java.time.Instant;

public class Main {

 public static int compareDate(Instant sampleDate) {
  return sampleDate.compareTo( Instant.parse("2012-11-16T06:15:00Z"));
 }
 
 public static void main(String[] args) {

  Instant lower = Instant.parse("2000-01-01T00:00:00Z");
  Instant higher = Instant.parse("2020-12-31T23:59:00Z");

  int result = 100;
  int steps = 0;
  Instant foundDate = Instant.now();
  
  while (result != 0) {
   
   int difference = (int) (Duration.between(lower, higher).toMillis() / 2000);
   foundDate = lower.plusSeconds(difference); 
   result = compareDate(foundDate);
  
   if (result == -1) {
    lower = foundDate;
   }
   else if (result == 1) {
    higher = foundDate;
   }
   steps++;
  }
  
  System.out.println("Found date " + foundDate + " in " + steps + " steps.");
 }
}

On the basis that you understand the JodaTime version, the new Java 8 version is straight-forward.

 So it seems that for many date manipulation tasks the new Java 8 objects will meet our needs, and can be considered a success. JodaTime can do much more than just this, so it won’t be redundant just yet, but I think it will be an extra overhead we won’t need for basic date manipulation.

 What we have seen so far is 2 of the Java 8 classes from the java.time library – the Instant and the Duration class. There are other useful classes in this library however, and we’ll look at some of these in the next post.



 * To say that an Instant represents a Date and Time is not the full story - it's got a very precise definition and we'll be exploring that in the next blog post.

Hadoop Course - Understanding the Scripts

Over the last week or so we've had a few support calls asking questions about the scripts provided in chapter 5 of the course, that are used to switch Hadoop between standalone and pseudo-distributed modes.

This post will explain in a bit more detail what each script is and how it works. These are custom scripts that I've developed while working with Hadoop, so you won't (probably!) find them elsewhere on the internet, but I think they make the process of managing Hadoop configurations on a development machine really easy.

Until you've got through chapter 8 of the course not everything in this post will make sense, but feel free to contact me if you have any questions after reading this - or raise a support call through https://www.virtualpairprogrammers.com/technical-support.html


There are 4 scripts provided with the course:

(1) resetHDFS

This script is designed to clear down your HDFS workspace - that is to empty out all the files and folders in the Hadoop file system. It's like formatting a drive. What the script actually does is:

• stop any running Hadoop processes
• delete the HDFS folder structure from your computer
• recreate the top level HDFS folder, and set its permissions so that the logged on user can write to it
• run the hdfs format command - this will create the sub-folder structure needed
• restart the hadoop processes
• create the default folder structure within HDFS that's required for your pseudo-distributed jobs (/user/yourusername)

NOTES:

(1) You must be in the folder where the script is located to run this script. You should run it by entering the following command:

./resetHDFS

(2) The script contains a number of lines that must be run with admin privileges - these contain the word sudo. As a result, running this script will require you to enter your admin password 1 or more times. Although this might seem frustrating, you will not be running this script regularly - only when you wish to delete all your data, and then it's a quick and easy way to do it.

(3) Because this script creates the HDFS required file and folder structures, we use it to create them for the first time. When the course was first released there was a typing error - on line 2, sudo was misspelt sduo. This has been corrected but if you have downloaded a copy with the typo, you might wish to correct it!

(2) startHadoopPseduo

This script will switch Hadoop into Pseudo-distributed mode - if you're currently in standalone mode then this is the only script you need to run.

What the script actually does is:

• remove the existing symbolic link to the configuration directory
• create a new symbolic link to the configuration directory containing the pseudo-distributed configuration files
• start the Hadoop processes

(3) stopHadoop

This script simply stops the Hadoop processes - it should be run if you're in pseudo-distributed mode and are going to switch back to standalone mode. It doesn't change any configuration settings, it just stops the processes running. 

(4) startHadoopStandalone

This script removes the existing symbolic link to the configuration directory, and creates a new symbolic link to the configuration directory containing the standalone files. Although I've called this script "startHadoopStandalone" it doesn't actually start anything, as no processes run in standalone mode.

So... which scripts do you need to run and when:

If you're in standalone mode and you want to be in pseudo-distributed mode, just run startHadoopPseudo

If you're in pseudo distributed mode and you want to be in standalone mode, first run stopHadoop and then run startHadoopStandalone

If you have just switched on your machine and want to run in either mode - just run the relevant startScript. In this instance you don't need to run the stop script because you have no running processes if you have just booted up.

Hadoop Course - Setting Environment Variables - correction to chapter 5

We have just been made aware of an error in the Hadoop course, chapter 5, at approximately 19 minutes in the video. This error has been fixed in and the video was replaced on 22nd October - so this will only affect you if you downloaded chapter 5 before the 22nd October 2014. All customers can download the replacement video if preferred.

The issue relates to the part of the video that deals with setting your environment variables, and instructs you to edit either your .bashrc file (Linux) or .bash_profile (Mac)

There is a mistake in the last 2 lines that I ask you to add to these files - the lines reference the HADOOP_INSTALL variable - this should in fact reference HADOOP_PREFIX as we haven't set HADOOP_INSTALL.

The last 2 lines to be added should therefore be:

export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_PREFIX/lib/native
export HADOOP_OPTS="-Djava.library.path=$HADOOP_PREFIX/lib"

Please accept my apologies for this error. When I display my own .bashrc file (at about 20 minutes into the video) you'll see the correct information shown.

Groovy Course Correction - Chapter 21 (Files and Templates)

I've been made aware today (thanks to a customer asking us to help solve a problem with his code relating to chapter 21 of the Groovy course) of a mistake on the video and with the file supplied for this chapter.

In the exercise I set you to practice with templates, I show on screen the file called DailyCheckInTemplate.txt from the practicals and code folder. This is at approximately 15:22 on the video.

The video tells you to copy the file from the templates folder in chapter 17, and shows you the file on screen. Unfortunately the file provided and shown is not right - it includes fields like $it.date - these should be $date.

The problem with using $it.date is that Groovy will be looking for a key of it.date in the map of properties we supply to the template engine, but the keys won't be preceeded with the "it" - that is we'll be creating a map with a key of "date" and not "it.date".

If you use the version of the template supplied in the starting workspace, you'll get an error message similar to this:

Caught: groovy.lang.MissingPropertyException: No such property: it for class: SimpleTemplateScript1
groovy.lang.MissingPropertyException: No such property: it for class: SimpleTemplateScript1
at SimpleTemplateScript1.run(SimpleTemplateScript1.groovy:1)

The version of this file in the final workspace for chapter 21 is correct, so please pick up the DailyCheckinTemplate.txt file from the following location instead, and you'll not have any problems with your code:

PracticalsAndCode / End of Chapter Workspaces / Chapter 21 - Files and Templates / Hotel Manager / templates / DailyCheckInTemplate.txt

Hadoop - new course coming soon!

I'm pleased to announce that recording of my next Virtual Pair Programmers course is now almost complete. The course is covering Hadoop for Java Developers. If you haven't heard of Hadoop (is there anyone who hasn't?) this is a framework for distributing the processing of large amounts of data accross a a network of computers.

The course assume some basic Java knowlege, but no prior knowledge of Hadoop or its Map Reduce programming model.

Once recording is complete, there will be an edit phase and of course some post-production work to complete, but the likely running order is as follows:

• An overview of what Hadoop is, and introducing the concept of the map-reduce programming model
• Getting to grips with map-reduce, including creating some map-reduce code in standard Java
• Hadoop operating modes, and how to set up and install Hadoop
• Creating our first Hadoop Map-Reduce job
• The Hadoop Distributed File System (HDFS)
• Understanding the map-reduce process flow, including combine and shuffle
• Looking at map reduce job configuration options, such as file formats, runtime options
• Creating custom data types 
• Chaining multiple jobs, and adding extra Map steps to jobs 
• Optimising jobs
• Working with JDBC databases
• Unit testing (with MRUnit)
• Secondary Sorting (sorting the values as well as the keys)
• Joining Data from multiple files
• Using the Amazon EMR service

The course has a number of real world examples throughout and two large case studies to work through too so there's lots of practical exercises. As well as model answers and sample code throughout, I'm also including some templates that I use for my own map-reduce jobs which you'll be able to re-use in your own projects.

If you are a Microsoft Windows user, then you need to know that installing Hadoop on Windows is hard, so in the course, I ask you to use a virtual machine running Linux... and I'll talk you through how to install and configure that... no prior knowledge of Linux is required.  Mac and Linux users can either install Hadoop directly, or also use a virtual machine - all the options are covered.

The course should be going live some time in September so keep an eye out on this blog or the Virtual Pair Programmers' facebook page for more information.

Why you can't use Derby with Hadoop

I'm currently in the middle of writing my next course for Virtual Pair Programmers, which will be on using Hadoop. Typically in Virtual Pair Programmers courses, we use Apache's Derby database. We choose this because  that's because it's light-weight, and so easy to distribute. It needs pretty much no installation / configuration etc. We can provide students with a full copy of the application and sample databases, and they can avoid having to spend time setting up and configuring a database server, such as MySQL, and having to import a database.

One of the topics we'll be covering on the Hadoop course is the use of the DBInputFormat and DBOutputFormat to read from and write to a relational database (we'll be learning about Sqoop too but the same issue will affect Sqoop... it's just that I've not got to that part of the script just yet!).

In preparing some data and test code to use on the course, I've today discovered that Hadoop just won't work with Derby. I find this somewhat surprising, given that both projects come from the Apache camp, but having spent several hours digging to find out why this might not work, I've finally found the issue. There's really not much available online about this point so I thought I'd write a blog post about it in the hope that it helps someone in the future avoid the pain I've been through today!

On trying to get database reads working, I've been coming up with a horrible looking error message. I won't bore you with the full stack trace; the important part of it is:

java.sql.SQLSyntaxErrorException: Syntax error: Encountered "LIMIT" at line 1, column 75.

The issue here is that Hadoop generates SQL statements in the background to read from the database. Rather than reading the whole table in one go, each map method call will read the next record. The SQL that Hadoop generates (that we can't see) includes the LIMIT keyword... and as per the derby FAQ this keyword is not supported.

So it seems that there's just no easy way to read in or write out to a Derby database from Hadoop. So on the course we'll be using MySQL to learn how to work with relational databases directly from Hadoop, but for anyone using Derby and wanting to work with Hadoop, I think the only option is going to be to create a dump of the data in text format for Hadoop to import.

If you have found a way to get Derby working with Hadoop please do let me know!

Groovy Programming is now available!

I'm excited to announce that Groovy Programming, the latest training course from Virtual Pair Programmers (my second course for them) is now available to purchase!

As with all Virtual Pair Programmers' courses, Groovy Programming is written from scratch for delivery by video, but is based on many years of experience in working with and teaching the language. We believe you'll learn far more quickly than from reading books - in fact you'll cover everything you need to be a competent Groovy programmer but at a fraction of the cost of a face-to-face course, and naturally with the convenience that our unique training methods give - the ability to download and keep all the video files, so you can study at a time and place that suits you!

 Groovy Programming contains 12 hours of video, but with lots of practical exercises it will take most students around a week to complete. Also included with the download are complete code for all worked exercises, and guidance notes for the tasks, as well as all the software you need (except Groovy and Eclipse, but we cover on the videos how to install and configure these!)

There's a full breakdown of the content of Groovy Programming on our website, but if you have any queries about this course, you're welcome to contact me through https://www.virtualpairprogrammers.com/contact.html. In the meantime, thank you for your continued support, and we hope you continue to enjoy our courses.

Running db-derby with recent releases of Java

This blog post is an errata item for my Java Fundamentals course, and will also apply for the other Virtual Pair Programmers courses where we use the db-derby database.

I discovered while recording the upcoming Groovy course that there has been a security change in the most recent release of Java (1.7.0.51) that has meant that the default configuration for db-derby no longer works. Running db-derby with the startNetworkServer command will result in an error message which says somewhere early on in the error message:

access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")

The easiest and quickest way to overcome this seems to be to run the database on a higher port number, such as 50000 - to do this, instead of running the startNetworkServer command, run the following instead to start the db-derby database:

NetworkServerControl -p 50000 start

In your code, you'll need to change the connection strings to incorporate the new port number, so that the line of code which creates the connection includes the port number - it should look like this:

conn = DriverManager.getConnection("jdbc:derby://localhost:50000/library");

This should overcome the error - if you find you have any further unexpected errors that you can't resolve however, do get in contact via the Virtual Pair Programmers contact us page!

Groovy Course coming soon

One of the topics that we've been asked to provide a course on at Virtual Pair Programmers a number of times over the last few years is Groovy... so I'm pleased to announce that I'm currently making good progress on creating the Groovy Course, which I hope will be released around the end of March 2014.

While I've been talking about the Groovy course to fellow Java programmers and trainers, in particular I've had a number of conversations about what it should cover , everyone seems to agree that once you start with Groovy you don't want to switch back to plain old Java, and I guess this is primarily because everything you can do in Java can be done in Groovy, often more quickly, and of course you can do more too. I've come to the conclusion that for many Java programmers it's really quite easy to get up and running in Groovy, but to really harness it's power, and get the most out of the language, it needs a really quite thorough course.

For anyone who doesn't know what Groovy is, I've pasted below a response to the question "what is groovy" taken from Stack Overflow... although this isn't the top answer on that site, it's the one that I like the most as I think it gives a real flavour of what Groovy is really about from a programmer's perspective:

Groovy is a dynamically typed language that runs on the Java platform and includes some features that a lot of people wish were in Java (ex: closures). One nice thing about Groovy is that it reduces the amount of code needed to do common tasks such as parsing XML files and accessing databases. While learning Groovy you can always mix in straight Java code. This is nice since it allows you to ease into Groovy at your own pace while delivering functional code. If you've been using Java for a while I think you'll appreciate the simplicity of using Groovy since you can program more functionality using less keystrokes. The inclusion of closures was a big selling point for me. One word of caution: if you use Groovy for production code you should make sure there is descent test coverage (since Groovy is a dynamic language). Even if you decide not to use Groovy, it's not a huge time investment to learn and experiment a bit.

The chapter list for our forthcoming course isn't quite complete, but the likely structure and outline content is as follows:

• Introduction: The difference between Groovy and Java, installing Groovy and setting up a development environment
• Part One: Getting started - looking at the power of key aspects of programming in Groovy, such as objects, methods, strings, operators, closures, ranges and looping and unit testing
• Part Two: Case Study - using everything we have learned to start to build a working application - our example is going to be a hotel room booking system
• Part Three: Going deeper - more on closures, working with files including XML, databases, Meta Object Protocol, using stubs and mocks in unit testing and finally packaging and deployment

Our case study will start after we have studied the basics, and we'll be developing a back-end system to help a small hotel manage its room bookings. As we learn more advanced topics, we will then enhance the back-end system to provide more functionality. 

We'll put an update on progress nearer the release date, but in the meantime, if you're welcome to contact me through www.virtualpairprogrammers.com