Java Toolbox

9. November, 2012

 posted an article with some tools that you should know about when developing Java code: “A Software Craftsman’s Toolbox: Lightweight Java libraries that make life easier.

Along the same lines, Jeeeyul came up with an idea to make

System.out.println( "Hello World." );

produce this output:

(MyHelloWorld.java:10) : Hello World.

Just takes 34 lines of code: “Make System.out.println() Rocks!


Jazoon 2011, Day 1 – Eclipse Mylyn: Redefining the “I” of the IDE – Benjamin Muskalla

26. June, 2011

Eclipse Mylyn: Redefining the “I” of the IDE – Benjamin Muskalla

Mylyn is one of those things that can change your world if you just give it a chance. The talk emphasized one of the major points: We write the code in an IDE (integrated, not intelligent), we track bugs in a bug tracker, we communicate with email, twitter and Facebook and we track progress on a piece of paper.

Being able to save the context (i.e. the classes and files involved) in a bug, so, say, a junior doesn’t have to wade through the whole source to even get started, is something that I’ve been missing several times already. If only I wasn’t such an old dog, already.

Links:


New Approach to Documentation

15. May, 2011

Documentation usually has these three attributes: It’s incomplete, outdated and plain wrong.

That doesn’t apply to every bit of information in your documentation but it you can be sure the statement above is correct for the whole documentation.

As a consumer of such documents, it’s a nice puzzler to determine into which of the three categories a bit of information belongs.

This leads to the common “we hate documentation” stance that all software developers soon adopt, no matter if they have to write/maintain the documentation or if they have to use it.

As we all know, the only reliable source of documentation are unit tests. But they can still be incomplete (= missing the example you need) or outdated (= missing examples for the latest API).

The solution? Generate documentation from the source code. And I don’t mean “from javadoc in the source code”, I mean literally from the code. If a method is used in a certain way in 317 places in your code and once in a different way, then you have two examples. One of them probably works, the other is probably documents a bug which your tests missed.

Eclipse is starting to get support for this. The first step was code completion. Now we have a couple of guys working on Eclipse Code Recommenders.

This summer, Stefan Henß starts to work on an “extended documentation platform” for Eclipse.


Hidden JUnit features: @Rules

8. October, 2010

@Rules seem a better solution than @RunWith to do some special work before/after a test. The release notes mention a couple of ideas:

  • Notification on tests
  • Setting up or tearing down resources, especially when they are used in multiple test classes
  • Special checks performed after every test, possibly causing a test to fail.
  • Making information about the test available inside the test

Related articles: