Browser Standards: HTML5 Test - Best Results

Since the number of the available browser is constantly growing, it becomes every day more important to adhere to international standards. Until the last year, every developer was interested about how much a browser supported the XHTML 1.0 or 1.1 specifications and the CSS 1.0 or 2.0 specifications.

Nowadays things have changed a little bit. We are entering a new dynamic era of internet browsing. Browsers will be even more capable of serving and displaying media contents. Doing what? Correctly implementing the HTML 5 standard and the CSS 3.0 specifications.


To help developers in the understanding and/or evaluation of the behavior of a browser, Niels Leenheer has written the HTML5Test web page. This page uses a little bit of Javascript to trick your browser with common HTML 5 implementation test cases, and collects all data in a really clean report. I suggest you to try that page now with your current browser, just to get an idea.

This test gives each browser a score, based on how many HTML 5 elements or features can handle correctly. The max score a browser can reach is 300, plus some additional bonus points for not-strictly-necessary features.

I gathered some results for the main web browsers, in the chart you can see below. I tried to use the more recent version for each browser. Just to get an appetizer of what will be next, I also tried a beta/alpha/nightly version of each of them.
Continue reading

Loggable: a simple log4j meta-library - Part 2

In a recent post I described the goal of my Loggable meta-library. If you haven't read it yet, I suggest you to do it now.

What we are going to do now is analysing the second main component of the meta-library, the centralized controller Log.

How does it work

The main responsibility of the Log class is handling the logic behind the creation and returning of the Logger instance that the caller class should use. This logic, as we've already seen, is driven by the @Loggable annotation.

The Log class will have a single point of access: the public static method get(). Let's look at if, briefly:

	public static Logger get() {
		// Retrieve the StacKTraceElement of the caller method
		StackTraceElement caller = getCaller();
		// Retrieve the caller class
		Class<?> clazz = getClass(caller);
		// and its Loggable annotation instance
		Loggable annotation = getAnnotation(clazz);

		logger.debug("Returning a Logger for " + clazz.getSimpleName());

		// Retrieve the suitable logger for the caller class and returns it
		Logger suitableLogger = getLogger(annotation, clazz);
		return suitableLogger;

This method does a precise series of things:

  1. Retrieves the stack trace element related to the caller method
  2. Retrieves the Class<?> instance which describes the caller class
  3. Reads the @Loggable annotation from the caller class
  4. Returns the suitable Logger instance, depending on the class and its @Loggable annotation definition

The whole code for this class will be available within the meta-library package, so I'll focus just on the main private method: getLogger().

Bonus hint: as you can see, in my development environment the Log class makes a direct access to a Logger instance. This is strictly necessary because of recursions problems: if the Log class would call itself for logging purposes, this will generate a never-ending recursion stack. Try it, and try to explain why: this will be your homework for today 🙂 .
Continue reading

Loggable: a simple log4j meta-library - Part 1

If you work in a J2EE environment, you surely have (or at least will have) used the standard Apache log4j library almost once. This powerful and configurable logging library is commonly used throughout whole enterprise projects, for many reasons: debugging, testing, exception logging, tracing, application profiling, et cetera.

A common code that shows how to use a org.apache.log4j.Logger instance is the following:

package com.marzapower.test;

import org.apache.log4j.Logger;

public class MyClass {
	private static final Logger logger = Logger.getLogger(MyClass.class);

	public static void main(String... args) {
		logger.debug("Hello World!");

As you can see, you define a private (visible only to the instances of this specific class) static (shared amongst all instances of the class) final (constant, not variable) Logger instance, and then you use it within the class. If you had another class, you should define a similar object into that class too. If you had a third, again, you'd define a Logger in that class too. And so on.

But when the number of the classes in your project grows, this approach easily becomes very frustrating. You are writing your code, and want to use a Logger, but you cannot do it directly unless you define the Logger instance for your classes. Again, if you are refactoring an existing class, that heavily uses the Logger instance for debugging purposes, and you delete all the Logger.debug() calls then ... the classic yellow exclamation mark flag appears in your Eclipse editor: the private Logger instance defined is not being used anymore, so its declaration should be removed. And so on, you probably have faced a different (but still similar) problem before.

Continue reading