vendredi 22 juillet 2011

Veille technologique semaine 29

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • Un bilan six semaine après le jour de l'IPV6 : avez-vous vérifié votre connectivité IPV6 ?
  • Le JDK 7 est toujours prévu pour fin juillet 2011 : quelques vidéos de présentations sur le web.
  • Un article sur le code mal conçus et mal écrit : c'est un problème de qualité non fonctionnel qui se traduit par une bombe à retardement. Il faut être très vigilant sur la qualité de conception, pour éviter une dégénérescence de l'application.
  • Un article d'Oracle au sujet de la programmation concurrente (multi-thread) et du fork / join du JDK 7.
  • Un nouvel article (en français) sur les principes SOLID : Single responsibility principle, Open close principle,  Liskov principle, Interface segregation principle, Dependency inversion principle.
  • Une synthèse du principe d'injection de dépendance.
  • La modularité avec OSGi : l'injection de dépendance avec et sans OSGi.
  • Le primitifs Java sont plus performants que les wrappeurs correspondants : réfléchir à deux fois avant d'avoir des problèmes de performances.
  • Les dépendances cycliques dans un logiciel sont interdites : comment les supprimer.
  • Le JDK 5 et le toString() des tableaux.
Bonne lecture.

Six weeks after World IPv6 Day, what have we learned?
Last month's World IPv6 Day created some excitement about IPv6. Once it was over, however, everyone went back to work—which for most people doesn't include anything IPv6-related.
The idea behind World IPv6 Day on the 8th of June was to flush out broken IPv6 setups by simultaneously turning on IPv6 across a large number of Web properties —including the four largest in the world. Few, if any, problems were reported, so in that sense WIPv6D was a resounding success. Apparently, it's possible to add IPv6 addresses to large Web destinations without significant adverse effects.

Java SE7 To Arrive At End Of July
On Monday, The Java Community Process completed voting on the final approval ballots for Java SE7, and all JSRs were given the green light.

This completes the JCP's work on Java 7, but there's a few more steps to finishing the product, according to Mark Reinhold, the Chief Architect of Oracle's Java Platform Group:

At this point all of the work required to define the abstract Java SE 7 Platform in the JCP is done but the actual product, JDK 7, is not quite finished.

Here at Oracle we're busy wrapping up final testing of the release candidate, build 147. If all goes well then that will be declared the GA build on 28 July per the schedule posted in January. Oracle's commercial binaries, based almost entirely on OpenJDK code, will be published that day; implementations from other vendors will follow.


See the replays for all technical breakouts below:
• Making Heads and Tails of Project Coin, Small Language Changes in JDK 7 (Presentation/PDF)
• Divide and Conquer Parallelism with the Fork/Join Framework (Presentation/PDF)
• The New File System API in JDK 7 (Presentation/PDF)
• A Renaissance VM: One Platform, Many Languages(Presentation/PDF)
• Meet the Experts: Q&A and Panel Discussion

Watch the Java 7 Celebration Webcast
Oracle is committed to Java: the technology, the community, the Java Community Process (JCP), and the entire ecosystem focused on moving Java forward.
Watch this Webcast to find out more about the features of Java 7, hear from technologists at companies that use Java technology, and learn through a series of technical presentations and a panel discussion.

Bad Code: The Invisible Threat
One of the first things said by the non-believers of the software craftsmanship movement was that good and clean code is not enough to guarantee the success of a project. And yes, they are absolutely right. There are innumerable reasons which would make a project to fail ranging from business strategy to competitors, project management, cost, time to
market, partnerships, technical limitations, integrations, etc. Due to the amount of important things a software project may have, organizations tend not to pay to much attention to things that are considered less important, like the quality of the software being developed. It is believed that with a good management team, deep hierarchies, micro management, strict process and a large amount of good documentation, the project will succeed.

How do the new fork/join tasks provided by Java SE 7 make it easier to write parallel programs?

Multicore processors are now widespread across server, desktop, and laptop hardware. They are also making their way into smaller devices, such as smartphones and tablets. They open new possibilities for concurrent programming because the threads of a process can be executed on several cores in parallel. One important technique for achieving
maximal performance in applications is the ability to split intensive tasks into chunks that can be performed in parallel to maximize the use of computational power. Dealing with concurrent (parallel) programming has traditionally been difficult, because you have to deal with thread synchronization and the pitfalls of shared data. Interest in language-level support for concurrent programming on the Java platform is strong, as proven by the efforts in the Groovy (GPars), Scala, and Clojure communities. These communities all try to provide comprehensive programming models and efficient implementations that mask the pain points associated with multithreaded and distributed applications. The Java language itself should not be considered inferior in this regard. Java Platform, Standard Edition (Java SE) 5 and then Java SE 6 introduced a set of packages providing powerful concurrency building blocks. Java SE 7 further enhanced them by adding support for parallelism.

Les principes SOLID
A l'heure où de nombreux débats font rages sur l'éventuel successeur du langage Java, le XKE (Xebia Knowledge Exchange) de Mars a été l'occasion de faire un retour sur les fondamentaux de la conception Orienté Objet.
Faisons un petit sondage dans la communauté : quels arguments avanceriez-vous en faveur du langage Java ?
Parmi les principaux arguments, il est fort à parier que les réponses seront en majorité les applets (heu… non plus maintenant… mais souvenez vous dans les années 90), la JVM, le crossplatform, le monde Open Source et la Communauté, les nombreux frameworks, la simplicité d'écriture et la gestion de la mémoire, les IDEs, etc.

A beginners guide to Dependency Injection
This article presents a high level overview of Dependency Injection (DI). It aims to present the overall  concept of Dependency Injection to the junior developer within the context of how it could be used in a  variety of DI containers.

Dependency Injection (DI) or Inversion of Control (IOC) ?

OSGi: A Proven Approach for Developing Modular Applications
OSGi is about how to create a useful application by installing a set of (preferably reusable) modules in a framework. Basically, we set out in 1998 to solve the component programming model; amazingly I think we largely succeeded looking at the many successful OSGi projects. Mission accomplished?
comment on this article Not really, looking at the often heated debate around OSGi in the Enterprise world: Spring, Jigsaw, etc.
Many love it, some seem to hate it with a vengeance (Come on guys, get a life, this is only technology). My explanation is that OSGi violates some Enterprise developers' basic expectations that it should just be a library on your class path, providing some useful and convenient functions but otherwise staying out of the way.

Low GC in Java: Use primitives instead of wrappers
There are two good reason to use primitives instead of wrappers where possible. Clarity. By using a primitive, you are making it clear that a null value is not appropriate.
Performance. Using primitives is often much faster. Clarity is often more important than performance, and is the best reason to use them. However, this article discussed the performance implications of using wrappers.

Breaking Dependency Cycles
If you look into rules for good software design you!ll probably come around the notion that dependency circles are bad. From my interview experience I!d say that many of the more experienced developers know that rule. And almost everybody agrees to that rule when asked. (Of course that might be due to the way I phrase the question. Some people say I can be pretty … convincing).

Stringifying Java Arrays
J2SE 5 provided significant new language features that made Java significantly
easier to use and more expressive than it had ever been. Although "big" new J2SE 5  features such as enums, generics, and annotations, there was a plethora of new APIs and methods that have made our lives easier ever since. In this post, I briefly look at two of my favorites when dealing with Java arrays:
the Arrays.toString(Object[]) method and the Arrays.deepToString(Object[]) method.

Aucun commentaire: