(Photo: Singur suflet pustiu by dani81_const)
This article, Expression Language Overview” href=”http://www.informit.com/articles/article.aspx?p=30946″>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?
Recently I have been having problems with Eclipse running out of memory.
Previously I had as my command line argument for Eclipse.
eclipse.exe -vmargs --Xmx512m
The double dashes were a problem, preventing Eclipse to properly load the correct memory settings from eclipse.ini.
I then removed the -vmargs –Xmx512m from the command line argument and instead modified eclipse.ini which is in the top level of the Eclipse installation. This blog article, Eclipse and memory settings, explains how you should put each argument on a separate line and that you can go to Help > About Eclipse Platform and then click on the Configuration Details button to check that Eclipse is running with the correct settings.
I changed this:
-Xms40m -Xmx512m
to:
-Xms120m -Xmx1024m
but I reverted back when I realized it was my original command line argument that was the problem.
I tried to use these settings as recommended in this forum, [news.eclipse.tools.jdt] Re: How to prevent out of memory errors?
-Xms120m -Xmx1024m -XX:PermSize=256M -XX:MaxPermSize=512M
But for some reason that kept crashing the Eclipse startup.
Maven profiles are a pretty neat concept for organizing different settings for different builds.
Typically one sets them up in your settings.xml. Projects will also have profiles in profiles.xml whose values you can override with your values in settings.xml.
A few observations I made about profiles.
Often I find myself wondering what version of Adobe Flash or Shockwave I am running. Here are some useful pages for doing that.
One day I might try to figure what is the difference between Flash and Shockwave, when I actually care.
In one of our JSP files we included a droplet like this:
<dspel:droplet name="/betweengo/droplet/foo">
However the actual properties file is named Foo.properties. On Windows this was not an issue because Windows file system is case insensitive but when we moved to UNIX we saw this exception:
javax.servlet.jsp.JspException: CANT_FIND_DROPLET: Unable to find the droplet with name "/betweengo/droplet/foo"
This is not surprising since UNIX’s file system is case sensitive. Once we corrected the capitalization ATG was able to locate the droplet.
(Photo: dolphin’s dance by kalandrakas
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. 🙂
URLHammer is a simple tool from ATG for doing load and performance testing.
Here is an example of using it.
E:\>cd ATG\ATG2006.3\DAS\lib E:\ATG\ATG2006.3\DAS\lib>set CLASSPATH=classes.jar E:\ATG\ATG2006.3\DAS\lib>java atg.core.net.URLHammer http://localhost:8080/test.jhtml 10 100 -cookies Time = 110068 ms (9.09 requests/s; average latency = 1101 ms) 0 errors out of 1000 requests
ATG’s looping droplet have the nice ability of sorting nested properties. For example say you have a repository item Person and it has a property address which is a repository item Address and you want to sort on the address’s street. Then you can do something like this.
<dspel :param name="sortProperties" value="+address.street"/>
ATG does this through the magic of DynamicBeans.
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.