1. Let FOP auto-detect the fonts
2. Create a font metrics file and tell FOP where to find it

Auto-detection is a pretty nice feature since FOP does the job to find and interpret the font.  The major drawback of this solution is that FOP scans different places for fonts (the default font folders of the OS,  every folder in “.” and it looks for special entries in MANIFEST.MF). This is done every time you create a new Fop instance. You can guess how that might effect an application if it’s creating lots of PDF files.

To improve the performance you can create font metrics files an tell FOP where to find them. Compared to auto-detection this is a cheap operation. But there’s also a drawback: URIs to the files have to absolute paths. Especially if you’re using different environments  (Development, Testing, Pre-Production etc.) absolute paths are hard to find.

Wouldn’t it be nice if you can put your font files in a JAR and FOP just finds it? FOP can’t do it by default but you can teach FOP how to. First you have to implement an URIResolver:

import java.io.InputStream;
import javax.xml.transform.Source;
import javax.xml.transform.TransformerException;
import javax.xml.transform.URIResolver;
import javax.xml.transform.stream.StreamSource;

public class ClasspathUriResolver implements URIResolver
{

  public Source resolve(String href, String base) throws TransformerException
  {
    Source source = null;
    InputStream inputStream = ClassLoader.getSystemResourceAsStream(href);
    if (inputStream != null)
    {
      source = new StreamSource(inputStream);
    }
    return source;
  }
}

The next step is to register this URIResolver as a custom URIResolver. You can access the default URIResolver via the FopFactory:

FopFactory fopFactory = FopFactory.newInstance();
FOURIResolver uriResolver = (FOURIResolver) fopFactory.getURIResolver();

uriResolver.setCustomURIResolver(new ClasspathUriResolver());

FOP now tries to find the font and metrics file with its built in feature and if no files are found the ClasspathUriResolver is called. If still no font can be found an PDFConformanceException is thrown.

The final step is to put your files somewhere in the classpath (best choice would be a JAR file). If you're putting them in a JAR file in the folder fonts the appropriate FOP config would look like:

<renderers>
 <renderer mime="application/pdf">
   <fonts>
     <!-- Arial  -->
     <font
       metrics-url="\fonts\arial.xml"
       kerning="yes"
       embed-url="\fonts\arial.ttf">
       <font-triplet name="Arial" style="normal" weight="normal" />
       <font-triplet name="ArialMT" style="normal" weight="normal" />
     </font>
   </fonts>
 </renderer>

FOP now finds the font and can embed it. Since the file is loaded into the Classloader ever subsequent lookup is very fast. If you don't want to open an InputStream every time and you don't have many fonts you can cache the contents in a byte[] and put an ByteArrayInputStream in the StreamSource.

For comparison: When I use auto-detection creating a new Fop instance takes about 300 ms. Using predefined metrics files the instance is created < 20 ms.

// Sample.java
String buffer = "";
for (String string : listOfStrings)
{
  buffer += string;
}

// Sample.class
String buffer = "";
for (String string : listOfString)
{
  buffer = new StringBuilder(buffer).append(string).toString();
}

Every time the String concatenation is invoked a new StringBuilder instance is created and but never assigned. Hence it is immediately eligible for Garbace Collection. What a waste of Memory. If you really need to concat Strings in a loop you better do it directly with a StringBuilder.

• Based on Java 1.5 and hence using Generics
• More standard compliant (Commons Collections occasionally break standard behavior)

Go to their website and make sure to read the FAQ.

For days ago, Reinhold published a straw-man proposal of how closures (or more formal: lambda expressions) could look like in Java. I’m still not sure whether I’m happy about closures in Java or not. On the one hand it definitely helps to reduce the number of lines of code since it drops redundant information (e.g. the decleration of a Runnable).

Thread th = new Thread(new Runnable() {
                         public void run() {
                            doSomeStuff();
                            doMoreStuff();
                         }
                       });

Thread th = new Thread(#(){ doSomeStuff(); doMoreStuff(); } )

On the other hand it increases the complexity of the JVM itself and makes maintenance a bit harder. This will affect only few developers but it’s another stop to the grave of Java (death by non-maintainability).

I think time will tell how Closures will affect the Java world and if it’s a good idea to include it or not.

This gets even more important if your code is not used exclusivly by you but provided as a 3rd party lib. Dozens of programs might be broken after an updte just because a constant has been changed.

So I thought about it it came to my mind: Just connect to the LDAP server with the credentials provided and look if everything is fine:

public boolean authenticate(final String username, final String passwd) {
  final Hashtable<String, String> env = new Hashtable<String, String>();
  env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
  env.put(Context.PROVIDER_URL, "ldap://myldap:383");
  env.put(Context.SECURITY_PRINCIPAL, "CN=" + username + ",CN=Users,DC=Test");
  env.put(Context.SECURITY_CREDENTIALS, passwd);
  try {
    new InitialLdapContext(env, null).close();
  } catch (AuthenticationException ae) {
    return false;
  } catch (NamingException ne) {
    throw new RuntimeException(ne);
  }
  return true;
}

Et voila, user can be authenticated without much effort.

The next possible solution would be the validator attribute of a JSF component. While this is appropriate for small forms it creates a lot of overhead in big forms (assume you have 10 input fields which follow different constraints). Also it leaves a “Do Repeat Yourself” taste in the delevoper’s mouth. Okay, so what’s the one and only solution.

As always I don’t think there is any but one that comes pretty close: JSR-303 aka Bean Validation. Emerged from Hibernate Validation this JSR aims to simplify bean validation. The JSR is currently in its final proposal stage hence the final release 1.0.0 should be near.

Instead of writing you own code you annotate your beans and tell the Validator what to look for. @NotNull e.g. tells the Validator that the value must not be null. The Rest of the validation is very very very easy:

final ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
final Validator addressValidator = factory.getValidator();
final Set> violations = addressValidator.validate(beanToValidate);

And with this set of violations you can display whatever error messages you want.

You can download it from the Sourceforge page of Hibernate Validator which also contains a very good “Getting started” guide which was (co-)written by Gunnar Morling. At his blog you can find two good introductions, too (Part1 and Part2). For further information just follow the blog of Gavin King et. al.

Or if you use Maven you can download it from JBoss’ Maven repository:

Hibernate Validator
Bean Validation API