I wanted to con­tinue this post series but time goes by sooooo quickly (and I’m in a quite lazy mood lately).

Any­way, back for a new fea­ture that Java has brought us: mul­ti­ple catch clauses. And hon­estly, even if it’s a lit­tle one com­pared to other fea­tures, I find it a great addi­tion to the Java developer’s toolkit. We (should) always seek to improve our code and reduce main­te­nance costs through refac­tor­ing etc, but some­times the lan­guage doesn’t help.

Han­dling excep­tions has been one area where code rep­e­ti­tion often comes up. You’ve prob­a­bly all writ­ten stuff like this:

} catch (SomeException ex) {
     logger.error(ex);
     throw ex;
} catch (OtherException ex) {
     logger.error(ex);
     throw ex;
}

And you’ll be pleased to know that with Java 7, you can now refac­tor your code and do this instead:

} catch (SomeException  | SomeOtherException ex) {
     logger.error(ex);
     throw ex;
}

Yummy!

Some pic­tures from our mini-trip to Zeebruges:

In the first post of this series, I’ve told you a bit about the new dia­mond nota­tion which is a nice addi­tion and pro­vides for bet­ter code read­abil­ity and less ver­bosity. And not only that, but since we’re typ­ists first and pro­gram­mers sec­ond, it also allows us to increase the LOC / minute count (and whether that is a good thing is actu­ally open to debate) ;-) (sorry for those poor hunt and peck typ­ists among you).

For this sec­ond post, I want to talk about a fea­ture that has been requested about 16 YEARS ago and that was finally imple­mented in Java 7: the abil­ity to write switch state­ments with String cases. I won’t insult you with an exam­ple, if you want one, then check the offi­cial docs.. Also, I won’t cover the per­for­mance aspects, which other peo­ple have already explained quite nicely.

As many of you know, it’s a fea­ture that has been avail­able for a long time in many other pro­gram­ming lan­guages (e.g., C#, JavaScript, ruby, …) and even though hard­cod­ing String lit­er­als should be avoided when­ever pos­si­ble, there are still cases where it makes sense.

To cater for the lack of that fea­ture, mul­ti­ple workarounds were used. One of which (the ugli­est IMHO) being to use if-then-else blocks to han­dle all the cases for non-binary deci­sions (more com­plex than sim­ple if-else), which indeed leads to unreadable/unmaintainable code (even though it is con­text based and some­times if-then-else blocks make more sense than using a switch).

Another approach, which I think is way bet­ter on mul­ti­ple lev­els is to define an enum with a fromString(String) method and use the enum val­ues in a switch via the val­ueOf method. That tech­nique allows to avoid repeat­ing hard­coded Strings all over the place and keeps the code eas­ily refac­torable. Not only that, but it is also way more flex­i­ble. For exam­ple, in the from­String method (or what­ever you decide to call it), you can decide whether you want to sup­port case sen­si­tiv­ity or not, how to treat null val­ues, etc. You can find a nice writeup of that idiom there.

The sup­port for String objects in switch state­ments is very wel­come, but keep in mind that it isn’t the sil­ver bul­let and that it shouldn’t be used in all cases (haha) :)

Java 7 has finally been released! There have been a lot of dis­cus­sions around the fea­tures that would/wouldn’t be included in Java 7. After a while, I decided to stop check­ing the news around that sub­ject since it changed so often. And appar­ently, some of the most awaited fea­tures have been deferred to Java 8 or later. Among which: JSR 294 (Lan­guage and VM sup­port for mod­u­lar pro­gram­ming), clo­sures,  or JDK mod­u­lar­iza­tion (project Jig­saw). Too bad! But any­how, now Java 7 is here and it’s time for me to check it out. In this series of posts, I’ll write about the new fea­tures that I find inter­est­ing as I dis­cover them (don’t except the list to be exhaus­tive though).

So let’s get started! Here’s the first bit I’ve just read about:

You can now replace the type argu­ments required to invoke the con­struc­tor of a generic class with an empty set of type para­me­ters (<>: infor­mally called the dia­mond) as long as the com­piler can infer the type argu­ments from the context.

If we trans­late this to actual code, it really means that instead of:

Map<Foo,Bar> fooBar = new HashMap<Foo,Bar>();

You can now write this:

Map<Foo,Bar> fooBar = new HashMap<>();

Or this:

Map<Foo,List<Bar>> fooBars = new HashMap<>();

Instead of that:

Map<Foo, List<Bar>> fooBars = new HashMap<Foo, List<Bar>>();

This is a nice addi­tion, but make sure to check out the ref­er­ence doc­u­men­ta­tion for more details, it doesn’t stop there ;-)

Syn­tax­High­lighter is a very cool syn­tax high­light­ing JavaScript library cre­ated by Alex Gor­batchev (if you don’t know about it yet, check out the demo page). As you’ll notice, I actu­ally use it on this very blog.

Using it is pretty straightforward:

• load the XReg­exP library required by Syn­tax­High­lighter: http://xregexp.com/

• load the main script:

  <script src="js/shCore.js" type="text/javascript"></script>

• load one or more of the avail­able brushes (syn­tax high­light­ing scripts):

  <script src="css/shBrushJScript.js" type="text/javascript"></script>

• include at least one of the avail­able theme stylesheets:

  <link href="css/shCore.css" rel="stylesheet" type="text/css" />
  <link href="css/shThemeDefault.css" rel="stylesheet" type="text/css"/> 

• wrap the code to high­light in a <pre> block and spec­ify the brush that should be used:

               <pre class="brush: js">function foo(){ ... }</pre>
             

• finally, exe­cute the high­lighter using the following:

               <script type="text/javascript">
                 SyntaxHighlighter.all();
               </script>
             

The main issue with this way of con­fig­ur­ing Syn­tax­High­lighter is that you’ll either have to load exactly those brushes you need or load them all even if they’re not needed. This prob­lem remained until ver­sion 3 intro­duced the Autoloader script.

You can find all the details about its usage on that page, but basi­cally you have to load the autoloader script and tell it about all the brushes aliases that it should rec­og­nize along with the path to the cor­re­spond­ing scripts. Much bet­ter, yay!

One prob­lem I’ve had with the autoloader script is that it doesn’t seem to appre­ci­ate URIs for the loca­tion of the brush scripts when using the default syntax:

Array: [ 'alias1 alias2 /full/path/to/brush.js', ... ]

Although, it works per­fectly fine when using the alter­nate syn­tax (which is alas a lit­tle bit more verbose):

Array: [ [ 'alias1', 'alias2', '/full/path/to/brush.js' ], ... ]

Finally, I’ve come up with the fol­low­ing script, largely inspired by the exam­ple on that page but using the alter­nate syntax:

	<script type="text/javascript">
		var baseSyntaxHighlighterScriptsPath = "http://base-path-to-scripts-folder/";
		function getSyntaxHighlighterScriptPath(name){
			return name.replace('@', baseSyntaxHighlighterScriptsPath);
		}

		SyntaxHighlighter.autoloader(
			[ 'applescript', getSyntaxHighlighterScriptPath('@shBrushAppleScript.js') ],
			[ 'actionscript3', 'as3', getSyntaxHighlighterScriptPath('@shBrushAS3.js') ],
			[ 'bash', 'shell', getSyntaxHighlighterScriptPath('@shBrushBash.js') ],
			[ 'coldfusion', 'cf', getSyntaxHighlighterScriptPath('@shBrushColdFusion.js') ],
			[ 'cpp', 'c', getSyntaxHighlighterScriptPath('@shBrushCpp.js') ],
			[ 'c#', 'c-sharp', 'csharp', getSyntaxHighlighterScriptPath('@shBrushCSharp.js') ],
			[ 'css', getSyntaxHighlighterScriptPath('@shBrushCss.js') ],
			[ 'diff', 'patch', 'pas', getSyntaxHighlighterScriptPath('@shBrushDiff.js') ],
			[ 'erl', 'erlang', getSyntaxHighlighterScriptPath('@shBrushErlang.js') ],
			[ 'groovy', getSyntaxHighlighterScriptPath('@shBrushGroovy.js') ],
			[ 'java', getSyntaxHighlighterScriptPath('@shBrushJava.js') ],
			[ 'jfx', 'javafx', getSyntaxHighlighterScriptPath('@shBrushJavaFX.js') ],
			[ 'js', 'javascript', 'jscript', getSyntaxHighlighterScriptPath('@shBrushJScript.js') ],
			[ 'perl', 'pl', getSyntaxHighlighterScriptPath('@shBrushPerl.js') ],
			[ 'php', getSyntaxHighlighterScriptPath('@shBrushPhp.js') ],
			[ 'text', 'plain', getSyntaxHighlighterScriptPath('@shBrushPlain.js') ],
			[ 'py', 'python', getSyntaxHighlighterScriptPath('@shBrushPython.js') ],
			[ 'ruby', 'rails', 'ror', 'rb', getSyntaxHighlighterScriptPath('@shBrushRuby.js') ],
			[ 'sass', 'scss', getSyntaxHighlighterScriptPath('@shBrushSass.js') ],
			[ 'scala', getSyntaxHighlighterScriptPath('@shBrushScala.js') ],
			[ 'sql', getSyntaxHighlighterScriptPath('@shBrushSql.js') ],
			[ 'vb', 'vbnet', getSyntaxHighlighterScriptPath('@shBrushVb.js') ],
			[ 'xml', 'xslt', 'html', 'htm', getSyntaxHighlighterScriptPath('@shBrushXml.js') ]
		);

		SyntaxHighlighter.all();
	</script>

Tip of the day:

Last week-end, I wanted to learn a bit more about the Play! frame­work, thus I down­loaded it, installed it and cre­ated my first appli­ca­tion. Then I encoun­tered a frus­trat­ing prob­lem: Play cur­rently doesn’t seem to be friends with Cygwin.

The fol­low­ing com­mand, sup­posed to start the appli­ca­tion doesn’t really work as expected when exe­cuted from a Cyg­win bash shell:

    $ play run

Instead of start­ing the app as expected, it just fails and whines:

Error opening zip file or JAR manifest missing : /cygdrive/...play-x.y.z/framework/play-x.y.z.jar
Error occurred during initialization of VM
agent library failed to init: instrument

For­tu­nately, it seems that using play.bat instead works as expected:

    $ play.bat run

That prob­lem is in fact being worked on, I just saw that there’s a pull request for a (par­tial ?) fix: .

Pour les gens désireux de décou­vrir le monde des sys­tèmes dis­tribués, peer-to-peer, les dif­férentes archi­tec­tures pos­si­bles et surtout les sys­tèmes de répu­ta­tion, voilà ma thèse de mas­ter. Je la dis­tribue sous license Cre­ative Com­mons, vous pou­vez donc en faire ce que bon vous sem­ble.

Télécharge­ment:

• le mémoire
• les slides de la présentation

Remar­que: un remède idéal pour les insomniaques!

I’ll never get enough b/w baby pictures ;-)