Qu'en pensez-vous ?
Que Larry Ellison est en train d'appliquer une grosse quantité de vaseline sur la rondelle du département java.
Oui, cela me semble être le cas
Non, je ne pense pas que ses décisions le réflète
Je n'ai pas d'avis, trop tôt pour me prononcer
Qu'en pensez-vous ?
Que Larry Ellison est en train d'appliquer une grosse quantité de vaseline sur la rondelle du département java.
On se croirait dans une vrai tragédie grec:
Un Dieu (Sun), créa le café (Java), un Oracle s'en empara pour chercher à le soustraire à la vue des Hommes...
Certains nouveaux Titans (IBM,Redhat,...) mécontents du comportement de l'oracle se concertent pour aider ces pauvres hommes à récupérer leur café...
A quand la suite
![]()
Voilà pourquoi la société marchande ne peut pas assurer la pérennité d'une nation et d'un continent !
Tout le Moyen âge et même la Renaissance ont été barrés par de tels comportements, justifiés commercialement.
à commencer par les unités de mesure différentes à 20 km de distance !
Vive les normes disponibles à tous !
![]()
S'accaparer de tout pour avoir le contrôle de tout et choisir ceux que l'on va VENDRE au monde, voilà peut être la vision d'Oracle pour réussir
Ils ne savaient pas quoi faire avec javafx, ça ne m'étonne pas qu'ils le vire... Perso, je trouve qu'ils ont le droit. Quand on possède un truc, on peut le détruire. C'est la vie. Gosling n'avait qu'à le mettre en OpenSource de leur vivant. Tant pis pour ces hippies
, ils ont condamné le café, qui soit dit en passant détruit les réflexes et rend le développeur, mou et verbeux... Un peu comme le java, enfin. J'ai jamais supporté de voir du café et cette pauvre mascotte très sympathique, je suis sûr qu'elle méritait mieux que ça. D'ailleurs Oracle, ils ont eu une réplique dans Iron Man, et ce n'était pas du café... Vous comprenez ?
ze cloude
Sans surprise, Oracle va repousser la date de sortie de Java EE 8
mais envisage de livrer une édition de Java SE chaque année
Mise à jour le 22/09/2016 - JavaOne : Oracle veut orienter Java EE 8 vers le cloud et repousse sa sortie à fin 2017, Java EE 9 devrait être disponible un an plus tard
Comme annoncé il y a un mois, Oracle va reporter la sortie de Java EE 8. Cette version qui devait être disponible à la mi 2017, va finalement sortir en fin 2017. C'est ce qu'a affirmé Anil Gaur, vice-président du groupe chargé de Java EE et WebLogic Server, lors de la conférence JavaOne 2016 à San Francisco, qui a débuté le 18 septembre pour se terminer le 22 septembre.
Comme on pouvait le pressentir également, à partir de Java EE 8, Oracle veut moderniser sa plateforme pour le cloud et les microservices. Java EE a été écrit pour aider les entreprises à construire des sites Web et applications sur des serveurs d'applications. Mais les besoins des entreprises ont changé au fil des années. Oracle est convaincu que la prochaine génération d'applications sera exécutée dans le cloud et non sur des serveurs d'applications. Avec cette évolution vers le cloud, la firme ne veut pas que les développeurs Java ne soient plus utiles dans ce nouveau monde, d'où cette nouvelle orientation. Java EE 8 devrait donc fournir des fonctionnalités basiques pour les organisations ciblant les conteneurs et le cloud ; lesquelles fonctionnalités seraient renforcées avec la sortie de Java EE 9 qu’Oracle prévoit de livrer un an plus tard.
Comme l’annonçaient déjà les derniers mouvements contre Oracle dans le but d’accélérer le développement de Java Enterprise Edition (Java EE), Oracle ne pourra pas respecter sa promesse de livrer Java EE 8 dans les délais prévus, c’est-à-dire, dans la première moitié de l’année 2017. C’est ce que ressort du compte rendu d’une réunion du Java Community Process (JCP), qui coordonne l'évolution du langage Java et des technologies qui lui sont associées.
Au cours de cette réunion, Anil Gaur, le vice-président du groupe chargé de Java EE et WebLogic Server, a donné un bref exposé oral sur la nouvelle stratégie Java EE d'Oracle. D’après lui, le style de programmation des entreprises est en train de changer, avec de plus en plus d’applications qui sont déployées dans des environnements de cloud computing. Selon le compte-rendu publié sur le site de JCP, Anil Gaur aurait expliqué que « plutôt que des appservers traditionnels qui font tourner plusieurs applications, les applications sont maintenant distribuées et déployées dans le cloud via des runtimes modulaires dédiés à une seule application ou un service. »
Le vice-président d’Oracle chargé de Java EE souhaite que « l'avenir de Java EE soit viable pour la prochaine génération d'applications. » Il estime donc que la plateforme « a besoin d’un nouveau modèle de programmation orienté vers la programmation de style réactif pour la construction d'applications distribuées à grande échelle ». Oracle souhaite également voir de nombreuses fonctionnalités disponibles pour la plateforme et pour cela, le géant des bases de données dit être en discussion avec de grands fournisseurs de Java EE. Parmi ces fonctionnalités, on peut citer HTTP/2, Config, O-Auth, Open ID Connect, etc. Dans le but d’ajouter toutes ces nouvelles fonctionnalités, Anil dit que la date de sortie prévue pour Java EE 8 va changer, donc sera repoussée. Mais la nouvelle date n’a pas encore été fixée. Oracle prévoit de fournir de plus amples détails à la conférence JavaOne qui aura lieu le mois prochain.
Si Oracle veut rassurer la communauté au sujet de ses plans pour Java EE, pour les défenseurs de la plateforme, notamment Reza Rahman, l’un des chefs de file de Java EE Guardians, le plus important, c’est de livrer Java EE 8 le plus vite possible. Les autres fonctionnalités pourront venir après. « Toutes les autres nouvelles fonctionnalités qu’Oracle a à l'esprit pourraient être rapidement incluses par la suite dans les versions à venir. Je pense que cela pourrait satisfaire le plus les besoins de la communauté. » Dit-il.
Probablement la bonne nouvelle qui ressort de cette réunion du JCP, Oracle prévoit aussi de raccourcir les cycles de livraison des éditions de Java SE, qui vont passer de jusqu'à trois ans ou plus à une version par an. D’après le compte rendu, cela implique toutefois « qu'ils ne vont pas nécessairement savoir à l'avance quelles sont les fonctionnalités qu’une version particulière pourrait contenir ».
Source : Java Community Process
Et vous ?
Qu’en pensez-vous ?
Voir aussi :
Google vs Oracle : Google Play sur Chrome OS remet-il en cause le fair use ? Oracle demande à présenter son nouvel argument au jury
Oracle brise le silence et rassure au sujet de Java EE, la firme pourrait dévoiler un nouveau plan pour la plateforme à la JavaOne en septembre
Des partisans de Java EE soutenus par Red Hat et IBM décident de poursuivre leur propre développement de la plateforme indépendamment d'Oracle
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Oracle multiplie les retards, concernant Java. Pas bon...
Bof, ce n'est pas comme si l'industrie était passée à Spring, Akka etc depuis des lustres
Certains subissent encore Java EE et ses monstrueux serveurs d'appli à la JBoss ou Websphere ?
N'oublies pas que les utilisateurs de Spring & co. ont souvent toujours besoin d'un certain nombre de technos JEE (Servlet, JMS, JPA, et j'en passe... selon les cas d'utilisation). Pour eux, je pense que ce retard est une vrai mauvaise nouvelle : il va encore retarder les évolutions des technos qu'ils utilisent (Servlet 4 par exemple) au profit d'une nébuleuse stratégie "JEE pour le cloud" d'Oracle qui ne leur fait ni chaud ni froid...
Si cela est vrai, alors il y a probablement un énorme chantier à prévoir et repousser les délais de sortie ne serait pas étonnant.Oracle est convaincu que la prochaine génération d'applications sera exécutée dans le cloud et non sur des serveurs d'applications
Maintenant, je vois bien ce que c'est qu'une application JSF exécutée dans GlassFish (par exemple) accessible par internet ;
mais alors quelle est la particularité des applications "exécutée dans le cloud" ?
Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)
Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cours/developpons/java/
La spécification finale de Java EE 8 disponible en téléchargement
après son approbation par le comité exécutif du JCP
D'après un calendrier précédemment annoncé, la spécification finale de la prochaine version de l'édition entreprise de Java (Java EE 8) devrait être disponible avant la fin de cet été, mais sa publication a été plutôt un peu discrète. Linda DeMichiel, Specification Lead de la plateforme Java Enterprise Edition, a récemment uploadé sur GitHub la spécification finale de Java EE 8, laquelle est disponible en téléchargement au format PDF.
Sur la page d'accueil du Java Community Process (JCP), on voit également que c'est le 21 août que les membres du comité exécutif du JCP ont, par un vote, approuvé la spécification de Java EE 8, en l'absence du vote d'Intel.
Voilà donc trois ans passés depuis le moment où la spécification de Java EE 8 a été soumise au JSR Review en aout 2014, première étape dans la spécification. Cette version qui devait être disponible à la mi 2017 a été finalement reportée, mais devrait sortir avant la fin de l’année. C’est en tout cas ce qu’avait annoncé Anil Gaur, vice-président d'Oracle chargé de Java EE et WebLogic Server, lors de la conférence JavaOne 2016 à San Francisco. Il avait également annoncé qu'Oracle allait moderniser sa plateforme pour le cloud et les microservices. Java EE a été écrit pour aider les entreprises à construire des sites Web et applications sur des serveurs d'applications. Mais les besoins des entreprises ont changé au fil des années. Oracle est donc convaincu que la prochaine génération d'applications sera exécutée dans le cloud et non sur des serveurs d'applications. L'entreprise a, pour cette raison, décidé de doter Java EE 8 de fonctionnalités basiques pour les organisations ciblant les conteneurs et le cloud.
Après un sondage réalisé par Oracle en décembre 2016, l'entreprise a également conclu qu'avec JSON-B (Java API for JSON Binding), il était important de livrer les technologies REST et HTTP/2 dans Java EE 8. Le géant des bases de données avait d'ailleurs affirmé que la plus grande partie du travail relatif à l'intégration de ces technologies dans Java EE 8 était déjà terminée.
Parmi les autres technologies qui étaient annoncées pour Java EE 8, Oracle a également mentionné la version 2.0 de CDI (Context and Dependency Injection), une spécification destinée à standardiser l'injection de dépendances et de contextes au sein de la plateforme Java EE, mais aussi les spécifications Bean Validation 2.0 et JSF (JavaServer Faces) 2.3. Suite aux réponses des utilisateurs au sondage, Oracle a aussi décidé d'accélérer le développement des normes Java EE pour les technologies OAuth et OpenID Connect, mais a regretté que cela ne soit pas possible pour Java EE 8.
Oracle avait prévu de poursuivre tous ces efforts après Java EE 8, mais comme on s'y attend, Oracle n'aura probablement plus la charge de coordonner le développement de Java EE après cette version. L'entreprise a en effet annoncé qu'après la sortie de Java EE 8, elle compte transférer le développement de la plateforme à une fondation open source.
Source : Spécification finale de Java EE 8
Et vous ?
Qu’en pensez-vous ?
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
donc java 9 pour la fin de 2018... ish c'est loin ça
C'est le moment pour passer a .Net / .Net Core
ok je sors![]()
Java EE 8 : Oracle veut transférer la spécification MVC à une autre organisation
les JSR pour Management 2.0 et JMS 2.1 seront supprimés
Cette année, Oracle a fait l’objet de nombreuses critiques à cause d’une négligence constatée de la plateforme Java. La vague de critiques a commencé en fin 2015, lorsqu’Oracle a commencé à se séparer de développeurs importants pour la communauté Java en même temps que des échanges de mails abordant « l’obsolescence programmée » de la plateforme ont fait surface.
Suite à sa défaite contre Google dans le procès autour des API Java, Oracle a également retiré discrètement des fonds destinés au développement de Java et Java SE. Ce fait a été mis au jour après que certains développeurs Java imminents, soutenus par des organisations, ont décidé de poursuivre leur propre développement de Java EE ; une décision prise avoir constaté une interruption soudaine de l’activité d’Oracle autour de Java EE.
Oracle a donc fini par briser le silence pour essayer de taire les critiques. Le géant des bases de données a affirmé son engagement vis-à-vis de la plateforme Java, mais sa vision avait bel et bien changé pendant tout ce temps de silence. Le nouvel objectif d’Oracle de devenir leader du cloud a demandé une nouvelle orientation de Java EE, ce qui, selon la firme, nécessite de repousser la sortie de Java EE 8 prévue initialement pour la mi-2017, à la fin de l’année prochaine.
Comme annoncé à la JavaOne 2016 par Anil Gaur, vice-président du groupe chargé de Java EE et WebLogic Server, à partir de Java EE 8, Oracle veut moderniser sa plateforme pour le cloud et les microservices. Java EE a été écrit pour aider les entreprises à construire des sites Web et applications sur des serveurs d'applications. Mais les besoins des entreprises ont changé au fil des années. Oracle est convaincu que la prochaine génération d'applications sera exécutée dans le cloud et non sur des serveurs d'applications. Avec cette évolution vers le cloud, la firme ne veut pas que les développeurs Java ne soient plus utiles dans ce nouveau monde, d'où cette nouvelle orientation.
Java EE 8 devrait donc fournir des fonctionnalités basiques pour le cloud, alors que d’autres fonctionnalités de la plateforme devraient également payer les frais de la nouvelle direction empruntée par Oracle. C’est le cas du MVC qui serait moins pertinent dans un environnement cloud. Oracle étudie donc la possibilité de transférer la spécification à un autre membre de la communauté ou une organisation pour le développer en tant que composant autonome pour Java. Le Modèle-Vue-Contrôleur (MVC) est un modèle courant dans les frameworks Web, où il est utilisé principalement par des applications basées sur HTML. Le Modèle se réfère aux données de l'application, la Vue à la présentation des données de l'application et l’interface utilisateur, et le Contrôleur à la partie du système responsable de la logique de contrôle, la gestion des événements et la synchronisation.
Dans un billet de blog, l’évangéliste Java EE David Delabassee, qui a fait l’annonce, ajoute encore que la société retire officiellement les JSR (Java Specification Requests) pour l’API Management 2.0 (JSR 373) et JMS 2.1 (JSR 368). L'API Java Message Service (JMS) est une API Java permettant d'accéder aux systèmes de messagerie d'entreprise à partir de programmes Java dans les environnements Java EE et Java SE. Elle fournit un moyen pour les programmes Java de créer, d'envoyer, de recevoir et de lire les messages d'un système de messagerie d'entreprise. En ce qui concerne l’API Management 2.0, elle vise à « remplacer les API Management EJB actuelles et définir de nouvelles interfaces REST pour décrire les objets gérés. Cela devrait accroître l'interopérabilité et la facilité d'utilisation de la nouvelle interface, grâce à la large palette d'outils et de bibliothèques HTTP existants », est-il indiqué sur le site du Java Community Process (JCP).
« Ces changements sont cohérents avec la feuille de route révisée de Java EE présentée à la JavaOne 2016, dans laquelle Oracle a proposé de supprimer ces JSR de Java EE 8 », explique Delabassee. Il explique encore que ces changements reflètent aussi les feedbacks de la communauté Java dans un sondage dans lequel la société a demandé aux membres quelle est la priorité qu’ils accordent à un ensemble de fonctionnalités de la plateforme Java EE. « Management, JMS, et MVC ont été positionnés au bas du classement de toutes les technologies sur lesquelles a porté l'enquête », dit-il. « Nous publierons bientôt une mise à jour décrivant les résultats globaux de l'enquête et les prochaines étapes pour Java EE 8 », a-t-il ajouté.
Source : Oracle
Et vous ?
Qu’en pensez-vous ?
Les fonctionnalités retirées vous semblent-elles utiles ?
Voir aussi :
JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
Le JDK 9 va supporter la compilation anticipée (AOT) en commençant par les systèmes Linux 64-bit exécutant Java 64-bit
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Oracle joue les apprentis sorciers avec Java EE. C'est pas bon...
pour ce qui est de l'api management
le passage de RMI à ResT est une bonne chose. Cela était devenu assez insupportable.
J'utilise Jolokia https://jolokia.org/ qui publie les MBean de la JVM via une API rest
Pour ceux qui veulent voir ça de façon plus conviviale regardez hawtio http://hawt.io/ qui utilise jolokia pour présenter une interface d'admin de la jvm
Quant à l'abandon de MVC, quand je voit la quantité industrielle d'implémentation de MVC dans la JEE qui divergent de l'API JEE (JSR) je me dis que cela fait bien longtemps que le divorce entre java et communauté est consommé.
Par contre si je pense que l'API JMS avait besoin d'évoluer pour prendre en compte les nouveautés (avec des années de retard), je trouve dommage sa disparition.
en effet sa présence permettait à minima d'utiliser une messagerie sans en connaitre l'implémentation.
Bien que très souvent vu que l'API JMS n'a pas évolué en temps est en heure nous sommes contraint pour des raisons de performance d'utiliser une implémentation particulière. il est très fréquent d'avoir dans le code une option permettant de revenir à JMS. Cela permet de proposer le support d'une ou deux messagerie en utilise l'API propriétaire et de bénéficier des perf, mais aussi via JMS de supporter toutes les messageries JMS (éventuellement avec une baisse de perf).
Maintenant reste à savoir ce que vont devenir ces APIs. soit la communauté en a réellement besoin et un groupe va se former pour standardiser le domaine soit elle n'en a pas le besoin fort et on ira vers un éparpillement.
mais les écosystèmes ne supportent pas le vide. il y aura forcément un changement.
A+JYT
Java EE 8 : les utilisateurs de Java EE veulent les services REST et HTTP/2 comme futures améliorations
d'après un sondage d'Oracle
La société Oracle a récemment lancé un sondage dans lequel elle a invité ses utilisateurs à se prononcer sur leurs préférences par rapport aux futures améliorations qu'ils souhaiteraient voir intégrer dans la prochaine version de Java EE (Java Enterprise Edition). Ce sondage, qui s'est déroulé durant les mois de septembre et octobre, a regroupé environ 1 700 participants et a porté sur vingt-et-une (21) technologies.
Les résultats du sondage montrent que la plupart des participants ont voté pour les services REST et le HTTP/2, faisant ainsi de ces derniers les plus importantes améliorations futures attendues par les utilisateurs de Java EE. En effet, parmi les technologies mises en concurrence par Oracle, REST (JAX-RS 2.1) et HTTP/2 (Servlet 4.0) sont arrivées en tête du classement.
Avec JSON-B (Java API for JSON Binding) à la 6e place du classement, Oracle estime qu'il est important de livrer ces technologies (REST et le HTTP/2) dans Java EE 8, dont la sortie est prévue pour fin 2017. Le géant des bases de données affirme d'ailleurs que « la plus grande partie du travail relatif à l'intégration de ces technologies dans Java Entreprise Edition 8 (Java EE 8) est déjà terminée ».
Parmi les autres technologies qui doivent être livrées avec Java EE 8, Oracle mentionne également la version 2.0 de CDI (Context and Dependency Injection), une spécification destinée à standardiser l'injection de dépendances et de contextes au sein de la plateforme Java EE. Les spécifications Bean Validation 2.0 et JSF (JavaServer Faces) 2.3 seront également incluses dans Java EE 8. Si ces technologies n'ont pas été prises en compte dans le sondage, Oracle estime qu'elles ont cependant connu des progrès significatifs pour faire partie de la prochaine version de Java EE.
Suite aux réponses des utilisateurs, Oracle a envisagé d'accélérer le développement des normes Java EE pour les technologies OAuth et OpenID Connect, mais regrette que cela ne soit pas possible pour Java EE 8.
Comme nous l'avons déjà rapporté, les JSR (Java Specification Requests) pour l’API Management 2.0 et JMS (Java Message Service) 2.1 seront supprimés. Oracle étudie également la possibilité de transférer de la spécification MVC à un autre membre de la communauté ou une organisation. Ces décisions s'expliquent par la position de ces technologies à l'issue de l'enquête.
Source : blog Oracle - Rapport du sondage
Et vous ?
Qu'en pensez-vous ?
Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.
Cool encore une brouette de standards qui vont arriver avec 10 ans de retard et mettre 5 ans avant de pouvoir être utiles à quelque chose.
Le JSON bon, je pense qu'ils vont faire un ersatz du de facto-standard Jackson data mapper, moins bien maintenu, moins stable et avec 50 factory qui se marchent dessus. Avant que quelqu'un me traite de sale langue il faut regarder ce qu'il s'est passé avec les API XML, une re-pompe honteuse de Apache Xerces restée buggée pendant des années (super l'API SAX qui charge en mémoire tout le fichier), un système surréaliste qui demande de gérer 3 checked exceptions juste pour instancier un parser, un système de Features sous forme de clé-valeur mal foutu que l'implémentation peut prendre en compte ou pas suivant l'humeur. Résultat on finit avec du code "standard" qui est moins portable au final que se servir d'une librairie tierce.
Partager