Tag Archives: netbeans

Groovy, Java, Programming, Scripting, Software

Working with Groovy Tests

For my new project Xapper I decided to try and write my tests in Groovy. Previously I had used Groovy scripts to generate data for Java tests but I was curious as to whether it would be easier to write the entire test in Groovy instead of Java.

Overall the experience was a qualified “yes”. When I was initially working with the tests it was possible to invoke them within Eclipse via the GUnit Runner. Trying again with the more recent 1.5.7 plugin, the runner now seems to be the JUnit4 one and it says that it sees no tests, to paraphrase a famous admiral. Without being able to use the runner I ended up running the entire suite via Gant, which was less than ideal, because there is a certain amount of spin-up time compared to using something like RSpec’s spec runner.

I would really like all the major IDEs to get smarter about mixing different languages in the same project. At the moment I think Eclipse is the closest to getting this to work. NetBeans and Intellij have good stories around this but it seems to me to be a real pain to get it working in practice. I want to be able to use Groovy and Java in the same project without having Groovy classes be one of the “final products”. NetBeans use of pre-canned Ant files to build projects is a real pain here.

Despite the pain of running them though I think writing the tests in Groovy is a fantastic idea. It really brought it home to me, how much ceremony there is in conventional Java unit test writing. I felt like my tests improved when I could forget about the type of a result and just assert things about the result.

Since I tend to do TDD it was great to have the test run without having to satisfy the compiler’s demand that methods and classes be there. Instead I was able to work in a Ruby style of backfilling code to satisfy the runtime errors. Now some may regard this a ridiculous technique but it really does allow you to provide a minimum of code to meet the requirement and it does give you the sense that you are making progress as one error after another is squashed.

So why use Groovy rather than JRuby and RSpec (the world’s most enjoyable specification framework)? Well the answer lies in the fact that Groovy is really meant to work with Java. Ruby is a great language and JRuby is a great implementation but Groovy does a better job of dealing with things like annotations and making the most of your existing test libraries.

You also don’t have the same issue of context-switching between different languages. Both Groovy and Scala are similar enough to Java that you can work with them and Java without losing your flow. In Ruby, even simple things like puts versus println can throw you off. Groovy was created to do exactly this kind of job.

If the IDE integration can be sorted out then I don’t see any reason why we should write tests in Java anymore.

Standard
Programming

Toy Scala Static Webserver in less than 100 lines

Doh! The original link to the code was for the wrong file! Sorry. Corrected below.

Okay so there has been a craze for writing static webservers in new languages in less than 100 lines recently and I am not claiming that this code is anything special but I wanted to give to give the NetBeans Scala plugin a go (in NetBeans 6.5) so here’s my version of a Scala static webserver (in less than 100 lines, natch).

The code is more of a Toy at the moment as it assumes a very happy path. However it does work and it did provide some useful learning about Scala.

The good stuff includes: compact code, class imports, XML literals, map literal syntax and the NetBeans plugin does a good job of providing codealong feedback from the compiler.

Confusing stuff:

  • accessing array indexes with () not [], it makes sense but you have to get used to when coming from Java
  • implementing Java interfaces in Scala: still not totally sure how you do that
  • getting the right type to allow a Java API to be called: Array[Byte] seemed to take a long time to get right and not having type-coercion for Scala Lists to Java Lists means there is a anemic list variable in play
  • functions that have many parameters make for confusing IDE errors; do you want Int, Int, Int, Int, String, String or Int, Int, Int, Int?

And finally the bad:

  • the streaming IO for binary files is entirely imperative and is basically Java code, I’ve been told that Scalax can help put a prettier front on that
  • nothing to do with Scala but the in-built Java HttpServer should have had the public API in interfaces and there should have had an NIO-based HttpExchange
  • I.cant.stop.using.periods even.if.I.dont.have.to

Overall I am pretty happy with the quality of the final code and I feel I’m finding the balance of the language more and seeing Scala as more of an extension of Java than something entirely unique.

Standard
Java, Programming, Web Applications

Notes on NetBeans 6.1

I am working on an exciting web prototype project at the moment and I am using NetBeans 6.1 rather than my usual Eclipse environment. Overall I am very happy with the experience. The good points are:

  • NetBeans seamlessly integrated with my existing Tomcat instance, configured it correctly and makes it easy to build and deploy my application making my build-compile-deploy cycle as quick as it has ever been
  • The Javascript support is excellent and allowed to discover the JQuery API with no problems
  • It has been easy to define libraries and have them brought in to the project
  • The built-in XSLT validation and one-click transform of a test file is really powerful and very simple to use
  • Associating a web project with different deployment servers is easy
  • The GUIs for writing Java Web App configuration files is great
  • Managing NetBean Modules is easy and the interface is good
  • NetBeans 6.1 is fast, really noticably faster than 6.0.1

That is a whole lot of positive, so what hasn’t been so good?

  • Code templates complete on a different keystroke to code completion. The seperation doesn’t make sense to me. Both things are about completing what I have typed.
  • The window of opportunity for completing a code template is too narrow. If you don’t complete while typing the template stub then it doesn’t work.
  • When entering the parameters of a generated method you have to hit return too much. If the auto-generated code has aready correctly assigned variables to the parameter position then I’m done. At the moment though you have to hit return for each parameter otherwise the code generator gets in a tizzy and often opens brackets on the line below the current method.
  • Really gnarly HTML can take a long time to parse for the navigator windows and the slowdown is noticeable across the whole IDE. XML blazes by comparision.
  • There’s a lot of magic going on to make the project work automagically and there isn’t a good “raw” representation of the project that would make it easy to work from CI and the command-line.

Essentially most of these problems are to do with the interface being too fussy and in some cases too specialised. However I do thing I am getting the benefit of the integrated development environment and while it may not be as fast as Rails it is some of the fastest Java web development I have ever done.

Standard
Java, Software

Java IDEs support Subversion

At last! A genuine point of differentiation between NetBeans and Eclipse. NetBeans has long had SVN support but to be honest it is a little ugly and requires you to download the Collab.Net SVN client. Subversive has been a far superior SVN plugin with a choice of connectors and a decent implementation of a diff editor and team synchronisation page.

Therefore I am absolutely delighted that the Eclipse project has adopted the Subversive code base and is incubating it for release as the official in-built SVN plugin for Eclipse. It’s an excellent decision and puts Eclipse ahead as far as SVN support is concerned. I look forward to the official incorporation of the new plugin.

Part of the reason why Subversive is great is that it really makes it easy to use a variety of SVN provider implementations. My favourite is SVNKit which has always been reliable, fast and fully featured. It surprises me that NetBeans which is otherwise very much all about the Java has chosen to use a native SVN implementation. I would really like them to create an SVNKit based plugin.

Standard