Category Archives: Java

Closures for Java open a new door for logging: Logosure

1 Reply

For a long time we Java programmers have relied on conditional blocks to guard against unneeded string concatenations and other expensive computations that occur when we want to create complex log messages. In other words, we want those concatenations to occur only when the logger will actually log them.

While SL4J’s use of vararg parameters eliminates a huge chunk of these conditional blocks, there still are (possibly rare) cases that creating a log message involves more than just string concatenations and as such it is still necessary to guard the block of logging logic inside a conditional block.

Thanks to Java closures this is not true anymore. In what follows I present a basic implementation of a prototype proof-of-concept logger called Logosure that relies on BGGA closures and skips execution of chunks of logging logic when their corresponding levels are turned off.

The Logger

Our logger is very simple. It only contains two different logging levels: INFO and WARNING. For the sake of simplicity, the levels do not have parent-child relationship. In other words, if the logger’s level is set to INFO, it only emits INFO level logging messages and when it’s set to WARNING it only emits WARNING level log messages.

Again, for the sake of simplicity, our logger only prints to the standard output.

And Level is an enum:

The only interesting part of this logger class is the first log method: it receives a function type as its second parameter that returns a String object. It invokes the logging block passed to it only if the current logging level is equal to the level passed in as the argument. Using this Logger is very simple:

In the example above the code inside the third logging block won’t be executed at all. This happens all without littering our source code with conditional blocks.

As Java closures are still work in progress and the syntax is still a matter of debate it is too soon to implement a full-fledged closure based logger, but I believe that once Java closures become finalized we will see logging frameworks adopt closures in similar ways.

You can fork the current version of Logosure from Github.

Java and XSLT: A bug story

2 Replies

A few days ago I was busy removing our project’s dependency on Apache Xalan and Xerces (we wanted to use Java’s built-in implementation of XML and XSL APIs). In some of our XSL files, we use Xalan-Java Extensions to call Java methods from the stylesheet file. After removing the Xalan and Xerces JAR files from the class-path and deleting all the references to Xalan specific namespaces and tags from the stylesheet files, all stylesheet parsing and compilation errors disappeared, but the output generated by Java’s built-in version of XSL [cci lang="java"]TransformerFactory[/cci] was different to what used to be generated by Xalan.

After some investigation it turned out that some calls to Java code from the XSLT files are being ignored by the transformer. Debugging the code and stepping through all the method calls down to XSLTC and other internal classes did not uncover the reason for the mysterious skipping of these Java calls.

Suddenly something came to my attention: in some of the XSLT files, we are not interested in the value returned by the Java call; we only call a method to modify the state of the Java class. To do so, we declare a variable in the form of:

To call [cci lang="java"]aUtilityMethod()[/cci] and then never use [cci lang="XML"]$ununsedVariable[/cci] anywhere in the XSLT file again. I decided to use one of these variables in the XSLT file to see if that forces the XSL transformer to call the method, so I added a harmless comment right after the variable declaration in the form of:

Voila! Now the transformer is calling [cci lang="java"]aUtilityMethod()[/cci]. It turned out that Java’s default built-in version of [cci lang="Java"]TransformerFactory[/cci] is either skipping running the select expression for unused variables or is doing it lazily. Considering that XPath expressions are side-effect free and that they only return a set of nodes, it makes sense to implement suchlike optimizations, but the optimizer should check the select expression and omit the optimization if it is a Java call.

But is it a bug? Well, yes and no. The truth is that it’s not working correctly. But on the other hand, as this feature is an undocumented and internal feature of the default XSLT implementation of the JDK, it is an unsupported feature and it is better to avoid its use.

Decomposition, coupling and cohesion, and volatility

Leave a reply

Decomposition by “coupling and cohesion” and “volatility” are two architectural decomposition methods that are unlikely to be used together in the same project. However it’s possible to first decompose by CoC and identify the parts of the system that should be kept together, and then use decomposition by volatility to isolate the parts that are likely to change in the future. This means that we might need to reduce the cohesion of the system to some extent, but it should make changing or replacing the volatile parts of the system less of a hassle.

One more reason to like IntelliJ IDEA

Leave a reply

So in my last post I complained about Eclipse developers’ unwillingness for fixing long standing bugs. Now less than a year ago, I suggested to JetBrains to add a feature to IDEA that can come in handy when you want to quickly setup a project:

Defining Libraries as Maven Coordinates

This enables developers to quickly define libraries as Maven coordinates even in projects that do not use Maven and then IDEA can download the appropriate JAR files for the project from Maven repos.

This can be done either by asking the developer to enter the dependencies in a text field like:

And also by providing a text field for entering additional repositories:

[or] Alternatively, a short form syntax might be used for declaring the coordinates:

Also there should be selectable options for downloading source and JavaDocs for the libraries from Maven as well.

And yes my friends! IDEA gurus do pay attention to their users’ requests. This feature has now been added to IntelliJ IDEA X, the next version of the IDE:

Getting External Libraries Easily

JARs of many frameworks and their dependencies get updated too often now. But you do not want to turn your project into a Maven project just because of this? Then this feature is just for you.

In IntelliJ IDEA 10 you can search for & download libraries with dependencies for any framework published on some public maven repository. Minimum Maven experience is required. Just click ‘Attach Classes from Repository…‘

Now let’s see when they will add my other feature request to IDEA: @SuppressWarnings like feature for HTML elements.

To be fair, the NetBeans team has also fixed all the bugs that I’ve reported to them very quickly. But, Eclipse… no matter how great you are and how great your architecture is, your WTP is sooo buggy and years after Maven’s debut, you still don’t have a rock solid Maven plugin. Shame on you mate!

Three tools for testing email sending using SMTP

1 Reply

Email1: smtp4dev: Windows 7/Vista/XP/2003/2010 compatible dummy SMTP server. Sits in the system tray and does not deliver the received messages. The received messages can be quickly viewed, saved and the source/structure inspected. Useful for testing/debugging software that generates email. I have been using this for quite some time now and it is working seamlessly.

2: MockSMTP.app: MockSMTP is a native Mac application that embeds its own SMTP server. It also features an e-mail client browser, enabling instant viewing of both raw content and HTML rendering, so you can see how your mail looks when delivered. A nice product overall but is buggy.

3: Dumbster: The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The best option among the three for unit testing Java applications.

JCP Specs should be published in ePub format too

Leave a reply

With the ever increasing popularity of electronic book readers such as Amazon’s Kindle and Apple’s iPad, JCP should now publish all the Java specs in ePub format too. Unlike their PDF counterparts, ePub readers can render text with the user’s choice of font family and size. They also use the available display real-estate more efficiently.

In the near future ePub will be at least as important as PDF when it comes to electronic documents and books.

Simply send an email to the JCP PMO and let them know that you’d like the JCP specs to be published as ePub documents too.

Fixing “Content Assist” for implicit objects of JSP pages in Eclipse

2 Replies

While Eclipse recognizes implicit objects in JSP pages, it fails to show the content assist popup for them. This can be fixed by adding the appropriate JSP/Servlet JAR files of your application to your project. If your target application server is Tomcat 6.0.x, for example, you can create a User Library and add the following Tomcat JAR files to it:

  • annotations-api.jar
  • el-api.jar
  • jasper-el.jar
  • jsp-api.jar
  • servlet-api.jar

And then add this User Library to your project. Now Content Assist should work for implicit objects as well. Alternatively, if your target application server is JBoss and you have JBoss Tools installed, you can select the J2EE 5.0 libraries from the Add Library… window to enable content assist for your Web app.