Java trop bien

Quelle collection Java utiliser et dans quel cas ?

admin — Sun, 27 Jan 2013 14:10:31 +0000

Nous avons déjà vu dans un précédent article les différentes entre ArrayList, LinkedList et Vector. Mais qu’en est-il pour les autres collections ?

Voici un document qui résume parfaitement les divers scénarios d’utilisation des collections Java : https://docs.google.com/spreadsheet/pub?key=0Aq3e8BiuZY2wdFpHSlV0QzVmV1lUNHJidGd2b0Zrb3c

Création d’entités JPA à partir d’une base de données MySQL avec Eclipse

admin — Mon, 07 May 2012 12:28:24 +0000

Cet article décrit étape par étape le processus de création d’entités JPA à partir d’une base de données MySQL existante, avec l’IDE Eclipse Indigo 3.7.

Télécharger la version “Eclipse IDE for Java EE Developers” d’Eclipse Indigo 3.7
Télécharger le driver JDBC MySQL mysql-connector-java-5.1.20.jar
Créer un nouveau projet JPA
Taper le nom du projet puis cliquer sur Next
Cliquer sur l’icône “Download library…”
Cliquer sur “EclipseLink 2.3.2 – Indigo” puis cliquer sur Next
Cliquer sur “Add connection…”
Cliquer sur MySQL puis sur Next
Cliquer sur MySQL JDBC Driver 5.1
Cliquer sur l’onglet JAR List, sélectionner mysql-connector-java-5.1.0-bin.jar et cliquer sur Remove JAR/Zip
Cliquer sur Add JAR/Zip… et sélectionner le driver JDBC mysql-connector-java-5.1.20.jar téléchargé à l’étape 2)
Cliquer sur l’onglet Properties, taper les paramètres de connexion à la base de données, et cliquer sur OK
Cliquer sur OK
Cliquer sur Test Connection. Le message “Ping succeeded!” doit apparaître
Cliquer sur Finish
Créer des nouvelles entités JPA à partir des tables
Cocher les noms des tables dont on veut générer les entités correspondantes
Saisir le nom du package dans lequel seront générées les entités, cocher java.util.List, puis cliquer sur Finish. C’est terminé !

Avantages :

Possibilité de choisir pour chaque champ le type de la variable (Long à la place de long par exemple)
Possibilité de choisir comment sont générées les clés primaires

Inconvénients :

Pas de génération automatique des méthodes equals(), hashCode() et toString()
Pas de génération automatique des Named Queries
Pas de génération automatique de différents constructeurs

Comment implémenter le pattern Post/Redirect/Get avec Struts2

admin — Sun, 01 Jan 2012 14:56:46 +0000

Après avoir vu comment implémenter le design pattern Post/Redirect/Get avec des servlets, voici comment faire avec le framework Struts2 :

Environnement de développement :
jdk1.7
Eclipse Indigo
Tomcat 7.0.12

Tout d’abord, l’action Struts2 redirigeant vers la page index.jsp :

import com.opensymphony.xwork2.ActionSupport;

public class IndexAction extends ActionSupport {

	private boolean confirm;

	public String execute() throws Exception {
		return SUCCESS;
	}

	public boolean isConfirm() {
		return confirm;
	}

	public void setConfirm(boolean confirm) {
		this.confirm = confirm;
	}
}

Ensuite, la JSP index.jsp contenant un formulaire avec un bouton submit :


<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@taglib prefix="s" uri="/struts-tags" %>



	
		L'article a bien été ajouté au panier.
	
	
		Cliquer pour ajouter l'article au panier.

Ensuite, l’action Struts2 vers laquelle le formulaire est posté, qui effectue la redirection 302 vers une autre action Struts2. Contrairement au code utilisant des servlets, Struts2 ne permet pas de définir le code HTTP 303 pour la redirection.

import com.opensymphony.xwork2.ActionSupport;

public class PRGAction extends ActionSupport {

	public String execute() throws Exception {
		return "redirect";
	}
}

Enfin, le fichier de configuration struts.xml :






	
		
			/jsp/index.jsp
		
		
			 
		 		index
			 	true

Comment implémenter le pattern Post/Redirect/Get avec des Servlets

admin — Fri, 30 Dec 2011 00:41:29 +0000

Il existe 2 méthodes HTTP pour afficher une page web : Get et Post.

La méthode Get est utilisée lorsqu’on clique sur un lien ou pour afficher les résultats d’un formulaire de recherche. Dans ce 2ème cas, le fait que les paramètres de la requête soit présents dans l’url permet de bookmarker la page de résultats, ce qui n’est pas possible lorsqu’un formulaire utilise la méthode Post.
La méthode Post est généralement utilisée pour des formulaires contenant des données tapées par l’utilisateur et destinées à être traitées. C’est le cas des formulaires d’inscription, de login ou d’ajout d’un article à un panier.

Le problème avec la méthode Post, c’est le risque de double submit. En effet, après avoir soumis un formulaire, si un utilisateur tente de rafraîchir la page ou d’utiliser le bouton back du navigateur pour revenir à la page précédente, il obtient le message d’avertissement suivant :

Ce message peut faire peur aux utilisateurs, surtout après avoir soumis un formulaire de paiement.

Heureusement, grâce au design pattern Post/Redirect/Get (PRG), on peut éviter l’affichage de cette pop-up. Le principe du PRG est le suivant :

L’utilisateur soumet un formulaire avec la méthod Post
Le server traite les données et retourne au browser une réponse avec le code HTTP 303 (un redirect de type See Other) indicant l’url de la page de résultat
Le browser effectue une requête HTTP avec la méthode Get pour aller chercher la page de résultat

Il existe toutefois 2 inconvénients au design pattern PRG :

2 allers-retours entre le client et le serveur au lieu d’un peut avoir un impact légèrement néfaste sur le temps de réponse de la page.
L’url de la page de résultat peut contenir des paramètres sensibles (qui ne seraient pas apparus dans l’url s’il n’y avait eu qu’un Post), ce qui peut poser problème au niveau de la sécurité.

Voici le code permettant d’implémenter le design pattern Post/Redirect/Get avec des servlets :

Environnement de développement :
jdk1.7
Eclipse Indigo
Tomcat 7.0.12

Tout d’abord, la JSP index.jsp contenant un formulaire avec un bouton submit :

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>

<%
	Boolean confirm = (Boolean)request.getAttribute("confirm");
%>




	<%
		if(confirm != null && confirm)
		{
			%>
			L'article a bien été ajouté au panier.
			<%
		}
		else
		{
			%>
			Cliquer pour ajouter l'article au panier.
			<%
		}
	%>

Ensuite, la servlet vers laquelle le formulaire est posté, qui effectue la redirection 303 vers une autre servlet. On remarquera l’utilisation de l’annotation @WebServlet, ce qui évite d’avoir à déclarer la servlet dans le fichier web.xml :

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/prgServlet")
public class PRGServlet extends HttpServlet {

	protected void doPost(HttpServletRequest request,
			HttpServletResponse response) {

		response.setStatus(HttpServletResponse.SC_SEE_OTHER);
		response.setHeader("Location", "/myapp/confirmationServlet?confirm=true");
	}

}

Enfin, la servlet qui redirige vers la jsp correspondant à la page de résultat :

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/confirmationServlet")
public class ConfirmationServlet extends HttpServlet {

	protected void doGet(HttpServletRequest request,
			HttpServletResponse response) throws ServletException, IOException {

		request.setAttribute("confirm",
				Boolean.valueOf(request.getParameter("confirm")));

		getServletContext().getRequestDispatcher("/index.jsp").forward(request,
				response);
	}
}

Dans un prochain article, nous verrons comment implémenter le design pattern Post/Redirect/Get avec Struts2.

Quelle API pour convertir des objets Java en JSON ? Partie 5

admin — Tue, 27 Dec 2011 23:50:00 +0000

Pour finir cette série d’articles sur les librairies JSON, nous allons parler de Gson. Cette librairie développée par Google est moins complète que Jackson, mais aussi bien documentée. En outre, Gson accorde une grande importance au support des Generics.

Maven snippet :


	com.google.code.gson
	gson
	2.0

Contrairement à Json-lib et XStream, Gson ne possède pas de dépendances transitives.

Dans les exemples qui suivent, nous utilisons toujours le même objet User défini dans l’article sur json.org.

JSON to Java

String json = "{User:{login:'admin',password:'123456'}}";
Gson gson = new Gson();
JsonParser parser = new JsonParser();
JsonObject jsonObject = (JsonObject) parser.parse(json);
User user = gson.fromJson(jsonObject.get("User").toString(), User.class);

Gson est ici moins stricte que Jackson car elle ne requiert pas de double quotes dans la syntaxe du JSON.

Gson est la librairie dont les noms de méthodes sont les plus lisibles. Pas besoin de réfléchir pour comprendre ce que font les méthodes fromJson() et toJson().

Gson est moins pratique que XStream pour la désérialisation. En effet, le mapping ne semble pas fonctionner lorsque la syntaxe du JSON contient une clé racine. Il a donc fallu que je parse d’abord le JSON pour en extraire la clé racine.

Java to JSON

User user = new User("admin", "123456");
Map map = new HashMap();
map.put(User.class.getCanonicalName(), user);
Gson gson = new Gson();
String json = gson.toJson(map);
// imprime {"User":{"login":"admin","password":"123456"}}
System.out.println(json);

Là encore, Gson est moins pratique que XStream et Jackson pour la sérialisation puisque je dois passer par la création d’une map pour obtenir la syntaxe JSON que je veux.

Bilan

Comme l’indique cet article, Gson possède des performances équivalentes à celle de Jackson. Toutefois, elle est un moins complète que Jackson et moins agréable à utiliser que XStream.

Quelle API pour convertir des objets Java en JSON ? Partie 4

admin — Tue, 27 Dec 2011 00:34:53 +0000

La 4ème partie de cette série d’articles sur les librairies JSON porte sur Jackson.

Jackson est une librairie JSON très complète (plus de 250 classes !) et bien documentée. Pour info, les frameworks Jersey et RESTEasy s’appuient sur Jackson pour générer du JSON à partir de beans possédant des annotations JAXB.

Maven snippet :


	org.codehaus.jackson
	jackson-mapper-asl
	1.9.3

Attention, Jackson est proposée sous 2 licences différentes : ASL et LGPL. Pour savoir laquelle choisir, c’est par ici.

Jackson est une librairie modulaire. Seul le jar jackson-core est indispensable, mais il doit être utilisé conjointement avec d’autres jars en fonction des besoins. Par exemple, pour convertir des objets Java en JSON et inversement, il faut également ajouter le jar jackson-mapper dans le classpath.

Dans les exemples qui suivent, nous utilisons toujours le même objet User défini dans l’article sur json.org.

JSON to Java

Jackson est plus stricte que json.org, Json-lib et XStream concernant la syntaxe du JSON. Si les clés ne sont par entourées de double quotes, une JsonParseException est levée.

String json = "{\"User\":{\"login\":\"admin\",\"password\":\"123456\"}}";
ObjectMapper mapper = new ObjectMapper();
User user = mapper.readValue(json, User.class);

Ce code ne fonctionne pas avec l’objet User tel qu’il a été défini dans l’article sur json.org. Ceci est dû au fait que je ne peux pas utiliser l’option WRAP_ROOT_VALUE lors de la désérialisation car comme le dit la javadoc, cette option n’a pas encore été implémentée dans Jackson. Pour contourner le problème, j’utilise l’objet User suivant :

public class User {

	private String login;
	private String password;

	@JsonProperty("User")
	private User user;

	public User() {
	}

	public User(String login, String password) {
		this.login = login;
		this.password = password;
	}

	public User getUser() {
		return user;
	}

	public void setUser(User user) {
		this.login = user.getLogin();
		this.password = user.getPassword();
	}

	public String getLogin() {
		return login;
	}
	public void setLogin(String login) {
		this.login = login;
	}
	public String getPassword() {
		return password;
	}
	public void setPassword(String password) {
		this.password = password;
	}

	public String toString() {
		return "User [login=" + login + ", password=" + password + "]";
	}
}

Java to JSON

User user = new User("admin", "123456");
ObjectMapper mapper = new ObjectMapper();
mapper.configure(SerializationConfig.Feature.WRAP_ROOT_VALUE, true);
Writer strWriter = new StringWriter();
mapper.writeValue(strWriter, user);
String json = strWriter.toString();
// imprime {"User":{"login":"admin","password":"123456"}}
System.out.println(json);

L’option WRAP_ROOT_VALUE ayant été implémentée pour la sérialisation, je n’ai pas besoin de modifier l’objet User. J’utilise celui qui a été défini dans l’article sur json.org. De plus, l’avantage par rapport à Json-lib et json.org est que je n’ai pas besoin de passer les attributs de l’objet User dans une map.

Bilan

Jackson est une librairie complète mais modulaire, ce qui évite d’avoir des jars inutiles dans le classpath. Le nom des méthodes est plus intuitif qu’avec XStream. De plus, d’après cet article, c’est la librairie JSON qui possède les meilleures performances.

Quelle API pour convertir des objets Java en JSON ? Partie 3

admin — Fri, 23 Dec 2011 18:51:07 +0000

La 3ème partie de cette série d’articles sur les librairies JSON porte sur XStream.

À la base, XStream sert à convertir des objets Java en XML et inversement. Mais on peut aussi l’utiliser pour JSON. XStream s’appuie pour cela sur une librairie JSON bas niveau appelée Jettison. D’ailleurs, le framework CXF s’appuie lui-aussi sur Jettison

Maven snippet :


	com.thoughtworks.xstream
	xstream-parent
	1.4.2

Contrairement à json.org, XStream requiert une dépendance. Si on n’utilise pas Maven, il ne faut pas oublier d’ajouter jettison-1.2 dans le classpath.

Dans les exemples qui suivent, nous utilisons toujours le même objet User défini dans l’article sur json.org.

JSON to Java

String json = "{User:{login:'admin',password:'123456'}}";
XStream xstream = new XStream(new JettisonMappedXmlDriver());
User user = (User)xstream.fromXML(json);

Ici, l’avantage de la librarie XStream par rapport à json.org, c’est qu’elle propose la méthode XStream.fromXML(), qui crée automatiquement un objet User avec les bons attributs, alors qu’avec json.org, il fallait créer l’objet et setter les attributs soi-même. On regrette quand même le nom peu intuitif de cette méthode.

Java to JSON

User user = new User("admin","123456");
XStream xstream = new XStream(new JettisonMappedXmlDriver());
xstream.setMode(XStream.NO_REFERENCES);
String json = xstream.toXML(user);
System.out.println(json);

Ici, l’avantage par rapport à Json-lib et json.org est que je n’ai pas besoin de passer les attributs de l’objet User dans une map et ça fait très plaisir. Pour retrouver un fonctionnement similaire à Json-lib et json.org, il faut utiliser le DROP_ROOT_MODE

Bilan

XStream est plus agréable à utiliser que Json-lib et json.org. Néanmoins, dû au fait que cette librairie est à la base destinée à sérialiser des objets Java en XML, le nom des méthodes est peu intuitif.

Quelle API pour convertir des objets Java en JSON ? Partie 2

admin — Wed, 21 Dec 2011 23:10:00 +0000

Dans la 2ème partie de cette série d’articles sur les librairies JSON, nous abordons Json-lib. Cette librairie est basée sur json.org, la librairie qui faisait l’objet du 1er article de cette série. Cela explique pourquoi certaines classes de json.org et Json-lib ont le même nom. Toutefois, Json-lib possède des fonctionnalités avancées.

Maven snippet :


	net.sf.json-lib
	json-lib
	2.4
	jdk15

Contrairement à json.org, Json-lib requiert des dépendances. Si on n’utilise pas Maven, il ne faut pas oublier d’ajouter commons-lang 2.5, commons-beanutils 1.8.0, commons-collections 3.2.1, commons-logging 1.1.1 et ezmorph 1.0.6 dans le classpath.

Dans les exemples qui suivent, nous utilisons encore le même objet User défini dans l’article sur json.org.

JSON to Java

String json = "{User:{login:'admin',password:'123456'}}";
JSONObject jsonObject = JSONObject.fromObject(json);
JSONObject jsonObjectUser = (JSONObject) jsonObject.get("User");
User user = (User) JSONObject.toBean(jsonObjectUser, User.class);

Ici, l’avantage de la librarie Json-lib par rapport à json.org, c’est qu’elle propose la méthode JSONObject.toBean(), qui crée automatiquement un objet User avec les bons attributs, alors qu’avec json.org, il fallait créer l’objet et setter les attributs soi-même.

Java to JSON

Map map = new HashMap();
map.put("login", "admin");
map.put("password", "123456");
JSONObject jsonObject = new JSONObject();
jsonObject.put(User.class.getCanonicalName(), map);
String json = jsonObject.toString();
// imprime {"User":{"login":"admin","password":"123456"}}
System.out.println(json);

Ici, pas d’avantage par rapport à json.org. C’est même plus pénible parce que la méthode put() ne retourne pas un objet JSONObject, ce qui empêche de chaîner les appels de méthode.

Bilan

La librairie Json-lib n’apporte pas grand-chose par rapport à json.org si l’on se contente des fonctionnalités basiques. D’après cet article, les performances de Json-lib sont même pires que celles de json.org.

Quelle API pour convertir des objets Java en JSON ? Partie 1

admin — Sat, 17 Dec 2011 17:19:08 +0000

Il existe plusieurs APIs permettant de convertir des objets Java en JSON (et inversement). Voici les 5 plus connues :

- json.org (http://www.json.org/java)
- Json-lib (http://json-lib.sourceforge.net)
- XStream (http://xstream.codehaus.org)
- Jackson (http://jackson.codehaus.org)
- Gson (http://code.google.com/p/google-gson)

Chacune de ces librairies a ses particularités.

Dans ce 1er article, nous verrons quelles sont les particularités de l’API json.org, et comment l’utiliser.

Maven snippet :


	org.json
	json
	20090211

JSON to Java

Le but est de convertir une chaîne de caractères au format JSON en objet Java. Dans les exemples qui suivent, l’objet Java sera le suivant :

public class User {

	private String login;
	private String password;

	public User(String login, String password) {
		this.login = login;
		this.password = password;
	}

	public String getLogin() {
		return login;
	}
	public void setLogin(String login) {
		this.login = login;
	}
	public String getPassword() {
		return password;
	}
	public void setPassword(String password) {
		this.password = password;
	}

	public String toString() {
		return "User [login=" + login + ", password=" + password + "]";
	}
}

Le code permettant de convertir le JSON en objet User est :

String json = "{User:{login:'admin',password:'123456'}}";
JSONObject jsonObject = new JSONObject(json);
JSONObject jsonObjectUser = (JSONObject) jsonObject.get("User");
User user = new User(jsonObjectUser.getString("login"),
     jsonObjectUser.getString("password"));

La conversion fonctionne, mais on remarque que l’objet JSONObject accepte en argument une string JSON dont le format n’est pas valide. En effet, la spécification JSON indique que les clés et les valeurs de type String doivent être entourées de double quotes. D’après moi, il aurait fallu qu’une exception soit levée.

Java to JSON

Le but est de convertir l’objet User en une chaîne de caractères au format JSON.

User user = new User("admin", "123456");
String json = new JSONObject(user).toString();
// imprime {"login":"admin","password":"123456"}
System.out.println(json);

Là aussi, la conversion fonctionne, et le format de la string JSON générée est valide puisqu’elle contient des doubles quotes. Par contre, on remarque que la clé User a disparu de la string JSON. Ce n’est pas le résultat que j’attendais. Pour obtenir ce que j’attendais, je dois utiliser le constructeur sans argument et passer par la création d’une map, ce qui est plutôt pénible :

Map map = new HashMap();
map.put("login", "admin");
map.put("password", "123456");
String json = new JSONObject().put(User.class.getCanonicalName(), map).toString();
// imprime {"User":{"login":"admin","password":"123456"}}
System.out.println(json);

Bilan

Cette API est assez simple, ne possède pas dépendances transitives, mais elle manque de possibilités, et ne fait pas toujours ce qu’on attend d’elle.

Java EE 7 inclura JCache

admin — Sat, 10 Dec 2011 16:58:58 +0000

L’API de caching JCache, décrite dans la JSR 107 fera partie de Java EE 7.

Il existait déjà plusieurs API de caching dans le monde Java, comme Ehcache, mais il n’existait pas de standard. L’avantage d’avoir un standard est de pouvoir switcher très simplement d’une implémentation à une autre, c’est à dire sans modification du code source de l’application. Il suffit juste de changer la dépendance dans Maven.

Une implémentation de JCache, ehcache-jcache, est déjà en court de développement (git).

Pour rappel, la sortie de Java EE 7 est prévue pour le 3ème ou 4ème trimestre 2012.

Tuning des performances de la JVM chez Twitter

admin — Sun, 30 Oct 2011 08:45:01 +0000

Un diaporama créé par Attila Szegedi, ingénieur chez Twitter :

Everything I Ever Learned About JVM Performance Tuning @Twitter

Faut-il faire du Sharding de base de données ?

admin — Sat, 27 Aug 2011 15:41:27 +0000

Un article expliquant le concept de Sharding de base de données, avec ses avantages et ses inconvénients : http://software-development-thoughts.blogspot.com/2011/07/to-shard-or-not-to-shard-that-is.html

Hudson ou Jenkins ?

admin — Sat, 27 Aug 2011 14:34:33 +0000

Depuis la fusion Oracle/Sun et la scission Hudson/Jenkins, on peut se demander lequel des 2 outils il faut utiliser. Cet article présente 5 avantages de Jenkins par rapport à Hudson : http://blog.cloudbees.com/2011/07/five-reasons-why-developers-choose.html

8 bonnes pratiques de base pour un développeur Java/J2EE

admin — Sat, 27 Aug 2011 14:13:04 +0000

Utiliser un IDE
Notepad++ c’était suffisant pour faire du PHP. Nous, on est là pour développer des applications d’entreprise. Alors on a besoin d’être productif. Un IDE offre beaucoup d’avantages : autocompletion, génération de code automatique, refactoring, etc. Les 3 principaux IDE pour Java sont Eclipse, NetBeans et IntelliJ IDEA. IntelliJ IDEA est le meilleur des 3 mais sa version gratuite ne permet que de coder des applis J2SE, pas J2EE. La version payante coûte 168 €.
Commenter son code
Mettez des commentaires Javadoc sur chaque classe et chaque méthode, qu’elle soit publique ou privée, et même si le nom de la méthode est suffisamment parlant pour comprendre ce qu’elle fait. Pour les getters/setters, générez les commentaires automatiquement avec l’IDE. À l’intérieur d’une méthode, mettez un commentaire pour expliquer chaque étape de votre algorithme.
Définir un standard pour le nommage des variables
Au début du projet, définir un standard pour le nommage des classes, méthodes, variables, constantes, id et class CSS, fonctions JavaScript, etc…
Tester son code
Concernant le back-end, chaque service Spring doit être tester avec JUnit. Pareil pour chaque méthode des classes utilitaires. Concernant le front-end, effectuez des tests Selenium, voire des tests unitaires JsUnit si l’application web repose beaucoup sur JavaScript.
Utiliser un VCS
Même s’il n’y a qu’un seul développeur sur le projet, il faut toujours utiliser un outil de gestion de versions, ne serait-ce que pour conserver l’historique des modifications apportées au code. Eclipse Indigo contient un client CVS. Pour SVN, il faut télécharger le plugin Subclipse. IntelliJ IDEA contient en standard des clients CVS, SVN, Git et Mercurial.
Commiter quand il faut
- Pendant la phase de dev du projet, ne pas attendre 2 semaines pour commiter une fonctionnalité. Il faut commiter au moins une fois par jour, pour au moins 2 raisons. Première raison : il sera plus facile de résoudre des éventuels conflits sur des petites modifications de fichier. Deuxième raison : s’il y a une coupure de courant dans la nuit et que votre disque dur claque, vous perdrez maximum 1 jour de taf. Avant chaque commit, vérifiez que vos modifications ne vont pas casser le build en lançant un mvn test.
- Pendant la phase de recette du projet, commitez à chaque correction de bug. Pensez à bien préciser le numéro du bug (si le bug est a été créé dans un bugtracker) dans le commentaire du commit.
Soigner la qualité du code
Il existe plusieurs outils qui aide à améliorer la qualité du code Java. Les plus connus sont Checkstyle, PMD, et FindBugs. Le plus simple est en fait d’utiliser Sonar puisqu’il intègre ces 3 outils.
Suivre l’actualité de la communauté Java
Participer à des conférences (JUG, JavaOne, Devoxx) pour se tenir au courant des derniers nouveautés et s’abonner à des blogs ou des comptes twitter créés par des développeurs/architectes Java qui peuvent contenir des astuces, des tutos et autres infos utiles.

Fonctions JavaScript utiles

admin — Tue, 23 Aug 2011 20:52:50 +0000

Une liste de fonctions JavaScript qui peuvent être utiles

// Renvoie true si str est un entier, false sinon
function isInteger(str) {
    return (parseInt(str).toString() == str)
}

// Renvoie true si str se termine par suffix, false sinon
function endsWith(str, suffix) {
    return str.indexOf(suffix, str.length - suffix.length) !== -1;
}

// Récupère la valeur du paramètre name dans l'url
function getParamValue(name,url) {
  var regexS = "[\\?&]"+name+"=([^&#]*)";
  var regex = new RegExp( regexS );
  var results = regex.exec(url);
  if( results == null )
    return "";
  else
    return results[1];
}

C’est pas du Java mais ça pas grave.

Différence entre et

admin — Sun, 12 Jun 2011 18:06:03 +0000

Il existe 2 façons d’inclure une JSP dans une autre :
- La directive :

<%@ include file="toto.jsp" %>

- L’action :

Ces 2 possibilités sont évidemment différentes, et l’une n’est pas meilleure que l’autre, sinon il n’en existerait qu’une. Voyons quelles sont les particularités de chacune :

La directive <%@include%>
- L’inclusion est effectuée à la compilation de la JSP. Cela équivaut à copier-coller le code de la JSP fille dans la JSP parente. Une unique servlet est donc générée à partir des deux JSP.
- Les variables déclarées dans des scriptlets de la JSP parente sont accessibles dans la JSP fille.
- La JSP fille n’étant pas compilée de façon standalone, elle n’a pas forcément l’extension .jsp. Elle peut par exemple avoir l’extension .jspf, ce qui recommandé pour les JSP fragments.
L’action
- L’inclusion est effectuée à l’exécution de la JSP. Deux servlets sont générées : une pour la JSP parente, et une pour la JSP fille.
- Pour accéder depuis la JSP fille à une variable déclarée dans la JSP parente, il faut utiliser l’action pour passer la variable et la récupérer avec request.getParameter(“xxx”).
- La JSP fille doit pouvoir compiler de façon standalone, elle doit avoir l’extension “.jsp” et doit contenir les imports nécéssaires.

Conclusion :

Si la JSP parente contient une structure conditionnelle et que la ou les JSP filles ne sont incluses que sous certaines conditions, il faut utiliser l’action pour éviter d’alourdir la page HTML avec du code qui ne sera pas utilisé.
Si on veut créer une JSP fille qui contiendrait tous les imports nécessaires à plusieurs JSP parentes (pour factoriser le code), il faudra utiliser la directive <%@include%>.

Qu’en est-il du tag de la JSTL ?
Tout comme l’inclusion est effectuée à l’exécution de la JSP. Toutefois, contrairement aux 2 autres, permet d’inclure une page pouvant appartenir à un autre contexte ou être hébergée sur un autre serveur. De plus, grâce aux attributs var / varReader, permet de stocker le contenu de la page incluse dans une String / Reader.

Déploiement parallèle dans Tomcat 7

admin — Sun, 05 Jun 2011 16:40:53 +0000

Une nouvelle fonctionnalité a fait son apparition dans Tomcat 7 : le déploiement parallèle.

Le déploiement parallèle permet de déployer plusieurs versions d’une appli web dans le même context path. Les différentes versions déployées sont donc accessibles via la même URL. De plus, il n’est pas nécessaire d’effectuer un arrêt-relance de Tomcat.

Lorsqu’une nouvelle version de l’appli est déployée, Tomcat redirige automatiquement les nouveaux utilisateurs sur la nouvelle appli. Les utilisateurs ayant une session existante sur l’ancienne appli seront quant à eux redirigés sur l’ancienne appli.

Pour profiter de cette fonctionnalité, il suffit d’ajouter le numéro de version de l’application précédé des caractères ## dans le nom du war. Par exemple : mywebapp.war, mywebapp##001.war, mywebapp##002.war, etc…

À quoi sert le SerialVersionUID ?

admin — Sun, 05 Jun 2011 10:46:08 +0000

Lorsqu’une classe implémente l’interface Serializable, elle doit définir une variable nommée serialVersionUID pour éviter que l’IDE signale un warning. Pour comprendre à quoi sert cette variable, il faut comprendre à quoi sert la sérialisation.

La sérialisation est un mécanisme permettant de stocker des instances de classes dans des fichiers binaires (séquences d’octets). Ainsi, les objets sérialisés persistent, même après l’arrêt de la JVM. La méthode ObjectOutputStream.writeObject() permet de sérialiser une classe, tandis que ObjectInputStream.readObject() permet de déssérialiser une classe.

Le serialVersionUID est un “numéro de version” qui permet de s’assurer, lors de la déssérialisation, que les versions des classes sont concordantes. Si ce n’est pas le cas, une InvalidClassException est levée.
En effet, si vous avez sérialisé une classe, puis que vous y ajoutez ou retirez un attribut, l’objet sérialisé ne sera alors peut-être plus compatible avec le programme.

Il faut donc déclarer le serialVersionUID de la manière suivante :

private static final long serialVersionUID = 1L;

puis incrémenter sa valeur à chaque modification d’attributs non transients de la classe.

Optimisation Tomcat

admin — Fri, 03 Jun 2011 16:03:42 +0000

En environnement de Production, la documentation de Tomcat recommande la configuration suivante concernant Jasper 2, le moteur de JSP :

Désactiver le development mode. Par défaut, il est possible de modifier à chaud les jsp d’un war, car Jasper vérifie à chaque accès à la JSP si elle a été modifiée.
Activer genStringAsCharArray. Cela génère des tableaux de char plus performant.

Dans le fichier web.xml :


 
     jsp
     org.apache.jasper.servlet.JspServlet
     
         fork
         false
     
     
         xpoweredBy
         false
     
     
         development
         false
     
     
         genStringAsCharArray
         true
     
     3

Écrire un nombre en toutes lettres en Java avec icu4j

admin — Sun, 24 Apr 2011 15:39:51 +0000

Le code ci-dessous s’appuie sur la librairie icu4j pour convertir un nombre en toutes lettres, quelque-soit la langue. Il suffit de passer la locale en argument :

double nombre = 1218.47;
int formatter = RuleBasedNumberFormat.SPELLOUT;
NumberFormat nf = new RuleBasedNumberFormat(Locale.FRANCE, formatter);
String resultat = nf.format(nombre);
System.out.println(resultat);
//imprime mille-deux-cent-dix-huit virgule quatre sept

À noter le bug sur les chiffres après la virgule…

Le jar est téléchargeable ici.

Avec Maven :


	com.ibm.icu
	icu4j
	4.6.1

Différences de performances entre ArrayList et LinkedList (2ème partie)

admin — Sun, 24 Apr 2011 13:30:54 +0000

Dans la 1ère partie, nous avons vu que la principale différence entre ArrayList et LinkedList est qu’ArrayList implémente l’interface RandomAccess. Comparons les performances de ces deux collections grâce à la notation Big O :

	get()	add()	remove()	contains()
ArrayList	O(1)	O(1)	O(n)	O(n)
LinkedList	O(n)	O(1)	O(1)	O(n)

Rappel :

O(1): - temps constant : le coût est le même quelque-soit la taille de la collection
O(n): - temps linéaire : plus la liste est longue, plus le coût augmente car il faut parcourir chaque élément de la collection
O(log n): - temps logarithmique : plus la liste est longue, plus le coût diminue.

Ce tableau confirme ce qui avait été dit dans la 1ère partie : get() est plus performant pour l’ArrayList, remove() est plus performant pour la LinkedList.

Empêcher les attaques XSS avec Tomcat

admin — Sat, 05 Feb 2011 17:42:05 +0000

Une attaque de type cross-site scripting (XSS) consiste à injecter du code JavaScript malveillant dans un site web afin qu’il soit exécuté par les visiteurs du site. Le but de ce type d’attaque est souvent de voler les données privées des visiteurs stockées dans des cookies.

Heureusement, il est possible de configurer Tomcat pour qu’il empêche l’accès aux cookies à JavaScript : en utilisant la fonctionnalité httpOnly. Cette fonctionnalité est disponible depuis les versions Tomcat 5.5.28 et Tomcat 6.0.19 mais elle n’est pas activée. Elle est par contre activée par défaut dans Tomcat 7.

Pour activer cette fonctionnalité, il faut modifier la balise du fichier conf/context.xml :

...

Pour accéder aux cookies des visiteurs, il faut donc impérativement utiliser du code Java côté serveur, comme ceci :

Cookie[] cookies = request.getCookies();

Différence entre final, finally et finalize

admin — Sat, 01 Jan 2011 21:38:04 +0000

final
Le mot clé final peut être utilisé sur une variable, une méthode ou une classe. Sur une variable, il la transforme en constante. Sur une méthode, il l’empêche d’être redéfinie (override) dans une sous-classe. Sur une classe, il l’empêche d’être étendue.
Attention, lorsque la variable n’est pas un type primitif mais un objet mutable (ArrayList, HashMap, etc.), il n’est pas possible de lui réassigner une nouvelle instance, mais il est possible de modifier son état grâce à ses méthodes internes.
finally
Le mot clé finally intervient lors du mécanisme de gestion des exceptions. Le bloc finally peut être ajouté à la suite d’un bloc try/catch. Qu’une exception soit levée ou pas, le contenu d’un bloc finally sera toujours exécuté. On l’utilise généralement pour libérer des ressources (fermeture de socket, fermeture de fichier, fermeture de connexion à une base de données) afin d’éviter un lock de la ressource si une exception a été levée.
finalize
Cette méthode de la classe Object ne doit jamais être appelée manuellement. Elle est automatiquement appelée par le Garbage Collector juste avant que l’objet soit supprimé du tas (heap).

Conversion String vers byte[] et byte[] vers String

admin — Sat, 01 Jan 2011 20:32:03 +0000

String vers byte[]

On utilise la méthode getBytes() de la classe String :

		String s = "love";
		byte[] b = s.getBytes(); //contient {108, 111, 118, 101}

Si la rapidité est un critère important pour vous, sachez que la méthode ci-dessous est plus performante :

		public byte[] stringToBytes(String s) {
			byte[] b = new byte[s.length()];
			for (int i = 0; i < b.length; i++) {
				b[i] = (byte) s.charAt(i);
			}
			return b;
		}

}

byte[] vers String

On utilise le constructeur new String(byte[]) :

		byte[] b = {108, 111, 118, 101};
		String s = new String(b); //contient "love"

Oracle renomme les certifications Java

admin — Mon, 01 Nov 2010 14:04:03 +0000

Suite au rachat de Sun par Oracle, les certifications on été rebaptisées depuis le 1^er septembre 2010. La plus connue d’entre elles, la SCJP, se nomme dorénavant OCJP. Ci-dessous un récapitulatif des certifications Java avant et après le rachat de Sun :

Avant :

Après :

Pour ceux d’entres vous qui souhaitent passer la certification OCJP, voilà ce qu’il faut savoir :

Nom de l’examen : Oracle Certified Programmer for the Java 2 Platform, SE 6.0
Ancien nom : Sun Certified Java Programmer SE 6
Référence : 310-065
Durée de l’examen : 3h
Style : QCM de 60 questions
Note minimum pour passer l’examen : 58.33%
Prix : 238 € / 300 $
Centre d’examen sur Paris : 206 rue La Fayette 75010 Paris
Livre de référence : SCJP Sun Certified Programmer for Java 6 Study Guide
Logiciel gratuit pour s’entrainer : Exam Lab

Création d’entités JPA à partir d’une base de données MySQL avec Netbeans

admin — Sun, 05 Sep 2010 17:49:31 +0000

Cet article décrit étape par étape le processus de création d’entités JPA à partir d’une base de données MySQL existante, avec l’IDE Netbeans 6.9.1.

Télécharger la version Java (pas la version Java SE) de Netbeans 6.9.1
Créer un nouveau projet Java Web ou en ouvrir un existant
Après création du projet, faire un clique-droit -> New -> Entity Classes from Databases…
Sélectionner New Data Source…
Saisir un nom JNDI, puis sélectionner New Database Connection…
Sélectionner le driver MySQL et les paramètres de connexion à la base de données

Remarque : si le compte MySQL utilisé pour la connexion ne possède pas de mot de passe (utilisateur root par exemple), il se peut que la création de la Data Source échoue.
Sélectionner la nouvelle Data Source, cliquer sur les noms des tables dont on veut générer les entités correspondantes et sur le bouton Add pour les ajouter dans la colonne de droite.
Saisir le nom du package dans lequel seront générées les entités
Sélectionner default et java.util.List. Cliquer sur Finish. C’est terminé !

Avantages :

génération des méthodes equals(), hashCode() et toString()
génération des Named Queries
génération de différents constructeurs

Inconvénients :

génération d’annotations @Basic(optional = false) inutiles
impossibilité de choisir des noms d’attribut différents des noms de colonne
impossibilité de choisir les types des attributs (Long à la place de long par exemple)
si, après génération, on remplace les long par des Long, il faut réécrire les méthodes equals()

Logging Java : bonnes pratiques

admin — Sun, 29 Aug 2010 21:55:32 +0000

Les 2 principaux frameworks de logging Java sont :

Apache Log4J, créée à l’origine par IBM
l’API officielle de Sun issue de la JSR 47, disponible depuis le JDK 1.4 dans le package java.util.logging (JUL)

Personnellement, je préfère Log4J car je trouve les noms des niveaux de Log4J (DEBUG, INFO, WARN, ERROR, FATAL) plus parlant que ceux de JUL (FINEST, FINER, FINE, INFO, WARNING, SEVERE).

Toutefois, il est recommandé d’utiliser plutôt des frameworks de meta-logging comme SLF4J ou JCL (Apache Commons Logging). En effet, ces frameworks fournissent une interface haut-niveau qui permet aux développeurs de choisir derrière cette façade l’implémentation de leur choix. Cela permet donc de changer de framework de logging sans retoucher au code.

Si vous utilisez par exemple SLF4J + Log4J, vous avez dans votre classpath les jar slf4j-api.jar et slf4j-log4j12.jar. Si vous souhaitez changer pour SLF4J + JUL, il suffit de remplacer slf4j-log4j12.jar par slf4j-jdk14.jar et le tour est joué. D’ailleurs, JCL ayant des problèmes de classloader avec certains serveurs d’application, je recommande SLF4J + Log4J.

Concernant le choix des niveaux de log, il est recommandé d’utiliser :

DEBUG pour remplacer les System.out.println()
INFO pour des faits importants comme des appels de web services ou des opérations d’entrées-sorties
ERROR dans le catch(){} des exceptions

Dans le fichier de conf (log4j.properties ou log4j.xml) où l’on précise le niveau minimal de logging, on choisira généralement DEBUG en environnement de développement, et INFO en production. Ainsi, les éventuels logger.debug() présents dans le code ne seront pas pris en compte en production.

De plus, pour gagner en performance, il est conseillé d’envelopper les logger.debug() dans des tests if(logger.isDebugEnabled()) si le contenu du logger.debug() est coûteux (concaténation de String par exemple). En effet, même si les logger.debug() ne sont pas pris en compte en production, cela évite que leur contenu soit exécuté.

SLF4J propose également une notation moins verbeuse permettant de réaliser un test avant d’effectuer une concaténation : les accolades.
Si l’on écrit : logger.debug(“La chaine {} est plus longue que {}.”, string1, string2)
la concaténation ne sera effectuée que si le mode DEBUG est activé.

N’hésitez pas à proposer d’autres bonnes pratiques dans les commentaires de cet article.

Comment redefinir correctement la methode equals() ? (Suite)

admin — Thu, 05 Aug 2010 18:38:51 +0000

Dans la 1ère partie de cet article, je faisais uniquement référence à des POJOs. Dans cette 2^nd partie, je vais rajouter une précision concernant les entités JPA.

Lorsqu’on veut redéfinir equals() sur des entités JPA, on pourrait penser qu’il suffit de comparer le champ Id de l’objet. Toutefois, ceci est une mauvaise pratique, comme l’explique cet article

En effet, si on utilise uniquement le champ contenant la clé primaire dans equals(), on prend un risque. Si l’on veut par exemple insérer plusieurs entités dans un Set, il ne faut pas oublier qu’un Set ne peut pas contenir plusieurs éléments égaux selon equals().

Or, si les entités n’ont pas encore été persistées, leur Id vaudra 0 ou null, et elles seront donc toutes égales selon equals(). Le Set ne contiendra donc finalement que la dernière entité insérée.

Pour éviter ce risque, il faut donc utiliser dans equals() un ou plusieurs champs uniques au sens métier. C’est pourquoi, dans notre exemple ci-dessous, on utilise la combinaison des champs “name” et “creationDate” pour créer les méthodes equals() et hashCode().

@Entity
@Table(name = "PERSON")
public class Person implements Serializable {

    @Id
    @Column(name = "ID")
    private Long id;

    @Column(name = "NAME")
    private String name;

    @Column(name = "CREATION_DATE")
    private Date creationDate;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Date getCreationDate() {
        return creationDate;
    }

    public void setCreationDate(Date creationDate) {
        this.creationDate = creationDate;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result
                + ((creationDate == null) ? 0 : creationDate.hashCode());
        result = prime * result + ((name == null) ? 0 : name.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        Person other = (Person) obj;
        if (creationDate == null) {
            if (other.creationDate != null)
                return false;
        } else if (!creationDate.equals(other.creationDate))
            return false;
        if (name == null) {
            if (other.name != null)
                return false;
        } else if (!name.equals(other.name))
            return false;
        return true;
    }
}

Hachage d’une String avec les algorithmes MD5 et SHA-1

admin — Wed, 04 Aug 2010 05:41:01 +0000

Dans une application web, les algorithmes de hachage sont souvent utilisés pour crypter les mots de passe servant à l’authentification des utilisateurs. En effet, pour des raisons évidentes de sécurité, lorsqu’un utilisateur crée un compte sur un site, il ne faut jamais sauvegarder son mot de passe en clair dans la base de données. Ainsi, à chaque fois que l’utilisateur se connecte, on calcule le hash de son mot de passe et on le compare à celui de la base.

La particularité des algorithmes de hachage par rapport aux algorithmes de chiffrement, c’est qu’ils ne marchent que dans un seul sens, c’est-à-dire qu’il est impossible de retrouver le message d’origine à partir du message crypté. L’inconvénient est que si un utilisateur a oublié son mot de passe, on est obligé de lui en envoyé un nouveau.

Les fonctions de hachage les plus connues sont MD5 et SHA-1. SHA-1 étant plus robuste que MD5, son utilisation est fortement recommandée. Plusieurs variantes de SHA-1 encore plus robustes existent comme SHA-256, SHA-384 et SHA-512.

Voyons maintenant comment générer le hash d’une String avec les différentes fonctions de hachage fournies par J2SE :

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

public class MyClass {

	public static void main(String[] args) {
		String password = "ilovejava";
		try {
			// imprime 6c4cc3353297ab9015c357a6cdd745bb
			System.out.println(encode(password, "MD2"));

			// imprime debe9e70b2474010c263d13425939760
			System.out.println(encode(password, "MD5"));

			// imprime 2c901d50beecce6d9fabc55594ce71b7e151248
			System.out.println(encode(password, "SHA-1"));

			// imprime 63c764af78e568b64bc3b4236a28f9ff993e6790ae611f7...
			System.out.println(encode(password, "SHA-256"));

			// imprime 1359d188568f1bb1cd94cd8d5f4fbf01f4bc2db20fd21fb...
			System.out.println(encode(password, "SHA-384"));

			// imprime a29675d8a48a48b16c8ad71ef67e9575311616590ed5e08...
			System.out.println(encode(password, "SHA-512"));

		} catch (NoSuchAlgorithmException e) {
			e.printStackTrace();
		}
	}

	private static String encode(String password, String algorithm)
			throws NoSuchAlgorithmException {
		byte[] hash = null;
		try {
			MessageDigest md = MessageDigest.getInstance(algorythm);
			hash = md.digest(password.getBytes());
		} catch (NoSuchAlgorithmException e) {
			e.printStackTrace();
		}
		StringBuilder sb = new StringBuilder();
		for (int i = 0; i < hash.length; ++i) {
			String hex = Integer.toHexString(hash[i]);
			if (hex.length() == 1) {
				sb.append(0);
				sb.append(hex.charAt(hex.length() - 1));
			} else {
				sb.append(hex.substring(hex.length() - 2));
			}
		}
		return sb.toString();
	}
}

Pourquoi Android n’utilise pas J2SE ?

admin — Mon, 28 Jun 2010 21:57:46 +0000

Tout commence en 2006, quand Sun décide de passer Java en open source (licence GPL). Il en résulte 2 projets proposant une implémentation gratuite et open source de Java : OpenJDK et Apache Harmony. OpenJDK, développé par Sun, est sous licence GPL, tandis que Apache Harmony est développé par l’ASF et proposé sous licence Apache.

Le souci, c’est que seul OpenJDK est aujourd’hui officiellement certifié en tant qu’implémentation de Java. Pour être certifiée, une implémentation de Java doit valider le JCK, une suite de tests conçues par Sun. Pourquoi Harmony n’a t-il jamais pu être certifié ? Parce que Sun a fait en sorte que cela n’arrive pas. Comment ? En rajoutant une clause à la licence du JCK qui restreint son champ d’utilisation (FOU en anglais). Cette clause interdit à un programme basé sur une implémentation certifiée de Java d’être exécuté sur un appareil mobile, ce que l’ASF n’a évidemment pas pu accepter.

Et pourquoi Sun veut-il à tout prix empêcher Harmony d’être certifié ? Parce que lorsque l’on est pas certifié, il est difficile d’être crédible et de convaincre certaines sociétés (les constructeurs de téléphones mobiles par exemple) que l’on est vraiment compatible avec Java. Sun a signé de gros contrats avec de nombreux construteurs (Blackberry, Nokia, etc.) pour que leurs téléphones embarquent J2ME, et il ne faut pas qu’Harmony vienne briser son monopole.

Cela a conduit à la création d’une machine virtuelle, Dalvik, basée sur Apache Harmony et donc non certifiée. Dalvik étant la VM sur laquelle repose Android, cela explique pourquoi l’OS de Google n’utilise pas J2SE. Toutefois, depuis le rachat de Sun, des rumeurs affirment qu’Oracle pourrait abandonner la fameuse clause qui fait débat. Cela permettrait à Dalvik d’obtenir la certification, et à Google d’être encore plus crédible avec Android.

La gestion des dates en Java – Partie 2

admin — Tue, 04 May 2010 08:00:13 +0000

Si vous n’êtes pas fan de la librairie Joda-Time pour la gestion des dates, sachez qu’une nouvelle librairie est disponible depuis hier : Date4j. Cette librairie vient combler quelques lacunes de Joda-Time comme le manque de précision des dates (nanosecondes) et l’immutabilité des classes. Date4j est aussi plus simple à utiliser que Joda-Time puisqu’elle n’utilise que 3 classes, alors que Joda-Time en utilise plus d’une centaine !

Toutefois, si vous préférez utiliser des standards, vous pouvez toujours attendre la sortie de la nouvelle API officielle décrite dans la JSR-310 que je vous avais présentée dans un précédent article.

DOM, SAX, mais aussi STAX et TRAX

admin — Sun, 25 Apr 2010 13:44:35 +0000

Vous connaissez probablement les APIs Java DOM et SAX qui sont très utilisées pour parser du XML. Mais avez-vous déjà entendu parler de STAX et TRAX ?

D’abord, un petit rappel sur DOM et SAX :

DOM est une des APIs de la spécification JAXP, dont l’implémentation de référence est développée par Sun et fait partie de J2SE (package org.w3c.dom). Pour parser un document XML, le parseur DOM va créer une représentation en mémoire de celui-ci sous forme d’arbre. Bien que cela consomme beaucoup de mémoire et que les traitements soient plus longs, DOM possède 2 avantages :
1. possibilité d’accéder à tout moment à n’importe quel noeud du document
2. possibilité d’effectuer n’importe quelle opération CRUD (lecture, écriture, modification, suppression de noeuds)
SAX fait également partie de la spécification JAXP. Cette API est donc aussi présente dans J2SE (package org.xml.sax). SAX propose un parseur événementiel. Cela signifie qu’il va parser le document XML de manière séquentielle, et qu’il va considérer l’ouverture et la fermeture des balises comme des événements. À chaque fois qu’un événement surgit, le programme qui parse le document aura la possibilité d’effectuer un traitement (on appelle ça le Push parsing). L’inconvénient de SAX est qu’il n’est limité qu’à la lecture d’un document XML (pas de CRUD). Toutefois, il est beaucoup plus rapide que DOM, et consomme très peu de mémoire. Sur des documents de taille importante, il donc fortement conseillé d’utiliser SAX à la place de DOM.

JDOM (bonus track) : Cette API n’est pas développée par Sun et ne fait pas partie de J2SE. Pour l’utiliser, il faudra donc télécharger le jar ici et l’ajouter à votre classpath. L’intérêt de JDOM est qu’il simplifie la manipulation des documents XML par rapport à DOM et SAX. Je recommande l’utilisation de JDOM, et je vous conseille de lire cet article qui explique les avantages de JDOM.

Venons-en maintenant à STAX et TRAX :

STAX est le nom de la spécification Java décrite dans la JSR 173. L’implémentation de référence de STAX développée par Sun s’appelle SJSXP. Elle est présente dans J2SE 6. L’API STAX est similaire à SAX car elle est également événementielle. Néanmoins, STAX est plus puissante que SAX, car elle permet (comme DOM) d’écrire dans un document XML. De plus, STAX est plus simple d’utilisation que SAX car elle fait du Pull parsing. Contrairement au Push parsing, le Pull parsing permet au programmeur de demander explicitement au parseur de générer les événements. Le programmeur a donc ici un rôle beaucoup moins passif, car il peut piloter le parsing comme il le veut.
Pour info, sachez que STAX est utilisé dans les projets CXF et Axis2, donc c’est du lourd.

TRAX : JAXP contient aussi une API appelée TrAX permettant la transformation de fichiers XML. TrAX utilise en effet un processeur XSLT pour transformer un fichier XML en un autre fichier XML ou HTML. En fait, TrAX ne fournit pas de processeur XSLT particulier. Il propose juste une interface Java commune à tous les processeur XSLT, ce qui permet d’utiliser n’importe quel processeur XSLT comme Xalan ou Saxon. Toutefois, depuis la version 1.4, le JDK contient déjà une version de Xalan. Si vous souhaitez utiliser une version plus récente de Xalan dans votre projet, il faudra placer les librairies xalan.jar, serializer.jar, xercesImpl.jar et xml-apis.jar dans le dossier %JAVA_HOME%\lib\endorsed.

Dans un prochain article, nous verrons qu’il est beaucoup simple d’utiliser l’API JAXB lorsque l’on veut créer des objets Java à partir d’un document XML.

Comment redéfinir correctement la méthode equals() ?

admin — Sun, 04 Apr 2010 16:04:31 +0000

Lorsque l’on crée un POJO, on peut avoir besoin de redéfinir la méthode equals() pour diverses raisons. Par exemple, si l’on veut insérer des objets dans une Collection et pouvoir utiliser la méthode contains(). Ou encore, parce que l’on veut utiliser ces objets comme clé dans une HashMap.

import java.util.ArrayList;
import java.util.List;

public class MyClass {

	public MyClass() {
		List list = new ArrayList();
		Person p1 = new Person("toto", 10);
		list.add(p1);

		Person p2 = new Person("toto", 10);

		// imprime false car equals() n'est pas redéfinie
		System.out.println(list.contains(p2));
	}

	private class Person {

		private String name;
		private int age;

		public Person(String name, int age) {
			this.name = name;
			this.age = age;
		}

		public String getName() {
			return name;
		}

		public void setName(String name) {
			this.name = name;
		}

		public int getAge() {
			return age;
		}

		public void setAge(int age) {
			this.age = age;
		}
	}

	public static void main(String s[]) {
		MyClass myClass = new MyClass();
	}
}

L’exemple ci-dessus montre que la méthode contains() ne fonctionne pas comme on le voudrais car la classe Person ne redéfinit pas equals(). Au lieu de comparer un à un les attributs de la classe, equals() va par défaut comparer les références.

Voici la méthode equals() qui permet d’obtenir le résultat attendu :

@Override
public boolean equals(Object obj) {
	if (this == obj)
		return true;
	if (obj == null)
		return false;
	if (getClass() != obj.getClass())
		return false;
	Person other = (Person) obj;
	if (age != other.age)
		return false;
	if (name == null) {
		if (other.name != null)
			return false;
	} else if (!name.equals(other.name))
		return false;
	return true;
}

Toutefois, lorsque l’on redéfinit equals(), il y a une règle très importante à respecter :
Si 2 objets sont égaux selon la méthode equals(), alors ils doivent avoir le même hashcode.
Or, dans notre exemple, 2 objets Person égaux selon equals() n’ont pas le même hashcode :

System.out.println(p1.hashCode()); //imprime 1671711
System.out.println(p2.hashCode()); //imprime 11394033

C’est pourquoi il faut toujours redéfinir la méthode hashCode() lorsque l’on redéfinit la méthode equals(). Voici la méthode hashCode() qui correspond à notre exemple :

@Override
public int hashCode() {
	final int prime = 31;
	int result = 1;
	result = prime * result + age;
	result = prime * result + ((name == null) ? 0 : name.hashCode());
	return result;
}

Vous vous demandez peut-être pourquoi cette règle est importante ? Parce que la méthode hashCode() permet d’améliorer grandement les performances des structures de données basées sur des hash comme les Hashtable, les HashMap, et les HashSet. Pour comprendre pourquoi, il faut savoir comment fonctionne une HashMap.

Une HashMap contient en interne un tableau. Et en général, lorsqu’on veut accéder à un élément d’un tableau, on doit savoir à quelle position se situe l’élément dans le tableau. Cette position est toujours un nombre entier dont la valeur est inférieure à la taille du tableau. Lorsqu’on insére une paire de dans une HashMap, elle doit donc générer un entier unique qui correspondra à la position de la value dans son tableau interne. Pour cela, elle utilise la méthode hashCode() sur l’objet key. Ainsi, lorsqu’on voudra récupérer un élément de la HashMap avec get(Object key), la HashMap va une nouvelle fois utilise hashCode() sur l’objet key pour générer l’entier correspondant à la position de la value dans son tableau interne.

Comme vous vous en doutez, ce mécanisme de mapping est beaucoup plus efficace que de comparer une par une toutes les key de la map pour récupérer la value associée. Et pour que ce mécanisme reste efficace, il faut à tout prix éviter les collisions, qui interviennent lorsque certains objets d’une map possèdent le même hashcode.

Pour terminer cet article, précisons qu’il faut être très vigilant lorsque l’on crée des POJO mutables. Par opposition à immutable, un objet mutable est un objet dont la valeur des attributs peut être modifiée. Ainsi, si un POJO contient des setters, il est forcément mutable. Dans notre exemple, on pourrait alors se retrouver dans une situation comme celle-ci :

List list = new ArrayList();
Person p1 = new Person("toto", 10);
Person p2 = new Person("toto", 10);
list.add(p1);
System.out.println(list.contains(p2)); //imprime true

p1.setName("tata");
System.out.println(list.contains(p2)); //imprime false

Lorsque l’on utilise la méthode contains(), et donc equals(), sur des objets mutables, il faut faire attention à ne pas modifier l’état des objets une fois qu’ils ont été insérés dans une structure de données.

Configurer Eclipse avant de coder

admin — Sat, 03 Apr 2010 18:52:34 +0000

La première chose à faire lorsqu’on commence un nouveau projet Java, c’est de configurer son IDE. Voici les 5 étapes de configuration par lesquelles je passe avant de commencer à coder sur Eclipse.

Encodage des fichiers

Pour éviter tout problème d’encodage (sur les accents par exemple), il vaut mieux utiliser le charset UTF-8 dans votre workspace. En effet, sachez que le Cp1252 est réservé aux machines Windows et que l’ISO-8859-1 ne couvre que les langues d’Europe occidentale. Donc, si votre appli doit supporter Linux et qu’elle peut contenir des caractères arabes ou asiatiques, vous êtes morts sans UTF-8.

Choisir le bon compilateur

Eclipse compile les classes en conformité avec une version spécifique du JDK (par défaut 1.6). Si votre serveur de prod utilise une JRE 5, configurez votre compilateur en version 1.5.

Formater l’affichage du code

Vous pouvez indiquer à Eclipse comment afficher le code Java dans l’éditeur (taille de l’indentation, position des accolades, nombre maximum de caractères par ligne, etc.). Vous pouvez choisir un Formatter existant, ou créer votre propre Formatter et l’exporter en xml. Ainsi, lorsque vous ferez Ctrl + Shift + F, Eclipse formatera votre code en respectant votre Formatter.
C’est un réglage très utile lorsque l’on développe à plusieurs sur un projet et que l’on veut s’assurer que l’affichage sera le même quel que soit l’auteur de la classe.

Actions effectuées à la sauvegarde (Save Actions)

À chaque fois que vous sauvez votre travail, demandez à Eclipse de formater l’affichage de votre code en respectant les règles du Formatter, et demandez une réorganisation des imports. Ainsi, à chaque fois que vous ferez Ctrl + S, Eclipse fera aussi automatiquement un Ctrl + Shift + F et un Ctrl + Shift + O. Ce paramétrage me fait vraiment gagner un temps fou.

Plug-in Maven2

Après avoir installé le plug-in Maven2 sur Eclipse, vous verrez peut-être l’erreur suivante dans la console : Eclipse is running in a JRE, but a JDK is required. Some Maven plugins may not work… Cela signifie qu’il faut dire à Eclipse d’utiliser le JDK et pas la JRE fournie avec Eclipse. Pour cela, il faut rajouter les lignes suivantes dans le fichier eclipse.ini :

-vm
C:\Java\JDK\1.5\bin

La 2ème ligne correspond évidemment à l’emplacement du JDK. Pour plus d’infos sur le fichier eclipse.ini et l’option -vm, c’est par ici.

Si vous connaissez d’autres paramètres de configuration intéressants, n’hésitez pas à les partager dans les commentaires.

La gestion des dates en Java

admin — Sun, 21 Mar 2010 07:49:38 +0000

Il faut reconnaître que dans le JDK actuel, la gestion des dates est pénibles pour nous développeurs, car les APIs java.util.Date et java.util.Calendar sont très limitées.

Ainsi, bien souvent, on crée sa propre classe DateUtil qui peut contenir, par exemple, une méthode DateToString() utilisant SimpleDateFormat.

Sans oublier certaines curiosités, comme le fait que les mois commencent à 0 et les jours à 1. Ou encore le fait qu’il ne faut pas oublier de retirer 1900 pour l’année.

Pour remédier à ce problème, une nouvelle API est en préparation : elle est décrite dans la JSR-310 et sa javadoc est déjà consultable. Cette API pourrait être inclue dans le JDK7.

Pour ceux d’entre vous qui utilisent la library Joda-Time pour gérer leurs dates, sachez que cette nouvelle API a été inspirée par Joda-Time, comme l’explique le créateur de la JSR-310 sur son blog.

Enfin, en bonus track, je vous présente la library PrettyTime. Elle permet d’écrire des dates dans un format facilement lisibles par les humains, comme on peut en voir sur des sites comme Facebook ou Twitter (exemples : “right now”, “2 days ago”, “3 months from now”). Si vous voulez l’utiliser en français, pas d’inquiétude, PrettyTime supporte l’internationalisation grâce aux resource bundles.

Framework Collections : la méthode subList()

admin — Sun, 07 Mar 2010 17:41:54 +0000

La méthode subList() de java.util.List doit être utilisée avec précaution, car elle ne fait pas forcément de qu’on attend d’elle…

List liste1 = new ArrayList();
for (int i = 0; i < 10; i++) {
	liste1.add(new Integer(i));
}
// liste2 contient les chiffres de 0 à 5
List liste2 = list1.subList(0, 5);

// On retire le 1er élément de liste1
liste1.remove(0);

//Cette ligne provoque une java.util.ConcurrentModificationException
System.out.println(liste2.size());

Toute modification de liste1 empêche l’accès à liste2. Par contre, toute modification apportée à liste2 sera automatiquement répercutée sur liste1.
“C’est quoi ce bordel ?” me direz vous. Je vous répondrai que la réponse est dans la javadoc : subList retourne une “vue” de la portion demandée de la liste. liste2 n’est donc pas une liste à part entière, elle pointe simplement vers liste1, comme on peut le voir dans le code d’AbstractList.java :

public List subList(int fromIndex, int toIndex) {
        return new SubList(this, fromIndex, toIndex);
}

On voit bien que l’objet SubList conserve une référence à this.

Pour pouvoir accéder librement à une sous-liste tout en gardant le pouvoir de modifier la liste originale, il faut créer la sous-liste comme ceci :

List liste2 = new ArrayList(list1.subList(0,5));

Conlusion : quand vous voulez utiliser une méthode obscure, ne faites aucune supposition, lisez la doc.

Google Collections VS Apache Commons Collections

admin — Tue, 02 Feb 2010 22:23:33 +0000

Le framework Collections apparu en 1998 avec le JDK 1.2 souffre aujourd’hui encore de nombreuses lacunes (absence de FixedSizeList, LazyList, OrderedMap, etc.) qui peuvent être comblées soit par l’utilisation de la librairie Commons Collections créée par Apache, soit par l’utilisation de la librairie Google Collections. Laquelle des deux vaut-il mieux utiliser ? C’est ce nous allons voir dans ce rapide comparatif.

Ce comparatif est certes très succinct, mais il met en avant le principal : support et modernité. Alors que Commons Collections est à l’abandon puisqu’il n’a pas été mis à jour par Apache depuis presque 2 ans, la librairie Google Collections vient tout juste de sortir en version finale 1.0. Le support aux utilisateurs est donc probablement meilleur pour Google Collections. Et puis, la non-adoption des Generics par Commons Collections montre à quelle point cette librairie est en retard sur son concurrent.

Voici maintenant un exemple d’utilisation de Google Collections avec la ArrayListMultimap. Une Multimap est une Map qui permet d’associer plusieurs valeurs à une clé.

Avec une Map classique :

Map> annuaire = new HashMap>();
List numeros = new ArrayList();
numeros.add("0147484950");
numeros.add("0612131415");
annuaire.put("Jean Dupond", numeros);

Avec une Multimap, c’est beaucoup plus simple :

Multimap  annuaire = ArrayListMultimap.create();
annuaire.put("Jean Dupond", "0147484950");
annuaire.put("Jean Dupond", "0612131415");

Enfin, sachez que Google Collections va bientôt faire partie de Google Guava. Le projet Google Collections va donc purement et simplement disparaître au profit ce nouveau projet dont voici les noms de package :

com.google.common.annotations (déjà présent dans Google Collections)
com.google.common.base (déjà présent dans Google Collections)
com.google.common.collect (déjà présent dans Google Collections)
com.google.common.io
com.google.common.net
com.google.common.primitives
com.google.common.util.concurrent

Java est-il mort ?

admin — Mon, 16 Nov 2009 10:00:26 +0000

C’est la question que l’on peut se poser en lisant cet article paru récemment sur un blog américain. Le rachat de Sun par Oracle est-il à l’origine d’un déclin de Java ou y’a t-il d’autres raisons ? Et si Java était bien en train de mourir, vers quel langage devrions-nous nous tourner ?

Au même titre que la base de données open source MySQL, il est peu probable qu’Oracle stoppe le développement de la JVM et du langage Java. En tout cas, pas à court terme, tant le nombre d’applications (web, desktop, mobiles) basées sur Java est important.

De plus, Java est tout de même, après Python, le seul langage sur lequel Google a misé pour son Google App Engine. Même remarque concernant Android : Google a choisi Java comme principal langage de développement.

Enfin, le nombre d’offres d’emplois concernant Java/J2EE est toujours aussi élevé. Une simple recherche sur Monster le confirme.

Néanmoins, il est vrai que par rapport à PHP, cela a toujours été assez pénible de développer des applications web en Java/J2EE, malgré la parution de nombreux frameworks comme Struts2 et Hibernate. Alors que le Time to market se doit d’être de plus en plus court, l’utilisation de Java/J2EE pour le développement web est donc peut-être en danger.
Cela explique probablement l’émergence de Groovy, Scala et Clojure, 3 langages utilisant la JVM, mais qui ont la réputation de réduire les temps de développement.

Si dans quelques années la roue devait donc tourner, les amoureux de Java pourraient alors se consoler avec Groovy/Grails, voire se tourner vers la plateforme .NET de Microsoft, puisque la syntaxe du C# est très proche de celle de Java.

Client Java pour consommer un Web Service WS-* – Partie 1

admin — Sun, 13 Sep 2009 16:40:16 +0000

Pour commmencer cette série d’articles sur le développement de web services WS-*, le mieux est de coder un client sans utiliser de frameworks comme Axis ou CXF. Cela permet de comprendre ce qui se passe sous le capot et pourquoi ces frameworks nous facilitent la tâche.

Les Web Service WS-* reposent sur le protocole SOAP. SOAP définit la structure des messages échangés entre le client et le serveur. Ces messages sont le plus souvent transportés à l’aide du protocole HTTP. Un message SOAP n’est rien d’autre qu’un document XML contenant une série de balises spécifiques qu’on appelle enveloppe SOAP.

Voici le code d’un client qui consomme un web service exposé par le site w3school.com. Ce web service convertit une température Celcius en Fahrenheit. On va ainsi envoyer au serveur un message SOAP contenant 30°C, et il retournera un message SOAP contenant 86°F.

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

public class Client {

	public static void main(String[] args) {

		String temperature = "30";
		int port = 80;
		String host = "www.w3schools.com";
		String method = "POST";
		String url =  "/webservices/tempconvert.asmx";
		Socket s = null;
		InputStreamReader httpIn = null;
		PrintWriter httpOut = null;
		String request = null;
		StringBuilder response = new StringBuilder();

		try {
			//Ouverture de la socket
			s = new Socket(host, port);

			httpIn = new InputStreamReader(s.getInputStream());

			httpOut = new PrintWriter(s.getOutputStream(), true);

		} catch (IOException e) {
			e.printStackTrace();
		}

		//Construction de la requête
		request = method + " " + url + " HTTP/1.1n";
		request += "Host: www.w3schools.comn";
		request += "Content-Type: text/xml; charset=utf-8n";
		request += "SOAPAction: http://tempuri.org/CelsiusToFahrenheitn";

		StringBuilder soapMessage = new StringBuilder();
		soapMessage.append("<?xml version="1.0" encoding="utf-8"?>");
		soapMessage.append("<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">");
		soapMessage.append("<soap:Body>");
		soapMessage.append("<CelsiusToFahrenheit xmlns="http://tempuri.org/">");
		soapMessage.append("<Celsius>"+ temperature +"</Celsius>");
		soapMessage.append("</CelsiusToFahrenheit>");
		soapMessage.append("</soap:Body>");
		soapMessage.append("</soap:Envelope>");
		request += "Content-Length: " + soapMessage.length() + "nn";
		request += soapMessage.toString();

		//Envoie de la requête
		httpOut.println(request);

		try {
			int i = 0;
			while ((i = httpIn.read()) != 0) {
				response.append((char)i);
				if(response.toString().indexOf("</soap:Envelope>") != -1) {
					break;
				}
			}
		} catch (IOException e) {
			e.printStackTrace();
		}

		//On parse manuellement l'enveloppe SOAP
		String startTag = "<CelsiusToFahrenheitResult>";
		String endTag = "</CelsiusToFahrenheitResult>";
		int start = response.toString().indexOf(startTag);
		int end = response.toString().indexOf(endTag);

		temperature = response.toString().substring(start+startTag.length(), end);
		System.out.println(temperature); // imprime 86

		//Fermeture de la socket
		try {
			s.close();
		} catch (IOException e) {
			e.printStackTrace();
		}

		System.exit(0);
	}
}

On vient de voir qu’il est très pénible de coder un client web service sans framework, puisqu’il faut soit-même effectuer des tâches bas niveau comme l’ouverture/fermeture de socket, la construction de l’enveloppe SOAP et le parsing de la réponse. Même si on aurait pu utiliser l’API JAXP pour parser la réponse SOAP plutôt que d’utiliser des indexOf() et des substring(), le mieux est quand même d’obtenir la réponse sous forme de POJO.

Des frameworks comme Axis et CXF possèdent des APIs qui offrent un niveau d’abstraction élevé permettant de masquer les détails de l’utilisation de SOAP : les enveloppes SOAP sont générées automatiquement et les données retournées par le serveur sont automatiquement converties en objets Java. Il ne reste plus qu’à récupérer les données en appellant les getters de l’objet.

Quelle est la différence entre une URL et une URI ?

admin — Sat, 05 Sep 2009 08:10:26 +0000

Une URI est utilisée pour identifier une ressource. Les URL et les URN sont chacun un sous-ensemble des URI.

Les URL servent à localiser une ressource. Elles indiquent donc le protocole permettant d’accéder à la ressource.

Exemples :

http://www.microsoft.com

ftp://ftp.kernel.org
mailto:javatropbien@free.fr
Les URN servent juste à nommer une ressource. Aucun protocole d’accès n’est précisé.

Exemples :

urn:isbn:0451450523
urn:ietf:rfc:2141

Le schéma ci-dessous résume tout : une URL est une URI mais une URI n’est pas forcément une URL.

Mais au fait, c’est quoi une ressource ? D’après Roy Fielding :

Any information that can be named can be a resource: a document or image, a temporal service, a collection of other resources, a non-virtual object, and so on.

C’est une définition très vague. Même les objets non-virtuels (êtres humains, animaux, etc.) sont aussi des ressources du moment qu’ils peuvent être nommés !

En tout cas, ce qu’il faut savoir c’est qu’une URI n’identifie qu’une seule et unique ressource, mais que cette ressource peut avoir différentes représentations. Voici un exemple d’URI qui permet de comprendre la notion de représentation :

L’URI http://www.w3.org/Icons/w3c_home n’identifie qu’une seule ressource : l’image w3c_home. Vous avez sûrement remarqué que l’URI ne contient pas l’extension du fichier (.jpg, .png, etc.). En effet, le serveur web va déterminer lui-même quelle représentation de l’image w3c_home il va renvoyé au client. Ce mécanisme s’appelle la négotiation de contenu. En général, le serveur va choisir la représentation à renvoyer en fonction du User Agent du client. Ainsi, dans cet exemple, le serveur renvoie un .png si le browser du client est Firefox, et renvoie un .gif si le browser est IE.

La négotiation de contenu est également utilisée par les serveurs web pour retourner aux clients des pages web en fonction de la langue préférée du client. Ainsi, si la requête HTTP contient Accept-Language: fr; q=1.0, en; q=0.5, le client indique qu’il supporte le français et l’anglais et qu’il préfère le français. Le serveur va donc retourner la représentation de la ressource dans la langue demandée par le client.

OK, mais quel est le rapport avec Java ???
J’avais envie d’introduire les notions d’URI et représentation, qui sont à la base des architectures REST, avant de faire un article sur la construction de web services RESTful en Java.

Ouvrir une console DOS depuis le menu contextuel

admin — Fri, 04 Sep 2009 10:00:16 +0000

Ceux qui utilisent une console Dos pour lancer leur serveur Tomcat ou exécuter une tâche Ant savent qu’il est pénible d’avoir à taper des commandes cd pour se placer dans le bon répertoire, puisque par défaut, la console s’ouvre sur C:\Utilisateurs\%user%.

En effectuant la manip suivante, vous aller rajouter une option permettant de lancer une console DOS depuis le menu contextuel de Windows. Ainsi, lors d’un clique-droit sur un dossier, vous aurez la possibilité de lancer une commande qui s’ouvrira directement au niveau de ce même dossier.

Tapez Win + R pour ouvrir une fenêtre “Exécuter…”
Tapez regedit puis cliquer sur OK
Dans l’arbre de gauche, naviguez jusqu’au noeud HKEY_CLASSES_ROOT/Folder/shell.
Faites un clique-droit sur le dossier shell et choisissez Nouveau > Clé.
Cela crée un dossier dans shell que vous renommerez “Cmd”.
Faites un clique-droit sur le dossier “Cmd” et choisissez Nouveau > Clé.
Cela crée un dossier que vous renommerez “Command”.
Cliquez sur le dossier “Command” et double-cliquez sur l’élément “(par défaut)”.
Taper “Cmd” puis cliquez sur OK.

C’est terminé !

Comment crypter un texte avec l’algorithme RC4 en Java ?

admin — Thu, 27 Aug 2009 10:00:39 +0000

Les APIs Java Security couvrent un large éventail de domaines : authentification, PKI, cryptographie, etc. Cet article aborde le domaine de la cryptographie, plus précisément la cryptographie symétrique avec chiffrement par flot.

Il existe en effet 2 types de cryptographie : la cryptographie asymétrique et la cryptographie symétrique. En cryptographie asymétrique, on utilise une paire de clés (publique et privée) pour chiffrer les données, alors qu’en cryptographie symétrique on utilise une unique clé secrète. Je ne vais pas m’étendre plus sur la cryptographie asymétrique car ce n’est pas le sujet de cet article.

En cryptographie symétrique, il existe 2 types de chiffrement : le chiffrement par flot et le chiffrement par bloc. La différence entre les 2 est la suivante :

lors d’un chiffrement par bloc, les données sont découpées en blocs de taille fixe (par exemple 64 bits) avant d’être cryptées.

lors d’un chiffrement par flot, les données ne sont pas découpées, elles sont cryptés octet par octet.

À part ça, le principe est le même puisqu’il repose sur une clé secrète et l’opérateur logique XOR (OU exclusif). Il suffit donc d’effectuer un XOR entre la donnée (octet ou bloc) et la clé secrète pour obtenir la donnée chiffrée.

Après tout ce bla-bla, voyons comment utiliser les APIs Java Security pour crypter un texte avec l’algorithme de chiffrement à flot RC4. Ce code contient 2 méthodes permettant de crypté et décrypter une String “javatropbien”, la clé secrète étant la String “ilovejava”.

import java.security.*;
import javax.crypto.*;
import javax.crypto.spec.SecretKeySpec;

public class StreamCipher
{
	private final static String cleSecrete = "ilovejava";
	private final static String algorythme = "RC4";
	private final static Key cle = new SecretKeySpec(cleSecrete.getBytes(), algorythme);

	public static void main(String[] args)
	{
		String texteCrypte = encrypte("javatropbien");
		System.out.println(texteCrypte); //imprime "Äj•y§„ :Õ°Äó"

		String texteEnClair = decrypte(texteCrypte);
		System.out.println(texteEnClair); //imprime "javatropbien"
	}

	private static String encrypte(String texteEnClair)
	{
		Cipher cipher = null;
		try
		{
			cipher = Cipher.getInstance(algorythme);
		}
		catch (NoSuchAlgorithmException e) {e.printStackTrace();}
		catch (NoSuchPaddingException e) {e.printStackTrace();}

		try
		{
			cipher.init(Cipher.ENCRYPT_MODE, cle);
		}
		catch (InvalidKeyException e) {e.printStackTrace();}

		byte[] texteCrypte = null;
		try
		{
			texteCrypte = cipher.doFinal(texteEnClair.getBytes());
		}
		catch (IllegalBlockSizeException e) {e.printStackTrace();}
		catch (BadPaddingException e) {e.printStackTrace();}

		return new String(texteCrypte);
	}

	private static String decrypte(String texteCrypte)
	{
		Cipher cipher = null;
		try
		{
			cipher = Cipher.getInstance(algorythme);
		}
		catch (NoSuchAlgorithmException e) {e.printStackTrace();}
		catch (NoSuchPaddingException e) {e.printStackTrace();}

		try
		{
			cipher.init(Cipher.DECRYPT_MODE, cle);
		}
		catch (InvalidKeyException e) {e.printStackTrace();}

		byte[] texteEnClair = null;

		try
		{
			texteEnClair = cipher.doFinal(texteCrypte.getBytes());
		}
		catch (IllegalBlockSizeException e)	{e.printStackTrace();}
		catch (BadPaddingException e) {e.printStackTrace();}

		return new String(texteEnClair);
	}
}

Je précise qu’il faut que la taille de votre clé secrète soit comprise entre 5 et 16 caractères, sinon vous aurez droit à une belle java.security.InvalidKeyException. Pour contourner cette restriction, vous devez télécharger les deux jar contenus dans le zip Java Cryptography Extension Unlimited Strength Jurisdiction Policy Files et les copier dans le dossier jre6\lib\security de votre PC (sous Windows).

Pourquoi Java est-il lent ?

admin — Wed, 27 May 2009 10:15:14 +0000

Je viens de tomber sur un article très intéressant dans lequel un programmeur serbe explique pourquoi Java sera toujours plus lent que C++. On y apprend par exemple qu’un programme codé en Java utilise environ 2 fois plus de mémoire qu’un programme équivalent codé en C++. Lire l’article (en anglais).

Différences de performances entre ArrayList, LinkedList et Vector

admin — Tue, 26 May 2009 10:00:52 +0000

Faut-il plutôt utiliser ArrayList, LinkedList ou Vector ? Voici une question que tout développeur Java a dû se poser à un moment donné. Nous allons voir que cela dépend des opérations que l’on souhaite effectuer sur ces collections.

ArrayList et Vector
Les classes ArrayList et Vector implémentent toutes les deux l’interface RandomAccess, ce qui signifie que l’accès à un élément aléatoire de la liste par la méthode get() est très rapide. Par contre, les performances concernant l’ajout et la suppression d’un élément vont dépendre de la position cet élément dans la liste. Plus l’élément est loin dans la liste, plus l’ajout/suppression sera rapide.
D’accord, mais quelle est la différence entre ArrayList et Vector ? C’est comme pour StringBuilder/StringBuffer ou Hashtable/HashMap. Vector est synchronisée et donc thread-safe alors qu’ArrayList ne l’est pas. Par conséquent, Vector est plus lent qu’ArrayList et ne doit être utilisé qu’en environnement multithreadé.
LinkedList
Contrairement à ArrayList, LinkedList n’implémente pas RandomAccess, elle est donc plus lente lors de l’accès à un élément aléatoire de la liste. Par contre, LinkedList est plus efficace qu’ArrayList concernant la suppression d’un élément car le temps nécessaire pour effectuer la suppression reste toujours constant quelle que soit la position de l’élément dans la liste.

Optimiser la concaténation de chaines de caractères en Java

admin — Fri, 22 May 2009 09:30:40 +0000

Il existe 4 façons de concaténer des chaines de caractères : l’opérateur “+”, la méthode String.concat(), et les classes StringBuffer et StringBuilder. Mais avant de les comparer, il faut comprendre la base du problème : l’immutabilité de la classe String. String étant une classe immutable, une variable de type String ne peut pas être modifiée. Lorsque l’on croit modifier une String, en vérité, on crée un nouvelle String à partir de l’ancienne qui sera soumise au garbage collector.

Commençons notre comparatif en examinant l’implémentation de la méthode String.concat() :

public String concat(String str)
{
	int otherLen = str.length();
	if (otherLen == 0)
	{
	    return this;
	}
	char buf[] = new char[count + otherLen];
	getChars(0, count, buf, 0);
	str.getChars(0, otherLen, buf, count);
	return new String(0, count + otherLen, buf);
}

Exemple d’utilisation :

String s1 = "s1";
String s2 = "s2";
String s3 = "s3";
String s4 = s1.concat(s2).concat(s3);

Comme vous pouvez le voir, puisque String est immutable, String.concat() utilise en interne un tableau de char buf[]. Cela signifie que si l’on concatène n Strings, on va créer en mémoire n-1 tableaux intermédiaires. Pas très efficace…

Passons maintenant à l’opérateur “+”.
Exemple d’utilisation :

String s1 = "s1";
String s2 = "s2";
s1 += s2;

Pour savoir ce qui se passe en interne, observons le bytecode désassemblé obtenu grâce à la commande javap:
0: ldc #16; //String s1 2: astore_1 3: ldc #18; //String s2 5: astore_2 6: new #20; //class java/lang/StringBuilder 9: dup 10: aload_1 11: invokestatic #22; //Method java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String; 14: invokespecial #28; //Method java/lang/StringBuilder."":(Ljava/lang/String;)V 17: aload_2 18: invokevirtual #31; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 21: invokevirtual #35; //Method java/lang/StringBuilder.toString:()Ljava/lang/String; 24: astore_1 25: return
Comme vous pouvez le constater, l’opérateur “+” utilise en interne la classe StringBuilder. Dans cette exemple, 2 objets intermédiaires ont été créés : le StringBuilder et la String contenant le résultat de StringBuilder.toString(). Cette concaténation est déjà plus efficace que String.concat() car peu importe le nombre de String à concaténer, on aura toujours seulement 2 objets intermédiaires.

Voyons maintenant comment s’utilise la classe StringBuilder :

String s1 = "s1";
String s2 = "s2";
StringBuilder sb = new StringBuilder(s1);
sb.append(s2);

Après désassemblage, on obtient :
0: ldc #16; //String s1 2: astore_1 3: ldc #18; //String s2 5: astore_2 6: new #20; //class java/lang/StringBuilder 9: dup 10: aload_1 11: invokespecial #22; //Method java/lang/StringBuilder."":(Ljava/lang/String;)V 14: astore_3 15: aload_3 16: aload_2 17: invokevirtual #25; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 20: pop 21: return
On voit tout de suite que cette méthode est plus efficace la précédente puisque d’une part, on effectue 21 opérations au lieu de 25, et d’autre part, on n’a pas besoin d’un objet String intermédiaire pour stocker le résultat de StringBuilder.toString().

Et StringBuffer dans tout ça ? L’unique différence entre les classes StringBuffer et StringBuilder est que StringBuffer est thread-safe, donc plus lente. Ainsi, dans une application “single thread” (c’est-à-dire la plupart du temps), il faut toujours utiliser StringBuilder.

Pour conclure, voici mon opinion sur le sujet : lorsque que je veux concaténer un petit nombre de chaines, j’utilise l’opérateur “+” parce que je trouve que le code est plus lisible. Par contre, lorsque la concaténation a lieu à l’intérieur d’une boucle, je préfère améliorer les performances au dépend de la lisibilité en utilisant StringBuilder.

La comparaison de chaînes de caractères en Java (Suite)

admin — Mon, 11 May 2009 10:00:29 +0000

Dans un précédent article, j’avais dit qu’il faut toujours utiliser la méthode equals() et non l’opérateur == pour comparer des chaines de caractères en Java.
Je viens de me rendre compte que je n’ai pas été assez précis. Même si à l’époque, je parlais de la méthode equals() de la classe String, la meilleure solution est en fait d’utiliser la méthode equals() de la classe StringUtils appartenant à la librairie Apache Commons Lang. Il s’agit d’une librairie externe (qui n’appartient pas à l’API J2SE) et que vous pouvez télécharger ici.

Contrairement à la méthode equals() de la classe String, la méthode equals() de la classe StringUtils gère les chaines de valeur null sans lever d’exceptions. En effet, comme String.equals() est une méthode d’instance, si elle est invoquée par une String null, cela provoquera un NullPointerException. StringUtils.equals() étant une méthode de classe (static), elle pourra toujours être invoquée puisque l’élément StringUtils ne sera jamais null.

Voici un morceau de code pour mieux comprendre :

//Import de la librairie externe
import org.apache.commons.lang.StringUtils;

public class MyClass {

	public static void main(String[] args) {

		//Exemple 1
		String s1 = null;
		String s2 = "toto";
		if(s1.equals(s2)) //génère une exception
			System.out.println("egal");
		else
			System.out.println("pas egal");

		//Exemple 2
		String s3 = "toto";
		String s4 = null;
		if(s3.equals(s4)) //ne génère pas d'exception
			System.out.println("egal");
		else
			System.out.println("pas egal");

		//Exemple 3
		String s5 = null;
		String s6 = null;
		if(StringUtils.equals(s5,s6)) //ne génère jamais d'exception
			System.out.println("egal");
		else
			System.out.println("pas egal");
	}
}

Remarque : on pourrait alors se demander pourquoi les développeurs de Sun n’ont pas codé la méthode String.equals() en static ?
C’est parce qu’elle redéfinie la méthode Object.equals() et qu’une méthode de classe ne pas redéfinir une méthode d’instance. Par conséquent, Object.equals() et String.equals() possède la même signature et String.equals() prend donc en argument une variable de type Object, ce qui n’est pas le cas de StringUtils.equals().

Certains penseront peut-être que cela ne vaut pas le coup d’utiliser une librairie externe juste pour ça. Il est vrai que si, en théorie, vous vous arrangez pour toujours vous retrouver dans le cas illustré par l’exemple 2, et que vous êtes certains que s3 ne sera jamais null, alors String.equals() est suffisant. Mais comme dans la pratique c’est rarement le cas, il faut toujours utiliser StringUtils.equals().
De plus, StringUtils possède pleins d’autres méthode très puissantes. Personnellement, j’utilise beaucoup la méthode isNotBlank() car elle permet de vérifier qu’une chaine n’est ni vide, ni null, ni uniquement constituée d’espaces. Elle est donc idéale pour vérifier coté serveur (servlet, ActionForm Struts, etc.) que les champs obligatoires d’un formulaire ne sont pas vides.

La copie défensive en Java

admin — Tue, 24 Feb 2009 10:13:30 +0000

La copie défensive est une façon de programmer un objet mutable (qui peut être modifié après sa création) de façon à empêcher que celui ne soit manipulé d’une manière inappropriée. La plupart du temps, vos objets ne doivent pouvoir être modifiés que par des setters. Or, si vous n’utilisez pas de copies défensives, il est possible que vous rencontriez des bugs comme le montre l’exemple ci-dessous :

public class Cercle
{
	private int[] centre;
	private int rayon;

	public Cercle(int[] centre, int rayon)
	{
		this.centre = centre;
		this.rayon = rayon;
	}

	public String toString()
	{
		return "centre : (" + centre[0] + ","
               + centre[1] + ") et rayon : " + rayon;
	}

	public int[] getCentre()
	{
		return centre;
	}

	public void setCentre(int[] centre)
	{
		this.centre = centre;
	}

	public int getRayon()
	{
		return rayon;
	}

	public void setRayon(int rayon)
	{
		this.rayon = rayon;
	}
}

public class MaClasse
{
	public static void main(String[] args)
	{
		int centre[] = {1,2};
		int rayon = 3;

		Cercle cercle = new Cercle(centre, rayon);
		System.out.println(cercle.toString());
        // imprime "centre : (1,2) et rayon : 3"

		centre[0] = 5;
		centre[1] = 6;
		rayon = 10;

		System.out.println(cercle.toString());
        // imprime "centre : (5,6) et rayon : 3"
	}
}

Eh oui ! Vous n’êtes pas content car les coordonnées du centre de votre cercle ont été modifiées sans utiliser la méthode setCentre(). Heureusement le rayon de votre cercle, lui, n’a pas été modifié.
Pourquoi ? Parce que rayon est de type primitif et que centre est de type référence. Et si vous vous rappelez de l’article sur les types de variables, comme les références en Java sont passées par valeur, les modifications apportées au tableau original se répercutent sur le tableau du Cercle car ce ceux sont 2 références qui pointent vers le même objet.
Il faut donc utiliser une copie défensive dans le constructeur pour protéger votre Cercle :

public Cercle(int[] centre, int rayon)
{
	//On crée un autre tableau à partir du tableau passé en paramètre
	int autreCentre[] = {centre[0], centre[1]};
	this.centre = autreCentre;
	this.rayon = rayon;
}

et le bug est corrigé :

public static void main(String[] args)
{
	int centre[] = {1,2};
	int rayon = 3;

	Cercle cercle = new Cercle(centre, rayon);
	System.out.println(cercle.toString());
    // imprime "centre : (1,2) et rayon : 3"

	centre[0] = 5;
	centre[1] = 6;
	rayon = 10;

	System.out.println(cercle.toString());
    // imprime "centre : (1,2) et rayon : 3"
}

Ah… Quelqu’un me dit dans l’oreillette qu’on a un autre problème : il est encore possible de modifier le centre du cercle en passant par le getter !

public static void main(String[] args)
{
	int centre[] = {1,2};
	int rayon = 3;

	Cercle cercle = new Cercle(centre, rayon);
	System.out.println(cercle.toString());
    // imprime "centre : (1,2) et rayon : 3"

    cercle.getCentre()[0] = 9;
	System.out.println(cercle.toString());
    // imprime "centre : (9,2) et rayon : 3"
}

Pas de panique, il suffit de faire une autre copie défensive dans le getter. La classe Cercle devient donc :

public class Cercle
{
	private int[] centre;
	private int rayon;

	public Cercle(int[] centre, int rayon)
	{
		int autreCentre[] = {centre[0], centre[1]};
		this.centre = autreCentre;
		this.rayon = rayon;
	}

	public String toString()
	{
		return "centre : (" + centre[0] + ","
               + centre[1] + ") et rayon : " + rayon;
	}

	public int[] getCentre()
	{
		int autreCentre[] = {this.centre[0], this.centre[1]};
		return autreCentre;
	}

	public void setCentre(int[] centre)
	{
		this.centre = centre;
	}

	public int getRayon()
	{
		return rayon;
	}

	public void setRayon(int rayon)
	{
		this.rayon = rayon;
	}
}

Les annotations en Java

admin — Fri, 20 Feb 2009 10:17:59 +0000

Tout comme la notation vargars, les annotations sont apparus dans J2SE 5.0. Les annotations sont des méta-données qui peuvent être ajoutées au code source à différents niveaux (package, class, interface, enum, méthode, attribut ou variable locale) pour interagir avec le compilateur, ou simplement pour documenter le code.

Les 3 annotations prédéfinies dans J2SE 5.0 sont @Deprecated, @Override, et @SuppressWarnings mais vous pouvez aussi créer vos propres annotations.

L’annotation @Deprecated indique que l’élément marqué est déprécié et qu’il ne devrait plus être utilisé. Le compilateur génère un warning quand le programme utilise un élément marqué par l’annotation @Deprecated.
```
@Deprecated
private void ancienneMéthode()
{
	//Une ancienne méthode qui ne devrait plus être appelée
}
```

L’annotation @Override informe le compilateur que l’élément marqué doit redéfinir un élément déclaré dans une classe ascendante. Si la redéfinition est mal effectuée (par exemple, le nom de la méthode marquée est différent de celui de la méthode redéfinie), le compilateur génère une erreur.
```
@Override
private void maMethode()
{
	//Une méthode qui redéfinit une méthode héritée
}
```

L’annotation @SuppressWarnings demande au compilateur de supprimer le warning qu’il aurait généré en tant normal. Cette annotation nécessite un attribut indiquant le nom du warning à supprimer.
```
@SuppressWarnings("deprecation")
public static void main(String[] args)
{
	Date date = new Date(2009,2,15);
   //Constructeur déprécié mais aucun warning ne sera généré
}
```

Pour créer vos propres annotations, il faut utiliser l’annotation @interface.

@interface MonAnnotation
{
	String auteur();
	int version();
}

@MonAnnotation
(
 	auteur = "toto",
	version = 3
)
public class MaClasse {}

Surcharge et redéfinition de méthodes en Java

admin — Mon, 16 Feb 2009 14:32:30 +0000

Après avoir abordé rapidement la surcharge de constructeurs dans l’article portant sur varargs, j’ai eu envie de dédier un article entier au sujet des notions de surcharge et de redéfinition de méthodes. Cet article explique donc la différence entre la surcharge et la redéfinition de méthodes en Java.

Surcharge de méthodes
La surcharge (overloading en anglais) est également appelée surdéfinition. Elle intervient lorsqu’au moins 2 méthodes ou constructeurs d’une classe possèdent le même nom mais qu’il existe au moins une différence entre les méthodes/constructeurs concernées au niveau du nombre d’arguments ou du type des arguments.
```
public static void main(String[] args)
{
	int a = 0, b = 0;
	float c = 1.5f, d = 1.5f;
	addition(a,b); // imprime "additionne des int"
	addition(c,d); // imprime "additionne des float"
	float resultat = addition(a,b); // imprime "additionne des int"
}

private static int addition(int x, int y)
{
	System.out.println("additionne des int");
	return x + y;
}

private static float addition(float x, float y)
{
	System.out.println("additionne des float");
	return x + y;
}
```
L’exemple ci-dessus montre bien que le compilateur est capable de choisir par lui-même laquelle des deux méthodes il doit appeler. L’exemple montre aussi que le type de la valeur de retour d’une méthode n’intervient pas dans le choix de la méthode à appeler. En effet, bien que la variable resultat soit de type float, tout comme la valeur de retour de la 2ème méthode, le compilateur a appelé la 1ère méthode.
Redéfinition de méthodes
La redéfinition intervient lorsqu’une classe dérivée fournit une nouvelle définition d’une méthode d’une classe ascendante. Cette nouvelle méthode doit posséder non seulement le même nom que la méthode de la classe ascendante, mais également la même signature (même nombre d’arguments et même types) et le même type de valeur de retour. De plus, contrairement à la surcharge, la redéfinition ne concerne pas les constructeurs. En effet, premièrement cela impliquerait que la classe dérivée et la classe ascendante aient le même nom, ce qui n’est pas possible au sein d’un même package. Deuxièmement, cela n’aurait aucun sens puisque lorsque l’on instancie une classe dérivée, quoiqu’il arrive, on appellera un constructeur de la classe dérivée et pas un constructeur de la classe ascendante.

Il faut aussi savoir qu’il existe en fait 2 types de redéfinition :
- Redéfinition de méthodes d’instance (overriding en anglais)
- Redéfinition de méthodes de classe (hiding en anglais)
Jetez un oeil au code ci-dessous pour comprendre la différence :
```
class Animal
{
	public static void methodeDeClasse()
	{
		System.out.println("methodeDeClasse() dans Animal");
	}

	public void methodeInstance()
	{
		System.out.println("methodeInstance() dans Animal");
	}
}

class Chien extends Animal
{
	public static void methodeDeClasse()
	{
		System.out.println("methodeDeClasse() dans Chien");
	}

	public void methodeInstance()
	{
		System.out.println("methodeInstance() dans Chien");
	}
}

public class MaClasse
{
	public static void main(String[] args)
	{
		Animal a = new Chien();
		a.methodeInstance(); //imprime "methodeInstance() dans Chien"
		a.methodeDeClasse(); //imprime "methodeDeClasse() dans Animal"

		Chien c = new Chien();
		c.methodeInstance(); //imprime "methodeInstance() dans Chien"
		c.methodeDeClasse(); //imprime "methodeDeClasse() dans Chien"
	}
}
```
Comme vous l’avez compris, lorsque l’on a affaire à une redéfinition de méthode d’instance, la méthode invoquée sera toujours celle de la classe dérivée. Et lorsque qu’il s’agit d’une redéfinition de méthode de classe, la méthode invoquée est celle de la classe dont la référence a été déclarée.

Si vous n’avez rien compris, retenez au moins ceci : la redéfinition concerne des méthodes de même signature et la surcharge concerne des méthodes de signature différente.

Enfin, sachez qu’une méthode déclarée final peut être surdéfinie mais ne peut pas être redéfinie dans une classe dérivée.

La notation varargs en Java

admin — Fri, 13 Feb 2009 16:15:10 +0000

Toujours dans le domaine du passage d’argument, voici un article présentant la notation varargs apparut dans J2SE 5.0.

Pour ceux qui ne connaissent pas varargs, je parie que vous vous êtes déjà retrouvé dans une situation où vous vouliez passer plusieurs arguments à une méthode, sans savoir leur nombre exact au moment de la compilation. Dans ce cas, vous utilisiez sûrement un tableau ou une structure de données comme ArrayList dans laquelle vous ajoutiez vos arguments. C’est parce que vous ne connaissiez pas vargars ! Varargs est une notation permettant de passer à une méthode ou à un constructeur un nombre variable d’arguments. On parle alors de fonctions variadiques.

Voici un exemple de l’utilisation de la notation varargs :

public static void main(String[] args)
{
    imprimeBonjour("Steve"); // imprime "1 Bonjour Steve"
    imprimeBonjour("Bill", "Bob"); // imprime "2 Bonjour Bill Bonjour Bob"

    String[] tab = {"Samuel", "John"};
    imprimeBonjour(tab); // imprime "2 Bonjour Samuel Bonjour John"
}

private static void imprimeBonjour(String... prenoms)
{
    System.out.print(prenoms.length + " ");
    for (String prenom : prenoms)
    {
        System.out.print("Bonjour " + prenom + " ");
    }
}

Comme vous pouvez le voir, il suffit juste de mettre 3 petits points après le type du dernier paramètre et la méthode peut alors être appelée avec n’importe quel nombre de paramètres, y compris zéro. L’exemple montre qu’il est également possible de passer un tableau à la méthode. Enfin vous remarquerez que “prenoms” est considéré par la méthode comme un tableau, et que l’on peut donc utiliser la notation “.length” et la boucle “foreach”.

Peut-être que certains d’entre vous se disent que varargs pourrait permettre d’éviter la surcharge de constructeurs. Imaginons que vous souhaitiez créer une API de géométrie :

public class Point
{
    int x, y;

    /**
    public Point()
    {
        this.x = 0; this.y = 0;
    }

    public Point(int x, int y)
    {
        this.x = x; this.y = y;
    }
    **/

    public Point (int... coordonnees) throws Exception
    {
        if(coordonnees.length == 0)
        {
            this.x = 0; this.y = 0;
        }
        else if (coordonnees.length == 2)
        {
            this.x = coordonnees[0]; this.y = coordonnees[1];
        }
        else
        {
            throw new Exception();
        }
    }
}

Plutôt que de proposer à vos futurs utilisateurs 2 constructeurs différents pour créer un objet Point, vous vous dites :
“Je vais leur simplifier la tâche en leur proposant un constructeur unique grâce à varargs“.

Je vous le dit tout de suite, ce n’est pas une bonne idée. C’est même une très mauvaise idée.
En effet, ça vous oblige à vérifier vous-même la taille du tableau passé en paramètre et à lancer une exception si le nombre d’arguments n’est pas valide. Si vous aviez utilisé la surchage de constructeur, lorsque vos utilisateurs auraient utilisé votre API, le compilateur se serait chargé de vérifier lui-même si le nombre de paramètres est correcte.
Bref, varargs vous force ici à écrire un code plus lourd et moins robuste.

Quel type de passage d’argument en Java ?

admin — Mon, 09 Feb 2009 10:04:49 +0000

Je pense que la plupart des développeurs débutants ignorent quel type de passage d’argument est utilisé en Java.

Dans l’univers de la programmation, il existe deux mécanismes de passage et chaque langage utilise soit l’un, soit l’autre, soit les deux :

passage d’argument par valeur
passage d’argument par référence

Tandis que C++ autorise l’utilisation de l’un ou l’autre de ces mécanismes, Java ne permet que le passage d’argument par valeur. Même les références sont passées par valeur en Java.

La différence entre ces deux mécanismes est la suivante :
Lors de l’appel à une méthode, le passage d’argument par valeur permet de ne passer qu’une copie des variables, ce qui signifie que les éventuelles modifications apportées à ces variables dans le corps de la méthode n’affecteront pas les variables originales. Le passage d’argument par référence, lui, permet de passer les variables originales à la méthode, ce qui implique que les éventuelles modifications apportées à ces variables dans le corps de la méthode persisteront lorsque la méthode retournera.

Remarque : oui, c’est vrai, en C++ on peut aussi utiliser le passage par adresse, mais au final le résultat est le même que dans un passage par référence donc on s’en fout.

Maintenant, quand je lis sur certains sites des trucs du genre :
“En Java, les types primitifs sont passés par valeurs et les objets sont passés par référence.”, eh ben c’est faux pour 2 raisons.

En Java, on ne manipule jamais des objets directement, mais seulement des références à ces objets.
Comme je l’ai déjà dit, en Java, les références sont passées par valeur. La méthode reçoit donc une copie de la référence qui pointe toujours vers l’objet original, qui lui n’a pas été copié. Et comme nous l’avons vu dans l’article sur les types de variables, à cause de l’aliasing, il est normal que les éventuelles modifications apportées à l’objet dans la méthode se répercutent sur l’objet original.

Comme un exemple vaut mieux qu’un long discours, et comme deux exemples valent mieux qu’un seul exemple, voici deux exemples :

int i = 0; // i est une variable de type primitif.
incremente(i); // i vaut 1 dans la méthode
System.out.println(i); // imprime 0

private void incremente(int i)
{
    ++i;
}

List liste = new ArrayList(); // liste est une variable de type référence
ajoute(liste); // La taille de la liste vaut 1 dans la méthode
System.out.print(liste.size()); // imprime 1

private void ajoute(List liste)
{
    liste.add("item");
}

Pour conclure, on peut dire que “l’absence de pointeur” en Java simplifie la syntaxe du passage d’argument par rapport au C++. Néanmoins, le passage d’argument par valeur peut avoir une incidence sur les performances d’un programme lorsque l’on manipule de grosses structures données. En effet, bien que les variables temporaires créées lors d’un passage d’argument par valeur sont immédiatement détruites à la fin de l’exécution de la méthode, la duplication de données de taille importante consomme de la mémoire et nécessite du temps CPU pour effectuer les copies, ce qui engendre une baisse des performances.

La comparaison de chaînes de caractères en Java

admin — Fri, 06 Feb 2009 10:13:33 +0000

Tout comme dans le langage C, la comparaison de chaînes de caractères en Java comporte un piège. En C, il faut utiliser la fonction strcmp(chaine1, chaine2). En effet, l’opérateur == teste si les adresses mémoire des 2 chaines sont égales et non pas si leur contenu est égale.

Il en est de même en Java. Les opérateurs == et != comparent des références et non des valeurs. Ces 2 opérateurs sont parfaits pour comparer des variables de type primitif, mais lorsque l’on a faire à des variables de type référence, il faut toujours utiliser la méthode equals(). Et comme vous avez pu le lire dans l’article sur les types de variables, String ne fait pas partie des 8 types primitifs.

Toutefois, sachez qu’il est quand même plus judicieux d’utiliser l’opérateur == lorsque vous souhaitez comparer une chaine par rapport à la référence null, l’opérateur == étant plus rapide que la méthode equals().

Enfin, certains se demanderont peut-être quelle est la différence entre les méthodes equals() et compareTo() de la classe String. Pour simplifier, la distinction se fait dans le type de la valeur de retour : equals() se contente de renvoyer true ou false, tandis que compareTo() renvoie un int indiquant quel chaine est placée avant l’autre selon l’ordre alphabétique.

Les types de variables en Java

admin — Mon, 02 Feb 2009 17:15:36 +0000

Je commence ce blog par un article simple qui porte sur les types de variables en Java.

Comme vous le savez, les variables en Java sont divisées en 2 catégories : les types primitifs et les types références.
Les 8 sortes de type primitif sont : byte, short, int, long, float, double, boolean et char.
Les 3 sortes de type référence : class, interface et tableau.

Petite remarque en passant : un tableau de char n’est pas équivalent à une String.
Ainsi, la méthode equals() de la classe String ne fonctionnera pas comme vous le souhaitez même s’il n’y aura pas d’erreur à la compilation. Le code suivant vous le prouvera :

//Ce code va imprimer "pas pareil" sur la sortie standard.
String s = "abc";
char[] t = {'a', 'b', 'c'};

if(s.equals(t))
   System.out.println("pareil");
else
   System.out.println("pas pareil");

Abordons maintenant la notion d’objet.
J’ai beaucoup entendu la définition suivante : “Un objet est l’instance d’une classe.”
Eh bien c’est faux ! Enfin, disons plutôt que c’est partiellement vrai.
En Java, un objet est soit l’instance d’une classe, soit un tableau. Cette nuance est importante parce que cela signifie que les tableaux aussi héritent de la classe Object. Ils peuvent donc aussi utiliser la méthode clone() par exemple.

Pour en revenir aux types de variables, les variables de type référence permettent de désigner des objets. Pour ceux qui connaissent le langage C, ces variables sont en fait des pointeurs vers ces objets, c’est-à-dire que cette variable ne contient pas l’objet lui-même mais l’adresse mémoire à laquelle l’objet est stocké. Par conséquent, 2 variables de type référence peuvent pointer vers le même objet. Le code suivant va vous expliquer ce concept qui s’appelle l’aliasing :

char[] t1 = {'a', 'b', 'c'};
char[] t2 = {'a', 'b', 'c'};
char[] t3 = t2;
System.out.println(t1 == t2); //false
System.out.println(t2 == t3); //true

Ici, t1 et t2 ne sont pas égaux car ils contiennent chacun une adresse mémoire différente, tandis que t2 et t3, eux, pointent vers le même objet.

Hello World!

admin — Mon, 02 Feb 2009 12:43:31 +0000

C’est quoi encore ce nouveau blog ?

Je ne sais pas encore, pour l’instant je peux dire que le but de ce blog n’est pas de donner des cours de Java pour débutants. D’autres sites le font déjà très bien (developpez.com, siteduzero.com, etc.) et puis il y a évidemment la doc officiel de Sun.

En fait, je pense que je vais simplement présenter des aspects du langage de programmation Java qui sont généralement peu abordés dans les livres, des détails dont j’aurais aimé que mes professeurs me parlent à l’école pour m’aider à coder plus proprement.
Si l’envie m’en prend, j’aborderai aussi certains points de l’environnement J2EE, voire la programmation sur mobile avec Android.

Si tes collègues disent de toi que tu codes avec les pieds, ce blog est pour toi !