[JavaOne] Java 7

J'ai bien aimé aussi la notion de "superpackage" qui permet de meiux organiser ses packages en repoussant les limites du public.

Imaginons que une API composé de 2 packages :

• com.user contenant tous les types utilisables par les utilisateurs de l'API.
• com.user.intern contenant tous les types à usage interne, et qui ne devrait pas être utiliser directement par les utilisateurs de l'API.

:arrow: Actuellement il est impossible de bloquer l'accès au package com.user.intern et à ses classes. La solution est alors d'utiliser un seul et unique package et des classes en 'package-view'... :?


Avec les superpackages il est possible de définir des packages qui ne seront visible que par les autres packages membres, par exemple :

Code:

---

1 2 3 4 5 6 7 8

superpackage com.user { /** Liste des packages membres du superpackage. */ member package com.user; member package com.user.intern;   /** Liste des packages exportés (visible depuis l'extérieur du superpackage). */ export com.user; }

---

Et là seul le package com.user sera visible de l'extérieur ;)


a++

En effet, on a pouvoir mieux architecturer nos applications/triers les differentes classes sans compromettre la visibilite externe du programme.

Zut, pour les slides il faudra encore attendre 1~2 semaines :

Citation:

---

Envoyé par http://java.sun.com/javaone/sf/index.jsp

PDFs for the Technical Sessions will be made available for download at JavaOne Online approximately two weeks after the Conference.

---

A noter que le message a change au cours de ces dernieres 24h, hier, 2~3 heures apres le post de christopheJ, apres qu'ils les aient retire du catalogue, ils avaient marque qu'ils n'etaient pas dispos (avant 2 semaines) pour ceux qui n'avaient pas assiste a la conf. Maintenant c'est pareil pour tout le monde.

A propos des Closures, et pour ceux que l'anglais ne fait pas peur : http://today.java.net/pub/a/today/20...-2k7-mW07.html

Vous y trouverez à télécharger un fichier MP3 des questions/réponses de la session de Neal Gafter sur les Closures ;)

a++

perso :
les closures : pourquoi pas, ca va permettre de faire des choses qui sont faisable dans d'autres langages de scripts. a mon avis, interet surtout pour swing et les threads.

mega package ou jam... pfiouuuu, apres les jar, les war, et ejb-jar, les ear... faut qu'ils arretent. j'aurais preferé un simple systeme de versionning des jar.

la syntaxe de declaration courte est horrible. si ca passe, je l'interdirais dans mon checkstyle.

les reifield generics : oui, ca doit faire gagner en gros 10% de perfs aux collection en evitant le cast en sortie

les Bigdecimal : OUI, le bonheur, c'est la misere de faire des calculs avec cet objet, et on en fait pas mal en informatique de gestion

consumer jre: telechargement a la volée, interessant je pense, si on cumule avec les jam (en clair, eviter d'avoir plusieurs fois la meme version d'une librairie). le quick start si il arrive pour java 6 update 2 c'est du tout bon

Citation:

---

Envoyé par bouye

-Java Modularity/Java Kernel : j'en pense pas grand chose et je trouve l'idée ridicule (cf discussion sur la distribution du JDK par le passe). En quoi les gens trouvent difficile de télécharger 7~15Mo de nos jours quand on peut trouver des téléchargements de démos de jeu ou de logiciels de DAO/bureautique qui dépassent les 500Mo~1Go... De plus dans le pays ou Internet est moins développer, mieux vaut tout télécharger en une seule fois sur un poste et distribuer l'intégralité de la distrib sur CD sur les autres plutôt que de devoir télécharger/streamer à chaque fois sur chacun des postes.

De mon points de vie, la notion de modularité est uniquement interressante pour la mise a jour du JRE, et encore à nouveau uniquement dans un environnement connecté 100% du temps au Net (et via un débit rapide).

---

Je crois que tu es passé à coté de certaines choses. La raison d'être de Java Modularity/Java Kernel est surtout de réduire le temps de lancement de l'application en ne chargeant que le strict nécessaire. Tous les PC n'ont pas Java installé.

Exemple (réel) que tu peux rencontrer aujourd'hui: tu as la JVM installée en locale. Et tu va sur le site de la sncb pour regarder les trajets entre Bruxelles et Paris. Tu choisis d'avoir le calendrier pour choisir la date d'aller. Et là, tout se bloque, car c'est une applette Java, et qu'il faut lancer la JVM, et télécharger le petit jar pour le calendrier. Si Java était modulaire, il ne faudrait charger que 2mo en mémoire, et pas 15Mo ou 30Mo.
Mais ca, c'est dans le cas où tu as déjà la JVM installée en local.
Maintenant, imagine que tu n'as pas la JVM installée en local. Tu vas sur le même site, et l'applet se met en route. Comme il n'y a pas de JVM installée, il va commencer à l'installer pour toi. 2Mo, au lieu de 15Mo. Soit 2 secondes au lieux de 15 secondes si tu as une connection rapide à 8Mbits/sec. Et la prochaine fois que tu reviens sur ce site, c'est instantané. Plus de téléchargement.
Puis, tu découvres Glossitope, http://glossitope.org/site/. Pour le coeur de Glossitope, il te faut quasi rien. Peut-être 2Mo, peut-être 4Mo. Pas plus.
Et puis, tu commences à installer différents widgets pour glossitope. Et plus ces widgets sont complexes, plus tu télécharges avec des modules du JRE.
Jusqu'au jour où finalement tu auras, sans t'en rendre compte, un JRE installé complètement sur ton pc.
Mais, tu continueras à n'avoir en mémoire, selon l'application lancée, que le strict nécessaire.
Et ca, c'est super avantageux. non ?
Cette histoire de Java Kernel/JavaModularité va, je pense, redonner vie aux applets, et peut-être même aux applications de style JavaWebStart pour le consommateur final. Et puis, cette histoire de Java Kernel/Modularité, c'est la clé du succès pour JavaFX. JavaFX sans le Kernel/Modularité, est, à mon sens , voué à l'échec.

Un autre avantage, est que tu pourrais également distribuer ton application avec Java. En ne mettant que le stricte nécessaire de Java pour ton application, et pas tout ce qui serait superflu, réduisant la taille de ton application au niveau du Disque, mais aussi au niveau mémoire.

Vincent

Citation:

---

Envoyé par adiGuba

Autant je ne suis pas d'accord avec vous sur les closures (c'est un "must-have" à mon avis :mrgreen: ), autant je dois dire que ces "short instance creation" ne me branche guère...

---

Les closures en tant que tel ne me dérange pas trop. C'est la syntaxe affreuse que cela va introduire qui ne me plait pas.
Combien de développeurs Java savent dire, en lisant un code source contenant une classe anonyme ou de la généricité quelque peu complexe, ce que ca fait exactement.
Et puis, tu rajoutes quelque part la nouvelle syntaxe des closures. (qui est déjà grandement simplifiée comparée à ce qu'on avait vu au début. N'est ce pas adiguba ?)
Et ce que je n'aimes vraiment pas avec les closures, c'est que les mêmes lignes de code n'auront pas le même comportement selon qu'elles seront écrites dans le contexte des closures ou en dehors de ce contexte. Je pense ici au comportement du return, break, jetée d'une erreur. Et ca, je suis désolé, mais :vomi: :arf:
Celui qui est à l'origine de cela, il faudrait :kill:

Vincent

Pour les closures, c'est à peu de choses près la même syntaxe dans la plupart des langages qui l'utilisent : ex. Ruby (encore plus évolué, d'ailleurs, à ce niveau) ou DotNet.

Il suffit de s'y habituer. La puissance des closures compense largement le travail d'apprentissage, selon moi. 8-)

pour l es closure je n'ai pas trop bien compris ce que c'etait je vais alle me renseigner encore un peu plus mais d'apres ce que j'en avais vi ca ne m'avais pas emballe

sinon ce que je regrette c'est que la surcharge d'operateur n'apparait pas ...

Ca fait TRES longtemps que j'attends le support des propriétés. En effet, quand on fait des sites webs avec des EL, des beans pour des données extraites d'une BD, des sérialisations xml, des EJBs.... on bien obligés de mettre des getter/setter dans toutes ses classes.
Non pas que ce soit compliqué ou long, les IDE gèrent très bien la génération automatique de getter et setter, mais c'est vraiment rudimentaire et ça pourris complétement le code (qui n'a jamais copié toutes ces saletés à la fin de son fichier pour ne plus les voir?). Par contre je n'aime pas trop la syntaxe qu'ils proposent. Selon moi, une syntaxe similaire à celle du dotnet (où on peut spécifier l'existence et/ou le contenu d'un get et/ou set) qui génèrerait implicitement des gets/sets utilisables "comme dab" depuis l'extérieur de la classe serait une solution bien plus simple. La syntaxe à base de pointeurs ne serait utile que si c'est un appel implicite à des gets/sets, une fonctionnalité indépendante de la précédente quoi (mais je ne suis pas trop pour l'introduction de nouveaux opérateurs).
Sinon, pour les closures, si j'ai bien compris ce sont des fonctions lambda c'est bien ça?

Hmmm...
Des changements! Je me souviens lors de la sortie des generics, nombreuses étaient aussi les réactions vives. Et je rejoins Vincent quand il dit que une classe bien générifiée peut rendre le tout assez "obscure". En effet les Closures ne risque de ne pas simplifier. Et c'est là que, pour ma part, je ne sais pas à quel saint me vouer. Je m'explique:

• Les closures, pour moi, profiteraient grandement à des API tel io, nio ou encore jdbc. Combien de fois ai-je eu la chance de voir des TCTCF block mal gérer les exceptions (voir même le cas de figure où tout se passe bien!)... Tout recement j'ai eu l'occasion de terminer une implémentation où j'aurais aimé avoir les closures dans le language Java... Mais m'en serais-je sorti? J'ai mis pas mal de temps à réussir a implémenter ma première API générifiée... Les closures pourraient simplifier pas mal de chose pour les "novices" et rendre le language et la plateforme plus facile à approcher et à prendre en mains.
• Maintenant à quel prix? En effet, je n'ose même pas imaginer une classe générifiée fesant grandement appel aux closures... Et certes la gestion des exceptions et du return ne simplifie rien!

Je dois dire que j'ai assez confiance en Neil Gafter, mais je n'ai pas confiance dans les millions de programmeurs Java pour utiliser ces fonctionnalitée "proprement" et appréande déjà les premières solutions dont je devrais maintenir le code fesant appels à toutes ces "nouvelles" fonctions...
Alex

Les property sont une bonne chose, mais la syntaxe choisie laisse à désirer.
J'aurais aimé une syntaxe aussi souple que celle disponible ... en Pascal Objet !

Ex. avec Getter / Setter implicite (qu'on n'a pas à écrire) :

Code:

---

public property int maPropriété read maPropriétéInterne write maPropriétéInterne;

---

Ex. de propriété externe en lecture seule :

Code:

---

1 2	public property int maPropriété read maPropriétéInterne;

---

Ex. où l'on surcharge le setter :

Code:

---

1 2	public property int MaPropriété read maPropriétéInterne write setMaPropriétéInterne;

---

avec bien sûr plus loin alors :

Code:

---

1 2 3 4 5 6

private int maPropriétéInterne; public void setMaPropriétéInterne(int propriete) { log.debug("Ca y est on assigne maPropriete avec <" + propriete + ">"); this.maPaPropriétéInterne = propriete; }

---

Attention le message suivant contient du Flash

Citation:

---

Envoyé par vbrabant

Je crois que tu es passé à coté de certaines choses. La raison d'être de Java Modularity/Java Kernel est surtout de réduire le temps de lancement de l'application en ne chargeant que le strict nécessaire. Tous les PC n'ont pas Java installé.

[...]

---

Ah oui c'est le cote attrayant de la chose. Et si au final on a qq chose qui se charge plus vite (suivez mon regard... Flash) tout en permettant a l'utilisateur de trouver Java "cool" (...Flash) alors ca redorera son blason cote client (...Flash), surtout pour ce qui est de l'utilisation web (...Flash). Quoique dans l’application de la chose, c’est tout bon pour le JSE (Flash, Flash, Flash), je doute franchement qu’un administrateur JEE se laisse aller à activer une telle fonctionnalité de mise à jour sur laquelle il n’a aucun contrôle et côté JME… hum, faut pas rêver... ca reste trop limité aux possibilités de la platforme physique - je ne crois pas que mon téléphone supporterait une mise à jour constante de sa VM indéfiniment et il manquera de place assez rapidement pour installer des tonnes et des tonnes de libs supplémentaires. Non, la cible visée semble bien plus être le desktop web qu'autre chose. Pas même le desktop bureautique.

:( Mais je crains qu'au contraire tu n'ais pas saisi le contexte d'utilisation que je mentionne c'est à dire le monde "réel/actuel" hors des zones hyper-connectées que sont l'Amérique du Nord, l'Europe, le Japon, la Corée et les grandes-villes de part la planète ; bref, le reste du monde. Mais il est vrai que je faisais référence à des discussions/réflexions passées où j’expliquais peut-être mieux ce contexte.

Bref dans le monde "réel", aussi surnommé "trier-monde informatique" on n’a pas de gros débits, on n’est pas connecté 24h/24, on n’a pas de larges zones couvertes par des bornes Wifi en accès libre via les transports ou les gares et parfois on n’a même pas l'électricité ni le téléphone 24h/24. Hors on se propose de modulariser la distribution du JRE à un point tel qu'il faudra être connecté pour pouvoir utiliser du Java. S'il existe quelques part des distribution complètes tout reste Ok, et il me semble qu'adiGuba (ou Gfx je ne sais plus) avait bien indiqué dans une discussion passée qu'il était question de mettre en place des repository des extensions les plus utilisées, voir des grosse distributions comme cela se fait pour Linux (cf c'était une discussion ou je me plaignais de la volonté de retirer Java Sound du JRE, le premier effet direct de la modularisation du JRE, et de la difficulté de trouver les Java extensions sur le site officiel, sans compter du manque d'uniformité de leur format et de leur procédure d'installation).

Mais dans le cas ou le streaming devient le chemin obligatoire pour utiliser Java, ca va faire grincer pas mal de dents, dans ma zone par exemple, le Pacifique (mais ca marche aussi pour l'Afrique, l'Asie, etc...). Jusqu'à présent Java était une technologie intéressante/sexy pour tout pays en voie de développement de par son faible coût (cout minimal = paye du développeur, outils de devel gratuit, redistribution gratuite), la richesse de l’API (qui n’est pas liée a un OS particulier contrairement à .NET (oui je sais que Mono existe)), sa facilite de déploiement (on télécharge un JRE contenant tout ce qu'il faut, parfois une ou deux extensions et c'est bon, on le met sur un CD et on peut le redistribuer/dupliquer, etc...). Or là d’un coup on change la donne et il faudra que l’ordinateur client ait accès à Internet, etc…

Bon bref ca c’est le scénario exagéré/vue du côté négatif bien sur, j’attends de voir la mise en œuvre et bien sur même dans nos pays des progrès en connectique et dans les infrastructures de communication ont lieu régulièrement (quoiqu’à leur propre rythme) et donc sur le (très) long terme c’est probablement la voie à suivre.

je pense que tu n'as pas saisi. Le jre va continuer a etre distribué en entier. par contre, si en passant sur le net, tu tombes sur une applet, et que tu n'as pas encore installé java, le consumer jre entre en jeu, 2mo de download rapidos, et paf ca demarre.

J'avais pourtant pense avoir mis suffisement de "si" et de "dans le cas ou" pour que ca indique bien les suppositions :oops:.

Par contre attendons un peu la mise en oeuvre avant d'etre aussi categorique.

Java a dès le départ été conçu pour le web, particulièrement pour les applets, et cela n'a jamais marché, (du moins pour les applets).

À mon avis, c'est parce que Sun a toujours voulu parier sur les gros débits. Pourquoi se mettrait-il à parier aujourd'hui sur les bas débits - ou même seulement sur la config de tout le monde ?

Je ne vois rien dans les évolutions de java qui montre concrètement un tel engagement ; seul, peut être, le fait que Java Web Start soit devenu, bien tard, une techno utilisable par CD.

Pour l'instant au niveau de ces configs légères nous en sommes seulement aux effets d'annonce.

Il y a Java Me, qui pourrait indiquer que Sun veut gagner dans les configs pauvres. Mais dans ce domaine il est difficile de dire que le "write once, run partout" a été respecté. L'enjeu de Java Me est surtout de mettre en valeur les portables haut de gamme, à mon opinion.

J'admets qu'il me semble que Java - et Sun en général - commence à réussir sur le Desktop, et que cela peut entraîner des changement philosophiques de fond. On verra.

D'autres modification prevues qui m'avaient echappees. De plus il y a des chances que ceci soit disponible dans des futurs mises a jour de Java 6 plutot que de devoir attendre la mise a disponibilite de Java 7 :

*Graphics Performance on Windows : :king:

*Nimbus : parce que bon, il faut l'avouer, Ocean c'est pas vraiment beau... j'ai toujours trouve que c'etait une regression par rapport a Metal en fait.

Citation:

---

Envoyé par Chet Haase

When Will It Ship?
As I mentioned earlier, the Consumer JRE will be an update for Java SE 6, which means that we will be able to deliver it much more quickly than we could if we waited for another major release like Java SE 7. But it's still a lot of work, and we're not done yet. Our best estimates now put the release date in early 2008, although we are trying to pull in the date if at all possible. Given the amount and type of changes in this release (especially Java Kernel), we need to send this release through extensive testing to make sure that it's as solid as you should expect it to be.

We will roll out some features as they are available, so that you don't have to wait for early 2008 to get everything here. For example, the improved installation experience should be out in update 2 of Java SE 6, which is currently set for late June.

---

Citation:

---

Envoyé par bouye

*Nimbus : parce que bon, il faut l'avouer, Ocean c'est pas vraiment beau... j'ai toujours trouve que c'etait une regression par rapport a Metal en fait.

---

Ocean et Metal font un peu antiquité il faut l'avouer !

Par contre il me semble que l'intérêt d'Ocean était de conserver une compatibilité avec Metal au pixel près ! En adoptant Nimbus Sun adoucirait-il sa politique ?

De toute manière perso j'utilise le LnF système dans la plupart des cas ;)

a++

Pour ceux qui ne suivent pas le blog (Retrouvez les slides de JavaOne ou La sélection hebdomadaire de l'équipe Java du 25/05/2007) :

Les slides de JavaOne 2007 sont disponible en ligne : http://developers.sun.com/learning/j...rack=1&yr=2007

a++

Wahoo : "Extreme GUI Makeover 2007" & "Filthy-Rich Clients: Talk Dirty to Me", de quoi egayer sont debut de semaine :yaisse2:

Alors comme ca Gfx est passe de "Sexy French Guy" (2006) a "GUI Pimp" (2007) ? :mouarf:

Il vont passer la construction d'interface swing en XML ? ou il faudra attendre une autre version de java ?