Archive pour le ‘Java’ catégorie

Entrées les plus récentes »

RMI et les ports

6 octobre 2005 par Florent Garin

Classiquement, pour développer un serveur RMI, nous devons :

  • Définir une interface avec l’ensemble des méthodes « remotes » (cette interface étendra java.rmi.Remote).
  • Implémenter cette interface dans une class étendant java.rmi.server.UnicastRemoteObject.
  • Enregistrer le serveur auprès d’un registre RMI (il convient d’avoir précédemment lancé la commande rmiregistry).

Au niveau du code côté client, nous devons récupérer une référence de cet objet (son stub) à l’aide de la méthode Naming.lookup(name) qui interroge le service rmiregistry.

Dans le contexte d’un réseau local, cela fonctionne sans que l’on ait vraiment besoin de se préoccuper des ports de communication. Maintenant, si l’on souhaite offrir l’accès à notre serveur aux utilisateurs se trouvant en dehors du LAN, nous devons maîtriser les ports TCP/IP ouverts par notre application pour configurer notre pare-feux et les redirections NAT.

Grâce à la commande netstat nous constatons que rmiregistry écoute le port 1099 et que notre processus java un autre port qui varie à chaque lancement. Le port 1099 est le port par défaut du registre RMI. Il est toutefois possible d’en spécifier un autre en paramètre de la commande rmiregistry. Le second port correspond au port de notre propre service. Toujours grâce à la commande netstat nous remarquons que notre client se connecte une première fois au rmiregistry (sur le port 1099) puis ne dialogue plus qu’à notre application au travers du second port.

Tout ceci ne nous arrange pas, comment définir des règles sur le « router/firewall » si le second port change à chaque redémarrage ?
Un petit tour dans la javadoc nous apprend que le constructeur de la class UnicastRemoteObject admet pour paramètre le port d’écoute. Parfait, nous ajoutons donc super(port) dans le constructeur de notre serveur.

Cependant, nous ne pouvons choisir 1099 car ce port est déjà utilisé par le processus rmiregistry. Heureusement, il y a une solution, nous n’exécuterons plus la commande rmiregistry ; nous créerons directement le registre RMI dans la JVM de notre serveur au moyen de l’instruction LocateRegistry.createRegistry(pPort).

Ainsi nous arrivons à nos fins, notre application ne monopolise qu’un unique port connu et paramétrable.

Bookmark and Share

1 commentaire »

Posté dans Java

Tags:

Harmony

30 août 2005 par Florent Garin

Voilà quelques mois, le projet harmony a officiellement démarré à la fondation Apache.
Ce projet a pour but d’offrir une implémentation open source des spécifications de « Java 2 Platform, Standard Edition ».
Concrètement, il s’agit de développer l’environnement d’exécution, les APIs, le compilateur et l’ensemble des outils standards.
Certains pensent que ce projet est sans intérêt car l’implémentation de Sun, bien que sous licence propriétaire, est gratuite.
Je ne pense pas comme cela. Je vois trois avantages majeurs à bénéficier d’un environnement java open source :

  • Plus de plateformes supportées

Java est un langage multi-plateforme. Cependant Sun ne fournit « que » trois verions de son dernier JRE (Java Runtime Environment) 1.5 ; une pour MS Windows (x86 et AMD64), une pour Solaris (SPARC, x86 et AMD64) et une pour linux (x86 et AMD64).
Apple met aussi à disposition de ses clients la dernière JVM pour MacOS (processeur PPC).
Mais que faire si l’on souhaite installer une JVM sur un serveur linux PPC ? Se tourner vers la distribution d’IBM et se contenter de la version 1.4.2.
Pire encore, si l’on utilise l’OS freeBSD il faut se satisfaire d’une version 1.3 qui n’a pas passé les tests de conformité.
Que dire des nouvelles consoles de jeux ; Xbox360, playstation3 et nintendo révolution, aucune d’entre elles ne peut, pour l’instant, faire tourner java.
Le slogan « Write once run everywhere » de java n’est aujourd’hui que partiellement vrai. Le projet Harmony s’il aboutit pourrait changer la donne.

  • Accélérer la correction des bugs

Certaines anomalies concernant l’API Swing (interface graphique) sont enregistrés dans la base de bugs de Sun depuis plus de 7 ans…
Avec une JVM open source, la communauté des développeurs ne serait plus dépendante d’un éditeur et les « bug fix » se feraient certainement plus rapidement.

  • Distribution du JRE plus aisée

Les JRE de Sun bien qu’étant librement téléchargeable n’en demeurent pas moins propriétaire et leur distribution soumise à de nombreuses contraintes. Il n’est pas possible par exemple de livrer une application java avec un JRE allégé des classes non utilisées. Il n’est pas non plus possible d’intégrer le JRE dans les distribs linux (programmes sous licence GPL et propriétaire ne peuvent cohabiter sur le même media).
Interdit aussi de repackager le JRE sous forme de package debian ou rpm et profiter ainsi des mis à jour en ligne du système (l’équivalent, en mieux ;=), du Windows update).
Une fois de plus, un projet comme harmony lèverait ces limitations.

Bookmark and Share

1 commentaire »

Posté dans Java, Open Source

Tags:

Non-blocking I/O

18 juillet 2005 par Florent Garin

« New I/O » is a feature appeared with jdk 1.4, implemented in package java.nio.channels.

This feature allows to define multiplexed Non-blocking I/O operations. Thus, on the server side, it’s not required to spawn a new thread each time a client connects. It’s the responsibility of the application to create a working thread.

Below, a simple example extracted from the NetCopyPaste program in start() method of org.florentgarin.netcopypaste.network.SocketListener class. It’s probably overkill but NetCopyPaste has been voluntarily written using all the latest technologies.

Selector selector = Selector.open();

//we only register read operation
_channel.register(selector, SelectionKey.OP_READ);

//selector.select() method blocks until a registered operation occurs.
//Thus, it's a infinite loop
while (selector.select() > 0 ) {

Set<SelectionKey> readyKeys = selector.selectedKeys();
Iterator<SelectionKey> iti = readyKeys.iterator();

while (iti.hasNext()) {

SelectionKey key = iti.next();
iti.remove();
if (key.isReadable()) {

//we can have created a thread to do the job but in our case
//there's not so much to do, so we have kept our code simple.
MessageEvent messageEvent = readMessage(key);
fireMessage(messageEvent);

}


}


}

Most application servers such as tomcat has been rewritten to take advantage of the nio packages. If your application has some performance or memory usage issues, you must consider refactoring your code.

Bookmark and Share

Pas de commentaires »

Posté dans Java

Java 1.5.0_02

17 mars 2005 par Florent Garin

Sun vient de rendre disponible la deuxième mise à jour de la JVM 1.5.0. Cette mise à jour mineure certes, possède néanmoins selon moi un intérêt certain car elle corrige le bug non critique mais très irritant des fonts sous MS Windows. En effet, depuis la version 1.4.2, la police par défaut sous l’OS de Microsoft était mal rendue à l’écran notamment sur les caractères ‘C’,'x’ ou ’8′. Cela n’était vraiment pas du plus bel effet ! Il semblerait que Sun commence à comprendre l’importance de ces « détails » pour l’image de Java auprès du public ou des décideurs.

Bookmark and Share

Pas de commentaires »

Posté dans Java

Tags: