Introduction I’ve built a small example of running a standalone Java application that both serves static HTML, JavaScript, CSS content, and also publishes a REST web service. The example uses Jersey and Jetty. This example probably deserves a few posts to allow enough time to explain how the pieces fit together, so I’ll start with the primary Java pieces that make a JAX-RS application. A couple years back, while I was working through some slides to teach a Java class (mostly Java EE and Spring) I created a REST web service using Spring WebMVC.

Introduction I had an interesting conversation today about the cost of using string concatenation in log statements. In particular, debug log statements often need to print out parameters or the current value of variables, so they need to build the log message dynamically. So you wind up with something like this: logger.debug("Parameters: " + param1 + "; " + param2); The issue arises when debug logging is turned off. Inside the logger.

I taught an introductory Java session on generics, and of course demonstrated the shorthand introduced in Java SE 7 for instantiating an instance of a generic type: // Java SE 6 List<Integer> l = new ArrayList<Integer>(); // Java SE 7 List<Integer> l = new ArrayList<>(); This inference is very friendly, especially when we get into more complex collections: // This Map<String,List<String>> m = new HashMap<String,List<String>>(); // Becomes Map<String,List<String>> m = new HashMap<>(); Not only the key and value type of the map, but the type of object stored in the collection used for the value type can be inferred.

Introduction Last year I wrote a series of posts (Part 1, Part 2, Part 3) on the use of the new Java fork/join framework for a Monte Carlo simulation. First, an update. Going back through the code I discovered a bug in the way the triangle distribution was implemented. Fortunately this is a toy example, as it made the results inaccurate. My fault for not unit testing. I would still not suggest using this code for anything other than learning about fork/join.

Introduction I had an interesting conversation the other day about custom domain-specific languages and we happened to talk about a feature of Spring that I’ve used before but doesn’t seem to be widely known: the static application context. This post illustrates a basic example I wrote that introduces the static application context and shows how it might be useful. It’s also an interesting topic as it shows some of the well-architected internals of the Spring framework.

Introduction In a previous post I discussed the fork/join framework introduced with Java SE 7 and how it can be used to perform simple parallelism of certain types of tasks; that is, those that operate within a single JVM and involve a large piece of work that can be broken up into smaller pieces through a divide and conquer strategy. To illustrate this, I introduced an example of using fork/join to perform a Monte Carlo simulation of the Net Present Value of an investment with uncertain profits and discount rate.

This post continues a series discussing the new fork/join features added to Java SE 7. Part 1 and part 2 introduced an example application that performs a Monte Carlo simulation of the Net Present Value of an investment with uncertain profits and discount rate. The example application is available on GitHub. The previous post glossed over an important question: what is the “right” way to divide up the work? Of course, the answer is dependent on the type of work being performed and the machine on which it is run.

Introduction This is the first of a series of posts that will discuss an example application that uses the Java Fork/Join framework to do a Monte Carlo simulation of the Net Present Value of a prospective investment. This first post discusses the purpose of the example application as well as the purpose of the fork/join framework and the kinds of problems it can best solve. Fork/Join and Divide and Conquer The fork/join framework introduced with Java SE 7 is based on a specific model of parallel programming, similar to what is implemented in languages such as Intel’s Cilk Plus.

Even though reflection is used widely in popular libraries such as Spring and Jackson, direct use of reflection is thankfully pretty rare, as it can be challenging to make robust. One issue with reflection is that it can work in ways that break typical assumptions about Java. For example, looking up a method using reflection works very differently from the way Java finds and calls a method in normal code.

This is part 4 of a series discussing a sample webapp that uses Spring WebMVC and Jetty to add a REST API to a standalone Java application. Part 1, Part 2, and Part 3 were posted previously. This post discusses using Spring WebMVC for the client side, and also discusses some integration options for adding WebMVC to an existing application. WebMVC Client Of course, one of the largest motivations for a REST API is the ability to use it from any language, especially JavaScript in a browser.

This post is part 3 of a series that started here and continued here. There will be at least one more post in this series, to discuss Spring WebMVC as a client. All of the code is available as a project on GitHub. As I discussed previously, the Spring WebMVC example I provided is a complete web application, with the three files web.xml, rest-servlet.xml, and the controller class. But one of the reasons I wanted to put together this example is to show the class I was teaching the possibility of embedding this into an existing Java program.

Last time I introduced an example application I wrote to illustrate Spring WebMVC for a Java class. I think the application is a nice example because it also illustrates the ability to add a REST API to an existing standalone Java application using Jetty as an embedded servlet container. I’m presenting this example in a series of posts because I learned from personal experience teaching this that the more “under the covers” behavior there is, be it classpath scanning, annotation configuration, reflection, or proxying, the harder it can be for new folks to grasp.

While giving a series of presentations on using Java in a distributed environment (focusing on Java EE and Spring), I got a lot of interest in web programming. I did an extra presentation on servlets, but I didn’t want to leave it there, because writing Java servlets directly is not very efficient compared to tools like Spring WebMVC. So I made an extra presentation on WebMVC, which led me to make a sample application that provides both a client and a server using Spring WebMVC.

This is part 1 of 3. Also see part2 and part3. There are a lot of tutorials out there about providing REST web services in a servlet container by building and deploying a WAR. There are also cases where someone is looking to put a REST interface on an existing Java application. In that case it isn’t always possible to turn the application into a WAR or EAR and adding a servlet container as a separate process just adds a layer of complexity.

Apache Digester is a venerable library for parsing XML and turning it into a graph of Java objects. There are a lot of libraries out there for parsing and writing XML, and Digester isn’t the most performant at runtime, doesn’t support writing XML back out again, and can seem a little inaccessible to new users. But I like it very much, and it’s a very powerful tool in my toolbox.

I’m in the midst of teaching an Introduction to Java class. Like most courses of this type, when I introduce the standard JVM collections I intend to provide guidance on which type of collection to use when. I wanted to show the real-world effects of making the correct or incorrect decision, so I put together an example. I used the excellent Caliper library to create a class that benchmarks pulling data from existing collections.