Additions:
Des structures proposent un socle Debian avec openJDK par défaut dès le dév et la recette : si cela crée un souci,
~- cela se voit au plus tôt et côté dev c'est remonté (vu que cela n'arrivera pas en prod')
~- en terme de support, ce n'est pas forcément contractualisé explicitement, même si cela va de soi lorsque la cible de la prod' est sur du Debian.
~- Une exigence préalable de télécharger la JVM Oracle n'est désormais plus acceptable et ne peut être un axe de contournement de la directive.
~- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple), sans engagement de mise en conformité par la suite : non accepté, réalisé en interne pour 1 j.h en fait
~- cela se voit au plus tôt et côté dev c'est remonté (vu que cela n'arrivera pas en prod')
~- en terme de support, ce n'est pas forcément contractualisé explicitement, même si cela va de soi lorsque la cible de la prod' est sur du Debian.
~- Une exigence préalable de télécharger la JVM Oracle n'est désormais plus acceptable et ne peut être un axe de contournement de la directive.
~- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple), sans engagement de mise en conformité par la suite : non accepté, réalisé en interne pour 1 j.h en fait
Deletions:
~- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple)
Additions:
Si une application reste sur des technologies obsolètes, c'est qu'il n'y a plus de support en réalité : manger tous les midi paraît normal, pourquoi ne pas entretenir les applications apportant de la valeur de la même manière ? C'est la première réponse que je demande et qui détermine mon implication, si non (que j'ai déjà reçu, parfois retourné lorsque cela le méritait avec le budget afférant qui va de soi...)
Normalement : ce paragraphe est synthétique et cadre les enjeux (quelques millions), je détaille ci-dessous comme c'est bien compris et pris en compte (ou pas).
Normalement : ce paragraphe est synthétique et cadre les enjeux (quelques millions), je détaille ci-dessous comme c'est bien compris et pris en compte (ou pas).
Deletions:
Additions:
_Rappel_ que les applets sont obsolètes dans les navigateurs et actuellement non disponibles
Deletions:
Additions:
Cela fait plus de 5 ans que j'entends Mark Reihnold en parler (l'architecte de Java dès le début), mais je n'avais pas pris en compte la résistance au changement qu'il a pu rencontrer (notamment face aux éditeurs et intégrateurs). Je comprends mieux les versions LTS auquel j'adhérais auparavant, mais c'est bien tout le cycle qui doit être pris en compte : éditeur + achat + prod
Additions:
~- adoptOpenJDK 8 ne demande pas trop de boulot mais le passage à JDK 11 entérine l'obsolescence de beaucoup de méthodes avec un coup de développement réel (annoncées depuis 3 versions, nous sommes d'accord ; normalement, un _refactoring_ permet de gérer l'avenir et l'à venir... mais tout le monde n'applique pas les bonnes pratiques de développement, bien documentées depuis la démarche devops apparue depuis ~2010, en visibilité des entreprises, ça remonte à avant vu que j'en ai fait même avant 2003 et que cela fait partie des bonnes pratiques appliquées dans le libre _release early, release often_ :p)
~- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple)
=== Démarche en tant qu'architecte ===
Tenir la position, obtenir sa prise en compte, gérer les exceptions si engagement de résorption (avec coût + délai)
Ne pas prendre de raccourci : c'est JDK 11 et ensuite, pas « ok JDK 8 maintenant », un architecte est embêtant car il ne s'inscrit pas que dans le projet mais dans la durée, nous avons des comptes à rendre à l'exploitation aussi (ce qui inclut nos amis et néanmoins collègues de la sécurité qui essaient de faire prendre en compte le _patch management_ alors que cela devrait aller de soi...
~- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple)
=== Démarche en tant qu'architecte ===
Tenir la position, obtenir sa prise en compte, gérer les exceptions si engagement de résorption (avec coût + délai)
Ne pas prendre de raccourci : c'est JDK 11 et ensuite, pas « ok JDK 8 maintenant », un architecte est embêtant car il ne s'inscrit pas que dans le projet mais dans la durée, nous avons des comptes à rendre à l'exploitation aussi (ce qui inclut nos amis et néanmoins collègues de la sécurité qui essaient de faire prendre en compte le _patch management_ alors que cela devrait aller de soi...
Deletions:
Additions:
adoptOpenJDK 8 ne demande pas trop de boulot mais le passage à JDK 11 entérine l'obsolescence de beaucoup de méthodes avec un coup de développement réel (annoncées depuis 3 versions, nous sommes d'accord ; normalement, un _refactoring_ permet de gérer l'avenir et l'à venir... mais tout le monde n'applique pas les bonnes pratiques de développement, bien documentées depuis la démarche devops apparue depuis ~2010, en visibilité des entreprises, ça remonte à avant vu que j'en ai fait même avant 2003 et que cela fait partie des bonnes pratiques appliquées dans le libre _release early, release often_ :p)
