Throw undeclared checked exception in Java, take II

Wrapping is in many times a necessity as you may not be able to throw a declared exception for contract restrictions or want to reduce boiler plate code. Wrapping an exception with a RuntimeException is sub optimal, takes more resources and clutter the logs with unnecessary stack traces, makes you look for the root cause. Loved Alexey's idea about throwing undeclared checked exception in Java. Here is a small twist on that AnyThrow class: Now I can do So the compiler and the reader knows I'm breaking the flow with an exception. The stack trace does not have the AnyThrow in it and the "return null" there is only to trick the compiler.

Testing Guice can init servlets

Sequel to the prev post, binding servlets is not enough. You must make sure that Guice can initiate them. For example, a common error is not binding servlets as singleton, there you get exceptions like

ServletException: Servlets must be bound as singletons. Key[type=my.servlet.FooServlet, annotation=[none]] was not bound in singleton scope.

Here's a way to test for all servlets in Guice context When calling init on the filter it would init all servlets in context.

Testing Guice Servlet bindings

Evan if you work with Servlet (for the record, I hate j2ee) and Jersey you can still enjoy Guice.
Unfortunately its not that evident how to test that the ServletBinder is binding your servlets to the right place. Here is a small Assert class that does that.

Continuous Deployment at kaChing

In my last visit to Israel I visited IBM Research, Outbrain and Answers.com. Over there we discussed kaChing's culture, working methodologies and tools. The talk focused on continuous deployment and lean startup and was based on Pascal's and David's posts at kaChing Eng Blog.
Here is the presentation, using the fantastic Prezi tool.

Continuous Deployment on Prezi

Scala on Eclipse without the plugin

The Scala supported IDE is one of the few pain points of developers who want to start using Scala in their Java project. On existing long term project developed by a team its hard to step in and introduce a new language that is not supported by the existing IDE. On way to go about it is to hid the fact that you use Scala from the Java world by using one way dependency injection. Still, if you wish to truly absorb Scala into your existing java environment then you'll soon introduced cross language dependencies.

Most of our team is using Eclipse as the main IDE, its incrimental compilation in Java with its tight JUnit integration are great for fast TDD programming. Unfortunately the Eclipse Scala plugin is not there yet, it may hangs the IDE and messes up Java compilation - especially in large (more then 1000 source files) Java/Scala projects. Though the plugin is getting better over time some developers would find the plugin as a majore drag on their productivity.
For developers who do not write Scala at all or rather edit Scala with other editors, you can use this alternate path which lets them work on their Java or Scala code without messing with the plugin.

Compile Scala Eclipse project without Scala Plugin 

1. Add a compilation script to your project.
The Following script is using the Fast Scala Compiler (fsc). The fsc is a compilation server which always run in the background, as in a warm scalac always ready to receive new work. Is will reduce compilation time dramatically.
The classpath for compilation is taken from the Eclipse project .classpath file. You may take the source directory from there as well if you wish (exercise to the reader).
The params are not passed to the fsc in the command line since in my project's case the line is too long for the OS to handle. The alternative is to put it into a file and let fsc handle it for you.

#!/bin/sh
# Create a classpath from the eclipse .classpath file
lib=`grep classpathentry .classpath | grep "kind=\"lib\"" | tr -d '\t' | sed 's/.*path=\"\(.*[^src]\.jar\)\".*/\1/' | grep -v classpathentry`
CLASSPATH=`echo ${lib} | sed 's/ /:/g' `  

# point SCALA_HOME to Scala home (might want to add it to your project as well)  
export SCALA_HOME=lib-tools/scala-2.8.0

# java opts for your compilation server
export JAVA_OPTS="-client -Xmx1024M -Xms256M -XX:PermSize=128m -Xss2M -XX:MaxPermSize=256m -Xverify:none -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled"

DEST=target/bin-scala
mkdir -p $DEST

SCALAC_PROPERTIES=scalac.properties
echo "-classpath $CLASSPATH:target/bin" > $SCALAC_PROPERTIES
echo "-d $DEST -deprecation" >> $SCALAC_PROPERTIES
find src srctest -name *.java -o -name *.scala >> scalac.properties

time $SCALA_HOME/bin/fsc @$SCALAC_PROPERTIES &

2. Eclipse classpath
Add the scalac destination directory ($DEST) to the .eclipse classpath

3. Add the fsc builder to your project
Open the project properties and add the script above to the list of builders.
Set the working directory to be your project root directory.

5. Set the builder properties
Run it in the background when needed:

Add Scala syntax highlighting editor for Eclipse 

Even without the Scala plugin refactoring and debugging capabilities you can write some decent Scala code with the help of syntax highlighting for better readability. There are two options:

• The color editor which use jEdit modes. Daniel Spiewak added a Scala mode to it, unfortunately the plugin doesn't seem to work with Eclipse 3.6.
• The Colorer take5 project which works fine on my Eclipse on the Mac. It does not have a Scala mode yet but you can grab one at http://github.com/eishay/eclipsecolorer_scala 

It gives you a lightweight way (with its pros and cons) to write Scala in Eclipse.