IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La spécification finale de Java EE 8 disponible en téléchargement
Après son approbation par le comité exécutif du JCP

Le , par Michael Guilloux

268PARTAGES

9  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de GordonFreeman
Membre éclairé https://www.developpez.com
Le 14/09/2017 à 8:17
Bonjour,

Voilà qui me semble un très bon choix. La Fondation Eclipse n'a plus à prouver son engagement envers Java et réalise souvent des travaux de grande qualité.

Ça me redonne confiance dans l'avenir et l'évolution de la plateforme.
1  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 14/09/2017 à 9:02
Citation Envoyé par GordonFreeman Voir le message
La Fondation Eclipse n'a plus à prouver son engagement envers Java et réalise souvent des travaux de grande qualité.
Petit correctif: la Fondation Eclipse ne realise pas par elle-meme de travaux de developpement de projet. C'est la communaute qui developpe les projets, la Fondation a plutot pour objectif de donner les moyens a la communaute de travailler au mieux (en fournissant des services, ou en mettant en place des processus de recherche de qualite). Pour Java EE, ca restera a la communaute actuelle et future de s'en occuper, la Fondation va fournir ses services au projet, notamment en terme de gouvernance open-source, qui est le point cle sur des gros projets critiques comme ca.
1  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 17/09/2017 à 11:27
Citation Envoyé par GordonFreeman Voir le message

Ce que je comprend moins bien c'est la dissociation qu'il va y avoir entre Java EE et SE.
J'ai l'impression que c'était déjà le cas depuis des années, Java EE s'appuyant sur les briques de javaSE en rajoutant "tout ce qui manque" pour faire du EE. De temps en temps un brique glisse de EE vers SE quand elle est mature et suffisament nécessaire hors EE.
1  0 
Avatar de CaptainDangeax
Membre expérimenté https://www.developpez.com
Le 20/09/2017 à 15:50
Pour commencer, tu es une quiche en orthographe. ça m'a toujours épaté ce truc là, les gars qui sont capables d'écrire du code où la moindre faute de ponctuation (voire d'indentation pour le python) est sanctionnée par un violent ?SYNTAX ERROR OK. (Commodore 64 inside), et qui ne font pas la différence entre "à déployer" et "déployé" ou qui écrivent "un jeux" avec un X.
Tu ne réponds pas sur le fond, la différence entre du C++ compilé en langage machine et qui n'a besoin que de libstdc++, et le java qui a au minimum besoin d'un J2RE.
Quant à la disparition du C++, dans tes rêves... Il durera tant qu'il y aura des programmes écrits avec et qu'il faudra les maintenir. À chaque fois que tu utilises une nouvelle application, demande-toi avec quel langage elle a été écrite. C'est facile. En ce qui concerne mon Linux, le noyau et les gnu utils sont en C, ainsi que l'interpréteur Python ; les scripts d'administration sont en bash, en perl ou en python, et l'intégralité des applications graphiques sont en C++. libreoffice est même en train de remplacer des morceaux en java par des morceaux en C++. Quant aux appli java, j'en ai 3 : mplab-x, pour les µchip PIC, hodoku, un solveur de sudoku, et freerouter, un routeur de carte électronique. ça me va très bien comme ça, je me moque de savoir en quel langage c'est écrit, tant que ça fonctionne et que ce n'est pas trop lourd à installer (660MB de téléchargement pour MPLAB-X tout de même). Je ne suis pas un intégriste du C++, je ne programme même pas avec, pas plus que Java d'ailleurs, je préfère la simplicité du python qui ne nécessite pas de déclarer une classe pour lire un fichier texte, ou l'ASM pour les µcontrolleurs, et je ne souhaite la mort de personne.
PS : tu t'es pris 5 votes négatifs, il semblerait que ton avis ne soit pas vraiment partagé par ici.
1  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 20/09/2017 à 17:08
Citation Envoyé par super_navide Voir le message
Justement avec la fondation eclipse on aura peut-être pour java un compilateur pour faire directement un .exe avec tous ce qu'il faut pour l’exécution sans avoir la VM.
Ce compilateur, c'etait aussi l'idee de gcj mais ca n'a jamais vraiment marche. On peut faire de .exe avec des applis Java, c'est juste du packaging: en gros, l'appli contient la JVM, le .exe la demarre avec les bons parametres et fin de l'histoire. C'est assez courant.
1  0 
Avatar de super_navide
Nouveau Candidat au Club https://www.developpez.com
Le 21/09/2017 à 16:48
Citation Envoyé par rt15 Voir le message
Une partie des très grosses entreprises qui faisaient du Spring ou du JEE sont en train d'être séduites par la mode Node.js.

Les mêmes qui nous vantaient Java et les services web nous vendent aujourd'hui javascript côté serveur et les microservices.

Bien sûr il y a de l'inertie mais la tendance est marquée. Et le sex-appeal efface toutes les considérations techniques, c'est bien connu.
Et ça va bien plus vite que la prise de parts de marché du Java sur le C++. D'ailleurs dans le domaine des "gros" jeux vidéo le Java est quasi absent.

Si Java perd le combat côté serveur il va décliner bien plus vite que le C++.

Voici quelques données de mon PC pour compléter les states :
C/C++ : Vim, wireshark, VLC, WinMerge, Notepad++, Lightworks, gimp, IDA, Google earth, Chrome, Firefox, Frhed, 7-zip, Acrobat reader, Teams, Office, Visual 2005, notepad, IE, CamStudio, Virtual Box, Unlocker, WinDirStat...
Qui utilisent la VM .NET : Outlook, Daemon Tools Lite, SQL Server (Mais bon...)
Autre : Visual studio code, Delphi 7.
Java : Eclipse, SoapUI, DBeaver, Flash Builder, yEd.
Tu peux faire du java avec Node js sans problème avec le transpilateur http://www.jsweet.org/
Avec java il y a deux chose la syntaxe et la sémantique et l'execution reel (android / gwt / windows etc ... )
Ce qui manque a java est la sémantique des type value qui n'ont pas besoin d'être libérer car alloué sur la pile d’exécution.
Une fois cette évolution java devient aussi rapide que du C++ car le compilateur a des informations de sémantique pour faire les même optimisation qu'en C++.
La conséquence de ne pas avoir ce genre de fonctionnalité est qu'on doit écrire du code du genre :
class UneClasse {
static Vector2 tmp= new Vector2();
void calcul(Vector2 p,Vector2 d ,float distance) {
tmp.set(d);
tmp.multLocal(distance)
p.addLocal(tmp);

}

}

Avec un type value Vector2 on peut coder directement et sans allouer réellement d'objet
class UneClasse {

Vector2 calcul(Vector2 p,Vector2 d ,float distance) {
return p.add(d.mul(distance));

}
}

Le gain est énorme car on ne sollicite pas le garbage collector et pour facilement paralléliser un traitement car on utilise pas de variable static.

Voilà une des raisons pour laquelle java n'a pas pu être utilisé dans les jeux videos.
de plus de tel type pourrait être directement utiliser dans les api opengl .
Le document http://www.oracle.com/technetwork/ja...tz-3126134.pdf explique clairement l'objectif et aussi la complexité des type value.
2  1 
Avatar de GordonFreeman
Membre éclairé https://www.developpez.com
Le 21/09/2017 à 17:03
Citation Envoyé par super_navide Voir le message


Voilà une des raisons pour laquelle java n'a pas pu être utilisé dans les jeux videos.
Haaa ??
Je n'en citerai qu'un :
Aion, jeu MMORPG avec backend codé en java! Des milliers de personnes qui jouent en temps réel avec un serveur en Java.... C'est dingue hein.
Source : Aion-Lightning-4.9

Faudra penser à arrêter un jour avec les histoire de performances, de GC et autres de Java, on est plus en 1995.

Pour le reste je ne rebondirai pas.

Cordialement.
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 21/09/2017 à 19:09
Qu'un langage soit plus adapté à certaines activités qu'à d'autre n'en fait pas un mauvais langage. qu'il prenne ou perde des part de marché dans tel ou tel domaine n'en fait pas un langage en croissance ou en perte de vitesse. tout cela n'est que la vie normale d'un langage.

Que différent langages se recouvrent sur certaines activités n'en font pas nécessairement des concurrent frontaux. pour moi Java et C++ ou encore C# ne jouent pas dans la même cours. ils sont parfois utilisé dans les mêmes domaines mais leur prérogatives sont différentes, leur apports sont différents, leurs forces et leurs faiblesses sont différentes.

Quant à JEE je ne sais que penser. voilà des années qu'une de mes tâches est de récupérer des applications développer ici où là pour les ramener dans le droit chemin de la DSI. J'ai vu passé des dizaines d'applications estampillées JEE. en dix ans pas une seule était une application JEE au vrai sens du terme. ce n'était toutes que de simple web app un simple conteneur de war suffit à les faire fonctionner. pas d'ear pas de rar. bref j'ai vu des dizaines d'applications tournant sur des serveur JEE énormes alors qu'une simple jetty les fait tourner dans une JVM classique. je me demande quand JEE a réellement était en ordre de marche avec force. j'ai plutôt l'impression que beaucoup d'acteurs ont pioché quelques éléments qui les intéressaient dans JEE et n'ont jamais appliqué le modèle de A à Z. Il y j'en connais des appli JEE qui effectivement sont en conformité avec le modèle. je pense entre autre dans le monde bancaire. Mais je ne pense pas que ce soit la majorité.

Je constate de plus en plus que le modèle JEE cède la place à des conteneur générique. c'est à dire qu'on préfère des conteneur simple léger capable de déployer indifféremment des ear des war des jar etc. là ou JEE impose des conteneurs spécifiques.

enfin il est un domaine où Java est plutôt en bonne santé. c'est le middleware. Les EAI et autres ESB sont à très grande majorité écrit en java. il en existe quelques-uns en C++ mais c'est marginal. je n'entrerais pas dans les avantages des un et des autres. je constate que c'es bien vivant.

Java n'a jamais été un langage de prédilection pour produire des IHM. il existe bien quelques solution qui on eu leur heures de gloire mais ce n'est pas le domaine ou java a brillé. que ce soit pour produire une appli de bureau ou des webapp les HIM java ont très souvent été à la traine. (je ne dit pas qu'on peut pas, je dit qu'on n'en voit pas beaucoup) que d'autres solutions qui sont mieux adaptées pour se travail prenne le dessus est plutôt une bonne chose. Je ne crois pas au langage universel. je vois d'ailleurs que même pour php on s'oriente de plus en plus vers un IHM à base de JS/HTML/CSS et un service avec le langage serveur (Java, PHP, C#, ...)

pour moi Java va plutôt bien et est bien vivant. comme tout langage vivant il s'adapte au monde qui l'entoure. rien d'anormal.

A+JYT
1  0 
Avatar de nirgal76
Membre chevronné https://www.developpez.com
Le 26/09/2017 à 9:15
Citation Envoyé par kiprok Voir le message
Tandis que certains alchimistes cherchent à transformer le plomb en or, Oracle lui, pour faire le malin, transforme tout ce qu'il touche en plomb... (opensolaris/mysql/openoffice/java)
T'as oublié VirtualBox
1  0 
Avatar de GordonFreeman
Membre éclairé https://www.developpez.com
Le 14/09/2017 à 9:54
Citation Envoyé par Mickael_Istria Voir le message
Petit correctif: la Fondation Eclipse ne realise pas par elle-meme de travaux de developpement de projet. C'est la communaute qui developpe les projets, la Fondation a plutot pour objectif de donner les moyens a la communaute de travailler au mieux (en fournissant des services, ou en mettant en place des processus de recherche de qualite). Pour Java EE, ca restera a la communaute actuelle et future de s'en occuper, la Fondation va fournir ses services au projet, notamment en terme de gouvernance open-source, qui est le point cle sur des gros projets critiques comme ca.
Oui effectivement ma formulation n'était pas correct..

Le rôle de la fondation est de chapeauter et de donner des moyens aux différents intervenants.
Pour ce qui est de la réalisation et l'implémentation des fonctionnalités on va retrouver un ensemble d'acteurs de la communauté.

Perso je me réjouis de ce changement de gouvernance.
Ce que je comprend moins bien c'est la dissociation qu'il va y avoir entre Java EE et SE.

Cela me semble contre productif mais je me trompe peut-être... Si quelqu'un à des précisions à ce sujet je suis preneur (but, avantages/ inconvénients, risques, etc...)

Cordialement
0  0