Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
HTTPServer dans Java 1.6 ?
Bonjour,
cela fait quelque temps que je lis des choses du genre :
"serveur HTTP embarqué dans le JDK 1.6"
Cependant, en utilisant javasearch, je ne vois pas où se trouve ce serveur HTTP embarqué dans JDK 1.6.
Quelqu'un sait-il où il se trouve ?
Merci.
Salut,
Sun a bien inclut un serveur HTTP embarqué dans sa JVM, mais ce n'est pas standard du tout :
- Il n'est donc pas présent dans d'autre JVM.
- Il est fort possible qu'il soit supprimé/remplacé par la suite
Comme toutes les APIs non-standard de Sun cela appartient au package com.sun.* : http://java.sun.com/javase/6/docs/jr...e-summary.html
Mais il est plutôt déconseillé de l'utiliser si on veut conserver la portabilité de l'application...
Tu pourrais peut-être te tourner vers une API tierce comme HttpCore d'Apache...
a++
Merci pour ta réponse rapide et complète.
En fait, j'ai déjà écrit un petit serveur http léger pour communiquer avec le composant browser de swt.
Cela m'a pris un peu de temps mais c'était un bon exercice d'utilisation des sockets.
Je n'ai vraiment compris ton conseil qu'une fois remarqué que cette api non standard était livrée dans "rt.jar" et non pas dans un jar à part qui aurait pu être inclus comme celui d'apache HttpCore.
Du coup, je me pose des questions sur ces apis "non standard" ? Pourquoi ne sont-elles pas dans des jar séparés et versionnés ? qu'on pourrait réutiliser même si elles ne sont plus livrés ultérieurement dans le JRE/JDK ?
Je ne comprend pas trop l'intérêt de leur approche de tout mettre dans rt.jar si ça peut disparaître par la suite ...
Les API com.sun.* sont utilisées en interne par la JVM de Sun.Envoyé par benwit
Du coup, je me pose des questions sur ces apis "non standard" ? Pourquoi ne sont-elles pas dans des jar séparés et versionnés ? qu'on pourrait réutiliser même si elles ne sont plus livrés ultérieurement dans le JRE/JDK ?
Je ne comprend pas trop l'intérêt de leur approche de tout mettre dans rt.jar si ça peut disparaître par la suite ...
Ainsi lorsque certaines classes standards de la JVM peuvent utiliser ces APIs, et elles doivent donc être disponible pour la JVM.
Or si tu les proposent en tant que librairie externe tu risques d'avoir des conflits, car ces APIs peuvent énormément changer d'une version à l'autre (la compatibilité n'est pas assuré) et tu te retrouverais avec deux versions d'une même classe
Les packages com.sun.* ne sont pas fait pour être utilisés directement par les développeurs.
a++
Je comprend mieux.
Répondre avec citation
Partager