groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.1.8 and you are trying to load version 2.1.9

8. December, 2014

If you see this error while running the code from Eclipse, check the .classpath file for this line:

<classpathentry exported="true" kind="con" path="GROOVY_SUPPORT"/> 

In this case, Eclipse adds version 2.1.8 to the classpath and Maven adds 2.1.9. At runtime, Groovy detects both versions and aborts since this will cause subtle bugs.

Solution: Delete the line above in the .classpath file.

If you see a line which contains GROOVY_DSL_SUPPORT, then you can leave that in – the Groovy plugin will use the JARs which Maven adds to the classpath.


YouDebug, the Non-interactive Debugger

7. May, 2014

“Non-interactive” and “debugger” seem to be contradictory but bear with me. YouDebug is a tool which allows you to debug a running Java application with a script.

How could this be useful? From the website:

[…]your program fails at a customer’s site with an exception, but you can’t (or don’t want to) reproduce the problem on your computer[…]

Sounds like a familiar problem: Customer has a problem but they can’t give you access for security, legal or technical reasons. You can’t go there (too far away) of even if you could, security won’t let you touch anything.

In a nutshell, YouDebug is a debugger that is controlled by a Groovy script:

breakpoint("com.acme.SubStringTest",7) {
  println "s="+s;
}

This sets a breakpoint in line 7 of “SubStringTest” and then prints the value of the local variable “s”.

Granted, it’s more time-consuming then doing it yourself (and you may need several attempts to get at the bottom of things) but you don’t have to install an IDE at your customer site, you don’t have to bring the source code along and technically, the customer is already running code that you wrote so from a legal and security point of view, this isn’t much different.


Jazoon 2013 – Rocket Propelled Java

25. October, 2013

Jazoon 2013 badgeRocket Propelled Java” is about being more productive by writing less boilerplate code (slides on slideshare).

In his talk, Andres Almiray showed some tools to make your code more compact while keeping or even improving readability.

The first one is lombok and lombok-pg which use Java annotations to generate a lot of boiler plate code (slides 3-6)

Similar, you can use Groovy AST transformations to create things like immutables or singletons correctly (“There are 5-6 ways to create singletons. Only two of them are correct”, slides 7-9)

Note: You might be worried to add Groovy to a pure Java project. You don’t have to. Just use it for the AST transformations to stop wasting time on writing code that only makes your compiler happy. Use Groovy as a “boilerplate code buster.”

If you ever wanted to use “Design by Contract“, GContracts is for you.


Jazoon 2013 – 33 things you want to do better

25. October, 2013

Jazoon 2013 badgeTom Bujok listed a lot of methods, technologies and frameworks that you should be aware about in his talk “33 things you want to do better” (slides on speakerdeck)

At the beginning he reminded us how quickly a well designed system goes bad due to hurried changes. We need to be aware of our technical debt and we need to allocate time to spend on reducing it (slides 3-12).

As an example, car batteries are easy to find. They are a replacement part, designers and engineers make it easy to find. Compare this to the configuration of your project. If you need to change it, how easy is it to find the file that needs to be changed and then the place in the file?

Another important point is skills. In most other professions, you have some mastery of a skill before you use it. You train hundreds of hours before you play your first football game. In Software, we show you a computer, we show you the programming language of the year (not necessarily this year’s). There is no time to master the tools you have to use from day one (slides 13-15).

“We are what we repeatedly do; excellence then, is not an act but a habit.” – Aristotle

Or as Wikipedia defines it:

“Habits […] are routines of behavior that are repeated regularly and tend to occur subconsciously.”

Stop wondering why you always make the same mistakes – they’re habits. Eliminate them ASAP (slide 19):

Bad Habits – Katherine Murdock “The Psychology of Habit”:

  • Recognize bad habits and eliminate them ASAP
  • The older you get the more difficult it is to remove a bad habit
  • Each repetition leaves its mark!

Turning bad habits into good ones – Dr. Michael Roussell, PhD.:

  • You can’t erase a habit, you can only overwrite one.
  • Insert the new habits into the current habit loops

Bad Habits

Configure your IDE properly and remove bad defaults. Replace “ex.printStackTrace();” with “throw new RuntimeException(ex.getMessage(), ex);” (slides 43-45).

One bad habit is empty catch blocks with “can never happen” comments. If you see one during a code review, replace it with “System.exit(-1);”. It can never happen, right? Right? (slides 46-47).

Note: I have create a “ShouldNotHappenException” for this case 🙂

Another one is to make every method in a static helper class public. Maybe some of them can be package private? (slide 48)

Learn about other good habits. Read books like “Effective Java” (Joshua Bloch) and “Clean Code” (Robert C. Martin) (slide 49)

Use code reviews to notice bad habits and to spread knowledge in your team but prevent blame games. (slide 73)

Learn the keyboard shortcuts of your IDE (slide 78)

Remember (slide 79):

“Any jackass can kick down a barn, but it takes a good carpenter to build one.” – Sam Ryburn

Projects You Should Know

Project lombok and lombok-pg – In a nutshell, these hook into the Java compiler and generate additional bytecode when certain annotations are present. Bored with getters, setters, hashCode() and equals() plus a nice toString()? Use @Data (slides 21-28).

Guava (slides 29-33)) is a great library with many tools that you have been missing in Java for years. You might also want to look at commons-lang.

Want to use lambda expressions but can’t upgrade to Java 8? Then lambdaj is for you (slides 34-39).

Logging? slf4j (40-42). Especially nice when combined with the @Slf4j annotation from lombok.

Bored to write all that boiler plate code to create all those services and managers that form your app? Look at Guice or Spring.

Use Spock to make tests more compact and easier to understand. (slides 50-52)

Unitils contains all the helper functions that we always missed in JUnit and Hamcrest (53-56).

JUnitParams will help you run tests with different parameters (57-59).

Need to wait for something during a test? Awaitility will help. (60-61)

When mocking isn’t enough and you need to inject code during a test, Byteman is the tool you want to look at (62-63)

Getting bored writing boiler plate code in Java to make a compiler happy? Have a look at Groovy. (64-67)

How about adding dependencies to your scripts? Try Grape. (68-69)

Is your build a mess? Do you feel Maven is too verbose or too limiting? Gradle might be for you. (70-72)

Version control is slowing you down? Have a look at Mercurial or Git (75)

Use bash or Python to automate man-/menial work. If you’re on Windows, look at Babun or Cygwin. (76-77).


Jazoon 2013 – Spock: boldly go where no test has gone before

24. October, 2013

Jazoon 2013 badgeIf you look at your tests, do you see a lot of repetitive patterns? Or are you looking for a way to express your intent more easily? Then, Spock might be for you. The talk “Spock: boldly go where no test has gone before” by Andres Almiray (slides on slideshare) gave a good introduction to the framework. Here is an example:

class HelloSpock extends spock.lang.Specification {
    def "length of Spock's and his friends' names"() {
        expect:
        name.size() == length

        where:
        name     | length
        "Spock"  | 5
        "Kirk"   | 4
        "Scotty" | 6
    }
}

In a nutshell, this creates three tests, running the assertion name.size() == length for each tuple of values. Here is an example how to test a stack.

But this is just one of many ways which you can use to describe tests that Spock should execute for you. The page “WhySpock” lists 10 reasons.


Jazoon 2012: Divide&Conquer: Efficient Java for Multicore World

29. June, 2012

Not much new in the talk “Divide&Conquer: Efficient Java for Multicore World” by Sunil Mundluri and Velmurugan Periasamy.

Amdahl’s law shows that you can’t get an arbitrary speed-up when running part of your code in parallel. In practice, you can expect serial code to execute 2-4 times faster if you run it with, say, the fork/join framework of Java 7. This is due to setup + join cost and the fact that the tasks themselves don’t get faster – you just execute more of them at the same time. So if a task takes 10 seconds and you can run all of them in parallel, the total execution time will be a bit over 10s.

If you want to use fork/join with Java 6, you can add the jsr166y.jar to your classpath.

Again, functional programming makes everything more simple. With Java 8 and lambda expressions, syntactic sugar will make things even more readable but at a price.

You might want to check one of today’s new languages like Xtend, Scala or Groovy to get these features today with Java 6.


Closures and Bindings in Groovy

30. December, 2011

Mark Menard blogged about a hidden gem in Groovy which might be useful when you use closures a lot: Binding properties to a closure after the closure was created.

Remember, it’s simple to bind properties to a closure when those properties exist before the closure is created: Just define them. But how could you create a library of closures for user to consume?

def c = {
	println a // a isn't know here
}

def a = "Hello"

def binding = new Binding ()
binding.setVariable ("a", a)

c.setBinding (binding)
c.call()

As you can see, the property a isn’t known at the time the closure is defined. The binding allows to “inject” it later.

Groovy!


Groovy Eclipse V2 M2

14. December, 2009

It’s been a couple of days since the Milestone 2 of the new Goovy Eclipse V2 plugin was released. If you’re developing with Groovy and you’re using Eclipse and you’ve been living under a stone, get it now. It’s so much better than the old Groovy plugin.

In word: Development with Eclipse has become Groovy, again.

Links:
Groovy-Eclipse 2.0.0M2 New and Noteworthy
Groovy-Eclipse 2.0.0M1 New and Noteworthy


Traits for Groovy/Java

25. June, 2009

I’m again toying with the idea of traits for Java (or rather Groovy). Just to give you a rough idea if you haven’t heard about this before, think of my Sensei application template:

class Knowledge {
    Set tags;
    Knowledge parent;
    List children;
    String name;
    String content;
}
class Tag { String name; }
class Relation { String name; Knowledge from, to;

A most simple model but it contains everything you can encounter in an application: Parent-child/tree structure, 1:N and N:M mappings. Now the idea is to have a way to build a UI and a DB mapping from this code. The idea of traits is to implement real properties in Java.

So instead of fields with primitive types, you have real objects to work with:

    assert "name" == Knowledge.name.getName()

These objects exist partially at the class and at the instance level. There is static information at the class level (the name of the property) and there is instance information (the current value). But it should be possible to add more information at both levels. So a DB mapper can add necessary translation information to the class level and a Hibernate mapper can build on top of that.

Oh, I hear you cry “annotations!” But annotations can suck, too. You can’t have smart defaults with annotations. For example, you can’t say “I want all fields called ‘timestamp’ to be mapped with an java.sql.Timestamp“. You have to add the annotation to each timestamp field. That violates DRY. It quickly gets really bad when you have to do this for several mappers: Database, Hibernate, JPA, the UI, Swing, SWT, GWT. Suddenly, each property would need 10+ annotations!

I think I’ve found a solution which should need relatively few lines of code with Groovy. I’ll let that stew for a couple of days in by subconscious and post another article when it’s well done 🙂


Jazoon, Day 2: XWiki

24. June, 2009

I’m a huge fan of wikis. Not necessarily MediaWiki (holy ugly, Batman, the syntax!). I dig MoinMoin. I just heard the talk by Vincent Massol about next generation wikis. Okay, I can hear you moan under the load of buzzwords but give me a moment. XWiki looks really promising.

Wikis basically allow to publish mostly unstructured data. I say “mostly” because wikis give them some structure but not (too) much: You can organize it in pages and put it into context (by linking between the pages). Often, this is enough. But recently, MediaWiki has started to add support for structured data. See that infobox in the top left corner? But that’s just half-hearted.

XWiki takes this one step further. XWiki, as I understand it, is a framework of loosely coupled components which allow you to create a wiki. The default one is pretty good, too, so most of the time, you won’t even get into this. The cool part about XWiki is that you can define a class inside of it. Let me repeat: You can create a page (like a normal text page) that XWiki will treat as a class definition. So this class gets versioned, etc. You can then add attributes as you like.

After that, you can create instances of this class. The instances are again wiki pages. You can even use more than a single instance on a page, for example, you can have several tag instances and a single person instance. Instances are versioned, too. Of course they are, this is a wiki!

Now you need to display that data. You can use Velocity or Groovy for that. And guess what, the view is … a wiki page. So your designers can create a beautiful look for your the boring raw data. With versions and comments and everything. While some other guys are adding data to the system.

In “normal” wiki pages, you can reference these instances and render them using such a template. The same is true for editors. With a few lines of code, you can create overview pages: All instances of a class or all instances with or without a certain property or you can use Groovy to do whatever you can think of.

Now imagine this: You have an existing database where your marketing guys can, say, plan the next campaign. They can use all the wiki features to collect ideas, filter and verify them, to come up with a really good plan. Some of that data needs to go into a corporate database. In former wikis, you’d have to use an external application, switch back and forth, curse a lot when they get out of sync.

With XWiki, you can finally annotate data in your corporate database with a wiki page, with all the power of a wiki and you can even display the data set in the wiki and edit it there. Granted, the data set won’t be versioned unless your corporate database allows that but it’s simple to do the versioning in the data access layer (for example, you can save all modifications in a log database).

Suddenly, possibilities open up.