Vider le cache NetBeans

NetBeans possède un cache qui peut s’avérer gênant dans certains cas. Par exemple, dans un projet dans lequel on a créé des EJB et que l’on souhaite les supprimer, les fichiers générés restent et peuvent faire des conflits avec les nouvelles EJB que l’on souhaite créer.

Pour remédier à ce problème, il suffit de vider le cache de NetBeans. Celui ci se trouve dans le dossier :

C:\Users\<USERNAME>\AppData\Local\NetBeans\Cache

sous Windows et sous Linux dans :

~/.cache/netbeans/

Après avoir arrêté votre IDE, en supprimer ce dossier, son cache sera remis à zéro et les fichiers générés n’apparaîtront plus.

Subversion, problème de Working Copy

Subversion, bien qu’aujourd’hui de plus en plus délaissé pour Git, est un gestionnaire de version particulièrement efficace.

Cependant, de temps en temps, surtout avec des projets récupérés après quelques temps de mise de côté, Subversion n’arrive plus à mettre à jour la version locale du code en prétextant une erreur de Working Copy.

Le plus simple pour résoudre cette erreur est de supprimer purement et simplement les fichiers/dossiers .svn présent dans les sources du projet et de reconfigurer son dépôts pour aller récupérer le nouveau code.

Ceci n’est à utiliser qu’en dernier recours cependant si vous ne voulez pas perdre vos historiques locaux ou si vous ne voulez pas que risquer d’écraser du code que vous n’auriez pas encore commit.

Taille maximum d’un String

Dans la continuité des découverte faites avec Hook, une question qui s’était posée était la taille maximum que pouvait atteindre un String en Java, Par extension, j’ai cherché la réponse dans plusieurs langages.

Deux choses peuvent limiter la taille d’un String :

  • La taille de la pile attribuée (Heap Size) (Surtout lorsque l’on passe dans une machine virtuelle)
  • La taille maximum que peut prendre un tableau soit, en Java, Integer.MAX_VALUE. Ceci correspond à 2 147 483 647 caractères soit 2^31 -1 caractères ou la taille de stockage d’un int.

La gestion des String étant la même dans presque tous les langages, on peut considérer cette limite valide dans la majeur partie des cas.

Les détails viennent d’ici : http://blog.lecharpentier.org/2012/06/27/java.lang.string-limits/

Résoudre le « R cannot be resolved »

Sous Eclipse, lors de développements Android, un problème que j’ai rencontré assez souvent est l’erreur « R cannot be resolved« .

Ceci est souvent dû à une mauvaise importation de classe au début du code où au lieu d’importer la classe R générée dans le package du projet, l’IDE essaye d’importer la classe android.R

Pour corriger ça, il suffit de changer l’import android.R en supprimant la ligne correspondante puis en organisant les imports à l’aide du raccourcis Ctrl + Shift + o

Si impatiemment vous aviez supprimé R en vous disant qu’il allait le re-générer  c’est en relançant le projet qu’Eclipse devrait s’en charger.

Gérer ses formats de date sous Android

Tout programmeur a un jour été confronté à l’affreuse tâche de devoir gérer un format de date dans l’un de ses programmes. Des outils existent mais ne conviennent pas toujours aux besoin ou au format que l’on souhaite mettre en place et on en arrive souvent à se dire qu’avec un peu de tolérance, l’utilisateur ne devrait pas avoir besoin de sa foutue date.

Heureusement les développeurs Android ont pris le taureau par les cornes et nous ont donné le SimpleDateFormat.

Cette classe nous permet de traiter des données de date dans le format que l’on souhaite sans se heurter à des problèmes de fonctions deprecated ou à des librairies maison souvent aussi compréhensibles qu’inefficaces.

byte[] to String

Beaucoup de développement ces temps ci et donc pas mal de petites découvertes.

Sur le projet Hook, nous avions à traiter les images que nous envoyions comme des tableaux de Byte afin de le encoder en Base64. Ici, pas de fonction dans le JDK natif, mais une classe Base64 des plus efficaces dans le SDK Android. Cependant, de l’autre côté, pour les stocker, il nous fallait récupérer les tableaux, et les convertir en String. Ceci est déjà mâché en Java puisqu’il existe un constructeur de String prenant en paramétré un byte[]. Il est même possible de préciser l’encodage stocké dans la chaîne de caractère.

Modifier le dossier de base de Java dans NetBeans

J’ai récemment eu à réinstaller tous mes logiciels dont NetBeans et mon JDK (Java Development Kit). Cependant, manque de chance, entre le début et la fin de mes installation, la dernière version de Java avait changée et était passée de la 1.7u10 à la 1.7u11.

J’ai naturellement désinstallé l’ancienne version pour mettre la nouvelle mais, surprise, au lancement suivant de mon NetBeans, j’ai eu une magnifique erreur stipulant :

Cannot locate java installation in specified jdkhome:
C:\Program Files\Java\jdk1.7.0_11
Do you want to try to use default version?

Pour y remédier, rien de plus simple, il suffit d’aller modifier l’adresse suivant netbeans_jdkhome= dans le fichier de configuration de l’IDE. Ce fichier est /etc/netbeans.conf (Sous Windows, dans le répertoire d’installation de NetBeans)

Installer le SDK Android sous Windows avec l’installateur

Lorsque j’ai souhaité installer le dernier SDK Android sous Windows, un problème est survenu. En effet, le SDK était incapable de trouver le JDK pourtant déjà installé. Les recherches sur internet donnaient comme solution de procéder en appuyant sur retour puis suivant. Cela avait l’air de fonctionner avec beaucoup de personnes. Cependant, ceci ne m’a pas permis de résoudre mon problème.

J’aurais pu contourner ceci en dé-zippant juste la version compressée mais je voulais la version de l’installateur.

La solution a finalement été d’ajouter une variable d’environnement JAVA_HOME. Pour ce faire, il suffit de faire un clic droit sur Ordinateur -> Propriétés -> (Sur la gauche) Paramètres Système avancés -> (En bas) Bouton « Variables d’environnement … » -> (En bas) Bouton « Nouvelle… » -> Nom de la variable : JAVA_HOME et valeur de la variable : Adresse de l’emplacement du JDK.

Une fois cette variable ajoutée, relancer l’installateur et tout se passera bien.

On peut aussi, si l’on veut, ajouter l’emplacement du SDK Android au Path global de Windows afin d’accéder aux commandes directement depuis la console. Il suffit de faire pareil qu’au dessus sauf qu’on modifie la variable nommée « Path« , et on y ajoute à la fin l’emplacement de l’installation précédé d’un point-virgule.

Installer Java sous Linux et l’ajouter au Path de l’interface graphique

Je suis un utilisateur de Java depuis quelques années maintenant et malheureusement, depuis le passage à la version 7, il n’y a plus d’installateur automatique pour les versions autres que RPM (gageons que ce soit temporaire). Voici donc la procédure pour avoir un Java fonctionnel et facilement upgradable par la suite.

Tout d’abord, il faut commencer par télécharger le JDK et le JRE qui nous intéresse sur la page officielle de Java. Il faut bien sûr prendre la version tar.gz et pour ma part je prend la version 64bits. Je me retrouve donc avec les fichiers :

jre-7u7-linux-x64.tar.gz
jdk-7u7-linux-x64.tar.gz

Je créé ensuite un dossier java dans le dossier /opt/ puis y déplace le JDK et le JRE à installer à l’aide des commandes :

mkdir /opt/java
mv jre-7u7-linux-x64.tar.gz jdk-7u7-linux-x64.tar.gz /opt/java/

On décompresse ensuite les deux archives puis on les renomme respectivement en jre et en jdk :

tar -xzf jdk-7u7-linux-x64.tar.gz
tar -xzf jre-7u7-linux-x64.tar.gz
mv  jdk1.7.0_07 jdk
mv  jre1.7.0_07 jre

Il ne reste plus qu’à enlever les deux fichiers d’archives et on a les fichiers d’exécution de Java à leurs places définitives. L’avantage de cette mise en place est qu’il n’y aura qu’à remplacer les fichiers à l’intérieur des dossiers jdk et jre par les nouvelles version de Java. Ce sera ainsi le seul changement qu’il y aura à apporter par la suite pour mettre à jour sa version.

Maintenant qu’on a des emplacements de Java suffisamment génériques pour résister aux changements de versions, il faut les inclure au PATH. Il y a plusieurs solutions en fonction de ce que l’on désire mettre en place. Pour ma part, je voulais inclure Java partout (sous entendu y compris dans l’interface graphique) afin que les programmes qui en ont besoin le trouve facilement. De plus, ceci me permet de lancer facilement mes programmes sans mettre la direction absolue de mon installation.

Je vais maintenant détailler différentes possibilités d’installation :

  • La première permet d’ajouter Java au PATH console d’un seul utilisateur. Il suffit pour ce faire de rajouter les lignes :
export PATH=$PATH:/opt/java/jdk/bin:/opt/java/jre/bin
export JAVA_HOME=/opt/java/jre/bin

à la fin du fichier .bashrc de l’utilisateur.

  • La deuxième permet d’ajouter Java au PATH console de tous les utilisateurs du système. Il suffit de rajouter les même lignes qu’au dessus mais dans le fichier : /etc/bash.bashrc
  • La dernière, et celle que j’ai utilisé, permet de modifier le PATH de tout le système. Elle consiste à modifier le fichier /etc/environment. On modifie la ligne PATH et on rajoute une variable JAVA_HOME au fichier de cette manière :

PATH= »/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/java/jdk/bin:/opt/java/jre/bin »
JAVA_HOME= »/opt/java/jre/bin »

De nombreux détails sur les variables d’environnements et leurs utilisations sont présentes sur les pages officielles d’Ubuntu.

Après un simple redémarrage de l’ordinateur, les configurations seront prises en compte. Nous voici donc avec un Java facilement upgradable utilisable partout.

Nouvelle direction de ce blog

Un entretien de stage il y a quelques mois m’a fait prendre conscience qu’un blog peut aussi être une plateforme publique des compétences que l’on acquiert et maitrise au fur et à mesure des années. Ainsi, lorsque l’un des recruteurs m’a demandé pourquoi je n’avais rien concernant le développement (je postulais pour un poste en développement), je me suis retrouvé con à lui dire que je ne le mettais pas sur ce blog et qu’un autre allait voir le jour pour cela.

Après réflexion, rien ne m’empêche d’intégrer la partie développement dans ce blog et même au contraire, cela permet de centraliser l’intégralité de mes acquis au même endroit. Je pensais qu’il serait plus pratique d’isoler le développement afin de suivre l’évolution de tel ou tel projet sans qu’il soit mélanger au reste de mes recherches, mais finalement, les tags permettent facilement de séparer les contenus.

Je marquerais ainsi aussi désormais les différentes trouvailles / architectures / plug-ins / configurations / fonctions que je trouverais concernant le développement dans tous les langages que je rencontre / utilise.

Enfin, je mettrais aussi un CV en version Light pour que les recruteurs éventuels qui atterriraient sur mon site puissent savoir que je suis la personne qu’il leur faut. ^^