vendredi 5 décembre 2008

Veille technologique semaine 49

Pour cette semaine 49, je vous propose les sujets suivants :
  • sortie de JavaFX en version 1.0. Après plus d'un an depuis l'annonce à JavaOne en juin 2007, SUN propose la technologie JavaFX en version 1.0. Une technologie basée sur Java, pour réaliser des applications IHM pour internet : les RIA (Rich Internet Application). Le terme riche fait référence à l'expérience utilisateur : interactions, look and feel, multimédias, etc... pour des IHM connectés à des applications distantes à travers internet. C'est une technologie qui se place en concurrence de la technologie Air d'Adobe (flash) et de la technologie Silverlight de Microsoft, ou de l'HTML 5. C'est ambitieux de la part de SUN de se placer en challenger.
  • JavaFX c'est quoi ?
  • FAQ JavaFX
  • JavaFX script
  • La version 2.0 des API de persistance : JPA avec les requêtes basées sur des critères typées. C'est une avancé importante sur le chemin de l'intégration d'un langage de requête dans Java, comme LINQ pour C#.
  • LIQUidFORM par google qui propose de résoudre le même genre de problème de requêtes typées pour JPA.
  • Un article technique sur le principe de compression des pointeurs mémoire pour les JVM 64 bits en pointeur 32 bits. Cette compression permet d'avoir les avantages du mode 64 bits du pentium (meilleures performances) sans les inconvénients de la taille des pointeurs 64 bits : la JVM est en mode 64 bits mais avec des pointeurs 32 bits, ce qui donne une mémoire maximum adressable de 32 Go = 4Go x 8 = 32G octets. Question : pourquoi 4 x 8 ? A votre avis ? Réponse dans l'article.
  • L'article suivant est une explication de ce principe de compression de pointeur : oops = "ordinary object pointer"
  • Un article sur l'analyse de la couverture de code. C'est un point incontournable pour augmenter la qualité de code.
Bonne lecture.


JavaFX Technologies At a Glance
JavaFX provides a productive development environment for web developers, mashup authors, and Java developers to quickly and easily build the next generation of rich internet applications (RIAs). With JavaFX, designers and developers can collaborate on building high-impact RIAs. Designers gain a broad set of tools to complete the designer/developer workflow, and developers have a simple, declarative scripting language with the right set of tools.

site JavaFX
http://javafx.com

Quickly and easily create and deploy Rich Internet Applications with JavaFX
It's here. The JavaFX Rich Client platform. A platform and tools suite that offers distinct advantages to Web developers, Web designers, and Java developers that are building rich, connected experiences.


Frequently Asked Questions : JavaFX
JavaFX is an expressive rich client platform for creating and delivering rich Internet experiences across all screens of your life.
JavaFX is fully integrated with the Java Runtime and takes advantage of the performance and ubiquity of Sun's Java Runtime Environment that is installed on literally billions of devices worldwide. In addition, JavaFX fosters a productive and collaborative developer-designer workflow.
Web developers and designers can use JavaFX to imagine, create and express a real experience that jumps out of the browser and into our day-to-day lives. JavaFX is the powerful combination of a scripting language â€" JavaFX Script, a rich client platform and set of tools that enable a complete, productive and collaborative developer-designer workflow.



JavaFX Released: Top 10 Things to Know



Experiments With JavaFX Script

JavaFX was unveiled at JavaOne 2007 as a new initiative for consumer-oriented Java applications. The strategy includes a new programming language called JavaFX Script that is geared towards developing Java-based GUIs, as well as libraries and tools for developing desktop, browser and mobile applications.



Java Persistence 2.0 Public Draft: Criteria API :
Probably the most significant of the new features introduced in the JPA 2.0 Public Draft is the Criteria API. This is a non-string-based API for the dynamic construction of object-based queries.

Criteria queries are constructed in terms of query definition objects.
As with JPQL static and dynamic queries, criteria query definition objects are passed to the EntityManager createQuery method to create Query objectsâ€"and then executed using the methods of the Query API.

Loosely speaking, a QueryDefinition object can be thought of as a set of nodes corresponding to the semantic constructs of the query: domain objects, which correspond to the range variables and other identification variables of the JPQL FROM clause where clause predicates, which comprise one or more conditional expression objects select clauses, which comprise one or more "select item" objects order-by and group-by items subqueries and so on...




LIQUidFORM stands for Language Integrated QUeries
For Object Relational Mapping and is a Java library that provides a Java Domain Specific Language for building type-safe and refactoring proof JPA queries.



Language Integrated Queries For Object Relational Mapping
LIQUidFORM stands for Language Integrated QUeries For Object Relational Mapping and is a Java library that provides a Domain Specific Language for
building type-safe and refactoring proof JPA queries. While the project draws its inspiration from the LINQ project, it is not LINQ for Java : its aim is only to help in writting JPA queries against your domain model. Read on to understand what LIQUidFORM is and what it is not.



32-bit or 64-bit JVM? How about a Hybrid?
Before x86-64 came along, the decision on whether to use 32-bit or 64-bit mode for architectures that supported both was relatively simple: use 64-bit mode if the application requires the larger address space, 32-bit mode otherwise. After all, no point in reducing the amount of data that fits into the processor cache while increasing memory usage and bandwidth if the application doesn’t need the extra addressing space.

When it comes to x86-64, however, there’s also the fact that the number of named general-purpose registers has doubled from 8 to 16 in 64-bit mode. For CPU intensive apps, this may mean performance at the cost of extra memory usage. On the other hand, for memory intensive apps 32-bit mode might be better in if you manage to fit your application within the address space provided. Wouldn’t it be nice if there was a single JVM that would cover the common cases?



Compressed oops in the Hotspot JVM
What's an oop, and why should they be compressed?
An "oop", or "ordinary object pointer" in HotSpot parlance is a managed pointer to an object. It is normally the same size as a native machine pointer, which means 64 bits on an LP64 system. On an ILP32 system, there is a maximum heap size of somewhat less than 4Gb, which is not enough for many applications. On an LP64 system, though, the heap for any given run may have to be around 1.5 times as large as for the corresponding IPL32 system (assuming the run fits both modes). This is due to the expanded size of managed pointers. Memory is pretty cheap, but these days bandwidth and cache is in short supply, so significantly increasing the size of the heap just to get over the 4Gb limit is painful.


L'analyse de couverture de code en Java
Il ne reste plus grand monde pour soutenir que l'écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel - la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :
Le conservatisme - pour ne pas dire la stupidité - de certains chefs de projet, qui persistent à voir dans l'écriture des tests une activité contre-productive, qui servira de variable d'ajustement au moindre coup de grisou. L'existant : quand le projet n'a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?

Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.
Pour le second, il faut un peu de bon sens, et un peu d'outillage.

C'est sur le deuxième aspect qu'interviennent les outils d'analyse de couverture de code (ou "code coverage" en anglais). Dans la suite, nous verrons que ces outils ne permettent pas
d'évaluer les tests unitaires d'un point de vue qualitatif, mais qu'ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :
  • Quels sont les tests unitaires déjà en place ?
  • Les tests sont-ils en phase (à jour) avec le code qu'ils testent ?
  • Les fonctions critiques de l'application sont-elles couvertes par les tests ?

Aucun commentaire: