Comme beaucoup de monde, je suppose, nous avons un environnement Windows/Active Directory et beaucoup d’applications métier internes qui nécessitent Java. Notre expérience est que Java ne se comporte pas bien dans un tel environnement réseau d’entreprise. L’installation initiale se passe bien (au moins il y a un MSI de nos jours), mais maintenir le bon fonctionnement peut être un vrai défi.
Les problèmes spécifiques que nous rencontrons incluent :
Java a son propre système de mise à jour, et ne s’intègre donc pas dans nos systèmes internes de gestion des correctifs.
L’absence de tout outil de gestion des paramètres Java via les GPO.
L’obligation pour les utilisateurs de configurer manuellement certains paramètres.
Plusieurs environnements d’exécution Java sur chaque machine (Oracle Jinitiator est un coupable particulier ici).
Des fichiers de paramètres critiques stockés sous le dossier Program Files.
Chez nous, c’est principalement un ensemble de scripts de connexion et de solutions de contournement bricolées, mais je suis intéressé de savoir comment d’autres personnes gèrent ces éléments, et s’il y a d’autres choses auxquelles il faut faire attention ici.
Je déploie les versions de l’environnement d’exécution Java depuis quelques années maintenant sous forme d’attributions d’installation logicielle depuis les stratégies de groupe. Je désactive la fonctionnalité de mise à jour en tant que transformation du MSI et je déploie les mises à jour, si nécessaire, via des mises à niveau obligatoires. Si des machines doivent conserver un ancien JRE (parce qu’une application le nécessite), j’utilise des groupes de sécurité pour empêcher les machines de recevoir les nouvelles mises à niveau. (Heureusement, je n’ai pas eu à le faire fréquemment.)
Je construis des transformations pour le MSI de Sun en utilisant l’outil Orca de Microsoft. Ce serait agréable d’avoir un outil comme le « Customization Wizard » d’Adobe, mais je peux faire tout ce dont j’ai besoin avec Orca.
Je n’ai pas eu l’occasion que des utilisateurs doivent « configurer manuellement certains paramètres », mais je le gérerais de l’une des deux façons suivantes. S’il s’agit de certains utilisateurs nécessitant des paramètres différents de la « norme », je déploierais soit une « préférence » de stratégie de groupe pour définir ce paramètre (en supposant qu’il se trouve dans la partie utilisateur du registre), soit un modèle administratif pour modifier le paramètre (en supposant qu’il se trouve dans la partie ordinateur du registre). S’il est nécessaire que l’utilisateur puisse modifier le paramètre à la demande, je modifierais à contrecœur les permissions du registre pour permettre à l’utilisateur (en réalité, un groupe de sécurité contenant l’utilisateur) de le faire. À contrecœur.
Si une application nécessite son propre JRE, j’aurais tendance à lier l’installation de ce JRE au script / GPO qui déploie l’application et à traiter les deux comme une unité. C’est la façon la plus simple que je puisse imaginer pour gérer cela.
J’ai du mal à me rappeler quels paramètres se trouvent sous « Program Files », mais j’accorderais à contrecœur la permission à un groupe de sécurité contenant les comptes utilisateur qui doivent modifier ces paramètres, si cela était nécessaire. Je me tiendrais probablement aussi la tête dans les mains en maudissant Sun.
Tant que Sun ne se sera pas ressaisi concernant le déploiement et la gestion en entreprise du JRE, je pense qu’il est probable que nous devrons tous avoir des solutions de contournement bricolées pour gérer cela. C’est frustrant, mais malheureusement typique. Il semble que la grande majorité des développeurs n’aient aucune idée de ce que c’est que de faire du travail d’administration système.