vendredi 29 juillet 2011

Veille technologique semaine 30

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • Sortie du JDK 7, comme prévu, le 28 juillet 2011 : articles sur le contenu avec les détails de la documentation.
  • Un article sur le pattern "Disruptor".
  • OSGi et la gestion des modules partagés.
  • Java et la réflexivité des génériques.
  • La définition des classes non mutables
  • La déclaration des variables : la forme dépends du langage de programmation.
  • La taille des objets en Java.
  • La taille des tableaux en Java.

Bonne lecture.


Java SE 7 Released: First Major Update Since December 2006
Java 7 is generally available from today, the first release of the Java platform since Oracle's acquisition of Sun. The release includes a number of small but welcome changes to the language, incorporates a new file API and the Fork/Join Framework, and improves dynamic language support on the JVM.

For Java 7 language changes have been managed as part of Project Coin (JSR 334), a successor to JSR 201, designed to enhance the Java language with an assortment of small changes to improve productivity. Of particular note is the introduction of "try-with-resources". This is analogous to C#'s using statement but based on a form of the try statement. As a result, whilst the using statement only takes a single resource, try-with-resources is able to handle multiple resources within the scope of a given block. Two changes have been made to exception handling. First, multiple exception types can be named as being handled by a single catch block. The grammar of a catch clause of a try statement is extended to allow a series of exception types, separated by the "OR" operator symbol, "|", to be used in the declaration of the exception parameter. Second, if an exception parameter is not modified and if it is rethrown inside the catch block, you don't now have to add the exception to the method signature.


Java SE 7 Downloads
This release includes new features such as small language changes for improved developer productivity, a new Filesystem API, support for asynchronous I/O, a new fork/join framework for multicore performance, improved support for dynamic and script languages, updates to security, internationalization and web standards and much more.


Java Platform Standard Edition 7 Documentation
Oracle has two products that implement Java Platform Standard Edition (Java SE) 7: Java SE Development Kit (JDK) 7 and Java SE Runtime Environment (JRE) 7.
JDK 7 is a superset of JRE 7, and contains everything that is in JRE 7, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 7 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language.

What's New in Documentation
Documentation is regularly updated to provide developers with in-depth information about new features in the Java platform.


Java as a platform and a language
Welcome to Java 7. Things around here are a little different than you may be used to. This is a really good thing—we have a lot to explore now that the dust has settled and Java 7 has been unleashed. By the time we finish our journey, you'll have taken your first steps into a larger world—a world of new features, of software craftsmanship, and other languages on the JVM.
 
We're going to warm you up with a gentle introduction to Java 7, but one that still acquaints you with its powerful features. We'll showcase Project Coin, a collection of small yet effective new features. You'll learn new syntax, such as an improved way of handling exceptions (multi-catch). You'll also learn about Automatic Resource Management and how it helps you to avoid bugs in the code that deals with files or other resources. By the end of this paper, you'll be writing Java in a new way and you'll be fully primed and ready for bigger topics.
Let's get going! We'll first dive into a critically important duality that lies at the heart of modern Java. This is a point that we'll come back to again throughout the book, so it's an absolutely essential one to grasp.


Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad
Martin Fowler has written a really good article describing not only the Disruptor, but also how it fits into the architecture at LMAX. This gives some of the context that has been missing so far, but the most frequently asked question is still "What is the Disruptor?". I'm working up to answering that. I'm currently on question number two: "Why is it so fast?". These questions do go hand in hand, however, because I can't talk about why it's fast without saying what it does, and I can't talk about what it is without saying why it is that way. So I'm trapped in a circular dependency. A circular dependency of blogging.


OSGi: Because Sharing Shouldn't Be Painful
At the dawn of Windows, applications were statically linked and life was simple; applications carried their own dependencies so there was never confusion. However, this simplicity had its costs.


Java Reflection: Generics
I have often read in articles and forums that all Java Generics information is erased at compile time so that you cannot access any of that information at runtime. This is not entirely true though. It is possible to access generics information at runtime in a handful of cases. These cases actually cover several of our needs for Java Generics information. This text explains these cases.

Here is a list of the topics covered in this text:
1. The Generics Reflection Rule of Thumb
2. Generic Field Types
3. Generic Method Return Type
4. Generic Method Parameter Types



Defining immutable classes
To make a Java class immutable, you must:
  • Make all fields final.
When you define fields as final in Java, you must either initialize them at declaration time or in the constructor. Don't panic if your IDE complains that you don't initialize them at the declaration site. It'll realize that you've come back to your senses when you write the appropriate code in the constructor.
  • Make the class final so that it cannot be overridden.
If the class can be overridden, its methods' behaviors can be overridden as well, so your safest bet is to disallow subclassing. Notice that this is the strategy used by Java's String class.
  • Do not provide a no-argument constructor.
If you have an immutable object, you must set whatever state it will contain in the constructor. If you have no state to set, why do you have an object? Static methods on a stateless class would work just as well. Thus, you should never have a no-argument constructor for an immutable class. If you're using a framework that requires this for some reason, see if you can satisfy it by providing a private no-argument constructor (which is visible via reflection).
Notice that the lack of a no-argument constructor violates the JavaBeans standard, which insists on a default constructor. But JavaBeans cannot be immutable anyway, because of the way the setXXX methods work.
  • Provide at least one constructor.
If you haven't provided a no-argument one, this is your last chance to add some state to the object!
  • Do not provide any mutating methods other than the constructor.
Not only must you avoid typical JavaBeans-inspired setXXX methods, but you must also be careful not to return mutable object references. The fact that the object reference is final doesn't mean that you can't change what it points to. Thus, you need to make sure you defensively copy any object references you return from getXXX methods.


Reversed type declarations
I can't write about Kotlin without first talking about the folly of "reversed" type declarations. Sadly this disease has afflicted Scala, Gosu and now Kotlin (but perhaps its not yet too late for Kotlin ;-).


Java: Getting the size of an Object
Java was designed with the principle that you shouldn't need to know the size of an object. There are times when you really would like to know and want to avoid the guess work. Measuring how much memory an object uses


Java: How much memory do different arrays consume
Arrays can be large and consume a significant amount of memory. It can me worth choosing the most memory efficient array/collection. Comparing array sizes.

Aucun commentaire: