betweenGo

Sometimes the resultant HTML from JSP files has too much white space.  This is because a lot of JSP logic will end up in only a few lines of actual HTML code and the rest is white space.

One efficient way to get rid of white space is to add this configuration to your web.xml on Tomcat/JBoss as described in this article, Trim Spaces in your JSP’s HTML.

    <init-param>
        <param-name>trimSpaces</param-name>
        <param-value>true</param-value>
    </init-param>

However this sometimes has undesired side-effects. For example this DSP:

<div class="foo">
  <dspel:valueof param="displayName" />
</div>

causes this undesired result:

<div class="foo"/>
  Frank Kim

The work around is to do this.

<dspel:getvalueof  var="displayName" param="displayName" />
<div  class="foo"><c:out  value="${displayName}"/></div>

The above problem might have been happening because we are running with a version of ATG that is for Servlet 2.3 but we are running with a version of JBoss that runs with Servlet 2.4.

There is another tip on removing white space in this JSP FAQ: Why I am getting extra whitespace in the output of my JSP?  In our code we had one file which included a bunch of tag libraries.  It originally looked like this.

<%/** Taglibs.jsp: include to pull in all taglibs */%>

<%@ taglib uri="/dspELTaglib" prefix="dspel" %>
<%@ taglib uri="/jstlCoreTaglib" prefix="c" %>
<%@ taglib uri="/struts-bean" prefix="bean" %>
<%@ taglib uri="/struts-tiles" prefix="tiles" %

When we changed it to this we saved about 5% in terms of page size in bytes.

<%@ taglib uri="/dspELTaglib" prefix="dspel"
%><%@ taglib uri="/jstlCoreTaglib" prefix="c"
%><%@ taglib uri="/struts-bean" prefix="bean"
%><%@ taglib uri="/struts-tiles" prefix="tiles" %>

You can use this tip with a DSP page and maintain indentation.

<dspel:page
  ><dspel:droplet name="/betweengo/droplet/Foo"
    ><dspel:oparam name="output"
      >Name: <dspel:valueof param="name"
    /></dspel:oparam
  ></dspel:droplet
></dspel:page>

In DSP to display formatted HTML text you use the valueishtml converter attribute.  For example:

<dspel:valueof param="displayName" valueishtml="true"/>

In JSTL to do this you tell JSTL not to escape the XML.  For example:

<c:out value="${displayName}" escapeXml="false" />

Running Java scripts in Cygwin bash scripts becomes a little tricky because you want to treat most paths in Cygwin as normal UNIX paths but Java expects DOS paths.  Therefore to get around this you can use the mixed option for cygpath.

For example:

if [ -e /usr/bin/cygpath ] || [ -e /bin/cygpath ]
then
  export FOO=`cygpath --mixed "e:\work\betweengo/target/foo"`
else
  export FOO="e:\work\betweengo/target/foo"
fi

The result on Cygwin is that FOO will be set to “e:/work/betweengo/target/foo” which will work both in DOS and UNIX.

Recently we noticed while running some ATG unit tests that tables were being created by the ATG repository if they had not already been created by our SQL scripts.  This was a functionality that I was unaware of but apparently it is not unique, Hibernate does this too.  I could not find any documentation about this nor could I determine how to turn it off.

The ATG repository creates these tables using the repository definition and the defaults for column width and data type.  It does not seem to warn that it is creating these tables.

This article, InformIT: The JSTL Expression Language > Expression Language Overview, informed me on how to test if something is empty or not.

Empty?

<c:if test=${empty foo}>...</c:if>

Not empty?

<c:if test=${not empty foo}>...</c:if>

Because interfaces are static, public and don’t change, by definition any members you declare in them are static, public and final. Therefore you don’t need to qualify such members.

For example:

public interface A {
  String FOO = "foo";
}

is the same as:

public interface A {
  public final static String FOO = "foo";
}

You can read some more about this in the forum Interface member variable by default static?

This article, Covariant Return Types, from java.sun.com and reprinted in a nicer format by Java Tips, explains well what covariant return types are.

You cannot have two methods in the same class with signatures that only differ by return type. Until the J2SE 5.0 release, it was also true that a class could not override the return type of the methods it inherits from a superclass. In this tip you will learn about a new feature in J2SE 5.0 that allows covariant return types. What this means is that a method in a subclass may return an object whose type is a subclass of the type returned by the method with the same signature in the superclass. This feature removes the need for excessive type checking and casting.

An example is:

public class Shape {
  private Shape shape;
  public Shape getShape() { return shape; }
}

public class Circle extends Shape {
  private Circle circle;
  @Override
  public Circle getShape() { return circle; }
}

Not the best example but a succinct one.

I never liked seeing people put constants in an interface and then implementing that interface in a class so that they can have direct access to those constants. That always seemed wrong to me and now this Sun article, Static Import, verifies my intuition.

In order to get around this, people sometimes put static members into an interface and inherit from that interface. This is a bad idea. In fact, it’s such a bad idea that there’s a name for it: the Constant Interface Antipattern (see Effective Java Item 17). The problem is that a class’s use of the static members of another class is a mere implementation detail. When a class implements an interface, it becomes part of the class’s public API. Implementation details should not leak into public APIs.

The suggested method is to use a static import.

import static java.lang.Math.PI;

However the article suggests using this sparingly.

Only use it when you’d otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes. If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from. Importing all of the static members from a class can be particularly harmful to readability; if you need only one or two members, import them individually. Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.

You can also do static import of methods.

import static com.betweengo.util.CollectionUtils.isEmpty;

However I would never do this, I like knowing where my static methods come from.

I found on this forum how to redirect to another page in JSP. One of the respondents explained it perfectly.

Well you have two options. Either you’ll do a server side forward or a client side redirect.
Server side forward has no interaction with the browser and therefore the URL on the location bar won’t change.
But if you do the HTTP redirect, the browser is instructed to load the other page and the contents of the location will change.
It’s your call which one to choose.

forward:

<% if (s1.equals(s2) ) { %>

     <jsp:forward page="s2.jsp"/>

<% } %>

redirect:

<% if (s1.equals(s2) ) {

    response.sendRedirect("s2.jsp");

} %>

I always forget how to do these things so I thought I should write it down.

Changing Dates:

Here is an example of getting the date for seven days ago from now.

    Calendar sevenDaysAgo = Calendar.getInstance();
    sevenDaysAgo.add(Calendar.DATE, -7);
    sevenDaysAgo.set(Calendar.HOUR_OF_DAY, 0);
    sevenDaysAgo.set(Calendar.MINUTE, 0);
    sevenDaysAgo.set(Calendar.SECOND, 0);
    sevenDaysAgo.set(Calendar.MILLISECOND, 0);

Formatting Dates:

Here is the simple way to format a date and time.

    DateFormat.getDateTimeInstance().format(sevenDaysAgo.getTime()))

The output is:

    May 21, 2008 12:00:00 AM