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

With this way of injection it is possible to really inject everything. POJOs, DB resoures like ResultSets even primitives can be injected.

The following two code listings show how to produce and how to consume. I’m going to explain what’s really happening here afterwards:

@Produces @Random int next() {
 return getRandom().nextInt(maxNumber);
}

@Inject @Random
private int number;

Okay, as promised here are some explanations:

@Produces tells Weld that something that might get injected somewhere is being produced here. What is specified by the next annotation. Although @Random might look like a built-in annotation it is not. I named it Random to point out that the int is generated (pseudo) randomly. This is a socalled qualifier annotation which tells the dependency injection framework where to look for the producer.

@Target( { TYPE, METHOD, PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
@Qualifier
public @interface Random
{
}

The only new thing is the @Qualifier annotation which is contained in the javax.inject package and defines qualifier annotations. As you can see in the samples above it is really possible to inject everything. There thousands of scenarios in which this might be useful. Just imagine a producer which generates a unique ID fo every instance.

Event / Observer concept

So far I just talked about the DI features of JSR-299. Althought the official name of this JRS-299 might say otherwise Weld is not limited to dependecy injection. One thing I really love is the event “bus” which basically an implementation of the observer pattern with lots of tuning and simplification.

The greatest simplification ist that there is no need to explicitly register an observer and the observable knows nothing about its observers. If you look a the “standard” observer pattern used in Swing you’ll find a method JButton.addActionListener(ActionListener l). It’s clear what’s happening here: an ActionListener is explicitly registered at one button. That means that the Button knows its listeners and the listener knows exactly to what component he or she is listening to.

The following annotation defines an observable (Standard Java: implements Observable):

@Qualifier
@Target( { PARAMETER })
@Retention(RUNTIME)
public @interface Event {
 String source();
}

The next part might seem a litte strange since it implements an annotation but later it will be clear why this is done.

package de.publicstaticfinal.web.jsf;
import javax.enterprise.inject.AnnotationLiteral;
public abstract class EventImpl extends AnnotationLiteral<Event> implements Event
{
}

Next we declare the concrete event we’re listening to. This is just a simple POJO. IF you look at the Java API this Event is equivalent to the second argument of Observer.update(Oberservable o, Object argument). For better clarification I name it HelloWeldEvent.

package de.publicstaticfinal.web.jsf;
public class HelloWeldEvent
{
 private String source;

 public HelloWeldEvent(String source)
 {
 this.source = source;
 }

 public String getSource()
 {
 return source;
 }
}

A simple event which contains the name of its source. What’s left is the event listener itself but that’s not that many code:

public void handleEvent(@Observes @Any HelloWeldEvent hwe)
{
 System.out.println(hwe.getSource());
}

@Observes is the annotations which tells Weld that this method listens to ALL (@Any) HelloWeldEvent which are raised in this application. This might be useful in some circumstances (imagine a logging facility which gets called every time a button is clicked) but on other occasions this is to bloated. Therefore I added the “method” source() to the Event annotation. With that it is possible to just listen to a special HelloWeldEvent.

public void handleEvent(@Observes @Event("button1") HelloWeldEvent hwe)
{
 System.out.println(hwe.getSource());
}

This observer method just gets called when the raised event’s source is “button1″. So far so good but how do you raise an event? The famous BeanManager provides a method for doing this: public void fireEvent(Object event, Annotation… bindings).

The first argument is the event itself. It is of type Object since there is no special interface an event has to implement which means that every Object could be an event. The next arguments are the anootation bindings which are used to resolve the listeners. In this tutorial’s case this would be Event. And now it might be clear why we need an implementation if Event. I used @Event(“button1″) to specify on which concrete event the listener should be called. Weld needs a mechanism to read this information and to decide whether the method should be called or not.

Written in Java it looks like this:

private void fireEvent(){
 beanManager.fireEvent(new HelloWeldEvent("Test"), new EventImpl(){
 public String source()
 {
 return "button1";
 }});
 }

When calling fireEvent a concrete implementation of Event is provided and Weld can use the source() method to retrieve the source. After an check whith equals to the value of @Event(…) Weld knows what methods to call. Be aware that we talk about synchronous events here. JSR-299 does not define asynchronous events.

This was the last part of my tutorial series. As I stated before JSR-299 is way to extensive to be completely covered by a tutorial. I just wanted to give people who are interested in working with it a litte help to get started. I hope that I achieved this goal a little bit and the ones who read the article are goind to use Weld (or other implementations) since it will boost your application.

Having said that lets go to…

Obtaining the BeanManager

In your web.xml/context.xml you declared a managed resource called BeanManager which is main interface to all Bean related stuff (adding/removing beans from a context etc.). There are two ways for obtaining the Bean Manager. The first way is to use dependey injection with the @Resource annotation:

@Resource(mappedName="java:/comp/env/BeanManager")
BeanManager beanManager;

Here you let the container do all the work. Or you cann ask Weld to inject the BeanManager by using @Inject:

@Inject
BeanManager beanManager;

Simple Dependency Injection

In the previous section I made a little trip to the future by using the @Inject annotation. As you might have already guessed this annotation tells Weld that the field/parameter should be injected. This is the simplest dependency injection available. You just tell Weld that you need something injected and Weld takes care of it. A good example for this would be a Cache which is typically application scoped (although every scoped bean can be injected):

package de.publicstaticfinal.web.jsf;

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Named;

@Named
@ApplicationScoped
public class Cache {...}

As you learned already this managed bean can be accessed via EL using #{cache}. But most often you’re not only using the Cache in the frontend but in the business logic too. The extenden HelloWeld bean would look like this:

package de.publicstaticfinal.web.jsf;

import java.io.Serializable;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;

@Named("helloWeld")
@SessionScoped
public class HelloWeld implements Serializable {
  private String message = "Hello Weld";

  @Inject
  private transient Cache cache;

  public String getMessage() {
    return message;
  }
}

The injected Cache object has to be marked as transient since HelloWeld is serializable while the Cache is not. If the cache field is not marked as transient Weld will throw an Exception since it enforces serializability. This is really a good feature in Weld since it leads to consistent data.

Another good point is that you can use loose coupling without much effort. If the Cache class above would be “CacheImpl” and implementing a Cache interface you don’t have to change your code that much. The Cache implementation class would look like this:

package de.publicstaticfinal.web.jsf;

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Named;

@Named("cache")
@ApplicationScoped
public class CacheImpl implements Cache
{

}

And the CacheImpl would be injected like this:

@Inject @Named("cache")
private transient Cache cache;

What if you need mor than one Caches? I’m too lazy at the moment to think of a scenario where you might need this but of course this is possible. Although with the restriction that this cannot be achieved directly by dependency injection. If you asked yourself why I explained how to obtain the BeanManager here’s the answer: the BeanManager helps you to create new instances of an injectable resource. The following mehtod gets called with getNewCache(“cache”):

private Cache getNewCache(String elName) {
  Set<Bean<?>> beans = beanManager.getBeans(elName);
  for (Bean<?> bean : beans) {
    Set<Type> beanTypes = bean.getTypes();
    for (Type type : beanTypes) {
      if (type.equals(Cache.class)) {
        Bean<Cache> tmp = (Bean<Cache>) bean;
        Cache newCache = tmp.create(beanManager.createCreationalContext(tmp));
        return newCache;
      }
    }
 }
 return null;
}

• 2: In this line all beans which can be accessed by #{cache} are retrieved
• 4: all types of the bean are read
• 6: Check if the bean is of type Cache
• 7: cast to the proper type
• 8: retrieval of the proxy object by api calls

I’m not going into detail of every single API call. If you’re interested in more information please refer to the Javadoc (link: http://docs.jboss.org/cdi/api/1.0-CR1/).

I think that’s enough for the second part of my tutorial. This part just covered injection of scoped beans. While this is a pretty powerful tool JSR-299 doesn’t limit injection to scoped beans. Generally speaking you can blow inject your foot away using Weld.