As I discussed in a series of four posts (see Part 1, Part 2, Part 3, and Part 4), I recently taught a class on Spring WebMVC and how it can be used to REST-enable a standalone Java application. As part of that discussion, I talked about using Jetty as an embedded servlet container, which let us create and access servlets without having to package our existing application as a WAR.

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.