if99.net

IF99 ITB

Archive for the ‘java’ Category

? Documenting Jersey REST API

without comments

Documentation is error-prone. So the best documentation should be the code itself… or automatically generated from the code.

I haven’t found any open source project that can do this so I created one. As I’m currently learning Scala, I decided to write the code with Scala. You can find the code in Bitbucket: https://bitbucket.org/enefem/restdoc

It’s by no mean complete so feel free to fork and add functionalities or ask for improvements.

Screenshot

How To Use

To use the tools, you must define an init-parameter in the Jersey Container. The param-name should be packageName and the param-value should the complete package name where your REST resources are located. Example is as follow:

<servlet>
    <servlet-name>Jersey REST Service</servlet-name>
    <servlet-class>
         com.sun.jersey.spi.container.servlet.ServletContainer
    </servlet-class>
    <init-param>
         <param-name>
              com.sun.jersey.config.property.packages
         </param-name>
         <param-value>
              de.fraunhofer.iais.tat.targeting.resources
         </param-value>
		  </init-param>
    <init-param>
         <param-name>packageName</param-name>
         <param-value>
             de.fraunhofer.iais.tat.targeting.resources
         </param-value>
    </init-param>
</servlet>

If you are using Guice and jersey-guice (which I do), you can define init-parameter as follow:

serve("/*").with(GuiceContainer.class,
   ImmutableMap.of("packageName", "de.fraunhofer.iais.tat.resource"));

And that’s all! The rest documentation should be available on path /restDoc.

Documenting Jersey REST API originally appeared on firdau.si on February 4, 2011.

Written by nanda

February 4th, 2011 at 9:06 pm

Posted in java

? Deployment parameter for REST resource

without comments

When you are creating resource in a REST application, it will only be automatically created if you have an empty parameter. The problem is, sometime we need a resource that is configurable, so it can be reused by other applications.

We can solve this problem by defining init parameter in our web.xml like this:

<servlet>
    <servlet-name>JerseyTest</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <init-param> 
        <param-name>param</param-name> 
        <param-value>test</param-value> 
    </init-param> 
</servlet>

Or if you’re using Guice (and jersey-guice), changing the end of your ServletModule like this:

serve("/*").with(GuiceContainer.class,
     ImmutableMap.of("param", "test"));

The parameter can be read by your resource by defining ServletConfig as field and annotate that with @Context. Example:

@Path("/test")
public class TestResource {
   @Context ServletConfig config;

   @GET public String testMethod() {
      return config.getInitParameter("param");
   }
}

Deployment parameter for REST resource originally appeared on firdau.si on January 28, 2011.

Written by nanda

January 28th, 2011 at 4:27 pm

Posted in guice,java,jersey,rest

Maven Plugin: Java Code Formatter

without comments

Enforcing code format in an organization needs discipline. And the best way to do that is by doing some automation. A plugin for Maven will be a easy decision if your organization has used Maven to manage the build.

This plugin is one plugin that exactly does that. The backbone on the plugin comes from Eclipse Java Formatter, which I still endorse as the best in the industry.

Compared to Jalopy, which is now not free, I find Eclipse formatter has the flexibility we often needed. Although it is not bug-free, for most cases it is more than enough.

However, I concerned by the fact that official maven doesn’t have the latest jar of Eclipse JDT. It still only has version 3.3 of it. Hopefully they will have it soon, especially after Helios is released, which bring a lot of improvement to the Java formatter.

Related posts:

  1. Java Formatter Improvement on Eclipse Helios
  2. My Eclipse Code Formatter
  3. Eclipse plugin: Introduce Static Imports

Maven Plugin: Java Code Formatter originally appeared on satukubik on June 10, 2010.

Written by Nanda Firdausi

June 10th, 2010 at 3:30 pm

Java Formatter Improvement on Eclipse Helios

without comments

A new milestone of Eclipse 3.6 just released with a long new and noteworthy list.

Instead of discussing what’s new from this release, I want to discuss a set of improvement from its Java Formatter. I still love Eclipse’s Java Formatter and with these new improvements, I even love it more. This improvements unfortunately didn’t make their way to list of new and noteworthy, hence the reason why I wrote this blog post.

First, we can now turn off the formatter for some part of your code that you don’t want to format automatically. This is achieved by defining special tags.

This is very useful to format a part of your code that will if formatted will be uglier. For example:

		// [format off]
		foo(           "|------------|\n"            +
		    "-----------|------------|-----------\n" +
	         "----------|   FORMAT   |----------\n"  +
	          "--------- |          | ---------\n"  +
	            "-------  |        |  -------\n"  +
	                      "--------");

No tools can keep this formatting no matter what are you trying, right? ;)

The next improvement is very beautiful. This is result of bug entry 59891 which is posted five years ago (! just to make sure that you understand its complexity).

Basically the problem is if you have nested method calls, Eclipse can’t group the arguments based on their call level. So if you have something like:

public class Main {
    public static void main(
            String[] args) {
        foo(bar(1, 2, 3), baz(4, 5, 6, 7));
    }
}

In case the editor set to wrap on 40th characters, you will get:

public class Main {
    public static void main(
            String[] args) {
        foo(bar(1, 2, 3), baz(4, 5, 6,
                7));
    }
}

With the improvement, you will get:

public class Main {
    public static void main(
            String[] args) {
        foo(bar(1, 2, 3),
                baz(4, 5, 6, 7));
    }
}

Very nice!

A longer example (based on post on StackOverflow.com).

With old formatter, the best you can get is:

		Options options = new Options().addOption(OPTION_HELP_SHORT,
				OPTION_HELP, false, "print usage information").addOption(
				OPTION_VERSION_SHORT, OPTION_VERSION, false,
				"print version and exit").addOption(
				OptionBuilder.withLongOpt(OPTION_PROPERTIES)
						.hasArg()
						.withArgName("FILE")
						.withType(File.class)
						.withDescription("specify a user properties file")
						.create());

Or anything explained on the original post. With the new improvement, you can set the formatter to get something like this:

		Options options = new Options()
				.addOption(OPTION_HELP_SHORT, OPTION_HELP, false, "print usage information")
				.addOption(OPTION_VERSION_SHORT, OPTION_VERSION, false, "print version")
				.addOption(	OptionBuilder
									.withLongOpt(OPTION_PROPERTIES)
									.hasArg()
									.withArgName("FILE")
									.withType(File.class)
									.withDescription("specify a user properties file")
									.create());

Beautiful, isn’t it? Just one bug maybe since there is a white space before OptionBuilder.

Beside those two, Helios also bring further supports for formatting annotations and various bug fixes. You can check the whole list by clicking this link.

Related posts:

  1. My Eclipse Code Formatter
  2. Performance benchmark for logging
  3. Be extremely careful when you initialize a non-final field in the declaration!

Java Formatter Improvement on Eclipse Helios originally appeared on satukubik on May 3, 2010.

Written by Nanda Firdausi

May 3rd, 2010 at 10:05 pm

Little Java Generic Quiz

without comments

Let say I have following code:

interface TestGeneric {

   public Integer test(List<Integer> a);
   public Boolean test(List<Boolean> a);

}

Can you guess what are the answers for following questions?

  • TestGeneric will be reported as error by Java 6 (true/false)
  • TestGeneric will be reported as error by Java 7 (true/false)
  • TestGeneric will be reported as error by Eclipse 3.5 using Java 6 (true/false)
  • TestGeneric will be reported as error by Eclipse 3.5 using Java 7 (true/false)
  • TestGeneric will be reported as error by (upcoming) Eclipse 3.6 using Java 6 (true/false)
  • TestGeneric will be reported as error by (upcoming) Eclipse 3.6 using Java 7 (true/false)

What’s your guess?

The correct answer is (highlight to see the answer): false, true, false, (can Eclipse 3.5 run Java 7?)?, true, true.

The fact that statement 1 is false is related to this bug entry: http://bugs.sun.com/view_bug.do?bug_id=6182950

Eclipse (as 3.6M2) offered a more consistent behavior by considering all cases as compile error as discussed here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=289247

And this op4j used exactly this feature and will not be compiled under Java 7 or using Eclipse 3.6.

Related posts:

  1. Java Tips: Using generic correctly
  2. Be extremely careful when you initialize a non-final field in the declaration!
  3. Java Tips: Memory Optimization for String

Little Java Generic Quiz originally appeared on satukubik on April 16, 2010.

Written by Nanda Firdausi

April 16th, 2010 at 7:54 pm

Job @ Oracle

without comments

So, James Gosling just left Oracle. That’s old story. And since the place has to be occupied…

Right where James informed us about his decision. Quick and smart move!

From @ankur_sharma

Related posts:

  1. Back to WordPress…

Job @ Oracle originally appeared on satukubik on April 16, 2010.

Written by Nanda Firdausi

April 16th, 2010 at 4:59 pm

Posted in funny,java,joke,oracle,sun

op4j: Bending the Java spoon

without comments

The tagline of op4j is very interesting: ‘Bending the Java spoon’, which implies that the library offer magic to Java programming. And indeed it does.

The basic idea of the library is to use Fluent Interface to a much greater use. To do this, the developer basically try to provide as much general functions as possible. It says that the current version of op4j has already more than 1000 functions.

If you read some examples from the website and from the blog, you can find several absolutely genuine idea how programming with Java can be enjoyable. One example:

Calendar date = Op.onListFor(1492, 10, 12).exec(FnCalendar.fieldIntegerListToCalendar()).get();

which if done without op4j will be something like:

Calendar date = Calendar.getInstance();
date.clear();
date.set(Calendar.DAY_OF_MONTH, 12);
date.set(Calendar.MONTH, Calendar.OCTOBER);
date.set(Calendar.YEAR, 1492);

Although on this particular case I can see some people will say that the first code is unclear because there the order of the integer can somehow confusing the reader, the fact that it saves a lot of program code is absolutely beautiful.

I love the fact that lately there are many Java libraries with a goal to make programming much enjoyable.

Related posts:

  1. Little Java Generic Quiz
  2. Java Tips: Initializing Collection
  3. Java Tips: Using generic correctly

op4j: Bending the Java spoon originally appeared on satukubik on April 16, 2010.

Written by Nanda Firdausi

April 16th, 2010 at 4:36 pm