This took me a few hours to figure out so I’m logging this here for my own sanity. If you have a bidirectional many-to-many mapping in Hibernate with a join table, the join table is only updated when the noninverse side of the mapping is inserted/updated. In the example below, the join table (pane_specs) is only updated when a spec is saved, not when a pane is saved:

Spec.java

@ManyToMany
@JoinTable(
name = “pane_specs”,
joinColumns = { @JoinColumn(name = “spec_id”) },
inverseJoinColumns = { @JoinColumn(name = “pane_id”) }
)
public List<Pane> getPanes() {

Pane.java

@ManyToMany(mappedBy = “panes”)
public List<Spec> getSpecs() {

A coworker and I were tasked with rewriting an internal application to manage our company’s workflow. We both have a background in Perl and not much Java, making us the perfect candidates to prototype potential frameworks. The following is what we came up with based on our (few) requirements:

• MVC framework
• view layer must allow us to write html and css
• must be flexible enough to extend to other upcoming projects

The final decision ended up being struts2, mainly due to it’s flexibility. Other frameworks seemed like they would allow us to develop more quickly, but we would have been stuck with them (custom tags, combined view/controller layers, etc). With struts and hibernate for the model layer, it seemed like we could quickly move to something else easily.

Servlets/JSP/JSTL

• Pros:
  1. Not a lot of re-learning, everything can be done pretty much the same way as in CGI.
  2. We have (read: Roger has) JSP and JSTL books
• Cons:
  1. Requires a couple little helper classes for working with Hibernate
  2. JSTL isn’t especially graceful
  3. Doesn’t look good on a job description or resume

Tapestry

(I tested 4.1, the current GA release. 5.0 is in beta testing, and probably will be released before long. There are already books out for 5, but not really any online tutorials.)

• Home page: http://tapestry.apache.org/
• Lots of tutorials: http://tapestry.apache.org/tapestry4.1/tutorials/index.html
• Hibernate+Tapestry: http://www.hibernate.org/96.html
• Pros:
  1. Allows you to write HTML with only a couple of additional non-standard attributes
  2. Very well documented and tutorial-ed.
  3. One “page specification” XML file (*.page) per page, instead of a single huge XML config file
  4. Coding is extremely simple, most of the complexity is in the page files.
• Cons:
  1. Lots of different components (for page specification files) using a kind of non-standard language
  2. Notorious for changing API between major releases (i.e. 5.0).

Wicket

• Home page: http://wicket.apache.org/
• A dated tutorial: http://cwiki.apache.org/WICKET/newuserguide.html
• Databinder, a Wicket+Hibernate linking library: http://databinder.net/site/show/overview
• Pros:
  1. An Apache project, implying longevity or better integration going forward
  2. Lots of people think it represents the future of Java frameworks
  3. AJAX and jQuery integration built-in
• Cons:
  1. Uses a very unique design pattern, a huge rethink from standard CGI or servlet coding.
  2. Tutorials and other information is a bit dated, making it hard to learn, especially with the unique design pattern. (This is even more true for Databinder)
  3. Lots of the HTML can/should/must be generated by code, instead of by hand.

Struts

• Home page: http://struts.apache.org/
• Tutorial: http://struts.apache.org/2.x/docs/hello-world.html
• Pros:
  1. Fairly minimal. Struts does some things for you, but keeps the general Servlet/JSP structure more or less unchanged
  2. Integration with Hibernate is as simple as with Servlets/JSP
  3. Virtually ubiquitous
  4. eCommerce suite uses Struts, so we will have to know it anyhow
• Cons:
  1. Eats babies
  2. Tastes like dirt

JSF (Java Server Faces)

• Home page: http://java.sun.com/javaee/javaserverfaces/
• Tutorial: http://www.coreservlets.com/JSF-Tutorial/
• Pros:
  1. lightweight, flexible
  2. lots of available libraries
  3. large community
• Cons:
  1. heavy xml markup
  2. mixed jsp and html tags
  3. confusing, lots of files to manage for each page

GWT (Google Web Toolkit)

• Home Page: http://code.google.com/webtoolkit/
• Tutorials: http://blogs.pathf.com/agileajax/2007/07/36-gwt-tutorial.html (36 of them)
• Pros:
  1. Tons of documentation
  2. Lots of 3rd libraries
  3. Eclipse support
  4. Handles browser differences
  5. Active Development
  6. Large Community
  7. Code in java, compiles to javascript
  8. Managed by Google
  9. HTML/CSS support
• Cons:
  1. Built for AJAX (does handle permalinks/multiple pages)
  2. Limited set of java libraries on client side

Echo

• Home page: http://echo.nextapp.com/site/
• Tutorial: http://echo.nextapp.com/site/echo2/doc/tutorial
• Pros:
  1. Lacks extensive XML markup
  2. Straightforward, not a ton of rampup
• Cons:
  1. All UI components are AWT like (no html/css)
  2. IDE support is commercial
  3. Built for single page apps only

These are some notes I scribbled down during Sun’s “Java Programming” class. Having programmed in Perl the last 7 years, this is what I wrote down as “noteworthy.”

• Everything in Java is an object except primitive types
• All objects are references in memory
• A ‘foreach’ loop in java looks like this:

for (Car y: x) {

y.speed = 100;

}

• Inherited objects always call the super classes constructor. The default is super() with no arguments. This can be overridden by placing a super(int i) as the FIRST EXECUTABLE STATEMENT in a subclass constructor.
• All objects inherit from the base class ‘Object’.
• obj instanceof class will return true or false based on whether obj is indeed an object of type class.
• defining the toString method for object obj allows you to define what is printed when System.out.println(obj) is called.
• The static keyword declares members that are associated with the class and not the class objects
• The final keyword ensures a member can not be changed. This means that methods and classes that use final can not be overridden or extended.
• The abstract keyword:
  • forces child classes to define a method.
  • classes with an abstract method must also be abstract.
  • abstract classes can not be instantiated directly (only via subclasses)
• An interface is a class with only abstract methods
• The implements class keyword is used for interfaces to enforce the rules of the interface. Unlike extends, implements can be used on more than one interface.
• For handling exceptions, you can use try and catch blocks, or declare your method with a ‘throws‘ clause that sends the exception back to whatever called that method.