Object-relational mapping (in the JPA compliant sense) is so ubiquitous nowadays in the Java development scene, that we rarely question ourselves if we really need it, and if not using it may be a better option.
In my experience, some systems benefit from using JPA technology (most systems actually), but some do not, in fact I think some systems become unnecessarily complicated and bigger because of it.
Going further with the topic, it’s worth to know the new fork/join framework introduced in Java 7. The pros and cons of this framework over the usage of thread pools or regular thread/runnable development has been subject of a lot of debate, but I think it is still a nice tool to have in your arsenal.
I’ll use a more classic approach to show you the basic structure of the fork/join framework and code a version of the Quicksort algorithm using it.
Picking up from where I left off in my last post about the java.util.concurrent package, it’s interesting and sometimes mandatory to get feedback from concurrent tasks after they are started.
For example imagine an application that has to send email batches, besides from using a multi-threaded mechanism, you want to know how many of the intended emails were successfully dispatched, and during the actual sending process, the real-time progress of the whole batch.
Sometimes you just don’t want or need the complexity of a fancy distributed transaction manager or complicated RPCs to coordinate a concurrent job amongst a farm of servers.
Here is a very simple and efficient way to achieve a lock/release type of concurrency control in a farm-like architecture using nothing but a few SQL sentences and your relational database.
Version 5 of the Java platform introduced a high level concurrency API, located in the java.util.concurrent package.
It allows for a much elegant and intuitive multi-threaded programming. I know this is old news for some, but I have found that most programmers still rely on the Thread class and Runnable interface to solve most concurrent problems in Java, when almost all of them can be implemented in a much cleaner way using the new API.
In this post series I’ll provide several examples on the usage of java.util.concurrent classes to solve common challenges. Let’s start with a simple parallel solution for data processing.
You have probably heard about convention over configuration, specially if you follow Ruby on Rails, the Play Framework or similar projects.
Taken from Wikipedia:
Convention over configuration (also known as coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.
What I propose is that you not only praise the advantages this paradigm brings to you as a developer, but that you apply the same principles to the software you create and then empower the users and support staff that will use it.
My company designs and develop mobile and web based banking solutions. Our customers (banks for the most part) are highly bureaucratized, orthodox (ie. like to have everything pre-defined and pre-approved) and risk adverse, and therefore change and the disruption of the status quo is not a normal sight within most of them.
Most banking IT departments are used to the good old waterfall development cycle (believe it or not). Additionally, when they purchase a tailor made system (or a highly customizable product based deployment) they prefer to know in advance exactly what the system will do, how will it do it and how long will it take to deploy it (even if they don’t know what they want themselves).
I believe this happens a lot in provider/customer relationships, and not only in the finantial sector.
But during real life software development projects at banks, as it happens on almost all software projects:
So an agile methodology seems to be in order, right? But how to couple both worlds…
Jul/4/2012: Updated the wrapper code to pre-compile the patterns (making them static) to improve performance by avoiding their re-compilation on each run.
Here is a good and simple anti cross-site scripting (XSS) filter written for Java web applications. What it basically does is remove all suspicious strings from request parameters before returning them to the application. It’s an improvement over my previous post on the topic.
You should configure it as the first filter in your chain (web.xml) and it’s generally a good idea to let it catch every request made to your site.
I bet that when you are about to start coding a new software piece, specially if it’s for a corporate customer, you don’t even question yourself whether to generate an activity log or not, it’s a mandatory commodity nowadays.
What’s not so obvious is that there are at least two major uses for an activity trail in almost all systems:
In my experience most developer generated log information is oriented towards solving the first issue (analyzing errors). And even if you include context information in the log about the user, his actions and consequences; your typical log has several disadvantages towards solving the second problem.
I recently had the need to list all the classes available within a given list of packages, to execute them via reflection as part of a plugin architecture in a new product we are developing.
This proved to be a little more hard than it should, since Javas provided reflection utilities don’t have any metadata regarding the contents of a package available in your classpath.