Blog blog("Baptiste Wicht"); (Posts about Java)

Detect overflows and more in Java with COJAC

Baptiste Wicht — Fri, 27 Nov 2015 13:18:52 GMT

Back at school, I worked on the COJAC project to detect numeric overflow in Java programs automatically. Since then, this project has evolved a lot and has now more features:

It can detect integer overflows

Detect smearing and cancellation with float and double types

Detect NaN and Infinite results from computations

Detect offending type casting

Moreover, all these features are available without any recompilation of your program. You simply add an argument to the invocation of the Java virtual machine and all these errors will be detected for you automatically!

Frédéric Bapst, the person in charge of the project has recently published two videos about the project, don't hesitate to check them out:

The first video presents the automatic analysis features of the tool:

And the second presents the numeric wrapper features of the tool for even more features:

If you have any question related to the project, you can add a comment to this page or contact me directly be email.

If you want more information on the project you can also check out its repository on Github: https://github.com/Cojac/Cojac

Some news

Baptiste Wicht — Tue, 04 Jun 2013 21:52:24 GMT

No, I'm not dead ;)

After having finished my Master thesis in March, I took a break from my personal projects including this project. I then started a job in my school, waiting for a Ph.D thesis. I'm now working on a very interesting Machine Learning project about Speech, unfortunately in Java ;)

I just started again working on eddic this week. I'm gonna try to improve as much as possible the performances of the parser. I will also try to post again some articles on this blog, although I don't know about what.

Jelastic Java Host - Recommended by James Gosling !

Baptiste Wicht — Tue, 28 Aug 2012 08:35:19 GMT

I recently came across an interesting tool. Jelastic is a Platform as a Service (PaaS) provider for Java. Basically, it's a cloud for Java applications.

The most interesting point about Jelastic (in my opinion) is the fact that it can run any Java application. There are no API to use or special change that have to be made: you can take any Java app that you have and run it on Jelastic. Jelastic runs Glassfish, Tomcat and Jetty application servers. It's up to the developer to choose the application server. Because it's only made for Java, you have directly access to the application server where you can deploy to, you don't have access to the machine itself.

Another great advantage of Jelastic is that it automatically scales vertically. At the beginning, you application is only allowed a very small amount of CPU and memory and when the system detects that it needs more, it automatically gives more resources to the application. And when the application has too much resources, there are released. That has the advantage that you don't need to worry about the resources of your application and that the costs are to the minimum when the application doesn't need a lot of resources. Of course, you can also put limits on the scalability. An application can also be run in several different application servers (horizontal scaling). It supports automatic load balancing for the different instances.

A Jelastic environment provides also access to a database server of your choice (MySQL, MariaDB, PostgreSQL, MongoDB, CouchDB). It also has several other good features. You can look at the official list if you want a complete list of features.

The official Jelastic site provides several very good guides about how to deploy a specific type of application to Jelastic. For example, there are guides for Play! Framework, Clojure or Alfresco.

The interesting point about Jelastic is that it has been recommended by James Gosling itself (the father of Java):

I really like Jelastic. It’s actually software package that a number of ISPs are using. It’s a Java hosting system and so you don’t get a bare Linux machine. What you get is a JavaEE container, and you can drop WAR files on them and they have this really nice control panel where you get a slider that says how many clones of Glassfish do you want and check boxes for [databases]. You don’t have to go into Linux – Oh my God, what it takes to install anything: it’s like which version of Linux is compatible with which app server and what time… they actually take care of that and it works lovely. I actually built these clusters and they can span multiple ISPs, multiple countries, multiple datacenters, and that’s how I deal with my personal extreme paranoia of the survivability of these things.

James is working in a small startup, Liquid Robotics that handles a set of automatic robots in the ocean.

I think that all these information are making of Jelastic a very good choice for a Java host !

More information

Source : James Gosling (Father of Java) Loves Jelastic
Official Site : http://www.jelastic.com

Algorithms books Reviews

Baptiste Wicht — Fri, 24 Aug 2012 06:52:04 GMT

To be sure to be well prepared for an interview, I decided to read several Algorithms book. I also chosen books in order to have information about data structures. I chose these books to read:

Data Structures & Algorithm Analysis in C++, Third Edition, by Clifford A. Shaffer
Algorithms in a Nutshell, by George T. Heineman, Gary Pollice and Stanley Selkow
Algorithms, Fourth Edition, by Robert Sedgewick and Kevin Wayne
Introduction to Algorithms, by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein. I have to say that I have only read most of it, not completely, because some chapters were not interesting for me at the current time, but I will certainly read them later.

As some of my comments are about the presentation of the books, it has to be noted that I have read the three first books on my Kindle.

In this post, you will find my point of view about all these books.

Data Structures & Algorithm Analysis in C++

This book is really great. It contains a lot of data structures and algorithms. Each of them is very clearly presented. It is not hard to understand the data structures and the algorithms.

Each data structure is first presented as an ADT (Abstract Data Structure) and then several possible implementations are presented. Each implementation is precisely defined and analyzed to find its sweet pots and worst cases. Other implementations are also presented with enough references to know where to start with them.

I have found that some other books about algorithms are writing too much stuff for a single thing. This is not the case with this book. Indeed, each interesting thing is clearly and succinctly explained.

About the presentation, the code is well presented and the content of the book is very well written. A good think would have been to add a summary of the most important facts about each algorithm and data structure. If you want to know these facts, you have to read several pages (but the facts are always here).

The book contains very good explanation about the complexity analysis of algorihtms. It also contains a very interesting chapter about limits to computation where it treats P, NP, NP-Complete and NP-Hard complexity classes.

This book contains a large number of exercises and projects that can be used to improve even more your algorithmic skills. Moreover, there are very good references at the end of each chapters if you want more documentation about a specific subject.

I had some difficulty reading it on my Kindle. Indeed, it's impossible to switch chapters directly with the Kindle button. If you want quick access to the next chapter, you have to use the table of contents.

Algorithms in a Nutshell

This book is much shorter than the previous one. Even if it could be a good book for beginners, I didn't liked this book a lot. The explanations are a bit messy sometimes and it could contain more data structures (even if I know that this is not the subject of the book). The analysis of the different algorithms are a bit short too. Even if it looks normal for a book that short, it has to be known that this book has no exercise.

However, this book has also several good points. Each algorithm is very well presented in a single panel. The complexity of each algorithm is directly given alongside its code. It helps finding quickly an algorithm and its main properties.

Another thing that I found good is that the author included empiric benchmarks as well as complexity analysis. The chapters about Path Finding in AI and computational geometry were very interesting, especially because it is not widely dealt with in other books.

It also has very good references for each chapter.

This book was perfect to read with Kindle, the navigation was very easy.

Algorithms

This book is a good book, but suffers from several drawbacks regarding to other books. First, the book covers a lot of data structures and algorithms. Then, it also has very good explanations about complexity classes. It also has a lot of exercises. I also liked a lot the chapter about string algorithms that was lacking in previous books.

Most of the time, the explanations are good, but sometimes, I found them quite hard to understand. Moreover, some parts of code are also hard to follow. The author included Java runs of some of programs. In my opinion, this is quite useless, empiric benchmarks could have been useful, but not single runs of the program. Some of the diagrams were also hard to read, but that's perhaps a consequence of the Kindle.

A think that disappointed me a bit is that the author doesn't use big Oh notation. Even, if we have enough information to easily get the Big Oh equivalent, I don't understand why a book about algorithms doesn't use this notation.

Just like the first book, there is no simple view of a given algorithm that contains all the information about an algorithm. Another think that disturbed me is that the author takes time to describe an API around the algorithms and data structures and about the Java API. Again, in my opinion only, it takes a too large portion of the book.

Again, this book was perfect to read with Kindle, the navigation was very easy.

Introduction to Algorithms

This book is the most complete I read about algorithms and data structures by a large factor. It has very complete explanations about complexity analysis: big Oh, Big Theta, Small O. For each data structure and algorithm, the complexity analysis is very detailed and very well explained. The pieces of code are written in a very good pseudo code manner.

As I said before, the complexity analysis are very complete and sometimes very complex. This can be either an advantage or a disadvantage, depending of what you awaits from the book. For example, the analysis is made using several notations Big Oh, Big Theta or even small Oh. Sometimes, it is a bit hard to follow, but it provides very good basis for complexity analysis in general.

The book was also the one with the best explanations about linear time sorting algorithms. In the other books, I found difficult to understand sorts like counting sort or bucket sort, but in this book, the explanations are very clear. It also includes multithreaded algorithm analysis, number theoretic algorithms, polynomials and a very complete chapter about linear programming.

The book contains a huge number of exercises for each chapters and sub chapters.

This book will not only help you find the best suited algorithm for a given problem, it will also help you understand how to write your own algorithm for a problem or how to analyze deeply an existing solution.

Algorithms Book Wrap-up

As I read all these Algorithms books in order, it's possible that my review is a bit subjective regarding to comparisons to other books.

If you plan to work in C++ and need more knowledge in algorithms and C++, I advice you to read Data Structures & Algorithm Analysis in C++, that is really awesome. If you want a very deep knowledge about algorithm analysis and algorithms in general and have good mathematical basis, you should really take a deep look at Introduction to Algorithms. If you want short introduction about algorithms and don't care about the implementation language, you can read Algorithms in a Nutshell. Algorithms is like a master key, it will gives you good starting knowledge about algorithm analysis and a broad range of algorithms and data structures.

Architexa is available for free - Understand your code base

Baptiste Wicht — Wed, 22 Aug 2012 03:00:37 GMT

Architexa is a tool suite that helps a team to document collaboratively a large Java code base. The tool is made for a whole team to understand a code base. The tool is available as an Eclipse plugin.

When several developers are working on a large application, it is not always simple to have a whole view of the application. Even with some documentation of the application code. It is even harder for a new developer that joins the project to know what the code base is about. In all these cases, Architexa will help your team. It can also be useful when you inherit an application.

Starting from today, Architexa is available for free for individuals and for teams of up to three developers. You can read the official announce at the end of the article.

My Review of Architexa

I tried Architexa on several of my current Java Projects, but never in team. So perhaps my point of view is not very accurate regarding to general users of the tool. I made my tests using Eclipse Juno.

However, even when working alone on a project, I think that this tool is very useful.

The installation is very straightforward, you just have to use the update site directly in Eclipse. Then, you have several new options in the EDI to use Architexa features.

Three diagrams are available in the Architexa tool suite:

Class Diagram : This diagram can be automatically generated for a package, or several packages.
Sequence Diagram : You can create Sequence Diagrams for some of your program actions.
Layered Diagram : This diagram allows you to represent the architecture of your application. The system allows you to represent several levels of details.

You can easily have several diagrams of each type in your project. You can store them as local files, in a server or in the community server to make them available for everyone.

You can add comment in each diagram. In each diagram you can also access the Javadoc of each class. Of course, you can also access any piece of code from your diagrams.

Advantages

Architexa is very simple to use. The tool have access to very good guides directly inside the IDE.
The Real-Time Code analysis is awesome. Once something is in a diagram, it is always kept up to date.
The sharing features are also great.
Even if there are fews diagrams, I think that there are largely enough to have a very good understanding of a code base.
All the graphs looks very nice, there are very readable

Drawbacks

No support for generics and enums.
The tool is only available as an Eclipse plugin. I'm especially using IntelliJ Idea and NetBeans.
The tool is only available for Java. There is a prototype for C/C++ that is available on demand, but I didn't tried it at the current time.
Sometimes, the creation of a very simple diagram takes a bit long time for my feeling. Creating a diagram with three elements can take several seconds. Perhaps, it is better with larger diagrams. I haven't had the occasion to test it with large code .

Conclusion

To conclude, Architexa is a great tool suite. It is useful for any Java developers that works in a large application. It allows them to have better understanding of its code base.

The official announce: Architexa Tool suite is Now Available for Free

More information on the official site: http://www.architexa.com/

COJAC, A Numerical Problem Sniffer

Baptiste Wicht — Tue, 28 Feb 2012 12:24:28 GMT

During my bachelor at the HES-SO University of applied sciences in Fribourg, I worked on a Java project, COJAC.

COJAC is a tool performing On-the-fly code instrumentation to help uncover numerical problems with integer (overflows) and floating point (smearing, cancellation, infinity, NaN) arithmetic.

Yesterday, Dr Dobbs published an article by one of my professor Frédéric Bapst and myself.

This article discusses the question of numerical problems in programming, and focuses on the approach of using on-the-fly code instrumentation to uncover them at runtime. Two realizations are presented: a complete and stable solution for Java applications, and a proof-of-concept Valgrind add-on for Linux executables. Both tools require no intervention on the source code and no recompilation, and should be helpful as a diagnostic tool for developers, as well as for education purposes for undergraduate programmers.

If you are interested by this project, I invite you to read the article on Dr Dobbs : Project of the Month: Cojac, A Numerical Problem Sniffer

You can also test the tool or browse the source code by downloading it on the COJAC website.

Compilers : Principles, Techniques & Tools - Book Review

Baptiste Wicht — Thu, 12 Jan 2012 08:27:19 GMT

Some weeks ago, I finished reading Compilers : Principles, Techniques & Tools, by Afred V. Aho, Monica S. Lam, Ravi Sethi and Jeffrey D. Ullman. This book is also called the Dragon Book due to the cover.

This book is a reference about compiler construction and design. If you are interested in this subject, this book is for you, it's a must-have. However, I have to warn you that this book is very technical and hard. Honestly, some of the chapters are beyond my comprehension. Before this book, I had no real comprehension of the subject. I will certainly read again some of the chapters when I will have more practice into the subject.

If you want, the book is full of exercises about each subject covered in the book. If you plan to do all the exercises, you'll need a lot of time as there are a lot of them and some of them are quite hard. I've done some of them but only a little part.

The first chapter introduces the construction of compilers. You will see the common structure of compilers, the evolution of programming languages and the science behind building a compiler and its applications. The second chapter is still quite general. It will teach you how to develop a simple syntax-directed translator. This chapter is very important as it will give you the basics for understanding the following chapters. You will learn how to define a grammar, what are the main parsing techniques and what is lexical analysis. It will also covers symbol tables and intermediate language generation.

With the third chapter (Lexical Analysis), we are entering the hearth of the matter. You will learn the vocabulary behind lexical analysis (tokens, lexemes, attributes, ...). Then, after you've learned how to define and recognize tokens, you will see the different techniques to build an efficient lexical analyzer. The first technique that will be covered is the use of a lexer generator (Lex). Then you will see in details how to construct a lexer using regular expressions or finite automata especially Nondeterministic Finite Automata and Deterministic Finite Automata.

The next one (Syntax Analysis) is about parsing. After learning how to define and write a grammar you will see how to parse it. You will see in details the most commons types of parsing (Top-Down, Bottom-Up) and the most common parsers (LL(K) and LR(K) parsers). The construction of these kinds of parsers is covered in details and the way to optimize them is also teached. Finally, you will see how to automatically generate a parser using Lex and Yacc. This chapter is sometimes very hard to understand (in my own opinion) but very interesting especially if you plan to build parser without generating it with some advanced tools (for example Yacc or Boost Spirit for C++).

The fourth chapter (Syntax Directed Translation) explains you how to translate some source code (parse it) into a coherent structure (an abstract tree) using a Syntax Directed Scheme. The translation is made based on a syntax using semantic actions and rules to translate the source into something else. You'll see different ways of doing that translations.

Then, the next one (Intermediate Code Generation) teaches you how to generate Intermediate Code from the source. Two different representations are covered : syntax trees and three-address-code. Another subject covered in this chapter is type checking. You'll see in details how to translate expressions, control flow instructions and switch statements into three-address-code statements.

The seventh chapter (Run-Time Environment) gives a lot of information about the different run-time targets that you can compile for. A lot of subjects are covered here: stack and heap allocation, locality exploitation, garbage collectors... This chapter is in my opinion a very good instruction to computer architecture. You cannot imagine develop a compiler without having a deep understanding of the target machine.

The next chapter (Code Generation) is also a very important one. In this chapter, you will see how to generate assembly code from the three-address-code. You will learn how to select the good instructions. A very important subject covered in this chapter is register allocation. You'll learn how to choose wisely the registers to produce efficient code. The basic blocks are also covered there with flow graphs. More than just generating code from Three-Address-Code statements, you'll also see how to optimize them. Only local (to a basic block) optimization techniques will be covered in this chapter. Several techniques that aims at testing if code is optimal are also taught there.

The global optimizations are covered in the next chapter (Machine-Independent Optimizations). You will discover several optimizations that you can do globally (inside a function but among different basic blocks). A data-flow analysis framework is explained here in details. After that, for each of the optimization, the parameters of the data flow analysis are explained. The optimization of loops is treated too.

The three next chapters (Instruction-Level Parallelism, Optimizing for Parallelism and Locality and Interprocedural Analysis) are the most complex of the book. They are covering in details the optimizations that can be made when a compiler supports instruction-level parallelism (executes several instructions in one clock cycle). It also covers interprocedural analysis of a program to allow even better optimization than global optimization inside a function. Honestly, I didn't understand some of the concepts described here. I will read them again one by one, chapter by chapter and try to implement some of the techniques in EDDI in the future.

To conclude, I will say that Compilers : Principles, Techniques & Tools is a very good book that every compiler designer and developer should read before starting constructing a compiler. Although very technical, it's quite clear and contains a huge amount of information. If you plan to develop a compiler, it is a very good idea to read this book first.

I've implement some of the techniques explained in this book in my own compiler. I implemented most of the local optimizations presented and Intermediate Code generation. You can find some information here.

Java 7 has been released!

Baptiste Wicht — Thu, 28 Jul 2011 11:46:53 GMT

Five years after Java 6, Oracle has just released Java 7!

This is the first release of Java since Oracle bought Sun Microsystems.

This new version of Java introduces a lot of new features, but some of the languages new features will be introduced in Java 8 as stated by the "Plan B".

In this version, there some great new language features, as stated by the JSR 334 :

Strings in switch
Binary integral literals and underscores in numeric literals
Multi-catch and more precise rethrow
Improved Type Inference for Generic Instance Creation (diamond)
try-with-resources statement
Simplified Varargs Method Invocation

We will also see the new NIO.2 API (specified by the JSR 203).

A new bytecode instruction has been added to the virtual machine, InvokeDynamic.

You can download Java SE 7 on the Oracle website.

I think it was time now for Java to have a new version with some refreshing, and it's IMO a good new version that we have now. I just hope that the next version, Java 8, will be here in less than five years to give us the closures.

JTheque Core 2.1.0 released !

Baptiste Wicht — Wed, 20 Oct 2010 05:12:33 GMT

It's my pleasure to announce that I've finally released JTheque Core 2.1.0 !

The different services of the core are now separated using OSGi. With this separation, I've improved a lot the design of the core and the orthogonality of the different services. Each service is now an OSGi bundle. I've also refactored the implementation of all services. Several services have been completely rewritten. The majority of the bundles are now thread-safe.

Now, to create modules for a JTheque application, you have to write an OSGi bundle representing the module. Then, you only have to use Spring to launch the module. This is done using Spring Dynamic Modules. The used OSGi container is Felix.

Now that this version of the core is finalized, I'll updates the applications. First of all, JTheque Movies with the new version of the core.

Fore more informations and to download JTheque Core, you can go on the description page. If you want to try developing a module (or see how it is done), you can consult this starter guide.

Compute command-line arguments with Apache Commons CLI

Baptiste Wicht — Thu, 14 Oct 2010 05:22:45 GMT

For a project at school, I needed to refactor an old code parsing almost 30 command line arguments. I needed to add some more arguments and change some old args, but the old code was not maintainable at all. So I decided to use a library to make the parsing. of the args.

I chose Apache Commons CLI. This is a really simple library to make that parsing. It's not perfect, but it makes the work I needed and is powerful to do that job.

With this API, you have to declare an Options instance. This class is used to describe the command line arguments of the program. Options constructor don't take any arguments.

Options options = new Options();

Swing tip : A better SwingWorker without exception swallowing

Baptiste Wicht — Fri, 24 Sep 2010 05:36:55 GMT

When we develop Swing applications, SwingWorker are very helpful. But there is a big disadvantage using this class. if you don't call get() in the done method, you will lose all the exceptions that the computation in the doInBackground() has thrown. And you action can stop and you will never see why. In 95% of my actions using SwingWorker, the doInBackground() return nothing.

Jonathan Giles has presented on his blog a good solution to solve this exception swallowing. In my side, I've often something to do in the EDT before the doInBackground() run, so I've made the changes on the code presented by Jonathan and it gave me that simple class that I found better than the SwingWorker :

public abstract class BetterSwingWorker {
    private final SwingWorker<Void, Void> worker = new SimpleSwingWorker();

    public void execute() {
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                before();
            }
        });

        worker.execute();
    }

    protected void before() {
        //Nothing by default
    }

    protected abstract void doInBackground() throws Exception;

    protected abstract void done();

    private class SimpleSwingWorker extends SwingWorker<Void, Void> {
        @Override
        protected Void doInBackground() throws Exception {
            BetterSwingWorker.this.doInBackground();

            return null;
        }

        @Override
        protected void done() {
            try {
                get();
            } catch (final InterruptedException ex) {
                throw new RuntimeException(ex);
            } catch (final ExecutionException ex) {
                throw new RuntimeException(ex.getCause());
            }

            BetterSwingWorker.this.done();
        }
    }
}

You can use it as the default SwingWorker. You must implement the doInBackground() and done() methods and you can, only if you want, override the before() method that is invoked in the EDT at the start of the process. And then, you can execute your SwingWorker using execute().

I hope this little class can be useful to somebody.

Source for the non-swallowing swingworker.

JDK 7 Features updated ! Plan B has apparently been approved

Baptiste Wicht — Mon, 20 Sep 2010 04:15:28 GMT

I was presenting the Plan B of JDK 7 the last week and apparently, this plan has been approved.

The JDK 7 Features page has been updated on the site of Oracle.

So here are the (definitive ?) list of features for JDK 7 :

JSR 292: Support for dynamically-typed languages (InvokeDynamic)
Languages update of the project Coin
Concurrency and collections updates (jsr166y)
ionet JSR 203: More new I/O APIs for the Java platform (NIO.2)
SCTP (Stream Control Transmission Protocol)
SDP (Sockets Direct Protocol)
Elliptic-curve cryptography (ECC)
client XRender pipeline for Java 2D
Create new platform APIs for 6u10 graphics features
Nimbus look-and-feel for Swing
Swing JLayer component

And we can also see that there is some new features that we doesn't have seen before:

TLS 1.2
JDBC 4.1
Unicode 6.0
Locale enhancement
Separate user locale and user-interface locale
NIO.2 filesystem provider for zip/jar archives
Use the Windows Vista IPv6 stack when available

And after all that informations, we can see the features delayed to JDK 8 :

JSR 294: Language and VM support for modular programming
JSR 308: Annotations on Java types
JSR TBD: Language support for collections [NEW]
JSR TBD: Project Lambda
Modularization (Project Jigsaw)
JSR 296: Swing application framework
Swing JDatePicker component

For more informations and the complete list of features for the two versions of JDK, you can consult the JDK 7 Features page. There will certainly be some additional informations at JavaOne this week.

JTheque Utils 1.1.5

Baptiste Wicht — Thu, 16 Sep 2010 06:01:19 GMT

It's my pleasure to announce the release of a new version of JTheque Utils, the 1.1.5.

There is a lot of changes in this version. First of all, the library is now OSGi Ready, you can use it with no problem in an OSGi application. Here are the main changes of this version :

The main classes have been made thread safe and all the classes are now documented to indicate if they are thread safe, not thread safe or immutable.
The library has now some annotations to document thread safety, thanks to Brian Goetz for the idea
SwingUtils support now headless environment
Version has a better version comparison
A new simple way to manage system properties with the SystemProperty class
CollectionUtils has a new set of methods to create collections and concurrent collections
A simple thread safe weak event listener list, WeakEventListenerList
HashCodeUtils has been improved to manage arrays
Some classes have been made Immutable
The utility class have new methods
And a lot of other little changes and bug fixes

More informations on the JTheque website. You can download it from here.

I hope that this library will be useful to someone.

Java Concurrency - Part 7 : Executors and thread pools

Baptiste Wicht — Wed, 15 Sep 2010 05:17:27 GMT

Let's start with a new post in the Java concurrency series.

This time we'll learn how to start cleanly new threads and to manage thread pools. In Java, if you have a Runnable like this :

Runnable runnable = new Runnable(){
   public void run(){
      System.out.println("Run");
   }
}

You can easily run it in a new thread :

new Thread(runnable).start();

This is very simple and clean, but what if you've several long running tasks that you want to load in parralel and then wait for the completion of all the tasks, it's a little bit harder to code and if you want to get the return value of all the tasks it becomes really difficult to keep a good code. But like for almost any problems, Java has a solution for you, the Executors. This simple class allows you to create thread pools and thread factories.

Java 7 Delays and Plan B

Baptiste Wicht — Thu, 09 Sep 2010 05:17:29 GMT

Mark Reinhold has posted a message about the planning of Java 7. In this message, he explains that the current schedule of the JDK 7 is completely unrealistic. This delay is due to the add of new projects (lambda, Coin, Jigsaw) and the acquisition of Sun by Oracle.

The current estimate by the team is that the JDK7 can be complete for a release around the middle of 2012.

But, Mark indicates a new option, the "Plan B". With this plan, the JDK7 will be available at mid 2011 without Jigsaw and Lambda and with only a portion of the Coin Project. And JDK8 will be released in late 2012 with the complete set of features scheduled actually for JDK7.

Personnally, I think it's a good idea to separate the two releases and have a first release soon. Like Mark says, it makes a very long time that we don't have had a new Java release, so it will be interesting to have a light JDK7 before 2012.

And you, what do you think ?

Source : Re-thinking JDK7, by Mark Reinhold

Java Concurrency - Part 6 : Atomic Variables

Baptiste Wicht — Wed, 08 Sep 2010 05:14:18 GMT

When a data (typically a variable) can be accessed by several threads, you must synchronize the access to the data to ensure visibility and correctness.

By example, if you have a simple counter (yes, once again) :

public class Counter {
    private int value;

    public int getValue(){
        return value;
    }

    public int getNextValue(){
        return value++;
    }

    public int getPreviousValue(){
        return value--;
    }
}

This class works really well in single-threaded environment, but don't work at all when several threads access the same Counter instance. If you don't know why, read this post about synchronization. You can solve the problem using synchronized at method level :

public class SynchronizedCounter {
    private int value;

    public synchronized int getValue(){
        return value;
    }

    public synchronized int getNextValue(){
        return value++;
    }

    public synchronized int getPreviousValue(){
        return value--;
    }
}

This class now works well. But locking is not a lightweight mechanism and have several disadvantages. When several threads try to acquire the same lock, one or more threads will be suspended and they will be resumed later. When the critical section is little, the overhead is really heavy especially when the lock is often acquired and there is a lot of contention. Another disadvantage is that the other threads waiting of the lock cannot do something else during waiting and if the thread who has the lock is delayed (due to a page fault or the end of the time quanta by example), the others threads cannot take their turn.

So how to do to avoid this disadvantages ? We must use non-blocking algorithms. This algorithms don't use blocking mechanisms and by that fact are more scalable and performing. These algorithms use low-level machine instructions which are atomic to ensure the atomicity of higher-level operations. While locking is a pessimistic approach, we can also use optimistic technique to develop algorithms. This time, we'll detect collisions between threads in which case, the operation fails and we do something else (often retrying the same operation).

The actual processors provide several instructions that simplify greatly the implementation of these non-blocking algorithms, the most-used operation today is the compare-and-swap operation (CAS). This operation takes three parameters, the memory address, the expected current value and the new value. It atomically update the value at the given memory address if the current value is the expected, otherwise it do nothing. In both cases, the operation return the value at the address after the operation execution. So when several threads try to execute the CAS operation, one thread wins and the others do nothing. So the caller can choose to retry or to do something else. We often use this operation to implement another operation, the compare-and-set. This method makes exactly the same things as CAS but return a boolean indicating if the operation succeeded or not.

Before Java 5.0, this operation was not available directly to developer, but in Java 5.0 several atomic variables (for int, long, boolean and reference values) were added. The int and long versions also supports numeric operations. The JVM compiles these classes with the better operations provided by the hardware machine, CAS or a Java implementation of the operation using a lock. Here are the classes :

AtomicInteger
AtomicLong
AtomicBoolean
AtomicReference

All these classes supports compare-and-set (via the compareAndSet() method) and other operations (get(), set() and getAndSet()). The setters operations are implemented using compareAndSet. These classes supports multi-threaded access and have a better scalability than synchronizing all the operations.

Here is how we can rewrite our counter using an AtomicInteger :

public class AtomicCounter {
    private final AtomicInteger value = new AtomicInteger(0);

    public int getValue(){
        return value.get();
    }

    public int getNextValue(){
        return value.incrementAndGet();
    }

    public int getPreviousValue(){
        return value.decrementAndGet();
    }
}

The incrementAndGet() and decrementAndGet() methods are two of the numeric operations provided by the AtomicLong and AtomicInteger classes. You also have getAndDecrement(), getAndIncrement(), getAndAdd(int i) and addAndGet().

This version is faster than the synchronized one and is also thread safe.

If you only have the compareAndSet(), here is how we can implement increment() method using it :

public void increment(AtomicInteger integer){
    while(true){
        int current = integer.get();
        int next = current + 1;

        if(integer.compareAndSet(current, next)){
            return;
        }
    }
}

This seems to be complicated, but this is the cost of non-blocking algorithms. When we detect collision, we retry until the operation succeeded. This is the common schema for non-blocking algorithms.

Here is a thread-safe Stack implemented using AtomicReference :

public class Stack {
    private final AtomicReference<Element> head = new AtomicReference<Element>(null);

    public void push(String value){
        Element newElement = new Element(value);

        while(true){
            Element oldHead = head.get();
            newElement.next = oldHead;

            //Trying to set the new element as the head
            if(head.compareAndSet(oldHead, newElement)){
                return;
            }
        }
    }

    public String pop(){
        while(true){
            Element oldHead = head.get();

            //The stack is empty
            if(oldHead == null){
                return null;
            }

            Element newHead = oldHead.next;

            //Trying to set the new element as the head
            if(head.compareAndSet(oldHead, newHead)){
                return oldHead.value;
            }
        }
    }

    private static final class Element {
        private final String value;
        private Element next;

        private Element(String value) {
            this.value = value;
        }
    }
}

It's really more complicated than using synchronized on the two methods but also more performing if there is contention (and often even if there is no contention).

So this ends this post. To conclude, atomic variables classes are a really good way to implement non-blocking algorithms and moreover are also a very good alternative to volatile variables, because they can provide atomicity and visibility.

Java Concurrency - Part 5 : Monitors (Locks and Conditions)

Baptiste Wicht — Mon, 06 Sep 2010 05:13:27 GMT

After seeing how to synchronize code using semaphores, we'll see how to do that using monitors.

Monitors are an other mechanism of concurrent programming. It's a higher level mechanism than semaphores and also more powerful. A monitor is an instance of a class that can be used safely by several threads. All the methods of a monitor are executed with mutual exclusion. So at most one thread can execute a method of the monitor at the same time. This mutual exclusion policy makes easier to work with monitor and to develop the method content of the monitor.

Monitors have an other feature, the possibility to make a thread waiting for a condition. During the wait time, the thread temporarily gives up its exclusive access and must reacquire it after the condition has been met. You can also signal one or more threads that a condition has been met.

There is several advantages on using monitors instead of a lower-level mechanisms :

All the synchronization code is centralized in one location and the users of this code don’t need to know how it’s implemented.
The code doesn't depend on the number of processes, it works for as many processes as you want
You don’t need to release something like a mutex, so you cannot forget to do it

When we must describe a monitor, we simple use the monitor keyword and describe the methods as common methods :

monitor SimpleMonitor {
    public method void testA(){
        //Some code
    }

    public method int testB(){
        return 1;
    }
}

To describe a condition variable, we use the cond keyword. A condition variable is a kind of queue of process who are waiting on the same condition. You have several operations available on a condition, the most important is to signal a process waiting to be awaken and to wait on a condition. There are some similarities between signal/wait operations and P and V of semaphores, but this is a little different. The signal operation does nothing if the queue is empty and the wait operation put always the thread in the waiting queue. The process queue is served in a first come, first served mode. When a thread wakes up after waiting on a condition, it must reacquire the lock before continuing in the code.

Before going further, we must have more information about the signal operations. When writing monitors, you normally have the choice between several philosophies for the signaling operation :

Signal & Continue (SC) : The process who signal keep the mutual exclusion and the signaled will be awaken but need to acquire the mutual exclusion before going.
Signal & Wait (SW) : The signaler is blocked and must wait for mutual exclusion to continue and the signaled thread is directly awaken and can start continue its operations.
Signal & Urgent Wait (SU) : Like SW but the signaler thread has the guarantee than it would go just after the signaled thread
Signal & Exit (SX) : The signaler exits from the method directly after the signal and the signaled thread can start directly. This philosophy is not often used.

The available policies depends on the programming language, in Java, there is only one policy available, the SC one.

In Java there is no keyword to directly create a monitor. To implement a monitor, you must create a new class and use Lock and Condition classes. Lock is the interface is ReentrantLock is the main used implementation, this is the one that we'll learn to use in the current post. To create a ReentrantLock, you have two constructors, a default constructor and a constructor with a boolean argument indicating if the lock is fair or not. A fair lock indicates that the threads will acquire the locks in the order they ask for. Fairness is a little heavier than default locking strategies, so use it only if you need it. To acquire the lock, you just have to use the method lock and unlock to release it.

The explicit locks have the same memory semantics than the synchronized blocks. So the visibility of the changes is guarantee when you use lock()/unlock() blocks.

So to implement, the monitor example we've seen before, we just need to create a class and use the lock to make the mutual exclusion :

public class SimpleMonitor {
    private final Lock lock = new ReentrantLock();

    public void testA() {
        lock.lock();

        try {
            //Some code
        } finally {
            lock.unlock();
        }
    }

    public int testB() {
        lock.lock();

        try {
            return 1;
        } finally {
            lock.unlock();
        }
    }
}

The person who've already read the other parts of this post set will say that it will be easier to use the synchronized keyword on the two methods. But with synchronized, we will not have the condition variables. If you don't need condition variables but only locking, it will be easier to use the synchronized blocks instead of Locks.

You can create conditions using the newCondition method on the lock. A condition is a variable of type Condition. You can make the current thread wait on the condition using the await method (and its variant with timeout) and you can signal threads using signal and signalAll methods. The signalAll methods wakes up all the threads waiting on the condition variable.

Let's try with a simple common example : A bounded buffer. It's a cyclic buffer with a certain capacity with a start and an end.

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class BoundedBuffer {
    private final String[] buffer;
    private final int capacity;

    private int front;
    private int rear;
    private int count;

    private final Lock lock = new ReentrantLock();

    private final Condition notFull = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();

    public BoundedBuffer(int capacity) {
        super();

        this.capacity = capacity;

        buffer = new String[capacity];
    }

    public void deposit(String data) throws InterruptedException {
        lock.lock();

        try {
            while (count == capacity) {
                notFull.await();
            }

            buffer[rear] = data;
            rear = (rear + 1) % capacity;
            count++;

            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    public String fetch() throws InterruptedException {
        lock.lock();

        try {
            while (count == 0) {
                notEmpty.await();
            }

            String result = buffer[front];
            front = (front + 1) % capacity;
            count--;

            notFull.signal();

            return result;
        } finally {
            lock.unlock();
        }
    }
}

So some explications :

The two methods are protected with the lock to ensure mutual exclusion
Then we use two conditions variables. One to wait for the buffer to be not empty and an other one to wait for the buffer to be not full.
You can see that I have wrapped the await operation on a while loop. This is to avoid signal stealers problem that can occurs when using Signal & Continue

And that BoundedBuffer can be easily used with several threads with no problems.

As you can see, you can use monitors to solve a lot of concurrent programming problems and this mechanism is really powerful and performing.

I hope you found that article interesting and that this set of posts about Java concurrency brings you some stuff about Java.

My Java Benchmarks on GitHub

Baptiste Wicht — Fri, 03 Sep 2010 05:16:20 GMT

I've created a new github repository for my Java Benchmarks : java-benchmarks

From now all my benchmarks will be pushed to this repository. This is more simple for me to manage and more secure also.

At this time, there is seven benchmarks on the repository :

Closest Pair Search Benchmark : A benchmark to test two closest pair point search algorithms : the naive one and the sweeping plane one. Results.
File Copy Benchmark : A benchmark on the different ways to make file copy in Java. Results.
Iteration Remove Benchmark : A simple benchmark to test if it's interesting to remove the read elements from a list when we make several iterations over the list.
Reflection Benchmark : A little benchmark to test the performances of reflection versus switch cases and direct invocations.
Short Indexes Loop Benchmark : A benchmark to test which primitive type is the most performing using as iteration index. Results.
Synchronization Benchmark : A benchmark to test the performances of the different synchronization mechanisms available in Java to provide mutual exclusion. Results.
Unmodifiable Benchmark : A benchmark to test the performances of unmodifiable collection versus creating a copy of the list.

I hope you'll find these sources interesting. If you found errors or improvements, don't hesitate to comment to tell me what.

Java Synchronization (Mutual Exclusion) Benchmark

Baptiste Wicht — Wed, 01 Sep 2010 05:13:18 GMT

I've created another benchmark. This time, I've benchmarked the different ways of synchronizing a little code using mutual exclusion on this code.

The code to protect will be very simple. It's a simple counter :

//Init
int counter = 0; 
//Critical section
counter++;

The critical section, if not protected with synchronization system, will not function properly due to possible interleavings (read the article on synchronization if you don't know what is interleaving).

Java Concurrency - Part 4 : Semaphores

Baptiste Wicht — Mon, 30 Aug 2010 05:11:55 GMT

We continue in Java Concurrency with the semaphores. Semaphores is also a way to synchronize threads.

Semaphores are a really simple concept, invented by the famous Dutch computer scientist Edsger Dijkstra. Basically a semaphore is a counter (integer) that allows a thread to get into a critical region if the value of the counter is greater than 0. If it's the case, the counter is decremented by one otherwise, the thread is waiting until it can go. And when the thread go away from the critical region, the counter is incremented by one to allow one more thread to pass the critical region. A semaphore is created with a certain value for its counter. So, you can execute two actions on a semaphore P and V.

By example, if you have a critical that cannot be executed concurrently, you can use a semaphore :

sem mutex = new sem(1)
P(mutex)
//Critical region
V(mutex)

So you must always call by yourself the P operation before the critical region and V after it. We call a mutex (mutual exclusion) a semaphore with a value of one. So only one thread can enter the region guarded by the semaphore. This is the most used semaphore. The other use of semaphore is to guard a set of resources like database connections or a data pool.

In Java, a semaphore is created using the java.util.concurrent.Semaphore class. You can create easily :

Semaphore mutex = new Semaphore(1);
Semaphore available = new Semaphore(100);

The P and V operations are represented using the acquire and release methods. The method acquire can be interrupted if the thread is interrupted. There is an uninterruptible version with the method acquireUninterruptibly(). There is also a third version with the tryAcquire method. This method acquire a permit only if there is one permit available, otherwise, this method return false directly. All the waiting methods have also an overloaded version with a timeout. You can also acquire several permits at once using the permits argument to the different versions of acquire methods.

A little example with a mutex using the same example as the previous post on Java concurrency :

public class Example {
    private int value = 0;

    private final Semaphore mutex = new Semaphore(1)

    public int getNextValue() throws InterruptedException {
        try {
            mutex.acquire();
            return value++;
        } finally {
            mutex.release();
        }
    }
}

For more informations about Semaphore in Java, the best is to consult the Javadoc of the Semaphore class.

To conclude, semaphores are a powerful ways to solve concurrency problems, but this is not adapted to all problems. If you need only mutual exclusion, synchronized blocks are a better solutions. The problems with semaphores is that you can forget to call the release method and that can cause deadlock sometimes difficult to find.

Java Concurrency – Part 3 : Synchronization with intrinsic locks

Baptiste Wicht — Fri, 27 Aug 2010 05:15:59 GMT

<After learning how to create threads and manipulate them, it's time to go to most important things : synchronization.

Synchronization is a way to make some code thread safe. A code that can be accessed by multiple threads must be made thread safe. Thread Safe describe some code that can be called from multiple threads without corrupting the state of the object or simply doing the thing the code must do in right order.

For example, we can take this little class :

public class Example {
    private int value = 0;    

    public int getNextValue(){
        return value++;
    }
}

It's really simple and works well with one thread, but absolutely not with multiple threads. An increment like this is not a simple action, but three actions :

Read the current value of "value"
Add one to the current value
Write that new value to "value"

Normally, if you have two threads invoking the getNextValue(), you can think that the first will get 1 and the next will get 2, but it is possible that the two threads get the value 1. Imagine this situation :

Thread 1 : read the value, get 0, add 1, so value = 1
Thread 2 : read the value, get 0, add 1, so value = 1
Thread 1 : write 1 to the field value and return 1
Thread 2 : write 1 to the field value and return 1

These situations come from what we call interleaving. Interleaving describe the possible situations of several threads executing some statements. Only for three operations and two threads, there is a lot of possible interleavings.

So we must made the operations atomic to works with multiple threads. In Java, the first way to make that is to use a lock. All Java objects contains an intrinsic locks, we'll use that lock to make methods or statement atomic. When a thread has a lock, no other thread can acquire it and must wait for the first thread to release the lock. To acquire the lock, you have to use the synchronized keyword to automatically acquire and release a lock for a code. You can add the synchronized keyword to a method to acquire the lock before invoking the method and release it after the method execution. You can refactor the getNextValue() method using the synchronized keyword :

public class Example {
    private int value = 0;    

    public synchronized int getNextValue(){
        return value++;
    }
}

With that, you have the guarantee that only thread can execute the method at the same time. The used lock is the intrinsic lock of the instance. If the method is static, the used lock is the Class object of Example. If you have two methods with the synchronized keyword, only one method of the two will be executed at the same time because the same lock is used for the two methods. You can also write it using a synchronized block :

public class Example {
    private int value = 0;

    public int getNextValue() {
        synchronized (this) {
            return value++;
        }
    }
}

This is exactly the same as using the synchronized keyword on the method signature. Using synchronized blocks, you can choose the lock to block on. By example, if you don't want to use the intrinsic lock of the current object but an other object, you can use an other object just as a lock :

public class Example {
    private int value = 0;

    private final Object lock = new Object();

    public int getNextValue() {
        synchronized (lock) {
            return value++;
        }
    }
}

The result is the same but has one difference, the lock is internal to the object so no other code can use the lock. With complex classes, it not rare to use several locks to provide thread safety on the class.

There is an other issue with multiple threads : the visibility of the variables. This seems when a change made by a thread is visible by an other thread. For performance improvements, the Java compiler and virtual machines can made some improvements using registers and cache. By default, you have no guarantee that a change made by a thread is visible to an other thread. To make a change visible to an other thread, you must use synchronized blocks to ensure visibility of the change. You must use synchronized blocks for the read and for the write of the shared values. You must make that for every read/write of a value shared between multiple threads.

You can also use the volatile keyword on the field to ensure the visibility of read/write between multiple threads. The volatile keyword ensure only visibility, not atomicity. The synchronized blocks ensure visibility and atomicity. So you can use the volatile keyword on fields that doesn't need atomicity (if you make only read and write to the field without depending on the current value of the field by example).

You can also note that this simple example can be solved using AtomicInteger, but that will be covered later in an other part of the posts.

Pay attention that trying to solve thread safety on a problem can add new issues of deadlock. By example, if thread A owns the lock 1 and are waiting for the lock 2 and if lock 2 is acquired by thread B who waits on lock 1, there is a deadlock. Your program is dead. So you have to pay great attention to the locks.

There is several rules that we must keep in mind when using locks :

Every mutable fields shared between multiple threads must be guarded with a lock or made volatile, if you only need visibility
Synchronize only the operations that must synchronized, this improve the performances. But don't synchronize too few operations. Try to keep the lock only for short operations.
Always know which locks are acquired and when there are acquired and by which thread
An immutable object is always thread safe

Here we are, I hope that this post helps you to understand thread safety and how to achieve it using intrinsic locks. In the next posts, we'll see another synchronization methods.

Java File Copy Benchmark Updates (once again)

Baptiste Wicht — Wed, 25 Aug 2010 05:26:11 GMT

I've made another updates to my file copy benchmark.

First of all, I used my little utility class to automatically create the graphs. The graph are a little less clean, but I spare a lot of time not creating them myself.

Then, I've also made some corrections on the code :

I''ve used a buffer size of 8192 instead of 4096
I've made some corrections using the channels because the old code can forgot to write some portions of the file
I used allocateDirect() instead of allocate() for the ByteBuffer.

And I've added a new method using Java 7 : Path.copyTo(Path path).

So the new results are all based on a Java 7 Virtual Machine.

You'll find all the new informations and result, on the original post : File Copy in Java - Benchmark

I hope this new informations will interest you.

Java 7 : The new try-with-resources statement

Baptiste Wicht — Tue, 24 Aug 2010 05:30:53 GMT

From the build 105, the compiler and runtime of Java 7 Releases have support for the new form of try : try-with-resources, also called ARM (Automatic Resource Management) blocks.

This new statement make working with streams and all kind of closeable resources easier. By example, in Java, you can have this kind of code :

private static void customBufferStreamCopy(File source, File target) {
    InputStream fis = null;
    OutputStream fos = null;
    try {
        fis = new FileInputStream(source);
        fos = new FileOutputStream(target);

        byte[] buf = new byte[8192];

        int i;
        while ((i = fis.read(buf)) != -1) {
            fos.write(buf, 0, i);
        }
    }
    catch (Exception e) {
        e.printStackTrace();
    } finally {
        close(fis);
        close(fos);
    }
}

private static void close(Closeable closable) {
    if (closable != null) {
        try {
            closable.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

A little bit heavy, isn't it ? This is only an example, here the management of exceptions is not good.

So let's use try-with-resources statement to simplify this code, who becomes :

private static void customBufferStreamCopy(File source, File target) {
    try (InputStream fis = new FileInputStream(source);
        OutputStream fos = new FileOutputStream(target)){

        byte[] buf = new byte[8192];

        int i;
        while ((i = fis.read(buf)) != -1) {
            fos.write(buf, 0, i);
        }
    }
    catch (Exception e) {
        e.printStackTrace();
    }
}

A lot cleaner, no ? With that code, the resources are automatically closed after the try. In the try resources list, you can declare several resources, but all these resources must implement the java.lang.AutoCloseable interface.

If you want more informations, about this new statement read try-with-resources specifications.

Java Concurrency in Practice - Book Review

Baptiste Wicht — Mon, 23 Aug 2010 05:05:00 GMT

I used my holidays to concentrate myself on the reading of my last book : Java Concurrency in Practice of Brian Goetz (with Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes and Doug Lea).

This book is, in my point of view, the reference for the development of concurrency programs in Java.

Reading this book, you will learn that concurrency is everywhere when programming in Java (all the examples are in Java, but the theory is valid for almost all programming languages). You will also learn why the GUI Frameworks are single-threaded. You will also understand that a lot of Java programs aren't correct because of the lack of thread safety.

The first chapter, the introduction, explains what's are the threads and why we use parallel processing. It contains also the first interleaving example (really simple) and how to solve it. In the third chapter, the author explains what is Thread Safety and how to achieve it using locks (intrinsic locks with synchronized). In the next chapter, you learn how to share objects between several threads. This include the notions of visibility, immutability, thread confinement and safe publication. With the fourth chapter, you learn how to design a thread safe class, delegate the thread safety to an other class and learn why it's really important to document the synchronization policies. In the last chapter of this first part, we see how to build blocks of statements. We use concurrent collections, blocking queues, synchronizers, blocking and interruptible methods.

The second part is about structuring concurrent applications. It contains information about the executor framework, finding parallelism, the cancellation and the shutdown of tasks, the thread pools and the GUI applications.

The third part is about liveness hazards, performance and scalability and also about testing concurrent programs.

The last part describe advanced topics. It contains explicit locks using ReentrantLock. It explains also how to build custom synchronizers. A chapter is about building concurrent programs using non-blocking algorithms. This algorithms are better performing but a lot more difficult to build. And the last chapter is about the Java Memory Model. This chapter is very technical but really interesting if you are interested to understand deeply the Java language.

To conclude, this book is a reference for every person who want to write concurrent applications.

Post Scriptum : This is the hundredth post of this blog. I'm proud to see that there is a lot of regular readers and I hope that this blog will live long.

A website for JTheque

Baptiste Wicht — Sat, 14 Aug 2010 09:51:40 GMT

I've the pleasure to inform you that I've created a new website in English for JTheque : http://www.jtheque.com

The old websites of JTheque (a French website and a French forge) were completely out of date and were too complicated too manage. This time I created an english, really simple, website to add the more useful informations about my JTheque projects. I always wanted to have a real website for JTheque. Before that, I had the Maven auto generated websites, but this is not a real website and it's not really good-looking. I used Google Sites to create this website.

At this time, I've included three projects in the website : JTheque Core, JTheque Utils and JTheque XML Utils. There is not a lot of informations for the moment, but from this time I'll include all the future informations in this new website and I will of course inform you via this blog of all the informations about my projects.

I hope that this website will interest you and that it will help to promote a little my JTheque Project.

If you found any error on the website, don't hesitate to contact me, via comment or email or whatever you want. If you need more informations on one or more project, don't hesitate to request them and I will include them in the website as soon as possible.