RSS Feed

Articles associés au tag ‘java’

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 !

 

Supprimer les warnings en Java

30 January 2008 par SeB Pas de commentaire »

Lors de l’étape de compilation, le Java permet de lever les warnings sur des portions de code qui sont corrects d’un point de vue syntaxique, mais qui peuvent poser des problèmes lors de leur exécution.

Le warning le plus courant est sûrement le suivant :

Type safety: Unchecked cast from Object to Collection<String>

Cependant, dans certains cas, le code est correct et ne posera pas de problème à l’exécution. Depuis Java 5.0, il est possible d’indiquer au compilateur, via les annotations, d’ignorer certains warnings sur des blocs de code donnés. Ceci est possible grâce l’annotation @SuppressWarnings.

Par exemple, dans le cas précédent et dans le cas moins évident présenté ci-dessous :

List is a raw type. References to generic type List<E> should be parameterized

Il faut utiliser, l’annotation de la façon suivante :

@SuppressWarnings("unchecked")

L’annotation @SuppressWarnings accepte un nombre important de paramètres. Damien Viel propose une liste des valeurs possibles.

Attention ! Cette annotation doit être utilisée à bon escient. Il est recommandé de se demander pourquoi le Java lève un warning à cet endroit et s’il peut réellement être ignoré…