Since this blog was new, the content has been syndicated at DZone through their Most Valuable Blogger (MVB) program. Most of the people who have read what I’ve written have read it there, so it’s been advantageous to me, especially when I was starting as a new blogger. Recently I was invited to join their Zone Leader program. As a result, I am joining a number of others posting original content at DZone and helping to syndicate the work of MVBs.

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’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.

This post is an excerpt from my new book, Conversational Git. The entire book is available on-line and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think. I recently had some close friends talk about their hesitation in adopting Git as opposed to continuing to work with Subversion. I’ve used Subversion for many years, and advocated for its use.

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.

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.

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.

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.

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 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 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.

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.

This post is an excerpt from my new book, Conversational Git. The entire book is available on-line and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think. I recently had some close friends talk about their hesitation in adopting Git as opposed to continuing to work with Subversion. I’ve used Subversion for many years, and advocated for its use.

Previous posts such as this one have shown using embedded Jetty to REST-enable a standalone Java program. Those posts were lacking an important feature for real applications: packaging into a JAR so the application will run outside of Eclipse and won’t be dependent on Maven and jetty:run. To make this happen, we will use Maven to build an executable JAR that also includes all of the Jetty and Spring dependencies we need.

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.

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’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’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.

Previous posts such as this one have shown using embedded Jetty to REST-enable a standalone Java program. Those posts were lacking an important feature for real applications: packaging into a JAR so the application will run outside of Eclipse and won’t be dependent on Maven and jetty:run. To make this happen, we will use Maven to build an executable JAR that also includes all of the Jetty and Spring dependencies we need.

Introduction I’ve talked before about Jetty as an embedded servlet container. Jetty also includes some useful utility servlet implementations, one of which is ProxyServlet. ProxyServlet is a way to create an HTTP or HTTP/S proxy in very few lines of code. Even though it’s part of the Jetty project, it’s modularized to be independent of the Jetty server, so you can use it even in cases where the servlet won’t be run in Jetty.

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.

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.

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 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.

Introduction I’ve talked before about Jetty as an embedded servlet container. Jetty also includes some useful utility servlet implementations, one of which is ProxyServlet. ProxyServlet is a way to create an HTTP or HTTP/S proxy in very few lines of code. Even though it’s part of the Jetty project, it’s modularized to be independent of the Jetty server, so you can use it even in cases where the servlet won’t be run in Jetty.

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.

Previous posts such as this one have shown using embedded Jetty to REST-enable a standalone Java program. Those posts were lacking an important feature for real applications: packaging into a JAR so the application will run outside of Eclipse and won’t be dependent on Maven and jetty:run. To make this happen, we will use Maven to build an executable JAR that also includes all of the Jetty and Spring dependencies we need.

Since this blog was new, the content has been syndicated at DZone through their Most Valuable Blogger (MVB) program. Most of the people who have read what I’ve written have read it there, so it’s been advantageous to me, especially when I was starting as a new blogger. Recently I was invited to join their Zone Leader program. As a result, I am joining a number of others posting original content at DZone and helping to syndicate the work of MVBs.

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.

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.

Previous posts such as this one have shown using embedded Jetty to REST-enable a standalone Java program. Those posts were lacking an important feature for real applications: packaging into a JAR so the application will run outside of Eclipse and won’t be dependent on Maven and jetty:run. To make this happen, we will use Maven to build an executable JAR that also includes all of the Jetty and Spring dependencies we need.

Introduction I’ve talked before about Jetty as an embedded servlet container. Jetty also includes some useful utility servlet implementations, one of which is ProxyServlet. ProxyServlet is a way to create an HTTP or HTTP/S proxy in very few lines of code. Even though it’s part of the Jetty project, it’s modularized to be independent of the Jetty server, so you can use it even in cases where the servlet won’t be run in Jetty.

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.

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.

Introduction I’ve talked before about Jetty as an embedded servlet container. Jetty also includes some useful utility servlet implementations, one of which is ProxyServlet. ProxyServlet is a way to create an HTTP or HTTP/S proxy in very few lines of code. Even though it’s part of the Jetty project, it’s modularized to be independent of the Jetty server, so you can use it even in cases where the servlet won’t be run in Jetty.

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.

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.

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.

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 One of the nice recent features of Spring (2.x era) is support for custom XML. This is the way that Spring itself has added all kinds of new tags such as <util:list> and <mvc:annotation-driven>. The way this works is pretty elegant, to the point that it makes an interesting alternative for configuring Java using XML, particularly if the application already uses Spring. I’ve written an example application to try to give an easily-copied example of how it’s done.

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.

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.

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.

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.

Introduction One of the nice recent features of Spring (2.x era) is support for custom XML. This is the way that Spring itself has added all kinds of new tags such as <util:list> and <mvc:annotation-driven>. The way this works is pretty elegant, to the point that it makes an interesting alternative for configuring Java using XML, particularly if the application already uses Spring. I’ve written an example application to try to give an easily-copied example of how it’s done.

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.