The 8 Nights of Java – Night 4

Continuing The 8 Nights of Java series, tonight we focus on one of the single most important releases of Java. Java 1.4 was released a time when many businesses were starting to look to Java as a foundation for their software systems. After years of licensing proprietary or difficult to use software, Java was seen as a breadth of fresh air for many software engineers. It was helped, in part, by the decline of Windows-based computers and explosive growth of Mac and open-source Linux systems in the workplace and in homes. After all, if all of your developers are using different operating systems, then you need a software development platform that works on all of them and in that, Java was a success. So many business adopted Java 1.4 during this time and stayed on Java 1.4 for over a decade. In fact, many large enterprise systems still rely on Java 1.4 to this day. Hopefully, someone will be hired to update them soon!

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 1.4 Notable Features
Sun released Java 1.4 (codename Merlin) on February 6th, 2002. Key new functionality included:

  • Regular expressions
  • Assertions
  • NIO Version 1
  • XML/XSLT support

From Jeanne:

I love regular expressions. They are one of my favorite language features because they are concise and expressive when written well. I was excited when they came out. While I started programming as a full time job after Java 1.4 was released, we were still using 1.3 as we waited for the application servers to support Java 1.4. This meant I was already employed and got to teach my teammates about regular expressions. I’ve actually given that presentation a number of times since.

I don’t use assertions because I write a lot of unit tests and the unit tests tell me about the type of problem that an assertion would. Tests help me design my code in a way that I don’t need assertions to tell me about the state of affairs. And then there is poor New I/O. I really like Java 7 NIO.2. New I/O “1”, not so much. It served it’s purpose in getting us to NIO.2 though.

From Scott:

I started programming professionally around the time that XML/XSLT were seen as the “new hot technology” to use on build enterprise systems. Having built-in support for XML transformations made Java look cutting edge at the time. While a lot of what is now done with XML is instead done by JSON, XML is still the core of many data-based systems. In fact, numerous web and mobile frond-end languages still use XML for their layouts, even if the developers using them rely solely on a GUI-based editor. Either way, Java 1.4 demonstrated that new technologies could be integrated into the JVM quite rapidly. That said, I’m still waiting for a JSON parser to become part of the standard Java runtime environment!

Java 1.4 also introduced NIO version 1, or NIO.1 for short. While NIO.2 is a quite powerful, if not commonly used framework, NIO.1 is basically dead weight at this point. The NIO.1 API never really caught on and today, very few people rely on file channels and the like. Since a key part of Java is keeping backwards compatibility, it remains part of the JRE, albeit rarely used.

why I like regular expressions + who says they aren’t readable

Scott and I are working on our second book (OCP 8). I’m excited that I get to write the part about regular expressions as that is one of my favorite programming topics. Why, you ask? Because it lets you write clear and efficient code.

The scenario

For the book, I wrote an example showing how validating a simplified phone number is so much easier with a regular expression. The rules for the example were:

  1. a phone number is exactly 10 digits
  2. a phone number may contain dashes to separate the first three digits and next three digits, but not anywhere else
  3. no other characters are allowed (no parens around the area code in this example)

For example, 123-456-7890, 123-4567890 and 123456-7890 are valid. In real life, the third one wouldn’t be; we allow this typo here to be nice.  However dashes aren’t allowed in random positions. 12-45-67-890 is not a phone number.

Without regular expressions

This isn’t in the book, but i tired to write the code “the long way” to ensure it was annoying long. It was. I tried to write the code in a readable way and the best I could think of was:

private static boolean validateLong(String original) {
   String phone = original;
   // remove first dash (if present)
   if (phone.charAt(3) == '-') {
     phone = phone.substring(0, 3) + phone.substring(4);
   // remove second dash (if present)
   if (phone.charAt(6) == '-') {
      phone = phone.substring(0, 6) + phone.substring(7);

   // validate 10 characters left
   if (phone.length() != 10) {
      return false;

   // validate only numbers left
   Set<Character> digits = new HashSet<>(Arrays.asList('0', '1', '2', '3', '4', '5', '6', '7', '8', '9'));
   for (int i = 0; i < phone.length(); i++) {
      if (!digits.contains(phone.charAt(i))) {
         return false;
   return true;

This is a lot of code. And to those who think regular expressions are unreadable, what do you think of the above? I don’t find it easy to see what is going on even though I wrote it. There’s just too much logic and too much detail to ensure is correct. (And no, it didn’t work on my first attempt.)

With regular expressions

Re-writing to use regular expression gives me this:

private static boolean validate(String phone) {
   String threeDigits = "\\d{3}";
   String fourDigits = "\\d{4}";
   String optionalDash = "-?";
   String regEx = threeDigits + optionalDash + threeDigits + optionalDash + fourDigits;
   return phone.matches(regEx);

Even if you don’t know the regular expression syntax, it should be obvious what is going on here. We look for three digits, an optional dash, three more digits, another optional dash and a final four digits.

It’s a tiny bit longer in the book version because {3} isn’t on the exam so that part is:

String threeDigits = "\\d\\d\\d";
String fourDigits = "\\d\\d\\d\\d";

Still. Way easier to read and faster to write than the original code without regular expressions. I consider regular expressions like a hammer. They aren’t the right tool for every job, but they are quite helpful when they are the right tool.