Then why it is difficult to wrote about this book? Well, the first issue is than the latest API (with significant changes) for JavaFX is 1.3 while the book is written for 1.2; There are several performance and stability improvements, new graphic controls so this was definitely an mandatory upgrade for anyone thinking seriously into using the language. But the real deal breaker here is than JavaFX script is being discontinued and instead is being made a proper Java API that can be used by your regular Java developers.

All this will happen on the ‘JavaFX 2.0′ version of the language, sometime next year. Also JavaFX script is not really dead … is reincarnated as an open source platform called Visage.

So if I were you I would wait to see how JavaFX 2.0 looks like instead, no investment in books or coding for the time being. As for Visage, I would rather go for a head to head comparison with other tools like Apache Pivot which is more mature at this point.

The good: The book is a good one, easy to read and with good concrete examples. The price tag is also good.

The bad: Not a problem with the book itself, but the technology is changing to fast and too much, so it doesn’t make sense to invest on this book. Wait until Oracle delivers JavaFX 2.0.

The ugly: Oracle should have pull the plug sooner. JavaFX has lost a lot of momentum and makes you wonder if now it’s real purpose will be to replace an aging Swing on the desktop.

There are great things scheduled for JavaFX, but we will have to wait some more to see them. Perhaps a new version of this book will be more than welcome once the new version is out.

–Jose

¡Ah, y tiene código abierto!

Yo en particular corro procesos los cuales pasan largo tiempo haciendo cosas durante el día. Una de las cosas que quiero que hagan es que si se mueren me digan porqué. En especial uno de los errores más difíciles de capturar son los de “OutOfMemory” (quedarse sin memoria) ya que en muchos casos la aplicación queda en un estado inconsistente; La recomendación dice que si se queda sin memoria es mejor matar a la aplicación, aunque muchas veces es imposible cambiar el código para hacerlo de manera limpia, por lo que este truco seguro le vendrá a la mano.

Pero primero, nuestro programa el cual se va a quedar sin memoria:

1
2
3
4
5
6
7

package com.kodegeek.blog;
public class RunOutOfMemory {
        public static void main(String [] args) {
                long [] array = new long[Integer.MAX_VALUE];
                System.out.println("Mi arreglo tiene un tamaño de: " + array.length);
        }
}

El programa es un poco artificial, en especial si podemos pedir suficiente memoria con parámetros como ‘-XmsXXXXm -XmxXXXXm’, pero ilustra un caso en que no podemos reservar suficiente memoria:

1
2
3
4
5
6
7
8
9

auyan:~ josevnz$ java -classpath . com.kodegeek.blog.RunOutOfMemory
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
	at com.kodegeek.blog.RunOutOfMemory.main(RunOutOfMemory.java:7)
auyan:~ josevnz$ echo $?
1
if [ $? != 0 ]; then
    echo "Mi programa se quedó sin memoria en $HOSTNAME"|mail kodegeek@kodegeek.com
fi
auyan:~ josevnz$

Un poco complicado, además de que si el programa se queda guindado (es decir la máquina virtual nunca termina) entonces nunca sabremos que fué lo que paso

¿Y como nos enteramos de que murió, por ejemplo recibiendo un correo electrónico? Bueno, es sólo cuestión de agregar unos cuantos parámetros:

1
2
3
4
5
6
7
8
9

auyan:~ josevnz$ java -classpath . -XX:OnOutOfMemoryError="echo 'Me quede sin memoria en $HOSTNAME'|mail jose.nunez@gmail.com; kill -9 %p" com.kodegeek.blog.RunOutOfMemory
#
# java.lang.OutOfMemoryError: Requested array size exceeds VM limit
# -XX:OnOutOfMemoryError="echo 'Me quede sin memoria en auyan.local'|mail kodegeek@kodegeek.com; kill -9 %p"
#   Executing "echo 'Me quede sin memoria en auyan.local'|mail jose.nunez@gmail.com"...
#   Executing "kill -9 254"...
Killed
auyan:~ josevnz$ echo $?
137

Hay muchos recipes en Internet, pero este es uno de mis favoritos

No sé, pero yo no he visto el primer RubyBus o C#Bus (Esta bien, está bien sólo estoy bromeando aquí )

Por ejemplo, para ver la lista de procesos de Java, en vez de hacer esto:

1
2

auyan:~ josevnz$ ps aux|grep -i java|grep -v grep
josevnz    176   0.0  1.5   717716  62436   ??  S     5:49AM   0:02.52 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java -Djava.library.path=/Library/Frameworks/JavaFX.framework/Versions/1.2/lib/desktop -Dfile.encoding=MacRoman -classpath /Library/Frameworks/JavaFX.framework/Versions/1.2/lib/shared/javafxrt.jar:/Users/josevnz/Documents/workspace/mytests/dist/Main.jar com.sun.javafx.runtime.main.Main MainJavaFXScript=com.kodegeek.blog.totalbodyweight.app.Main

Utilice a jps:

1
2
3
4

auyan:~ josevnz$ jps -lm|grep -v 'sun.tools'
112 
176 com.sun.javafx.runtime.main.Main MainJavaFXScript=com.kodegeek.blog.totalbodyweight.app.Main
148

Ambas muestran que el PID de mi programa es el 176, pero ¿cual es más fácil?

¡Amor a primera vista!

Hay muchas otras, pero les dejo con este articulo de IBM el cual hace un mejor trabajo describiendo las herramientas.

–José

Uno de los desarrolladores de NetBeans me mostró en el reporte de la cucaracha en donde está desactivado.

¿Entonces, cual es la solución? Bueno, algo inconveniente pero que funciona, simplemente cree un proyecto de Java (no JavaFX) y entonces desde allí incluya sus pruebas de unidad.

Pero como una foto dice más que mil palabras les dejo el ejemplo abajo, creado con uno de los ‘magos de código’ (wizzards) de NetBeans:

¡Misterio resuelto!

Me gané una franela y un libro (Real-Time Java Programming , de eric J. Bruno. Muy contento)

Bueno, hoy comenzó oficialmente el Java Road Trip Stop en la ciudad de Nueva York. Este evento, el cual contó con la participación de New York City Java Meetup Group, es una iniciativa de Oracle para demostrar los últimos avances de Java en dispositivos como el Amazon Kindle, JavaFX en la televisión y entre otras cosas.

Oracle se acuerda de los desarrolladores de Sun, muestra su fe en Java

¿Pero, de verdad hubo algo bueno o fué sólo propaganda de Oracle, con los respectivos tragos gratis?

Nada que ver. La charla tuvo mucha substancia, y lo mejor fué lo que cada uno de sus expositores tuvo que ofrecer.

Timothy explicó lo que no se debe hacer en su charla de las mejores prácticas

Timothy F se encargó de romper el hielo con una presentación de las mejores prácticas (III), en este caso el manejo de código duplicado. Su explicación práctica de como utilizar patrones de diseño como Strategy, Visitor e incluso factory fué muy valiosa, definitivamente pienso utilizar esos tips en mi código de ahora en adelante.

Brian nos explicó cosas como el proyecto Da Vinci, Coin y otros en el nuevo JDK 7

Después le toco el turno a Brian Goetz (el autor de ‘Java Concurrency in Practice’) al bate. Brian explicó con mucha emoción y detalles los aspectos técnicos del nuevo JDK 7, las diferencias con el Java SE 7 (no es lo mismo, el JDK es una referencia de implementación) y de las cosas buenas, en especial de productividad, concurrencia, soporte de otros lenguajes como JRuby, Scala y maquillaje del lenguaje que vienen pronto (nos adelanta que un anunció importante viene en JavaOne de este año).

El Java Road Trip continua este Miércoles y luego se moverá a otras ciudades en los Estados Unidos

La organización del evento estuvo impecable, pudimos ver el “Java Bus” (tiene tecnología Java, y una pantalla de datos la cual usa JavaFX), regalaron libros a los asistentes (me gané uno por preguntón ) pero sobre todo el nivel de asistencia de los asistentes fué alto, todo en un ambiente relajado. Tampoco me puedo quejar de la oportunidad de hacer contactos con otros programadores de distintas areas de la industria.

Java Meetup, muy buena experiencia, seguro me verán escribiendo más sobre este evento que ocurre al menos una vez al mes en NYC

¿Volveré a ir a un Java Meetup? Claro que sí. De verdad vale la pena y si usted vive cerca de Nueva York y le gusta Java entonces no debería perdérselo. En cuanto al Java Road Trip le recomiendo que vaya al sitio web y los siga desde Twitter, Facebook y otros.

Si, beta. Tiene una lista de problemas (entre esos la depuración de programas). Sin embargo, si escribo mis ‘unit tests’ debería estar más o menos bien, ¿no es así?

Lo primero que intenté hacer es convertir el método ‘main’ de una de mis clases en Java (no JavaFX) a Junit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181

/*
 * Helper class used to parse and process CVS data comming from an InputStream
 * License: GPL
 * @author josevnz at kodegeek dot com
 */
 
package com.kodegeek.blog.javafx.workout.app;
 
import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.regex.Pattern;
 
 
/**
 *
 * @author josevnz
 */
final public class CsvDataParser {
 
private List <list <Object>>data;
private static final Pattern splitPattern = Pattern.compile(",\\s*");
private SimpleDateFormat format;
private Pattern skipNonNumberPatter = Pattern.compile("^\\D+");
 
/**
 * Expected default number of data observations
 */
public static final int DEFAULT_DAY_COUNT = 365;
 
/**
 * Expected default number of series to display on the same chart
 */
public static final int DEFAULT_SERIES = 50;
 
    /**
     * Constructor
     * @param numSeries expected number of series on the stream
     */
    public CsvDataParser(int numSeries) {
 
        /*
         * Ddata is a list of lists where:
         * data(0): List of dates
         * data(n): Values of each series.
         * data is a rectangular array, every value matches a date
         */
        data = new ArrayList</list><list <Object>>();
        List<object> dates = new ArrayList</object><object>();
        data.add(0, dates);
        for (int i = 1; i < numSeries; i++) {
            List<Object> values =
                    new ArrayList</object><object>();
            data.add(i, values);
        }
 
        format = new SimpleDateFormat("MM/dd/yy");
    }
 
    /**
     * Parse a given input stream for data. Not thread safe. It is assumed than
     * the number of tokens on the stream is constant and there
     * are no data holes. The caller is responsible from closing the stream
     * @param io The data source
     * @throws Exception If there is a problem reading the stream
     */
    public void parse(InputStream io) throws Exception {
        BufferedReader lineRdr = new BufferedReader(new InputStreamReader(io));
        String line = null;
 
        try {
 
            while ((line = lineRdr.readLine()) != null) {
 
                if (skipNonNumberPatter.matcher(line).find()) {
                    continue;
                }
 
                String[] tokens = splitPattern.split(line, -1);
                int numSeries = tokens.length;
                if (numSeries ==0 || tokens[0] == null) {
                    return;
                }
 
                if (numSeries != data.size()) {
                    String error = String.format(
                            "Number of expected tokens is %s, got %s",
                            data.size(),
                            numSeries);
                    throw new Exception(error);
                }
 
                // Store dates as numbers, let the caller do any conversions
                List</object><object> dates = (List</object><object>) data.get(0);
                dates.add(format.parse(tokens[0]).getTime());
 
                // Get the values for each series now (rest of the tokens)
                for (int i = 1; i < numSeries; i++) {
                    List<Object> values = (List</object><object>) data.get(i);
                    values.add(Float.parseFloat(tokens[i]));
                }
 
            }
        } catch (Exception exp) {
            throw exp;
        }
 
    }
 
    /**
     * Get the collected data as a List of Lists. First element of the returned
     * list contains the dates as Epoch long dates, after that the series
     * @return Array of dates as epoch long
     */
    public Long [] getDates() {
        return data.get(0).toArray(new Long[0]);
    }
 
    /**
     * Get the values as a list of
     * @param index Valid ranges go from 1 to n
     * @return Array of float series values
     */
    public Float [] getSeriesValues(int index) {
        if (index < 1 || index > data.size()) {
            throw new IllegalArgumentException(
                    String.format("Invalid series index %d", index));
        }
        return data.get(index).toArray(new Float[0]);
    }
 
 
    /**
     * Unit test, show how the parser works on a CSV file. THIS SHOULD BE A
     * JUNIT TEST INSTEAD!!!
     * Program expects the property.
     * @param args List of files to parse. Each one like: numTokens:fullpathFile
     * @throws Exception If there are any problems
     */
    public static void main(final String [] tokens) throws Exception {
        for (String token: tokens) {
            String [] parts = token.split(":", -1);
            InputStream in = null;
            try {
                int nTokens = Integer.parseInt(parts[0]);
                File f = new File(parts[1]);
                if (f.canRead() && f.isFile()) {
                    in = new FileInputStream(f);
                    CsvDataParser instance = new CsvDataParser(nTokens);
                    instance.parse(in);
                    in.close();
                    Long [] dates = instance.getDates();
                    Float [] values = instance.getSeriesValues(1);
                    for (int i = 0; i < dates.length; i++) {
                        System.out.println(
                                String.format("%s -> %s",
                                new Date(dates[i]), values[i]));
                    }
                }
            } catch (NumberFormatException nfe) {
                System.err.println(
                        String.format(
                        "Invalid expected token value: '%s'", parts[0]));
            } catch (Exception exp) {
                throw exp;
            } finally {
                if (in != null) {
                    in.close();
                }
            }
        }
    }
 
}
</object></list>

Sin embargo la interfaz gráfica me abofetea con este error: No tests root folder was found

Que fastidio. No soy un experto en NetBeans (me defiendo mucho más con Eclipse), así que en vez de estar echando código ando resolviendo estos problemas. ¡Que perdida de tiempo!

Me pregunto si Oracle piensa competir en serio con Adobe Flash si su editor principal aún tiene este tipo de problemas.

Amanecerá y veremos, por los momentos ando tratando de resolver el asunto yo mismo, al mismo tiempo pedí ayuda en los foros oficiales. Una vez resuelto, podré correr Junit para JavaFX como lo indica este excelente blog.

Si leen la petición cuidadosamente, el argumenta que el uso de GPL no es suficiente. La intención es que Oracle le deje el desarrollo a una tercera compañía la cual va a seguir creciendo MySQL bajo GPL.

No entiendo el llanto, después que vendió MySQL a SUN, luego dejó a SUN para trabajar en MariaDB (Fork).

¿A quien le importa si MySQL deja de existir? Hay otras alternativas, muy buenas como PostgreSQL. Lo otro es que no creo que Oracle este interesado en destruirlo (aunque no creo que lo aumente o mejoren).

El software gratuito tiene este y otros dilemas. Un caso muy interesante es el de OpenNMS el cual pasó varios años peleando contra una compañía que tomó el producto, hizo dinero con él y no liberó los cambios para el beneficio de todos.

Yo creo que un fork de MySQL puede sobrevivir y prosperar. La licencia GPL protege el producto y hay muchas compañías interesadas en que MySQL viva.

Los dejo con la siguiente nota de LWN, a la final es la comunidad quien decide el éxito de una aplicación:

Still, it is telling that so much of the work done by the forks centers around the InnoDB storage engine: the patches written by Percona and OurDelta, Percona’s replacement engine XtraDB, and MariaDB’s replacement engine Maria. InnoDB is GPLv2-licensed, but the copyright is owned by … Oracle. Oracle acquired InnoDB’s creator Innobase in 2005. That acquisition sparked a flurry of concern that the database giant would kill the product, take it proprietary, or somehow use it against MySQL — many of the same nightmare scenarios now speculated about the Sun purchase. It is worth noting that in the intervening years two things have occurred: Oracle has not killed or maimed InnoDB, and the open source community has preemptively created its own innovative solutions, thereby insulating open source users and customers from disaster should Oracle take a step in the wrong direction.

The real question is not which fork is the MySQL, but whether the multiple patch sets and forks indicate sickness or health for MySQL as a whole. Excluding Drizzle, all of the projects were started because someone who cared a great deal about the future of MySQL saw something wrong with MySQL’s development process (and for its part, Drizzle was spawned by even deeper dissatisfaction with the technical direction of MySQL). Surely that much concern on the part of the community signifies health. There is no telling which forks will prosper and which will fizzle out, but that depends to a large degree on Oracle, and how it governs the project in the future.

¿Usted piensa firmar esta petición en línea?

Si, Oracle comprará a Sun Microsystems al final de este verano ($9.50 por cada acción). Mientras tanto IBM busca un par de interiores limpios. De todos los competidores de IBM, Oracle es quizas el que mejor sale parado de todo este asunto, ya que a diferencia de IBM no hay tanto solapamiento (recuerden, Sun hacia dinero de su venta de Hardware y soluciones de almacenamiento no de Software como Java). Menos solapamiento implica menos despidos en el lado de Sun, además de que Oracle tiene una mejor historia en como ha conservado las compañías que ha adquirido a lo largo de los años (como BEA con Weblogic por dar un ejemplo).

Oracle tiene una vision clara sobre como va a integrarse con Sun (mejor dicho, como Sun va a adaptarse a su nuevo entorno). Yo en particular creo que algunos productos sufrirán (JavaFX), otros serán posicionados de manera distinta, pero no desaparecerán, debido a que Oracle ya tiene ofertas en esas áreas (MySQL vs Oracle DB, Netbeans vs JBuilder, GlassFish vs Weblogic), otras mejoraran substancialmente (Sun JDK vs JRockit). En la parte de sistemas operativos (Solaris), Hardware (Sparc) y almacenamiento (OpenStorage) Oracle gana presencia instantánea.

Por cierto, este año quizas sea el año en el que Oracle quizas le saque dinero y provecho a Java (algo que Sun no hizo de manera directa). También es cierto que Oracle tiene menos tradición en el mundo OpenSource que IBM, quien sabe como le sacarán provecho a Java (por otro lado una postura más rádical no va a ayudarlos en nada).

Tiempos interesantes, pero en general creo que son buenas noticias para Sun y Oracle. No tan buenas para IBM la cual ahora tiene un competidor fortalecido tocándole en la puerta de varios negocios, no sólo el de las bases de datos.

Ya para terminar, ¿sabia usted que el rumor original sobre que compañia Oracle pensaba adquirir no era Sun sino RedHat (busquen más en Google si no me cree)?
Veneblogs: oracle, sun, java, mysql, acquisition

Blogalaxia: oracle, sun, java, mysql, acquisition

To2Blogs: oracle, sun, java, mysql, acquisition

Technorati: oracle, sun, java, mysql, acquisition

Del.icio.us: oracle, sun, java, mysql, acquisition