RSS Feed

Articles associés au tag ‘java’

Vagrant – JDK Oracle sur Ubuntu

16 September 2014 par SeB Pas de commentaire »

Récemment, j’ai voulu créer une box Vagrant contenant un environnement de développement Java prêt à l’usage. Sur GNU/Linux, il existe deux possibilités pour le JDK :

  • OpenJDK
  • Oracle JDK

Souhaitant rester au plus proche de la version de production, j’ai décidé d’installer la version d’Oracle. Cette version n’est pas disponible sur les dépôts officiels d’Ubuntu. Il faut passer par les dépôts PPA.

Création de la VM

Déclaration

La déclaration de la box est assez simple avec le fichier VagrantFile :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/trusty32"
  config.vm.provision :shell, :path => "scripts/provision_java.sh"
end

Provisionning

Comme je n’ai pas encore eu le temps de me pencher sur Puppet ou Chef, l’installation automatique du JDK 8 d’Oracle est réalisée au travers d’un simple script shell qui se charge de réaliser les tâches suivantes :

  1. vérifie si le provisionnement de Java a déjà été fait
  2. configure les dépôts APT les plus rapides
  3. ajoute le dépôt PPA
  4. lance l’installation automatique de Java 8
  5. configure la variable d’environnement JAVA_HOME
  6. nettoie le système (utile en cas d’échec de l’installation)

Voici le contenu du fichier scripts/provision_java.sh :

echo "[vagrant provisioning] Checking if the box was already provisioned..."
if [ -e "/home/vagrant/.provision_java_check" ]
then
  echo "[vagrant provisioning] The box is already provisioned..."
  exit
fi
echo "[vagrant provisioning] Updating mirrors in sources.list"
sudo sed -i -e '1ideb mirror://mirrors.ubuntu.com/mirrors.txt trusty main restricted universe multiverse\ndeb mirror://mirrors.ubuntu.com/mirrors.txt trusty-updates main restricted universe multiverse\ndeb mirror://mirrors.ubuntu.com/mirrors.txt trusty-backports main restricted universe multiverse\ndeb mirror://mirrors.ubuntu.com/mirrors.txt trusty-security main restricted universe multiverse\n' /etc/apt/sources.list
sudo apt-get update
echo "[vagrant provisioning] Installing Java..."
sudo apt-get -y install python-software-properties
sudo add-apt-repository -y ppa:webupd8team/java
sudo apt-get update
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 seen true | sudo /usr/bin/debconf-set-selections
sudo apt-get -y install oracle-java8-set-default
export JAVA_HOME="/usr/lib/jvm/java-8-oracle/jre"
echo "[vagrant provisioning] Java installed"
sudo dpkg --configure -a
apt-get autoremove -y
echo "[vagrant provisioning] Creating .provision_java_check file..."
touch .provision_java_check

Avec ces deux fichiers, vous pouvez lancer les commandes suivantes :

$ vagrant up
$ vagrant ssh

Une fois la VM créée et une fois connecté sur celle-ci, vous pouvez vérifier que le Java est correctement installé :

$ echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle

$ java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode)

Votre environnement de développement Java 8 est prêt !

Packaging de la box

Vous avez pu remarquer que le provisionnement de cette VM a pris un certain temps (une dizaine de minutes lors de mon test) entre la mise à jour des dépôts APT et le téléchargement du Java 8. Afin que la création des prochaines VM soit plus rapide vous pouvez packager celle-ci. Dans un premier temps, il faut effacer l’empreinte mémoire pour réduire au maximum la taille de la box avant de l’arrêter :

$ sudo dd if=/dev/zero of=/EMPTY bs=1M
$ sudo rm -f /EMPTY
$ sudo shutdown -h now

Il existe des articles qui expliquent une ou deux méthodes pour réduire significativement la taille d’une box Vagrant.

Ensuite, il faut créer la box avec la commande suivante :

$ vagrant package --output trusty32-java8-oracle.box

Installation de la box

Cette dernière étape est très simple et s’effectue avec la commande :

$ vagrant box add trusty32/java8/oracle trusty32-java8-oracle.box

Réutilisation de la box

Pour réutiliser cette box dans de nouvelles VM Vagrant, il suffit d’exécuter les commandes suivantes :

$ vagrant init trusty32/java8/oracle
$ vagrant up

Ou bien de créer le fichier VagrantFile suivant :

Vagrant.configure("2") do |config|
  config.vm.box = "trusty32/java8/oracle"
end

Cette fois, la création et le démarrage de la VM a pris moins de 3 minutes !

Vous êtes maintenant équipé pour créer à la demande des environnements de développement Java 8 très très rapidement.

 

Spring MVC Test – tester vos MessageConverter personnalisés

7 August 2013 par SeB Pas de commentaire »

Précédemment, nous avons vu comment ajouter le support du format CSV dans Spring MVC au moyen des MessageConverter. Il est maintenant temps d’automatiser les tests de ce composant. Pour cela, il faut utiliser Spring MVC Test framework.

Dans un premier temps, il faut déclarer un context Spring simplifié pour le test dans un fichier test-web-context.xml :

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:mvc="http://www.springframework.org/schema/mvc"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:beans="http://www.springframework.org/schema/beans"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.2.xsd
    http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.2.xsd">
  <context:component-scan base-package="com.mycompany.myproject.web.mvc.controler" />
</beans:beans>

Ensuite, il faut écrire un test unitaire qui va :

  • configurer le MessageConverter à tester
  • charger le contrôleur à tester
  • mocker les services du contrôleur
  • tester le comportement des requêtes proposées par le contrôleur

Voici le code du test unitaire utilisant Spring Test ainsi que Mockito :

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:test-web-context.xml" })
@WebAppConfiguration
public class StatsControllerTest {
  private static final String CSV_TEST_FILE = "src/test/resources/test.csv";

  @Autowired
  private StatsController statsController;

  @Autowired
  private CsvMessageConverter csvMessageConverter;

  @Autowired
  private StatsService statsService;

  private MockMvc mockMvc;

  private String csvContent;

  @Before
  public void setUp() {
    // charge le mock MVC et configure le CsvMessageConverter à tester
    mockMvc = MockMvcBuilders.standaloneSetup(statsController)
      .setMessageConverters(csvMessageConverter).build();

    // "mocke" le service utilisé par le StatsController à tester
    CsvReader reader = new CsvReader(new FileReader(CSV_TEST_FILE));
    List records = reader.readAllRecords();
    when(statsService.findAllStats(anyInt(), anyInt())).thenReturn(records);

    // charge le jeu de test
    csvContent = new String(Files.readAllBytes(Paths.get(CSV_TEST_FILE)));
  }

  @Test
  public void testGetAllStats() throws Exception {
    // exécute la requête HTTP GET, affiche des traces dans la console et vérifie le retour
    mockMvc.perform(get("/stats/2013/08.csv")).andDo(print())
      .andExpect(status().isOk())
      .andExpect(content().contentType("text/csv;charset=UTF-8"))
      .andExpect(content().string(csvContent));
    verify(statsService).findAllStats(2013, 8);
 }

  @Test
  public void testSaveAllStats() throws Exception {
    // exécute la requête HTTP POST, affiche des traces dans la console et vérifie le retour
    mockMvc.perform(
      post("/stats/2013/08").contentType(
        new MediaType("text", "csv", Charset.forName("utf-8")))
        .content(csvContent)).andDo(print())
      .andExpect(status().isOk())
      .andExpect(content().string(csvContent));
    verify(statsService).saveAllStats(2013, 8, Mockito.anyList());
    }

  @Configuration
  @EnableWebMvc
  public static class TestConfiguration {
    @Bean
    public StatsService statsService() {
      return Mockito.mock(StatsService.class);
    }
  }
}

Comme vous pouvez le constater, la mise en place du test est assez simple. Notez que des importations statiques ont été réalisées afin d’utiliser la fluent API :

import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.verify;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

Même si le prétexte de l’article est de donner la méthode pour tester un MessageConverter, vous avez ici toutes les informations de base pour réaliser les tests unitaires de vos contrôleurs implémentés avec Spring MVC.

Vous n’aurez maintenant plus d’excuse pour ne pas avoir automatisé les tests unitaires de vos contrôleurs (de la couche MVC) ! :P

 

Spring MVC – support du CSV

6 August 2013 par SeB Pas de commentaire »

S’il y a quelque chose que j’apprécie particulièrement dans Spring MVC, c’est bien la facilité et la rapidité à mettre en place des API REST. Par défaut, Spring MVC propose le support du XML, JSON, RSS, Atom et images.

L’ajout du support d’un nouveau format est extrêmement simple. Pour cela, il suffi d’implémenter l’interface AbstractHttpMessageConverter. Voici ci-dessous l’implémentation pour le support des messages HTTP au format CSV :

@Component
public class CsvMessageConverter extends AbstractHttpMessageConverter<List<?>> {
  public static final MediaType MEDIA_TYPE = new MediaType("text", "csv", Charset.forName("utf-8"));

  public CsvMessageConverter() {
    super(MEDIA_TYPE);
  }

  @Override
  protected boolean supports(Class<?> clazz) {
    return List.class.isAssignableFrom(clazz);
  }

  @Override
  protected void writeInternal(List<?> response, HttpOutputMessage output)
      throws IOException, HttpMessageNotWritableException {
    OutputStream out = output.getBody();
    CsvWriter writer = new CsvWriter(new OutputStreamWriter(out));
    writer.writeAllRecords(reponse);
    writer.flush();
    writer.close();
  }

  @Override
  protected List<?> readInternal(Class<? extends List<?>> request,
      HttpInputMessage input) throws IOException,
      HttpMessageNotReadableException {
    InputStream in = input.getBody();
    CsvReader reader = new CsvReader(new InputStreamReader(in));
    List<?> records = reader.readAllRecords();

    return records;
  }
}

Une fois le convertisseur implémenté, il faut le déclarer dans la configuration de Spring MVC :

<mvc:annotation-driven>
  <mvc:message-converters>
    <beans:bean class="com.mycompany.myproject.http.converter.CsvMessageConverter" />
  </mvc:message-converters>
</mvc:annotation-driven>

Maintenant, votre application est prête à générer ou recevoir des requêtes HTTP au format CSV très simplement comme dans le contrôleur suivant :

@Controller
public class StatsController {
  @Autowired
  private StatsService statsService;

  @RequestMapping(
    value = "/stats/{year}/{month}.csv",
    method = RequestMethod.GET,
    produces = "text/csv")
  @ResponseBody
  public List<Stats> getAllStats(@PathVariable("year") int year,
      @PathVariable("month") int month) throws IOException {
    return statsService.findAllStats(year, month);
  }

  @RequestMapping(
    value = "/stats/{year}/{month}",
    method = RequestMethod.POST,
    consumes = "text/csv")
  public List<Stats> saveAllStats(@PathVariable("year") int year,
      @PathVariable("month") int month, @RequestBody List<Stats> stats) {
    statsService.saveAllStats(year, month, stats);

    return statsService.findAllStats(year, month);
  }
}

Si vous souhaitez aller plus loin, vous pouvez bien-entendu consulter la JavaDoc de HttpMessageConverter.

Vous êtes donc maintenant capable de proposer le téléchargement de données au format CSV très simplement dans votre application. Libre à vous de reprendre ce convertisseur ou d’en implémenter d’autres. Vous avez peut-être besoin d’un convertisseur Protobuf ? :-P

 

Validation XML avec des schémas inclus/importés

25 July 2013 par SeB Pas de commentaire »

La validation d’un fichier XML avec un fichier de schéma XML indépendant est assez simple en Java. En revanche, dès que le schéma XML importe ou inclut d’autres schémas, la validation échoue car ces fichiers se sont pas chargés automatiquement. Après investigation, l’API de validation XML ne peut pas charger les schémas inclus. Heureusement, cette API permet d’enregistrer son propre résolveur afin de fournir le contenu des XSD incluses/importées.

Pour celà, il faut implémenter l’interface “LSInput” qui se charge de représenter le contenu du schéma chargé :

public class LocalInput implements LSInput {
	private String publicId;
	private String systemId;
	private BufferedInputStream inputStream;

	public LocalInput(String publicId, String sysId, InputStream input) {
		this.publicId = publicId;
		this.systemId = sysId;
		this.inputStream = new BufferedInputStream(input);
	}

	@Override
	public String getPublicId() {
		return publicId;
	}

	@Override
	public void setPublicId(String publicId) {
		this.publicId = publicId;
	}

	@Override
	public String getBaseURI() {return null;}

	@Override
	public InputStream getByteStream() {return null;}

	@Override
	public boolean getCertifiedText() {return false;}

	@Override
	public Reader getCharacterStream() {return null;}

	@Override
	public String getEncoding() {return null;}

	@Override
	public String getStringData() {
		synchronized (inputStream) {
			try {
				byte[] input = new byte[inputStream.available()];
				return new String(inputStream.read(input));
			} catch (IOException e) {
				return null;
			}
		}
	}

	@Override
	public void setBaseURI(String baseURI) {}

	@Override
	public void setByteStream(InputStream byteStream) {}

	@Override
	public void setCertifiedText(boolean certifiedText) {}

	@Override
	public void setCharacterStream(Reader characterStream) {}

	@Override
	public void setEncoding(String encoding) {}

	@Override
	public void setStringData(String stringData) {}

	@Override
	public String getSystemId() {
		return systemId;
	}

	@Override
	public void setSystemId(String systemId) {
		this.systemId = systemId;
	}

	public BufferedInputStream getInputStream() {
		return inputStream;
	}

	public void setInputStream(BufferedInputStream inputStream) {
		this.inputStream = inputStream;
	}
}

Ensuite, il faut implémenter le résolveur qui se charge de résoudre les dépendances avec des chemins relatifs par rapport à la XSD d’origine :

public class LocalResourceResolver implements LSResourceResolver {
	private final String relativePath;

	public LocalResourceResolver(final String relativePath) {
		this.relativePath = relativePath;
	}

	@Override
	public LSInput resolveResource(String type, String namespaceURI, String publicId, String systemId, String baseURI) {
		String xsdFilePath = relativePath != null ? (relativePath + "/" + systemId) : systemId;
		InputStream resourceAsStream = this.getClass().getClassLoader().getResourceAsStream(xsdFilePath);
		LSInput input = new LocalInput(publicId, systemId, resourceAsStream);
		input.setBaseURI(baseURI);

		return input;
	}
}

Enfin, il faut enregistrer ce résolveur auprès de la fabrique de schéma :

String xsdSourcePath;//chemin où se trouve la XSD afin de résoudre les chemins relatifs
SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
factory.setResourceResolver(new LocalResourceResolver(xsdSourcePath));

Cette solution se base sur l’article XML validation with imported/included schemas de Nicolas Fränkel et ce resource resolver pour la résolution des chemins relatifs.

Avec ces deux classes, vous serez capable de valider vos fichiers XML avec des XSD factorisées (ie. utilisant les tags <xs:import /> ou <xs:include />). Bonne validation ! :-)

 

NormandyJUG – annotations

23 January 2012 par SeB Pas de commentaire »

Mardi dernier, j’ai assisté lors de la session du NormandyJUG à la présentation d’Olivier Croisier sur les annotations. Autant le dire tout de suite : je ne suis pas fan des annotations. J’ai beaucoup de mal avec cette mode de mettre des éléments de configuration dans du code source. On nous rabâche depuis des années que le code source doit être réutilisable et donc générique. Or que depuis l’apparition des annotations, je vois beaucoup de code contenant du paramétrage. On se retrouve donc avec des binaires liés à un environnement. :-(

Néanmoins, c’est sans apriori que je me suis rendu à cette session. Espérant, apprendre quelque chose et peut-être changer d’avis. ;-)

Introduction

En regardant en arrière, on se rend compte qu’XDoclet est l’ancêtre des annotations. Ce système utilisait déjà une méthode de paramétrage et/ou injection/génération de code à partir d'”@” dans la JavaDoc. Cette implémentation avait deux défauts :

  • tout n’est pas documentable dans le langage Java
  • la documentation disparait à la compilation

Voilà pourquoi la création des annotation était nécessaire.

Afin d’assurer une compatibilité du byte code avec le Java <=4, l’implémentation des annotations réutilise les concepts existants dans la langage d’une façon parfois déroutante…

Annotations personnalisées

Pourquoi ?

  • remplacer les fichiers de configuration
  • simplifier le code avec la meta-programmation
  • ajouter des règles de compilation

Caractéristiques

  • un champ d’action
  • une durée de vie (source, compilation, exécution)

La compilation

Les annotations permettent de réaliser un plugin pour le compilateur (Java >=6) via les Pluggable Annotation Processor. Ceci permet entre autre de casser le build. Ce qui peut de révéler très pratique pour faire respecter des best pratices de développement. ;-)

Pourquoi ?

  • La génération de ressources
    • La configuration
    • Les classes
    • La documentation
  • L’amélioration du compilateur
    • Norme de codage
    • Message d’erreur

A ce stade de la présentation, Olivier met en garde l’utilisation de certain framework tel de Lombok qui a quelques contraintes tel que la dépendance de la compilation. En effet, votre compilateur doit être supporté par le projet. Comme toujours, c’est à vous d’estimer le ratio entre risques et avantages.

Comment ?

Ces annotations sont implémentées via AbstractProcessor. Une API permet de faire de l’introspection et découvrir dynamiquement les annotations. Nous avons le droit à une petite démo avec le  SerializableClassesProcessor.

Le runtime

Pourquoi ?

  • Le mapping
  • Les POJO
  • La configuration et/ou les frameworks

Notre intervenant nous illustre cela avec un CSVReader.

Aller plus loin…

Pour nous montrer ce qu’il est possible de faire avec les annotations, notre invité nous présente alors son proof of concept d’injection d’annotations : AnnotationInjector. Il nous avoue que c’est un framework assez sympa à réaliser mais qu’il n’a pas encore trouvé son utilité ! :-D

La conclusion

Une session très enrichissante qui ma réconcilié avec les annotations ! J’éviterai toujours les éléments de configuration dans le code (surtout s’il est lié à un environnement tel que développement, recette ou production). Néanmoins, j’ai déjà testé les Annotations Processor. Et les sembles prometteuses. :-)

La session se termine par une présentation de seren. Cet outil, réalisé par Olivier Crosier, a pour objectif d’optimiser les temps de traitement de la sérialisation et de désérialisation.

Si ce compte-rendu vous a donné envie de vous mettre aux annotations, sachez que la présentation et le code source est disponible sur GitHub.

 

NormandyJUG – Hibernate vs Cloud Computing & NoSQL

14 December 2011 par SeB Pas de commentaire »

Après plus d’un an et demi de pause forcée, j’ai pu enfin retourner au NormandyJUG !

Cette soirée était consacrée à un seul et unique thème :  l’accès aux données face à la montée en charge. La session était animée par Julien Dubois qui est entre autre l’auteur de Spring par la pratique. Le sujet ou l’intervenant devaient intéresser puisque nous étions une 50aine.

En partant du principe que la scalabilité d’une application Java est limitée par la base de données, la présentation consistait à évaluer les solutions disponibles. En effet, avec le Cloud Computing, il est “facile” d’ajouter des machines pour assurer la montée en charge d’une application mais le point de contention reste le serveur de base de données. Avant d’aller plus loin, il faut rappeler le théorème de CAP qui indique qu’il est impossible de répondre à ces trois contraintes en même temps :

  • Cohérent (Consistent)
  • Disponible (Available)
  • Tolérant aux pannes réseaux (Partition tolerant)
Quelles sont donc les solutions pour la base de données ne soit plus un point de contention ?

Le serveur de base de données

Les éditeurs de base de données proposent par exemple du partitionning de table sur différents disques. Les lectures seront optimisées mais ça ne résout pas réellement le problème d’écriture dans les faits.
Il est également possible de mettre en place des clusters d’applications pour le serveur de base de données. A priori, la montée en charge est possible. Cependant, le cluster doit positionner les locks réseaux qui malheureusement plombent les performances.

Hibernate et le cache

S’il n’est pas possible d’améliorer à volonté la performance de la base de données, nous pourrions être tenté de ne plus systématiquement faire appel à cette dernière. C’est là qu’en en scène le cache de niveau 2 d’Hibernate.
Il faut connaitre le fonctionnement d’Hibernate pour bien utiliser le cache. Il est également possible de mettre en pratique la loi de Zipf pour une utilisation avancée du cache. Néanmoins, très rapidement, vous allez être confronté à des problèmes de désynchronisation de cache. Il faut alors mettre en place une solution de cache distribué. Les solutions commerciales actuelles fonctionnent plutôt bien. En revanche, il faut en même temps investir dans des outils de monitoring afin de prévenir tout phénomène de split brain. Il faut savoir que ces outils peuvent proposer des systèmes de write-behind afin de lancer des batchs asynchrones d’insertion.

NoSQL

Si malgré tous ces efforts, votre application ne tient toujours pas la charge à cause de l’accès au données, il vous reste encore une solution : NoSQL (pour Not only SQL).
Vous vous rappelez du théorème de CAP ? En général, on veut un système cohérent (contrôle d’intégrité, transaction, etc…). Et c’est ce que fait la plupart des serveurs de base de données. NoSQL se concentre sur les deux autres contraintes au détriment de la cohérence. Enfin, pour être plus précis, NoSQL indique qu’il sera cohérent à un moment donné (mais pas forcément tout le temps).
Il existe de nombreuses solutions NoSQL mais ici nous avons vu Cassandra qui serait le plus performant en écriture. En gros, c’est un cluster de données sans maître où chaque données est répliquée sur au moins 3 noeuds. Lorsque l’on interroge un noeud, il répond tout de suite avec les informations dont il dispose. Puis va chercher à se mettre à jour (d’où le à terme sera cohérent). En écriture, la gestion des conflits se fait via une date cliente. C’est donc le dernier arrivé qui l’emporte ! ;-)
Par contre, oubliez schemas, tables, colonnes, SQL et autres ! Vous manipulez un identifiant et des listes de couples clé/valeur. Celà permet de faire des choses assez sympa comme le wide-row. Mais les contre-parties sont :
  • Pas de JPA ni JDBC, il faut tout faire à la main
  • Le modèle est défini dans le métier
Pour information, il existe des drivers pour différents langages. De plus, des projets sont en cours pour faciliter le développement avec par exemple Hibernate OGM (Hibernate) ou Kundera (JPA).
Mais alors quelle solution choisir ?
  • Vous avez besoin de transaction, d’intégrité ? La base de données relationnelle est votre meilleure amie !
  • Les solutions de cache sont vraiment des pistes intéressantes.
  • Vous avez un cloud ? Aujourd’hui, aucune base de données n’est scalable via le cloud. NoSQL pourrait être salvateur.
  • Et si on mixait SGBDR et NoSQL ? :-p
 

Java – impossible de supprimer des éléments dans une liste

2 September 2010 par SeB 5 commentaires »

Parfois, le Java peut nous rendre quelque peu perplexe. Prenons par exemple le code suivant :

String s[] = {"1","2","3","4"};
List<String>; l = Arrays.asList(s);
l.remove("1");

Ces lignes de code Java semblent correctes. Pourtant, à l’exécution, elles vont lever l’exception suivante :

java.lang.UnsupportedOperationException
java.util.AbstractList.remove(Unknown Source)
java.util.AbstractList$Itr.remove(Unknown Source)
java.util.AbstractCollection.remove(Unknown Source)

Mais pourquoi la classe List propose une méthode remove() qui n’est pas supportée ? Rappelons que List est une interface. En fait, la faute revient à la méthode Arrays.asList() qui retourne une liste liée à un tableau et donc non modifiable. Si vous voulez modifier une liste créée à partir de cette méthode, il faut utiliser le code suivant :

List<String> l = new ArrayList<String>(Arrays.asList(s));

La liste obtenue est modifiable. Vous pouvez y ajouter ou y enlever des éléments sans risquer une exception. ;-)

 

JAXB – ignorer les espaces inutiles dans les fichiers XML

19 August 2010 par SeB 2 commentaires »

JAXB permet de générer des classes Java à partir de XSD pour manipuler du XML plus facilement. En clair, il permet de générer un parseur et un générateur de flux XML en Java. Ce qui fait gagner énormément de temps en développement.

En revanche, par défaut, le parseur JAXB n’ignore pas les espaces inutiles (appelés whitespaces). Pas de panique, l’API JAXB permet de le faire assez simplement. Il faut seulement créer un filtre et l’appliquer lors de la lecture du flux XML.

Le code du filtre ressemble à ceci :

public class WhitespaceFilter implements EventFilter {
	public boolean accept(XMLEvent event) {
		return !(event.isCharacters() &amp;&amp; ((Characters)event).isWhiteSpace());
	}
}

Ensuite, pour l’appliquer il suffit d’instancier votre parseur de cette façon :

	JAXBContext jc = JAXBContext.newInstance("mon.package");

	// instancie le parseur XML pour ignorer les espaces inutiles
	XMLInputFactory inputFactory = XMLInputFactory.newInstance();
	XMLEventReader eventReader = inputFactory.createXMLEventReader(new FileInputStream("/monrepertoire/monfichier.xml"));
	eventReader = inputFactory.createFilteredReader(eventReader, new WhitespaceFilter());

	// parse le fichier XML
	Unmarshaller u = jc.createUnmarshaller();
	grid = (PCCADGRID)u.unmarshal(eventReader);

Cet exemple supprime les espaces inutiles entre les balises XML. En revanche, les espaces inutiles sont toujours présents dans les valeurs. Pour supprimer ces derniers, il faut mettre en place un adaptateur. Voici son code :

public class NormalizedStringAdapter extends XmlAdapter {
	public String marshal(String text) {
		return text.trim();
	}

	public String unmarshal(String v) throws Exception {
		return v.trim();
	}
}

Il y a trois méthodes pour l’appliquer. Soit lors de l’initialisation du parseur :

Unmarshaller u = jc.createUnmarshaller();
u.setAdapter(new NormalizedStringAdapter());

Soit avec une annotation sur les champs concernés :

@XmlElement(required=true)
@XmlJavaTypeAdapter(NormalizedStringAdapter.class)
String name;

Soit avec une annotation dans les classes package-info pour l’appliquer à tous les champs du type chaine de caractère :

@javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter(value=NormalizedStringAdapter.class,type=String.class)
package mon.package;

Une fois cet adaptateur mis en place, les données XML que vous chargerez ne seront plus polluées par des espaces, retours à la ligne, tabulations, etc…

Notez qu’il existe également un adapteur qui permet de compacter les espaces. Comme ci-dessus, il supprime les espaces en début et fin de chaine mais réduit les multiples occurrences d’espace à un seul espace. Si vous le cherchez, c’est :

javax.xml.bind.annotation.adapters.CollapsedStringAdapter

.

 

DZone RefCardz – aide mémoire Java

20 June 2009 par SeB Pas de commentaire »

Vous ai-je déjà parlé de la carte de référence Debian GNU/Linux ? Si ce n’était pas le cas, cet oubli est réparé. :-)

En écoutant l’épisode 5 des Cast Codeurs, j’ai appris qu’il existait à peu près la même chose (essentiellement mais pas que…) pour le monde Java. Ces pense-bêtes porte le doux nom de DZone RefCardz. Ce sont des cartes de référence sur un thème donné de 6 pages environ au format A4. Les sujets semblent issus de livres. A l’heure actuelle, il existe près d’une soixantaine d’aide-mémoire sur des sujets aussi variés que JSF 2.0, Scrum, MySQL, JPA, C#, etc…

Bien entendu, tout ceci est téléchargeable gratuitement au format PDF après s’être inscrit. Je sens qu’il va y avoir des imprimantes qui vont chauffer !;-)

 

Les Cast Codeurs – le podcast Java en français

19 June 2009 par SeB Pas de commentaire »

Suite à la première réunion du NormandyJUG, j’ai découvert l’existence du podcast Les Cast Codeurs – En français dans le Code. Je ne suis pas un très grand fan des podcasts et pourtant je trouve cette initiative excellente. Pour le moment, je n’ai écouté que le numéro 5 spécial JavaOne. L’ambiance est très bon enfant. :-)

Le podcast se décompose ainsi :

  • Les nouvelles du monde Java
  • Les outils de la semaine
  • Une discussion détaillée sur un sujet peu connu
  • L’interview d’un acteur francophone du monde Java

Vous pouvez retrouver sur leur site tous les liens évoqués dans le podcast. La fréquence des émissions n’a pas l’air d’être fixe (hebdomadaire, bi-hebdomadaire ?). En tout cas, une toute jeune initiative à féliciter !