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.

The answer a professor got from one of his students was so “deep” he had to pass it to his colleages via internet:

Bonus-question:

“Is hell “exotherm” (gives off heat), or “endotherm”(absorbs heat)?

Most students assumed with the help of Boyles law that gas cools down while expanding. One student however came up with this answer:

“First we need to find out how the mass of hell changes over time.
To be able to do this we need to first find out how many souls venture into hell and out of it.

It is my opinion, that souls , once they’ve entered into hell, won’t leave it again.

That’s why no soul ever leaves hell again.

Concerning the question how many souls go to hell, the opinions of the religions existing today, can give us an answer.

Most religions assert that you go to hell when you’re not one of them.
Since there is more than one religion and because you can’t belong to more than one of them you can assume further that all souls go to hell.

Wíth birth- and deathrates of today we can further assume that the amount of souls will exponentially increase.

Let’s now take a look at the size of hell.
According to Boyles law the size of hell must increase proportional to the arriving souls or else we have two options:

1.: In case hell expands slower than the number of souls arriving, both temperature and pressure inside of hell will increase so much that the whole hell falls apart.

2. In case the hell expands faster then the amount of new guests then temperature and pressure will fall causing the hell to freeze up.

Now which is it?

When we take into consideration Sandra’s statement to me in our first year here, that it will be a cold day in hell before she’d go to bed with me as well as the fact that I slept with her last night only number 2 can be valid.

That’s why I’m convinced that hell is endotherm and must be already frozen up.

My conclusion is, that hell can not accept any further souls and is therefore extinct….and so only heaven is still existing. This however, proves the existance of God, which explains why Sandra screamed: °Oh, my God!!!° the whole last evening.”

This student was the only one who got an “A”.

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

• MySQL will be sold to a competitor or
• Oralce guarantees (by signing some paper) that all previous version of MySQL will still be freely available and additionly will be released as free years for the next three years.

I’m not giving anyone an advice whether to sign the petition or not but everyone should take a look at the campaign and decide on which side he or she stands. More information about the topic and a little Q &A can be found at Monty’s blog.

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.

JavaEE6 marks a major milestone in enterprise Java with the arrival of subspecs such as CDI, JPA2, EJB 3.1 (with EJB Lite) or Servlet 3.0. But the most important part for me is the new web profile which was really overdue.JavaEE5 left web developers somewhere between all or nothing. POSCs (Plain Old Servlet Containers) proveded not all of the JEE stack that might be needed while full blown application servers like JBoss were too heavy (although JBoss did a< good job with the different profiles).

Integrating different Frameworks into POSCs can be really a pain in the ass. Take JPA for example. JPA in a POSC is nothing more than a JavaSE usage of the JPA. Which means there are no manged transactions no container managed persistence contexts etc. Everything had to be custom made which is not the desired way.

With the new web profile you only get what you really need: Servlets, JPA2, JTA, CDI, EJB Lite which makes web development a lot easier. But not only the developer benefits but also the vendors since they don’t have to implement the full stack.

Hopefully vendors will jump on the JEE6 train and there will be a vibrant market of implementations.

In a web application always put the stuff (which is not packaged a single JARs)  in /WEB-INF/classes/META-INF (e.g. persistence.xml or service files) and not in /META-INF. Otherwise the various applications will not be able to locate them.