Archive for the ‘Java’ Category

Using JUnit 5 with Spring Boot 2, Kotlin and Mockito

Tuesday, December 19th, 2017

I’ve just published a new article on Medium.com.

I’m lazy today, so I’ll just give you a link to it:
https://medium.com/@dSebastien/using-junit-5-with-spring-boot-2-kotlin-and-mockito-d5aea5b0c668

Enjoy!


Use bash to decompile Java class files recursively

Tuesday, December 8th, 2015

Here’s a quick one. As you *might* know, I like Bash (even though I’m a Win* user..), so here’s an alias I’ve added recently:

export JAD_HOME=...
append_to_path $JAD_HOME
alias jad='(jad.exe)&'
jadr() { ("jad.exe" "-d" "." "-s" "java" "-r" "**/*.class")& }

With the above, jad will execute ‘jad’ and ‘jadr’ will recursively decompile all Java class files in the current/sub folders.


New in Java 7 (03) – Multi catch

Saturday, December 3rd, 2011

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

Anyway, back for a new feature that Java has brought us: multiple catch clauses. And honestly, even if it’s a little one compared to other features, I find it a great addition to the Java developer’s toolkit. We (should) always seek to improve our code and reduce maintenance costs through refactoring etc, but sometimes the language doesn’t help.

Handling exceptions has been one area where code repetition often comes up. You’ve probably all written 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 refactor your code and do this instead:

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

Yummy!


New in Java 7 (02) – Switching over Strings, beyond good & evil

Tuesday, August 9th, 2011

In the first post of this series, I’ve told you a bit about the new diamond notation which is a nice addition and provides for better code readability and less verbosity. And not only that, but since we’re typists first and programmers second, it also allows us to increase the LOC / minute count (and whether that is a good thing is actually open to debate) ;-) (sorry for those poor hunt and peck typists among you).

For this second post, I want to talk about a feature that has been requested about 16 YEARS ago and that was finally implemented in Java 7: the ability to write switch statements with String cases. I won’t insult you with an example, if you want one, then check the official docs.. Also, I won’t cover the performance aspects, which other people have already explained quite nicely.

As many of you know, it’s a feature that has been available for a long time in many other programming languages (e.g., C#, JavaScript, ruby, …) and even though hardcoding String literals should be avoided whenever possible, there are still cases where it makes sense.

To cater for the lack of that feature, multiple workarounds were used. One of which (the ugliest IMHO) being to use if-then-else blocks to handle all the cases for non-binary decisions (more complex than simple if-else), which indeed leads to unreadable/unmaintainable code (even though it is context based and sometimes if-then-else blocks make more sense than using a switch).

Another approach, which I think is way better on multiple levels is to define an enum with a fromString(String) method and use the enum values in a switch via the valueOf method. That technique allows to avoid repeating hardcoded Strings all over the place and keeps the code easily refactorable. Not only that, but it is also way more flexible. For example, in the fromString method (or whatever you decide to call it), you can decide whether you want to support case sensitivity or not, how to treat null values, etc. You can find a nice writeup of that idiom there.

The support for String objects in switch statements is very welcome, but keep in mind that it isn’t the silver bullet and that it shouldn’t be used in all cases (haha) :)


New in Java 7 (01)

Sunday, July 31st, 2011

Java 7 has finally been released! There have been a lot of discussions around the features that would/wouldn’t be included in Java 7. After a while, I decided to stop checking the news around that subject since it changed so often. And apparently, some of the most awaited features have been deferred to Java 8 or later. Among which: JSR 294 (Language and VM support for modular programming), closures,  or JDK modularization (project Jigsaw). Too bad! But anyhow, 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 features that I find interesting as I discover them (don’t except the list to be exhaustive though).

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

You can now replace the type arguments required to invoke the constructor of a generic class with an empty set of type parameters (<>: informally called the diamond) as long as the compiler can infer the type arguments from the context.

If we translate 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 addition, but make sure to check out the reference documentation for more details, it doesn’t stop there ;-)


Play Framework and Cygwin

Wednesday, June 15th, 2011

Tip of the day:

Last week-end, I wanted to learn a bit more about the Play! framework, thus I downloaded it, installed it and created my first application. Then I encountered a frustrating problem: Play currently doesn’t seem to be friends with Cygwin.

The following command, supposed to start the application doesn’t really work as expected when executed from a Cygwin bash shell:

    $ play run

Instead of starting 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

Fortunately, it seems that using play.bat instead works as expected:

    $ play.bat run

That problem is in fact being worked on, I just saw that there’s a pull request for a (partial ?) fix: .