Entre lo nuevo que podemos ver en este set:

• El look-and-fell llamado Nimbus (para verlo es necesario tener la última actualización de Java, a la fecha: Java SE 6 Update 10)
• Una manera más fácil de ver el código de alguna característica en particular.
• Una manera más fácil de añadir nuevos demos de componentes.
  
• Nuevas características en algunos componentes.
• Etc.

Nuevas características: ver JTable

Referencias???

Visiten: https://swingset3.dev.java.net/ ahi está todo 

http://www.innovation.ch/java/java_compile.htm

¿No habrá BlueJ en línea? O por lo menos que acepte un proyecto BlueJ y lo compile ... para ir trabajando en un café internet.

Ejemplo:

  class Autoboxing   {     public void prueba()   {       Integer i = 4;       if (4 instanceof Integer)         System.out.println("Yes!");       else         System.out.println("No chango");       }   }    

Error de compilacion:

[macpablo:~/tmp] pablo% javac Autoboxing.java
Autoboxing.java:7: unexpected type
found   : int
required: reference
    if (4 instanceof Integer)
        ^
1 error
 

• The early JDK 7 build 20 is a step in the right direction. It’s performance is better than JDK 6 in every(!) benchmark ...
• Saying that C is generally several times faster than java is - according to those benchmarks - simply wrong ...
• Saying that Java is faster than C can also be pretty wrong, especially if you have to stick with one JVM ...

Es también interesante del artículo (y de uno posterior que está referenciado) el uso de otras herramientas de Java y C, por ejemplo el JDK de IBM y de BEA para Java y el compilador de Intel para C (esta es uno de los compiladores más optimizados para tecnología Intel que se conoce, por supuesto). 

Debemos ir a la defición de la clase String, si nos fijamos un String está implementado por un arreglo de char, por lo tanto eso nos lleva a que la longitud dependerá de cuanto puede almacenar un arreglo, el tamaño máximo de una arreglo, entonces si observamos, lo máximo que se puede poner para el tamaño de un arreglo es un int, por lo tanto podriamos pensar que el tamaño máximo de una cadena es: Integer.MAX_VALUE (2147483647) sin embargo, si hacemos esto, observamos que si hacemos algo como esto:
int[] arreglo = new int[Integer.MAX_VALUE];
y lo hacemos correr. saldra un mensaje "java.lang.OutOfMemoryError ", indicando que el arreglo excede el tamaño de la memoria de la Maquina VIrtual, eso porque JAVA tiene por defecto un espacio para ocupar, pero simodificamos eso (aumentamos) entonces lo maximo será 2^31-1 = Integer.MAX_VALUE caracteres...

Entonces ahora sacamos esta conclusion, como cada caracter ocupa 2 bytes en JAVA [1], entonces se puede almacenar 2(2^31-1) bytes lo que equivale más o menos a 4 GB
Bueno .. este fue el análisis que hice y llegue a estas conclusiones...

Espero pueda servir de algo a otras personas ....

 [1]: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html

Los ejemplos han sido recientemente liberados bajo licencia BSD.

 [1] http://www.netbeans.org/community/teams/evangelism/collateral.html#wallpapers

  public class SOP {       public static void main(String args[]) {         long timeBefore = System.currentTimeMillis();         final int N = 100000;         for (int i = 1; i <= N; i++)           System.out.println(i);         long timeAfter = System.currentTimeMillis();         System.out.println((timeAfter - timeBefore) + "ms");       }   }    

La corrida tarda 4677ms. Luego, si ponemos en un archivo de salida en cambio de mostrarlo en pantalla tenemos el tiempo de 1330ms. Lo que nos indica que algo pasa con el System.out.println (SOP), ya que la diferencia entre el vaciado a la pantalla y a un archivo es de alrededor de un tercio. El problema es que el SOP está pensado para E/S interactiva, es decir, tan pronto tienes algo que mostrar ponlo en la pantalla ya que tal vez hay que hacer una lectura en base a esa información. Pero para la generación de grandes cantidades de datos, no es necesario mostrar en la pantalla. Al vaciar a un archivo ya se nota que el Buffer de salida tiene que llenarse primero y luego se pasa a almacenar el flujo en el archivo. Pero también se puede configurar el objeto de salida para que: el buffer sea más grande y se espere su llenado para el vaciado en la salida correspondiente. El programa que hace esto sería:

import java.io.*;   public class SOP {       public static void main(String args[]) {         long timeBefore = System.currentTimeMillis();         FileOutputStream     fdout = new FileOutputStream(FileDescriptor.out);         BufferedOutputStream bos   = new BufferedOutputStream(fdout, 1024);         PrintStream          ps    = new PrintStream(bos, false);         System.setOut(ps);         final int N = 100000;         for (int i = 1; i <= N; i++)           System.out.println(i);         long timeAfter = System.currentTimeMillis();         System.out.println((timeAfter - timeBefore) + "ms");         ps.close();       }   }    

El programa ahora muestra 391ms. Una mejora de un orden de magnitud. Lo que ha hecho que la diferencia no sea tan drástica en el primer programa es que se muestran enteros, entonces de a varios caracteres por llamada al SOP. La performance se degrada más si hacemos una llamada por caracter (el numero 23789 tiene cinco caracteres). ¿Vale la pena entender bien los mecanismos de E/S no? Sabemos que en Java es compleja, pero es una solución completa y elegante que se puede ver en muy pocos lenguajes de programación.