vendredi 19 juin 2009

Veille technologique semaine 25

Pour cette semaine 25, je vous propose l'actualité suivante :
  • Oracle confirme son intérêt pour JavaFX
  • Deux articles de Wikipedia, à propos de la programmation déclarative versus la programmation impérative.
  • L'intégration de la géolocalisation dans les navigateurs internet avec html 5.
  • HTML 5 peut-il concurrencer flash, JavaFX ou silverlight ?
  • Une comparaison du développement de logiciel pour les plates-formes smartphone : JavaFX, Androide et iPhone.
  • L'invocation dynamique dans la JVM : performance pour les langages à typage dynamique : Groovy, JRuby, Jython ...
  • Un article au sujet du projet Jigsaw intégré au JDK 7 : première conséquence visible, la suppression du classpath ! Explication.
  • La suite avec la comparaison Jigsaw et OSGi.
  • Java et le temps réel : c'est quoi le temps réel et le runtime Java
  • Java et le temps réel : IBM propose un outil.
  • Un résumé des visisbilités en Java : public, protected, pakage private, private : conséquence.
Bonne lecture


Oracle s'investit dans JavaFx
Du moins, Larry Ellison, qui suggère de ré-écrire l'UI de OpenOffice en utilisant JavaFx.
En attendant cette hypothétique révolution, le framework de Sun a dévoilé quelques nouveautés durant JavaOne, en ajout à la sortie de la version 1.2 dont nous nous faisions l'écho la semaine dernière
.
  • Démonstration d'un outil collaboratif de développement : en plus des annonces de renforcement du développement du plugin JavaFx-Eclipse, Sun a donné une démonstration publique d'un outil de création graphique assez impressionnant : gestion de la Scene, drag and drop de composants, d'effets... Reste à savoir quand celui ci sera disponible...
  • Autre démonstration, plus attendue, celle de JavaFx for TV, avec une application réalisant des prévisualisations et des téléchargements de films à partir d'un téléviseur LG.



Imperative programming
In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way that imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.
The term is used in opposition to declarative programming, which expresses what needs to be done, without prescribing how to do it in terms of sequences of actions to be taken. Functional and logical programming are examples of a more declarative approach.


Declarative programming
In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow. Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it. This is in contrast from imperative programming, which requires a detailed description of the algorithm to be run.


La géolocalisation dans les navigateurs
HTML 5, la nouvelle mouture du célèbre langage à balises, va intégrer un certain nombre de nouveautés très intéressantes (voir ce billet). Parmi ces nouveautés, la balise ; qui permettra d'intégrer la géolocalisation dans les navigateurs de PC ou de téléphones.
Cette fonction permettra de développer facilement des applications Web contextuelles. Rappelons qu'il est aujourd'hui nécessaire de développer une application embarquée pour tirer parti de la géolocalisation. C'est une des raisons pour lesquelles le développement d'application iPhone connait un tel engouement : une simple application web ne permet pas de tirer partie du GPS. Un bon exemple de ce problème est l'application PagesJaunes (développée par SQLI...) : sa seule différence avec la version Web iphone.pagesjaunes.fr (http://iphone.pagesjaunes.fr) est la géolocalisation préalable à une recherche d'adresse.


HTML 5: Could it kill Flash and Silverlight?
HTML 5, a groundbreaking upgrade to the prominent Web presentation specification, could become a game-changer in Web application development, one that might even make obsolete such plug-in-based rich Internet application (RIA) technologies as Adobe Flash, Microsoft Silverlight, and Sun JavaFX.


Mobile Application Contest : Java FX - Android - iPhone
Dans le cadre de nos XKE (formations internes), beaucoup d'entre nous ont émis le souhait
d'étendre leur champ de compétence au développement d'application sur téléphone mobile. Nousavions plusieurs technologies dans nos bagages : l'installé iPhone (à première vue pas vraiment compatible avec des développeurs Java), l'étoile montante Android, et l'outsider JavaFx. Mais pour voir au-delà des promesses marketing, il nous fallait nous mesurer à ces technologies dans le cadre de leur utilisation réelle, sur un projet de la 'vraie vie'. Ainsi est née l'idée de ce contest : 3 technologies, 3 développeurs Java (Amin Fathallah sur iPhone, Erwan Alliaume sur Android, Pablo Lopez sur JavaFx), et un mois (sur notre temps libre) pour traiter d'un sujet choisi par nos collègues : afficher sur le téléphone mobile l'ensemble des photos Flickr à proximité de l'utilisateur géolocalisées sur une carte. Chaque technologie a donné lieu à une démo en live et une analyse du ressenti lors du XKE suivant.

Résultats et commentaires
Commençons par un survol des démos : JavaFx très poussif, sur émulateur. Pas un franc succès. Android sur un G1 flambant neuf, très convaincant, notamment par les divers ajouts hors cahier des charges. Large vainqueur à l'applaudimètre, l'iPhone, avec une UI très soignée et des effets graphiques à la hauteur de la réputation du célèbre terminal. Dans le même ordre, voici l'analyse de chacun des développeurs.


L'invocation dynamique pour Java se concrétise
Rémi Forax, l'un des 4 committers d'ASM, un framework de manipulation de bytecode largement utilisé dans le monde Java, vient d'annoncer que leur dernière version supportait l'instruction invokedynamic.

Cette instruction est définie par la JSR-292 et vise à simplifier l'invocation de méthodes non connues lors de la compilation, ce qui constitue une des principales capacités des langages dynamiques tels que Groovy. Un gain significatif de performance est donc attendu pour ces langages, puisqu'ils n'auront alors plus à s'appuyer sur un coûteux mécanisme d'introspection ou de génération dynamique de bytecode d'invocation.

Au delà des langages dynamiques qui sont les premiers destinataires de cette JSR, de nombreux frameworks pourront également profiter de cette possibilité. En effet, la manipulation de JavaBeans et d'annotations, deux concepts majeurs dans le monde JEE actuel, induisent de nombreuses invocations de méthodes découvertes au runtime. Dans de larges projets, cela conduit actuellement à la génération massive de bytecode pour éviter de très lentes introspections, induisant une forte consommation de la PermGen des JVMs.

Le support de l'instruction invokedynamic par ASM, combiné au fait que le draft actuel de la JSR-292 est d'ores et déjà implémenté et disponible dans la preview de l'OpenJDK 7 depuis la b59, permet d'être optimiste quant à la finalisation prochaine de cette JSR.


Classpath hell just froze over
"The classpath is dead" … that's what Mark Reinhold (Principal Engineer @ Sun) said at a general session during JavaOne 2009. It's the type of statement that should resonate with any of us who have been victims of classpath/jar hell. Mark announced this in the context of reviewing the new language features due to be released in JDK 7 (ETA 2010) or more specifically the new Java module system codenamed Jigsaw.

Module Systems and Jigsaw
Jigsaw is a low level implementation of a module system, which also includes some language and VM changes that are specified in JSR 294 (note that Jigsaw is being done outside of any JSR and is not a reference implementation of 294). Another implementation of a module system most Java developers are likely more familiar with is OSGi. But what is a module system and why do we need one?


Java Modularity - OSGi and Project Jigsaw
The JSRs Initially, there were three primary JSRs surrounding Java modularity - JSR 277, JSR 294, and JSR 291. Descriptions follow:

  • JSR 277 - Also known as the Java Module System, JSR 277 was an alternative module system being proposed that would have provided similar, though less, than what OSGi currently provides.
  • JSR 291 - Proposed by IBM around 2006, JSR 291 defines a dynamic component model for Java SE. This JSR brought OSGi into the JCP. In general, this did for Java SE what JSR 232 did for Java ME.
  • JSR 294 - Currently in progress, this JSR will define the language and virtual machine changes that will be made to support modularity on the Java platform.

Today, JSR 277 is inactive, JSR 291 is final, and JSR 294 is in progress. That makes it all seem rather simple. But things get messy pretty quickly. JSR 294 does not define a module system, it simply specifies changes to the language and VM that module systems can leverage. The intent is that module systems be built atop JSR 294. And today, there are two separate module systems for the Java platform - Project Jigsaw and OSGi.
The Module Systems
Many have heard of OSGi. It's been around for over 10 years, originated in the mobile and embedded systems space, was popularized by the Eclipse foundation upon adoption for it's plugin system, and is currently being leveraged by every major application platform vendor, including Sun's Glassfish product. Jigsaw, however, is not as mature nor as well-known.


Realistically real-time
Real-time Java application development using multicore systems

Javolution creator Jean-Marie Dautelle discusses different methods to reduce the worst-case execution time of Java applications by leveraging the extra processing power of multicore systems. The methods described here do not require specialized real-time virtual machines and are suitable for many types of applications for which unexpected delays in the tens or hundreds of milliseconds are not acceptable.

Real-time response is a requirement in Java application domains such as banking, online collaboration, and games development, as well as for safety critical applications used in hospitals, manufacturing, aviation, and emergency response systems. Unfortunately, the Java platform has long suffered from its erratic response time. Java applications are known to freeze because the garbage collector has "stopped the world." Incremental garbage collection (-Xincgc) improves this situation, but it does not completely eliminated the nasty "full GC" pauses associated with the Java platform.


IBM Real Time Application Execution Optimizer for Java
A tool that operates on compiled Java applications to optimize and verify application deployment in specialized environments.

What is IBM Real Time Application Execution Optimizer for Java?
IBM Real Time Application Execution Optimizer for Java helps to optimize and verify a compiled Java application, preparing the application for deployment in specific environments. It is a command line tool that can operate on any compiled Java application, whether standard edition, micro-edition, or real-time.

The tool provides the following functions:
  • Escape analysis of objects per method invocation
  • Control flow analysis that splits an application into archives according to thread accessibility
  • Control flow analysis that detects potental occurrences of real-time java runtime errors
  • MemoryAccessError, IllegalAssignmentError, IllegalThreadStateException
  • Control flow analysis that determines entry points into an application
  • Addition of stackmaps to Java class files
  • Verification of Java class files
  • Auto-generation of classes that will load and initialize all other classes within the same archive
  • Specialized packaging of Java applications into deployable archives by packaging all referenced
  • Classes from a dual class path
  • Removal of unwanted attributes from Java class files

Les modificateurs de visibilité en Java


Aucun commentaire: