SoloCodigo

Hola:

En Ejemplo tonto de MySQL, tienes un tutorial que te cuenta por encima la instalación de mysql y luego se hace un programa tonto en java para que se enchufe a mysql.

Se bueno.

Hola:

En teoría sí.

Java define sus propios tipos de datos. Un entero java ocupa siempre lo mismo independientemente de en qué plataforma corra (16, 32 o 64 bits).

Las diferencias las "absorve" la máquina virtual. Tendrás que instalar una máquina virtual de java para tu plataforma de 64 bits.

Se bueno.

Hola:

No sé cual es el jar que dices. Puedes ir viendo jar en el directorio de instalacion de netbeans con el winzip o alguno similar, hasta reconocer alguna clase (el winzip no muestra los subdirectorios y por tanto, no permite ver los paquetes).

Para un applet tienes que subir el jar al servidor web, en el mismo directorio que tu applet. Luego en html tienes que poner algo como esto

<applet codebase="ClaseApplet" archive="fichero1.jar, fichero2.jar" ...

Te lo he puesto de memoria, quizás no sean así exactamente los nombres de los atributos.

Se bueno.

Hola:

Por un lado tienes la comuniciación normal con socket. RMI es un nivel más alto (como lo era RPC en C de unix). ¿Cuando se justifica un RMI en vez de un socket?

Desde mi punto de vista hay una diferencia básica entre un socket y un RMI. Cuando un cliente pide algo, puede tener que quedarse bloqueado o no esperando la respuesta, sin hacer nada mas.

Con sockets, se envia un mensaje de peticion y podemos seguir haciendo cosas, hasta que la respuesta esté lista para ir a recogerla. Podríamos bloquearnos si lo deseamos.

Con RMI, el cliente pide algo y se queda bloqueado hasta que se termine la respuesta. No hay posibilidad de seguir haciendo cosas.

Como te comenta rutger, cualquier aplicación cliente/servidor, podrías hacerla con rmi. De todas formas, yo creo que debería pensar si es mejor usar rmi o solo un socket normal. Yo creo que la decisión debe tomarse de acuerdo a lo que te he comentado. De hecho, la aplicación de la pizarra es algo más bien "asincrono", tu pintas cuando quieres y el servidor te va repintando las cosas. RMI yo creo que está más justificado en algo más "sincrono".

Más que una aplicación de pizarra o chat, en la que deberías poder seguir pintando mientras se va refrescando con lo de los demás, deberías pensar en algún tipo de aplicación en la que te quedes bloqueado y no puedas hacer nada más hasta que la petición termine.

Se me ocurren aplicaciones del siguiente estilo:

Un acceso a base de datos remota. Cuando un cliente hace una consulta, normalmente no debe hacer nada hasta que obtenga los resultados. De hecho creo que ODBC usa internamente este mecanismo. Quizás esta apliación queda descartada por lo que comentas de un software de gestión.

Un acceso a algún hardware que esté en fisicamente en otro pc. El servidor da funciones de acceso a ese hardaware por medio de rmi, por ejemplo, para obtener su estado, hacerle un reset, etc. El hardware puede ser cualquier cosa, desde un disco duro situado en el servidor en el que se quiera escribir o leer ficheros hasta una tarjeta de audio de la que quieres ir recogiendo una grabación que se esté haciendo en ella.

Un ordenador que esté especialmente preparado para hacer calculos rapidos (una CPU más potente que la de los clientes) y ofrezca diversos algoritmos de calculo a sus clientes.

De todas formas, es más mi opinión que algo que haya leido por ahi....

Se bueno.

Hola:

La que propones es otra solucion valida. Depende de si el programa unicamente debe lanzar el hilo cada cierto tiempo o debe estar haciendo en otras cosas. Para el primer caso vale el sleep(), para el segundo caso mejor el Timer().

Se bueno.

Hola:

Una opción que no sé si te vale es la siguiente.

Crea un DefaultTableModel y usalo para guardar ahi tus datos.
Crea un JTable pasándole el DefaultTableModel en el constructor.

Ahora, te puedes "suscribir" a cambios en los datos del DefatultTableModel a través de su método addTableModelListener().
A partir de ese momento, con cualquier cambio que se produzca en la tabla, te avisarán a través del TableModelListener que pases al llamar al addTableModelListener(). Ahi podrás hacer lo que necesites.

Se bueno.

Hola:

arge es un array de cadenas con las variables de entorno, terminado en NULL. Ahi tienes cosas como

"PATH=C:\ ... "
"HOME=C:\Documents... "
etc, etc.

Para leerlas, debes hacer un bucle como este

int i=0;
while (arge!=NULL)
{
...
i++;
}

Se bueno.

Un detalle.

Por más que he probado, dir no funciona en dos, ni cls ni ningún comando "interno" (comandos que no tienen un .exe, sino que están dentro de command.com).

Runtime.getRuntime.exec("dir");  // da error

He hecho pruebas estilo "start cls", "cmd cls", etc y no he conseguido nada, ya que se me abren nuevas ventanas o sesiones nuevas, que se cierran inmediatamente y no se ven los resultados.

¿Hay alguna forma de hacerlo?

Sed buenos.

Tienes que hacer algo como esto

En el A.h

en el B.h

De esta forma el include no es "recursivo". Si A.h incluye a B.h y este a su vez a A.h el compilador no termina nunca, y te da un error de que no puede abrir fichero (supongo que es lo que te pasa).

Luego, en los ficheros .cpp tienes que poner un include de mas

En A.cpp

En el B.cpp

Se bueno.

Otra opción más son los códigos ansi. Si tienes instalados los condigos ansi para tu ventana de ms-dos, escribiendo unos caracteres especiales (un escape y un par de letras raras) puedes conseguir que se borre la pantalla. En Codigos ansi tienes una explicación de como instalarlos y qué caracteres tienes que escribir. Una vez hecho, queda tan sencillo como

System.out.println ("<esc>]2J");

El <esc> es el código ascii 27, en windows lo puedes conseguir manteniendo pulsado alt y 27 en el teclado numerico y soltar alt. Te saldrá algo como esto ←

Se bueno.

Para que un componente sea realmente reutilizable, debes hacer que dependa de un numero pequeño de clases y que tenga una funcionalidad clara y solo una.

Dicho de otra forma, si haces una clase Cliente, esa clase puede contener los datos del cliente y algún método relacionado con algo algo del cliente, pero no debe saber escribirse en base de datos, en un fichero xml, pintarse en un gráfico y además imprimirse.

La mejor forma de hacer componentes reutilizables es dividir tu proyecto en mini-proyectos independientes. Por ejemplo, quieres hacer un juego de marcianos. Piensate (y haz) primero unas clases para mover iconos por pantalla, sin pensar para nada en marcianos. Hazte otro grupo de clases para captura de teclas al vuelo. Hazte otro grupo de clases para llevar una lista de jugadores y sus puntuaciones, etc, etc. Cuando tengas todo lo que se te haya ocurrido, hazte el programa de marcianos usando tus componentes.

La idea es sencilla, sin embargo por experiencia te aseguro que es muy dificil y requiere mucha practica aislarte de tu programa concreto (los marcianos) al hacer el componente reutilizable (la libreria de mover iconos). Al final, si no eres muy cuidadoso, acabas haciendo una libreria de mover iconos marcianos.

Se bueno.

Buenas:

Los hilos se ejecutan por turnos. La CPU ejecuta un cacho de hilo cada vez (salvo que tengas varias CPU en paralelo, en la que es posible que un hilo distinto se ejecute realmente en cada CPU). Si solo tienes una CPU, sólo se puede ejecutar un hilo o un proceso a la vez.

Cuando matas un hilo (desde código), sólo se muere ese hilo, los demás siguen a lo suyo.

Si con un ps de linux matas el proceso, mueren todos los hilos. De hecho, con un ps no salen los hilos, sólo sale el proceso que contiene esos hilos.

En cuanto a la señal, te lo digo por intuición, puesto que no he probado nunca, pero supongo que recibe la señal el hilo que se esté ejecutando realmente en ese momento.

Tienes algo de hilos y procesos en Hilos y procesos

Se bueno.

En señales y alarmas tienes un pequeño tutorial de señales y alarmas, con código que puedes descargar.
Se bueno.