Bob: We want to get feedback from the community and that might require changes to the language, such as the addition of new APIs, rich media, television, streaming, audio. There is a rich set of things we can do there that would require significant changes.

En disant cela, Robert pointe du doigt les faiblesses actuelles de Java concernant la gestion des « rich media » que sont les vidéos, la télévision, le streaming et même l’audio.
Mais il montre également la volonté de vouloir combler ces besoins. Je dirais ENFIN. Il était temps. Car tant qu’il n’y aura pas de streaming ni de support pour les codec vidéo dans Java, on continuera à voir la présence de Flash dans ce domaine. Suffit de voir comment sont proposées les vidéos de JavaOne (cfr le blog de DannyCoward). Un Flash Player est nécessaire.

Dave: In addition to the JavaFX Script language, Sun has introduced a new platform to the mix–JavaFX Mobile. That is a small GNU/Linux platform with a complete Java 6 runtime on it. Correct?

Bob: Correct.

Dave: So then why tie the name of the platform to a specific language? Isn’t that the blur problem we just talked about?

Je dois avouer que je me range du coté de David Bock (voir la suite de l’interview). Si JavaFX Mobile, c’est Gnu/Linux avec JAVA SE 6 (je suppose que c’est de cela qu’on parler lorsqu’il dit a complete Java 6 runtime), pourquoi avoir donné un nom à cette plateforme qui semble réducteur, dans le sens où cela fait croire qu’il ne supportera que des applications écrites en JavaFX alors que cela pourrait exécuter n’importe quelle application Java SE 6, donc également même des applications Groovy, ou JRuby, sans oublier Java, bien évidemment.

J’avais dit que je poserais la question aux Java Champions, pour confirmer, vu que la plupart sont sur place.

Et en fait, cela se confirme: il y a bien eu une annonce lors de JavaOne disant que Sun travaille sur un Consumer JRE.

Le premier qui m’a répondu, ce fut Roman Strobl, en m’envoyant un lien vers son billet sur le blog, qu’il a écrit suite à ma question: http://blogs.sun.com/roumen/entry/an_important_promise_from_this
Il y a eu aussi Yakov Fain qui m’a également envoyé son billet, intitulé « JavaOne: The most important 2 minutes »
Son billet contenant un lien vers le blog de Danny Coward où une vidéo contenant l’annonce est disponible.
Mais également un lien vers le blog de Chris Maki où on y apprend que

As a prototype, the team put together some trial, to run « hello world » the JRE was 2 MB, the SwingSet2 demo was just under 4 MB, whereas the whole JRE is 12MB

Soit, 2Mo de nécessaire pour le kernel, et 4Mo pour la démo SwingSet2.
Faudra voir maintenant comment cela sera mis en oeuvre. Est-ce que rien ne sera possible tant que tout ne soit pas téléchargé, ou est-ce qu’un interaction même minimale sera déjà disponible assez rapidement.

Ensuite, David Bock a fait savoir qu’il avait également eu la possibilité d’interviewer Robert Brewin, qui a apporté un peu plus d’informations: Cela ne sera pas fini dans l’Update 2 de Java 6, et qu’on en aura encore plus dans l’Update 3 de Java 6.

Dave: So what is the mechanism for that? Are there going to be pieces removed, and downloaded on demand in the cases where they are needed?

Bob: Exactly. Much like the Java 7 kernel project where you will start with a really small piece and download other pieces as necessary, this is the same general principle, just moved where possible to Java 6. Java 6 update 2 will contain the pieces that most people need, and other pieces will be lazily downloaded in the background as needed, hopefully in a way that doesn’t affect normal usage patterns.

Cela confirme donc bien que l’on verra déjà cela dans l’update 2 de Java 6.

Aussi, si on ne trouvait rien concernant la gestion de module dans Java 6 Update 2 (bien que cela ne semble plus le cas aujourd’hui), on trouve en fait pas mal d’information lorsqu’on fait une recherche sur « Consumer JRE ». On trouve même la RFE qui la concerne dans le bugdatabase de Sun

On retrouve donc

• Doug Lea, un professeur qui a été à l’origine de pas mal d’API. Plus connu pour le JSR 166 concernant la concurrency. Egalement Java Champion.
• Fabiane Nardon, Community Leader de java.net.javatools. Egalement Java Champion (et oui, il y a aussi des femmes parmi les Java Champions)
• Dalibor Topič, étudiant en Allemagne. Participe à la maintenant de Kaffe, un projet de machine virtuelle. Egalement membre de la Free Software Foundation, et participe aussi au projet GNU Classpath.

Les deux employés Sun sont Mark Reinhold et Simon Phipps.

Pour plus de détails: http://openjdk.java.net/groups/gb/

Maintenant que nous avons vu l’aspect administratif, légal, voyons l’aspect pratique.

Est-ce que tout le JDK est maintenant disponible en open source ?
Malheureusement NON. Certaines parties du JDK n’appartenaient pas uniquement à Sun (rappelez-vous mon billet à ce sujet) et il semble que certains partenaires (attention: ce n’est pas parce que je vous ai montré un code source mentionnant un copyright IBM qu’il faut en conclure que c’est ce partenaire qui crée des problèmes. Le code source que je vous ai montré dans le billet n’est pas dans l’API causant le problème) aient refusé que leur contribution soient rendues open source. Ainsi, une partie de Java2D, qui concerne le rendu des polices, si mes souvenirs sont bons, n’a pu être rendue open source. Et il y avait une autre partie qui n’était pas rendue open source. Mais je ne la retrouve plus pour le moment.
Sun espère donc que la communauté Java va l’aider à rendre open source cette partie, en réécrivant le code de ces API. Mais en attendant, il fournit le format binaire, pour pouvoir tout de même avec une version d’OpenJDK entièrement opérationnel.

Rappelez-vous qu’en décembre, il vous était possible de compiler le compilateur depuis NetBeans. Et bien, maintenant, il est possible de compiler tout le JDK depuis NetBeans.
Tout le JDK est disponible sous forme de projets NetBeans.

• Javac Compiler. C’est le compilateur javac. Qui était déjà disponible en décembre.
• Javadoc. contient les sources de javadoc.exe.
• JConsole. Les sources de la JConsole.
• JMX. Sources de l’api JMX.
• Swing. .
• AWT & Java2d. A l’exception, si j’ai bien compris de la partie concernant le rendu des polices.
• Jar & Zip. Contient les sources des api pour Zip et JAr, plus l’outil jar.exe.
• J2SE. Permet d’avoir tout le Java SE, sauf Hotspor. Qui est fournit par le projet World.
• World. Pour avoir et HotSpot, et Java SE.

Plus d’information à ce sujet: http://nb-openjdk.netbeans.org/index.html

Sun va également rendre le TCK disponible pour OpenJDK. Ce n’est pas encore clair quand ni comment (sous quelles conditions). Mais il sera disponible. C’est déjà une bonne chose en soi.

Une charte sera signée ce mardi soir à 18heures, (heure locale San Francisco, ca donne 03h00 le mercredi matin à Paris, et Bruxelles). Vous pourrez certainement la lire ici demain matin: http://openjdk.java.net/legal/charter/

Voir la press release de Sun: http://www.sun.com/aboutsun/pr/2007-05/sunflash.20070508.3.xml

Bonne lecture.

Vincent

Est-ce que le fait d’annoncer maintenant que NetBeans 6 fournit (depuis la milestone 9) un support pour Mercurial ne serait-il pas annonciateur d’une autre annonce plus importante ? comme le fait qu’on aurait droit à toutes les sources du JDK ?
(Actuellement, on avait à notre disposition que les sources du compilateur, si je ne m’abuse)

Va falloir être attentif aux annonces qui seront faites à JavaOne. Mais je suppose que cela n’est vraiment pas une coïncidence. S’il fallait que le support pour Mercurial soit prêt pour JavaOne, c’est qu’ils s’attendent à ce qu’on l’utilise.

Wait and See, comme dirait l’autre.

* Je dis bien devrais, car personnellement, je n’ai pas réussi :-(, malgré le fait que j’ai suivi, me semble-t-il, toutes les instructions à la lettre.

Vincent

/*
 * (C) Copyright Taligent, Inc. 1996, 1997 - All Rights Reserved
 * (C) Copyright IBM Corp. 1996 - 1998 - All Rights Reserved
 *
 *   The original version of this source code and documentation is copyrighted
 * and owned by Taligent, Inc., a wholly-owned subsidiary of IBM. These
 * materials are provided under terms of a License Agreement between Taligent
 * and Sun. This technology is protected by multiple US and International
 * patents. This notice and attribution to Taligent may not be removed.
 *   Taligent is a registered trademark of Taligent, Inc.
 *
 */

On comprends maintenant pourquoi cela peu prendre du temps pour Sun, pour rendre le JDK OpenSource: Où ils ont l’accord de Taligent pour mettre cela sous licence GPL, ou ils doivent réécrire cette classe.

Vincent

Ainsi, il nous propose une modification du compilateur qui doit permettre la déclaration de properties.

Mais je me demande tout de même pourquoi il n’a pas utilisé les annotations pour cela.

Il me semble que @Property serait bien plus puissant dans ce cas. Car cela nous permettrait de passer des paramètres à l’annotation, pour indiquer qu’il ne faudrait créer que le getter par exemple. Ou pour indiquer quelle méthode jouera le rôle du getter ou du setter.
Par exemple

@Property() String x;
serait équivalent à

tandis que

@Property(getter="getType") String x;
serait équivalent à

avec en prime la possibilité de dire que fichier des JavaBeans soit généré pour dire que getType est le getter de x

et finalement
@Property(name="type") String x;
correspondrait à

Mais bon. Je dis ca, je dis rien. De tout façon, combien d’entre nous se fatigue encore à taper tout ce code ? Les IDE génèrent depuis bien longtemps. Et puis cela va permettre d’exprimer la même chose de 2 façons différentes, et j’aime pas cela.

Mais qui suis-je dans le monde Java pour que ceux qui conçoivent la génération future des compilateurs java se soucient de mon avis. Car en effet, c’est un peu là le problème. On a chacun ses préférences et ses opinions. Difficile d’avoir tout le monde d’accord sur une syntaxe.

J’ai donc installé ce module de NetBeans me permettant de créer un projet avec les sources du compilateur.
Ensuite, il suffit de faire File -> New Project -> Sample -> OpenJDK, et choisi l’endroit où mettre le projet contenant les sources du JDK. Assurez-vous que le projet soit le principal.

Une fois cela fait, il vous suffit de faire Run -> Run Main Project et le compilateur java se compile. Ce qui est intéressant à noter est qu’il se compile tout d’abord avec le JDK utilisé par défaut (il vous faut au minimum le JDK 5). Et une fois que c’est fini, il se recompile lui-même.

Il a fallu 17 secondes à mon PC pour réaliser cette opération, ce qui est tout à fait acceptable, surtout lorsque l’on sait qu’il se compile 2 fois de suite, finalement.

C’est toujours intéressant et instructif de voir ce qui se passe dans le script Ant. Car cela pourrait être instructif pour nos projets à nous.

Examinons quelque peu les 2 fichiers qui nous intéressent: le build.xml et le build.properties.

build.jdk.version = 1.7.0
build.release = ${build.jdk.version}-opensource
build.number = b00
build.user.release.suffix = ${user.name}_${build.fullversion.time}
build.full.version = ${build.release}-${build.user.release.suffix}-${build.number}
 
# Set jtreg.home to jtreg installation directory
# jtreg.home =  
 
# Set test.jdk.home to baseline JDK used to run the tests
# test.jdk.home =  
 
compiler.source.level = 1.5

On y apprend donc déjà certaines choses:
1. c’est le compilateur du JDK 7 (build 00)
2. il vous faut un compilateur JAVA 5
3. dans la version complète du compilateur figurera votre nom et la date et heure de sa compilation.

Examinons maintenant le fichier build.xml.
Il commence par définir certaines propriétés pour indiquer où se trouvent les répertoires des
sources et les classes générées, …

    <property name="src" value="src"/>
    <property name="src.bin" value="${src}/bin"/>
    <property name="src.classes" value="${src}/share/classes"/>
    <property name="build" value ="build"/>
    <property name="build.bootclasses" value="${build}/bootclasses"/>
    <property name="build.classes" value="${build}/classes"/>
    <property name="build.gensrc" value="${build}/gensrc"/>
    <property name="build.jtreg" value="${build}/jtreg"/>
    <property name="dist" value="dist"/>
    <property name="dist.javac" value="${dist}"/>

Ensuite, il définit un patternset. Qui pourra être réutilisé à plusieurs endroits, ce qui permet de ne pas devoir à chaque fois redéfinir la même chose. Très intéressant donc.

<patternset id="src.javac"> 

    <include name="javax/annotation/processing/**/*.java"/> 

    <include name="javax/lang/model/**/*.java"/> 

    <include name="javax/tools/**/*.java"/> 

    <include name="com/sun/source/**/*.java"/> 

    <include name="com/sun/tools/javac/**/*.java"/> 

    <include name="com/sun/tools/javadoc/DocCommentScanner.java"/> 

    <exclude name="**/*-template.java"/> 

</patternset>

Ils y indique les fichiers à inclure, et les fichiers à exclure. On remarque que les fichiers -template.java sont ignorés. On comprendra pourquoi plus loin.

<target name="prep"> 

    <mkdir dir="${build.bootclasses}"/> 

    <mkdir dir="${build.classes}"/> 

    <mkdir dir="${dist.javac}/bin"/> 

    <mkdir dir="${dist.javac}/lib"/> 

    <tstamp> 

        <format property="build.time" pattern="MM/dd/yyyy hh:mm aa"/> 

        <format property="build.fullversion.time" pattern="MM/dd/yyyy_HH_mm"/> 

    </tstamp> 

    <property file="build.properties"/> 

</target>

Cette tâche prépare les répertoires, prend la date système et la formate de 2 façons différentes, dans de nouvelles propriétés.

<mkdir dir="${build.gensrc}/com/sun/tools/javac"/> 

<copy file="${src.classes}/com/sun/tools/javac/resources/version-template.java" 

    tofile="${build.gensrc}/com/sun/tools/javac/resources/version.java"> 

    <filterset begintoken="$(" endtoken=")"> 

        <filter token="JDK_VERSION"  value="${build.jdk.version}"/> 

        <filter token="RELEASE"      value="${build.release}"/> 

        <filter token="FULL_VERSION" value="${build.full.version}"/> 

    </filterset> 

</copy>

après avoir créé le répertoire pour le compilateur java, le script ant va modifier le template, en remplacant dans le code source certaines String par des valeurs de propriétés.
Un find & replace en fait. Ici, il va donc ouvrir le fichier template, remplacer les occurences de ${JDK_VERSION}, ${RELEASE} et ${FULL_VERSION} par la valeur des propriétés associées, et enregistrer la version modifiée dans un autre emplacement où se trouvent les sources générées.

<!-- to compile javac, set includeAntRuntime=no to prevent javac's  

 own tools.jar incorrectly appearing on the classpath --> 

<javac srcdir="${src.classes}:${build.gensrc}" destdir="${build.bootclasses}" 

    source="${compiler.source.level}"  debug="true" debuglevel="source,lines" 

    includeAntRuntime="no"> 

    <patternset refid="src.javac"/> 

    <include name="com/sun/tools/javac/resources/version.java"/> 

</javac>

Voici maintenant comment compiler les sources du compilateur.
C’est très simple. On indique les 2 répertoires où se trouvent les sources, et le répertoire où se trouveront les fichiers .class.

<echo message="recompiling compiler with itself"/> 

<pathconvert pathsep=" " property="src.javac.files"> 

    <path> 

       <fileset dir="${src.classes}"> 

           <patternset refid="src.javac"/> 

       </fileset> 

       <fileset dir="${build.gensrc}"> 

           <include name="com/sun/tools/javac/resources/version.java"/> 

       </fileset> 

    </path> 

</pathconvert>

ici, on va construire le chemin pour les répertoires les uns derrière les autres en les séparant par un espace.

        <java fork="true"  

            classpath="${build.bootclasses};${src.classes}"  

            classname="com.sun.tools.javac.Main"> 

            <arg value="-sourcepath"/> 

            <arg path="${src.classes}:${build.gensrc}"/> 

            <arg value="-d"/> 

            <arg file="${build.classes}"/> 

            <arg value="-g:source,lines"/> 

            <arg line="${src.javac.files}"/> 

        </java>

Et maintenant, on peut recompiler le compilateur, mais cette fois-ci en utilisant le compilateur que l’on vient de compiler.

        <copy todir="${build.classes}"> 

            <fileset dir="${src.classes}"> 

                <include name="com/sun/tools/javac/resources/*.properties"/> 

            </fileset> 

        </copy>

On copie les fichiers properties à leur bonne place

        <jar destfile="${dist.javac}/lib/javac.jar" basedir="${build.classes}"> 

            <manifest> 

                <attribute name="Built-By" value="${user.name}"/> 

                <attribute name="Built-At" value="${build.time}"/> 

                <attribute name="Main-Class" value="com.sun.tools.javac.Main"/> 

            </manifest> 

        </jar>

et le jar est fait, avec le manifest.

J’ai donc maintenant un fichier jar qui contient un compilateur java.
Mais comment être sûr que le compilateur Java est bien compilé.
En exécutant la batterie de tests qui est livrée avec.