Archive

Archive for May, 2008

Groovy + JUnit + Ant

May 29, 2008 6 comments

I found it extremely difficult over the past couple days to get Groovy and JUnit and Ant to play nicely together. If you have the opportunity to use Maven for your builds, do it. If you’re stuck with Ant, read on.

I’m writing unit tests in Groovy for an application that’s written entirely in Java. That part is easy – Groovy and Java work well together. And since Groovy ignores scope, you can access the private methods you wrote in Java (or Groovy), which makes testing even easier. Rather than using Reflection or calling the public methods that call those private methods, you can call your private methods directly from a Groovy class. Groovy treats them as if they’re public.

To use Groovy + JUnit + Ant, first you need to compile your Groovy files. This part is easy, if you know you have to do it. The groovyc Ant Task has some great examples you can copy and tweak, but make sure you put the groovy-all-VERSION.jar on your classpath. The similarly-named jar without the word “all” in it won’t work.

The hard part about Groovy + JUnit + Ant is this:

“By default Groovy unit test cases generate Java bytecode and so are just the same as any other Java unit test cases. One thing to watch is often Ant / Maven look for *.java files to find unit tests with pattern matching, rather than *.class files.” – Unit Testing (emphasis mine)

Here’s an example from the Ant JUnit Task page:

<junit>
  <!-- some details omitted -->
  <batchtest>
    <fileset dir="${src.tests}">
      <include name="**/*Test*.java"/>
      <exclude name="**/AllTests.java"/>
    </fileset>
  </batchtest>
</junit>

This doesn’t work for Groovy tests, but it should be easy enough to fix – just remove the “.java” extensions, right? Wrong. The JUnit task can find *.java files in your source directory, but not *.groovy files. So you need to change the fileset to point to your classes directory in addition to removing the “.java” suffix from the include and exclude. And if you use closures in your Groovy tests, they’ll get compiled to inner classes in separate files, so you probably want to exclude those from your fileset. Here’s what my task looked like when I finished:

<junit>
  <!-- some details omitted -->
  <batchtest>
    <fileset dir="${classes}">
      <include name="**/*Test*"/>
      <!-- a '$' in the filename means it's an inner class -->
      <exclude name="**/*$*"/>
    </fileset>
  </batchtest>
</junit>

Make sure to add some reporting and code coverage so you can see the statistics from your tests. Happy Anting.

Tags: , ,

Cookies in Firefox and Internet Explorer

May 18, 2008 9 comments

Mmm…cookies…

Firefox and IE handle them differently. Go figure…

Firefox always shares cookies – across tabs and across windows. No matter how your windows or tabs come into existence, cookies are always shared in Firefox.

IE 7 sometimes shares cookies. It always shares cookies in new tabs. It always shares cookies with the new window if you choose File -> New Window from the menu (or use Ctrl+N). However, if you have an IE window open and you use the Start menu or double-click a desktop icon to open another instance of IE, it will not share cookies.

Seems really strange to me, as clicking File -> New Window appears to do the same thing as double-clicking the IE icon on my desktop. Both show up in the taskbar at the bottom of the screen. Both show up in the Task Manager under the Applications tab. But further investigation shows that only one shows up in the Processes tab of the Task Manager.

IE 7 spawns a new process when you open it from the Start menu or the desktop. However, it uses the same process if you open a new window from an existing IE process. This explains why cookies are shared when you use File -> New Window or Ctrl+N.

I ran into problems with this while working on a web application using Servlets & JSP. (If you’re looking for a great reference, check out Head First Servlets & JSP). Once I realized that a session means something different in IE than it does in Firefox, it all made sense, but I spent a lot of time learning this the hard way.

Can’t all browsers act the same?

JavaOne Recap

May 13, 2008 1 comment

I had the opportunity to attend Java One this year! What follows is part 1 of a 2 part post describing my experience and things I learned.

The Theme

Sun was really pushing JavaFX and Mobile device development this year, although I’ve heard that the mobile push is every year. Netbeans and Glassfish got a lot of attention. Scala was unofficially talked about by some as a potential Java 3 language candidate.

Topics of Interest

Some of the topics and news I found interesting are listed below.

Coming in Java EE 6

  • Reduction of the amount of XML you need to put in your deployment descriptor.
  • Support for annotations for your filters, servlets and listeners. My assumption is that this will facilitate the reduction in XML configuration you need to write. A great side affect of this should be when you want to use any of the numerous web MVC frameworks out there, you should only need to plop the jar in your classpath (WEB-INF/lib) folder and be up and running without the need for web.xml changes.
  • JAX-RS – An API for implementing restful WebServices.
  • Scripting is “going to be treated as a first class citizen” (Not sure what that means really).

Coming in Java SE 7

  • Concept of modules or superpackages to wrap your code for organization, versioning support, and better information hiding than private/protected scoping gives you. See JSR’s 277 and 294 for more information. (Perhaps Groovy could benefit from this :P )
  • Sun says Applets are coming back, that they’re able to shrink the JVM to around 4.5mb, and that the cold start-up time for Applets will be equally as fast (or slow ;) ) as a warm start.
  • One really cool feature they demonstrated of applets is that you can drag and drop them onto the desktop now while they’re running and they’ll run outside of the browser.

Coming in JSF 2.0

The following came from a talk from Ed Burns and another gentleman from Sun on JSF 2.0 where the first 30 minutes they talked a lot about how JSF adoption is steadily increasing and how they’ve listened to the community, understand the pain points, and will improve JSF in version 2.0 of the spec. Some of the specific improvements/changes mentioned were:

  • Better IDE support. (Not sure if this means they’ll release plugins for the major IDE’s or what)
  • Facelets will be part of the spec.
  • JSF Unit will better support testing.
  • Faces Trace will help testing.
  • Integration with Seam and Spring Web Flow. (Not sure how they mean and I haven’t used either of these, though I know the basic concept of what they are/do).
  • Will simplify custom component creation by reducing the number of artifacts you have to produce.

Mobile Device Programming

  • There were plenty of technical sessions on Mobile device API’s for communication, geolocation, etc., but most of the subject material of those were over my head so I haven’t summarized them here. I found those talks very enjoyable though.

Experience

I had a great time at Java One and would like to go back in a few years!

It’s not a conference to go to every year. I didn’t learn as much as I would have at a NFJS conference, but I got a broader range of information about the Java platform and where it’s heading and a great opportunity to meet others.

In part 2 of this post I’ll have notes on JavaFX, Project Hydrazine, jMaki, Netbeans and Scala.

What’s the most fun you’ve ever had… programming?

May 4, 2008 8 comments

Like every kid that’s ever owned a guitar, I dreamed of becoming a rock star. These days my only goal musically is to keep having fun playing music. Hey, and sometimes fake instruments are just as fun as the real ones!

Similarly, I used to dream of becoming a programming rock star. I wanted to be a speaker at conferences and have other geeks ask for my autograph. These days my only goal is to keep having fun playing with Java and any other cool languages I can get my hands on. Groovy is pretty high on my fun list these days.

Seems like a simple thing to do: Have fun.

Having fun is important. More important than being a superstar. More important than a huge paycheck.

I love asking other programmers what’s the most fun they’ve ever had programming. I especially love to ask this question when I’m giving technical interviews. More often than I’d expect, many programmers claim that their current project has been the most fun.

Riiiight. So, why are you leaving? Oh, I’m sorry, looks like we’re out of time – it’s been a pleasure speaking with you *click!*.

So what’s the most fun you’ve ever had programming? Your answer will reveal a lot about you.

My answer? It was a college project. I was on a team of three that made a functional Trivial Pursuit client/server game. Actually, the other two guys on my team were really busy with other activities so I did most of the coding myself. I spent two or three weeks of late nights to complete it. I completely skipped my final Philosophy project that semester so I could program (resulting in one of the only B’s on my college transcript), but it was totally worth it. I had a blast!

That was just one example of fun for me. I have many others like it aaaaand probably nearly as many projects that… fall on the other end of the spectrum, to put it kindly.

What about you? What’s the most fun you’ve had? What was so great about it? You might be surprised what you learn about yourself in dreaming up the utopian project setting. Of course, I’m assuming I’d be a part of your all-star team! Right? RIGHT?!

So, like I said, I don’t care about being a programming rock star, but that didn’t stop me from picking up a copy of Rock Star Programmers recently. I plan on reading it this month along with about a dozen (literally) other books (can you believe I’m just now getting started on this classic!?!). I still believe I’ll do great things in my career and I hope to find inspiration from the stories of others that have done great things and, more importantly, had fun in the process.

Tags:

Groovy’s each method

May 4, 2008 2 comments

It’s one of the coolest things I’ve ever seen. The each method on Object allows you to iterate over anything. Literally. Anything.

In Groovy, everything is an Object. And since the each method is defined on class Object, that means everything has an each method. Everything. That means you can iterate over anything.

Lists, Ranges, Strings, and Maps. Everything has an each, and you can use it to iterate. You don’t have to deal with for loops. And while Java 5’s for-each loop is kinda nice, it’s nowhere near as cool as Groovy’s each.

In Java, you have to use a for (or while) loop to iterate. You might do something like this:

for (String str : myList) {
    System.out.println(str);
}

Here’s some similar code in Groovy:

myList.each {
    println it
}

Isn’t Groovy just so much cooler? You don’t have to define the type and you don’t even need to give the variable a name – by default, the parameter is called it.

Tags: