Je viens de publier la première mouture de Pojo Maker, mon second projet SourceForge. Ce petit utilitaire permet de créer des objets java avec une simple ligne de commande. Pour l'utiliser, c'est assez simple. Il suffit de mettre quelques paramètres à la ligne de commande et les objets sont créés selon la structure de répertoire du package configuré. Par exemple:
pojomaker --package-name=net.sf.projet.entities --connection=jdbc:derby:dossier_bd
Créera la structure de dossier suivante dans le répertoire en cours: net/sf/project/entities. Les fichiers de classes seront enregistrés dans ce dossier et auront comme nom de package net.sf.project.entities (je crois que c'était évident).
L'application offre quelques fonctionnalités intéressantes. Entre autre, les colonnes en lecture seules se voient créées avec un mutateur protected, ce qui empêche qu'on ne modifie une colonne auto incrémentée lors de l'exécution. De plus, si une colonne de type varchar est détectée, une verification sera faite au moment de l'exécution pour savoir si on dépasse la capacité du champs de base de données et une constante est créée pour indiquer la taille maximale du champs. Quand un dépassement est détecté, selon le paramètre saisi à la ligne de commande, un avertissement est envoyé à la console de débogage, une exception est lancée ou le dépassement de capacité n'est pas vérifié, selon le cas.
J'ai fait ce programme dans l'esprit de Bridge to Babylone, mon premier projet SourceForge. Je prévoir que les deux projets seront parfaitement alignés d'ici quelques semaines.
Affichage des articles dont le libellé est java. Afficher tous les articles
Affichage des articles dont le libellé est java. Afficher tous les articles
dimanche 14 juin 2009
mercredi 11 février 2009
SerialVersionUID
Qu'arrive-t-il quad on implémente l'interface Serializable en Java? Qu'arrive-t-il quad un étend une classe qui elle-meme implément Serializable? C'est simple, si on ne fait pas attention, le compilateur nous rappelera sans cesse d'ajouter un champs serialVersionUID avec ce doux message:
Dans la documentation de l'API de Java, on recommande au programmeur de déclarer ce champs de façon privée. Si ce champs n'est pas déclaré, le compilateur se chargera d'en générer un d'office. Ce numéro peut varier d'un compilateur à l'autre ou suite à une modification mineur de la classe qui ne touche pas ses champs internes. Ce changement causera alors une exception si on tente de désérialiser un objet qui avait été sauvegardé avec une compilation précédente. On désire évidemment éviter cette situation. Voilà pourquoi il vaut mieux que le programmeur contrôle ce champs et modifie sa valeur quand c'est vraiment nécessaire.
Suite à quelques recherches, j'ai remarqué deux écoles de pensées. La première consiste à commencer la numérotation à 1 et avancer selon les besoins et selon les classes. J'ai rencontré cet situation dans plusieurs exemples sur le Web. Alors que si on regarde dans les source de Sun, la valeur est immense :
Je partage donc ma trouvaille avec vous. C'est à la fois un petit utilitaire pour Java et ma première expérience Ajax. N'hésitez pas à faire vos commentaires.
Générateur de serialVersionUID
The serializable class MaClasse does not declare a static final serialVersionUID field of type longIl y a deux façon que je connaisse de se débarrasser du message en question. Soit on ajoute l'annoation @SupressWarnings("serial") ou encore on obéit et on met en place le champs demandé.
Dans la documentation de l'API de Java, on recommande au programmeur de déclarer ce champs de façon privée. Si ce champs n'est pas déclaré, le compilateur se chargera d'en générer un d'office. Ce numéro peut varier d'un compilateur à l'autre ou suite à une modification mineur de la classe qui ne touche pas ses champs internes. Ce changement causera alors une exception si on tente de désérialiser un objet qui avait été sauvegardé avec une compilation précédente. On désire évidemment éviter cette situation. Voilà pourquoi il vaut mieux que le programmeur contrôle ce champs et modifie sa valeur quand c'est vraiment nécessaire.
Suite à quelques recherches, j'ai remarqué deux écoles de pensées. La première consiste à commencer la numérotation à 1 et avancer selon les besoins et selon les classes. J'ai rencontré cet situation dans plusieurs exemples sur le Web. Alors que si on regarde dans les source de Sun, la valeur est immense :
public final class Copies extends IntegerSyntaxLa seule explication possible c'est que ce numéro est généré aléatoirement et est unique pour chaque classe ou version de classe. Je me suis creusé la tête un moment pour arriver à ce genre de numéro. Je me suis même fait un programme pour le faire à ma place. Jusqu'à ce que e trouve un site extraordinaire: www.random.org. Ce site offre un service de génération de nombre aléatoire basé sur un principe physique appelé bruit atmosphérique. Pour les besoins de ma cause, le fait que ce générateur soit de classe cryptographique n'était pas son plus grand avantage. Son service me permettrait de créer une page web qui générerait des numéro de série automatiquement. Il ne me restait plus qu'à copier-coller la ligne ainsi générée dans mes classes sérializable.
implements PrintRequestAttribute, PrintJobAttribute {
private static final long serialVersionUID = -6426631521680023833L;
...
}
Je partage donc ma trouvaille avec vous. C'est à la fois un petit utilitaire pour Java et ma première expérience Ajax. N'hésitez pas à faire vos commentaires.
Générateur de serialVersionUID
Libellés :
ajax,
java,
programmation,
random,
serialisation,
serializable,
serialization,
serialversionuid
Inscription à :
Articles (Atom)