mardi 8 mai 2012

Veille technologique semaine 18

Pour le bulletin de la semaine 18, je vous propose les sujets suivants :
  • la première semaine du procès d'Oracle contre Google au sujet d'Android. Oracle demande 1 milliards de dollars à Google.
  • Android porté sur C# : une solution alternative ?
  • Le JDK 7 update 4 passe en version de Java par défaut sur le site www.java.com
  • Quelle est la valeur ajouté d'une bonne architecture logcielle ?
  • Les values types pour la JVM ? C'est quoi ? C'est déjà présent dans C# dès la version 1.
Bonne lecture.

Google vs Oracle : un feuilleton judiciaire émaillé d'indiscrétions
Le 16 avril 2012 s'est ouvert le procès entre Oracle et Google devant la cour fédérale de Californie. Oracle, spécialiste de la gestion de bases de données, accuse Google de violation de propriété intellectuelle. C'est plus particulièrement Android qui est visé. Oracle affirme que la firme de Mountain View utilise du code Java sans sa permission. Le géant du logiciel a racheté Sun en 2010, inventeur de Java et détenteur de brevets sur ce langage... dont Google s'est servi pour construire Android.


Android Ported to C#
Oracle and Google are currently in a $1 billion wrestling match over Google's use of Java in Android. But Java is not the only way to build native apps on Android. In fact, it's not even the best way: we have been offering C# to Android developers as a high-performance, low-battery consuming alternative to Java. Our platform, Mono, is an open source implementation of the .NET framework that allows developers to write their code using C# while running on top of the Javapowered operating system, and then share that same code with iOS and Windows Phone.


XobotOS: Android Build on C# Instead of Java
Miguel de Icaza, Mono's founder, recently announced the creation of the XobotOS research project. XobotOS is the Android operating system with all Java code removed and C# code put in its place. Miguel offers two compelling reasons behind this research project:

Unlike Sun with Java, Microsoft submitted C# and the .NET VM for standardization to ECMA and saw those standards graduated all the way to ISO strong patent commitments. The .NET framework is also covered by Microsoft's legally binding community promise.


Moving to Java 7 as default
Back in February, I wrote a post on this blog stating that the End Of Life (EOL) of public support and public releases for JDK 6 was extended to November 2012, With the release of Java SE 7 Update 4, the Java SE 7 runtime is now available on java.com as the default JRE.


Java 7 update 4

New Supported Garbage Collector: Garbage First (G1)
Starting in Java SE 7u4 the Garbage First Collector is fully supported. The G1 collector is targeted for applications that fully utilize the large amount of memory available in today's multiprocessor servers, while still keeping garbage collection latencies under control. Applications that require a large heap, have a big active data set, have bursty or non-uniform workloads or suffer from long Garbage Collection induced latencies should benefit from switching to G1. For more detailed information about G1 see the G1 documentation page and command line options.
The G1 garbage collector – though not a real-time garbage collector – provides a much faster throughput of allocation/collection, which significantly limits the amount of full GC pauses that are often seen with prior garbage collectors. A presentation on G1 was available in JavaOne 2008, and is based on the ACM paper A generational mostly-concurrent garbage collector. To enable the G1 garbage collector in Java7u4, the same +XX:+UseG1GC is used as detailed on the VM command line options page, and more information is available via the garbage first collector description page.


Java 7u4 Brings Support for OSX
Last week's update of Java 7u4 brought about a number of minor changes to the runtime, including for the first time a release of JDK and JavaFX SDK for Mac OSX.

Prior to this release, Java releases for OSX have come through Apple who in recent years backed away from Java as a runtime platform. With the release of OpenJDK, instead of vendors providing their own variants and customisations on top of the platform, the goal is to have everyone converge on OpenJDK as the reference implementation. One advantage of this is that by moving the support upstream, security fixes will be made available for all platforms at the same time, instead of on a platform-by-platform basis. (Apple was particularly bad at releasing timely updates for its Java runtime; the recent spate of Flashback trojans and viruses were made possible through a Java security hole in Apple's original implementation which had been fixed for a while in OpenJDK.) It is worth noting that it is a 64-bit only build on Lion or later.


Is it worth the effort to design software well?
Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later.
The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better. We CannotMeasureProductivity nor can we measure design quality.


value types in the vm
Introduction
A value type is a data type which, generally speaking, is designed for being passed by value in and out of methods, and stored by value in data structures. The only value types which the Java language directly supports are the eight primitive types. Java indirectly and approximately supports value types, if they are implemented in terms of classes. For example, both Integer and String may be viewed as value types, especially if their usage is restricted to avoid operations appropriate to Object. In this note, we propose a definition of value types in terms of a design pattern for Java classes, accompanied by a set of usage restrictions. We also sketch the relation of such value types to tuple types (which are a
JVM-level notion), and point out JVM optimizations that can apply to value types.
This note is a thought experiment to extend the JVM's performance model in support of value types. The demonstration has two phases. Initially the extension can simply use design patterns, within the current bytecode architecture, and in today's Java language. But if the performance model is to be realized in practice, it will probably require new JVM bytecode features, changes to the Java language, or both. We will look at a few possibilities for these new features.


Value Types (C# Reference)
Variables that are based on value types directly contain values. Assigning one value type variable to another copies the contained value. This differs from the assignment of reference type variables, which copies a reference to the object but not the object itself.
All value types are derived implicitly from the System.ValueType.
Unlike with reference types, you cannot derive a new type from a value type. However, like reference types, structs can implement interfaces.
Unlike reference types, a value type cannot contain the null value. However, the nullable types feature does allow for values types to be assigned to null. Each value type has an implicit default constructor that initializes the default value of that type. For information about default values of value types, see Default Values Table.

Aucun commentaire: