Si alguien lo sabia, por que no dijo nada? Finalmente BlueJ y GreenFoot son open source. Habia algunos interesados en echarle mano al codigo. Es todo suyo.

Seguramente se acordarán del SwingSet2 que venía con los demos del jdk; pues al igual que ese, SwingSet3 es el nuevo kit de demos de los componentes del paquete swing de java.

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.

Nuevos componentes: Spinner (ya no tendremos que simularlo )

Nuevas características: ver JTable

Referencias???

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

Debe haber muchos, el que acabo de usar para probar un programita es:

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.

... siempre traen problemas.

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
 

Se trata de programas que miden la velocidad de aplicaciones computacionales que tienen lo mínimo de E/S. Algunas conclusiones:

• 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). 

Si, el título es provocativo a propósito, pero no armemos una guerra santa por favor. Se trata de un breve artículo que muestra las evoluciones de un ciclo para recorrer sobre una estructura. Desde el clásico for con un contador, en el que se explicita una estructura de datos subyacente (por lo menos algunas propiedades a las que está sujeta la estructura: secuencia, indizado, ...), hasta los iteradores de Smalltalk o las listas por comprensión de Haskell (esta otra lectura es un poco más sintetizada, muy al estilo académico). A pesar de que la wikipedia puede no ser "la fuente definitiva del saber", uno encuentra cosas interesantes, y esto es lo que dice sobre los iteradores denominados listas por comprensión mostrando ejemplos en varios lenguajes de programación.

Hace algunos días alguien me pregunto personalmente cuanto es el espacio máximo que puede ocupar un String, lo que pienso sería mejor pensar es cuantos caracteres puede almacenar una String. Mi explicación fue la siguiente:

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

Libro de Java2D y Swing http://filthyrichclients.org/

Los ejemplos han sido recientemente liberados bajo licencia BSD.

 

 

Para aquellos que gustan de un verdadero IDE (Entorno INTEGRADO de Desarrollo) para Java (principalmente), les dejo el enlace de una página [1] de la comunidad NetBeans en la que se ofrece algunos wallpapers (entre otras cosas).

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

Bueno, acabo de escribir en mi blog sobre el mito de la performance de Java. A la par he decidido dedicar un tiempo a demostrar algunas cosas que se puede hacer para mejorar la velocidad de programas Java. He googleado un poco y encontrado es artículo sobre la mejora de la performance de E/S en Java. Unas pequeñas pruebas con solamente la salida. Un programa tan sencillo como este para mostrar 100000 números en la pantalla:

  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.