File.separator ou File.pathSeparator pour être propre. Ou un autre champ statique comme ça dans File. Mais là c’est dépendant de l’OS, et j’ai envie de dire que c’est déjà une mauvaise idée dans un webserver, je pense que ça doit même être explicitement déconseillé par la spécification J2E (dont les webservices sont une sous-partie, bientôt appelée Web Profile).
Edit:
Ca me rappelle un projet J2E où les gens ont commencé à lancer des threads dans le conteneur. Java c’est bien pour les gens qui respectent les règles, c’est un enfer pour les autres !
Après, si vouloir tester une appli multi-plateforme sur ses deux plateformes cibles principales c’est un truc qui te parait bizarre, convenons juste que nous ne sommes en désaccord sur notre manière de travailler et restons en là.
Au taf je bosse en Go en ce moment, à la fois sous Windows 32bits (et cible 64bits), et sous Linux 64bits. J’en fais pile en ce moment en quantité des tests de plateforme. Je touche au portage Windows, et Go en Windows 32bits c’est pas la joie, et en plus on utilise des API système comme /proc pour gérer le nombre max de handles de fichiers. C’est vraiment de loin les tests les plus coûteux qui existent (en temps… je ne parle pas d’achat/immobilisation de machines pour des tests de charge). C’est avec ce point de vue là que je me dis que si j’étais sur un conteneur Web en Java et sur une archi bien définie je m’épargnerais autant que possible ce genre de tests. A la limite en one shot ça se justifie. Mais si tes tests sont amenés à être récurrents sache que tu mets le doigt dans un engrenage pas très sympa.
Si c’est du perso, et si c’est pour du conteneur web “à la main” je t’encourage alors à regarder du côté de Go. C’est vraiment pas mal pour ce genre d’usage (le site de 20 minutes tourne en Go il me semble). Et la portabilité est en grande partie assurée par Google si tu restes dans les clous.
Histrion, je pense que tu n’imagines pas qu’on puisse ne pas etre seul sur un projet, et qu’a partir de la, on ne peut pas garantir que tous les standards sont respectés…
Je ne suis pas sûr de comprendre ce que tu veux dire Berzehk. Je suis au contraire sur un projet où on gère du C++/CORBA historique, du Java 4 côté serveur qu’on ne peut pas mettre à jour à cause de dépendances très fortes, du Java 5 côté client, du Go pour le cache de données, et un vieux plugin Eclipse moisi pour l’interface d’administration des droits. Et justement on se garde bien de toucher à tout sans regarder les standards avant, sinon c’est un coup à exploser la dette technique du projet.
Si Twin commence son projet, et qu’il est seul, il a intérêt à aller là où il connaît les standards, ou bien à choisir un outil où les standards sont moins complexes et à les lire avant d’écrire le code (AMHA Go si c’est pour la découverte, ou PHP si c’est pour faire vite et efficace).
Non mais Go/PHP/node.lol/play/… on s’en tape hein.
Le monsieur demande comment tester une app sous linux, on lui explique les VM ou LiveCD basta. Y a pas d’histoire de standards ou j’sais pas quoi.
C’est bien ce que je dis. Je suis sur un projet ou les standards sont avec nos process: dans une armoire chez le département qualité… Ils ressortent ces dossiers pour les inspecteurs ISO. On les a jamais vu. Toi t’as de la chance, tes collegues se posent des questions avant de coder. Pas ici.
Donc, dans un cas comme le mien, tu ne peux jamais garantir que les standards sont respectés, t’es obligé de tester.
