Je vous propose, pour cette semaine, la petite sélection suivante :
- Java Temps Réel a été retenu pour le réalisation du logiciel pour un radar de surveillance,
- Microsoft travaille sur un container à injection de dépendance pour compléter le framework DotNet,
- Java a perdu la bataille du Web : les raisons et cela peut-il changer, rattrapé ?
- Le JDK 6 propose une petite classe java.util.ServiceLoader qui n'a l'air de rien mais qui peut être très utile pour faire de l'intégration de services via le JDK : à suivre.
- La liste de l'update 10 du JDK 6 : c'est une mise à jour du JDK 6 assez importante : l'implémentation du pipe Java2D sur Direct X pour windows est enfin terminé, le JRE est fractionné en plusieurs parties (Java Kernel), look and feel Nimbus, ...
- La suite de la semaine dernière sur les API du compilateur Java
- L'annonce de SUN sur le début de la fin du JDK 5. Le JDK 5 entre dans sa période de fin de vie (End Of Life) à partir du 8 avril 2008 jusqu'au 8 octobre 2009. Pour bénéficier des corrections critiques, SUN propose de migrer sur le dernier JDK gratuitement, ou de passer un mode de maintenance du JDK 5 financé.
Sun Java Real-Time System Selected for Space Surveillance Radar
The Java Real-Time specification has been chosen to be launched into space to provide a reliable platform for the Eglin Space Surveillance Radar as part of it's upgrade from legacy components.
Java Real-Time, a high-level development platform for creating applications that require unprecedented execution predictability, will be running on Solaris 10 enabling the radar to move from legacy, one of a kind software to a more standard platform.
"Our comprehensive tests have proven that Sun Java RTS running on Solaris 10 OS meets the real time behavior and throughput requirements for Eglin Space Surveillance Radar," said Matt Prechtel, ITT's Software Lead for the project. "We are looking forward to moving to a software platform based on the Real-Time Specification for Java and are actively evaluating Java RTS for other projects."
Compliance with this open standard enables us to use off-the-shelf hardware and operating systems plus offering us a lot more flexibility in terms of solution design." I find it very interesting that Java has been chosen for this project. The selection of the Java RTS for this job is big news - as a specification it never really seemed to get off it's feet. I wonder why Scala wasn't chosen, as it boosts an impressive, easy to use concurrency API.
If you were developing a time critical application, what would you choose? Is that Java RTS enough for a full modernization of such a sytem, or should they go a step further?
The Microsoft patterns & practices group has released its Dependency Injection container called Unity or the Unity Application Block. Developers can now create loosely coupled applications that are extensible using this lightweight container. InfoQ had the opportunity to talk with Chris Tavares, the lead developer of the Unity project.
Unity is a Dependency Injection (DI) container. The standard article describing DI is from Martin Fowler. As a quick summary, a DI container is a tool you can use to support building highly decoupled software. The DI container takes care of the details of which objects are interconnected, so you can build each one independently. This has a big impact for both testability and flexibility of the resulting code.
"Java is losing the battle for the modern web"...
Simon MacDonald pointed out a blog post from Andi Gutman, with the title "Java is losing the battle for the modern Web. Can the JVM save the vendors?" It's an interesting and challenging post from one of the founders of Zend Technologies. Why is this post relevant? Well, for one thing, as one of the authors of PHP, Andi can be described as being someone with influence – look at how many MySQL errors people can describe with Andi's work product. More seriously, Andi makes a lot of points about dynamic languages on the JVM, now getting a lot of traction from nearly all quarters.
Java is losing the battle for the modern Web. Can the JVM save the vendors?
A few years ago I worked on a very big Enterprise IBM Websphere project. We had some brilliant engineers in the project both in the development and architecture groups. I remember having had several discussions with some of the brightest people on the team regarding PHP and dynamic languages and generally they were looked upon as toy languages without a bright future. Lack of strict typing, scripting performance, and other reasons were given for why Java would persevere as the language of choice.
I was looking for a simple, low-overhead way to do plug-ins and the service provider mechanism in the jar file specification seems to fit the bill, is dead-simple (once you grok the doc), and requires almost no coding on my part: Java automatically finds the plug-ins at startup and they can be retrieved by a call to the static ServiceRegistry.lookupProviders() method. I can't help but wonder if something's wrong with this since I haven't ever run across it before, (though, I must admit, it hadn't ever occurred to me to read the Jar file spec), and googling for service discovery strategies brought up little useful information about it.
A simple service-provider loading facility.
Introducing Java 6 update 10
Don't be fooled by its unassuming name: the upcoming Java 6 update 10 is a very different animal than the updates that preceded it. Java 6u10 pushes the envelope by adding more new features and functionality than in any previous Java programming language update release, including many that have been a long time coming.
Officially, a "Java update release" is a release in which only the fourth version number (the 10 in 1.6.0_10) changes. Unlike major releases, update releases are not allowed to add, remove, or change any public APIs, and generally this has limited update releases to only containing bug fixes. 6u10 likewise contains no new or changed public APIs -- but despite that restriction, we still managed to squeeze in some incredible new features.
Why A Special Update Release?
- Java Kernel
- Next-Generation Java Plug-In
- Java Deployment Toolkit
- Nimbus Look and Feel
- Deployment Usability
- But Wait, There's More!
The Java Compiler API
Most developers think of the Java compiler, javac, as an unobtrusive command-line tool to invoke when you want to turn Java source code into class files. The Java Compiler API, JSR 199, released in final form last December, opens up the Java compiler to programmatic interaction as well. Artima spoke with JSR 199 spec lead and Sun engineer Peter von der Ahé about what programmatic compiler access means for developers.
Java SE 5.0 is in its Java Technology End of Life (EOL) transition period.
The EOL transition period began April 8th, 2007 and will complete October 8th, 2009, when Java SE 5.0 will have reached its End of Service Life (EOSL).
Customers interested in continuing to receive critical fixes, are encouraged to consider the following options:
- Migrate to the latest Java SE release
- Migrate to Java SE for Business 5.0