Enlaces patrocinados: limpieza
noticias en españa
responsabilidad social
viaje a rajasthan
tiendas de informatica
despedida de soltero
venta casas costa brava
depilacion permanente
alcoholimetro a monedas
tarot en directo
La clase String se utiliza cuando se trabaja con cadenas que no pueden cambiar. Por otro lado, StringBuffer, se utiliza cuando se quiere manipular el contenido de una cadena.
Para saber más visita webtaller.
Mostrando entradas con la etiqueta java. Mostrar todas las entradas
Mostrando entradas con la etiqueta java. Mostrar todas las entradas
lunes, 9 de abril de 2007
jueves, 5 de abril de 2007
Como ser un Gurú Java sin conocer Java
1. Antes del proyecto inicial pasa por jcp.org. Revisa todas las JSR's, aprende algunos números y títulos (5 bastan en general). Si tienes que reunirte con desarrolladores más avanzados - además lee el resumen. Menciona los JSRs durante la reunión y disfruta del impacto.
2. Si el proyecto va a ser realizado con Java EE: Enfatiza la amplitud de Java. Apunta a lenguajes elegantes como Python o Ruby.
No es necesario conocer estos lenguajes. Es poco probable que éstos sean usados en un ambiente Java EE. Si éstos lenguajes van a ser elegidos ir al punto 6.
3. Mencionar JDK 1.7 (esta estrategia es muy útil -> La mayorïa de las compañías están pensando ahora actualizar a Java5) y closures.
En general es suficiente con sólo mencionar el término "closure" en el contexto de Java.
4. Espera una cantidad aleatoria de tiempo. Elige algún tema y trata de iniciar una discusión; SOA vs. ROA, (Ruby on Rails vs. Java EE), Thin vs. Rich, Ajax vs. Rich, (Swing vs. SWT), Netbeans vs. Eclipse, Java EE vs .NET, (SOAP vs. REST) y OSGI y JSR-277. Los que
están entre () son mas graciosos y alargan la conversación.
5. Utiliza todos los términos relacionados con Web 2.0, SOA, etc. No te preocupes del significado: nadie es capaz de definirlos.
6. Sugiere lenguajes más esotéricos como Haskell, Scala o Fortress pero no Malbolge para la realización del proyecto. En general no hay razón para hacer eso (Java funciona bien), pero por qué no?
7. No olvides la generación de código. A veces es suficiente con iniciar una discusión acerca de MDA vs. MDSD. Si nada ocurre pregunta a los desarrolladores acerca de PIM, PSM y transformación de código
etc.
8. Muy importante: menciona cosas como velocidad de equipo, programación de pares, pregunta acerca de Xtreme-programming, Agile, Scrum, Crystal, Test First, Mocking (cuanto más mejor).
Visto en javaHispano.
2. Si el proyecto va a ser realizado con Java EE: Enfatiza la amplitud de Java. Apunta a lenguajes elegantes como Python o Ruby.
No es necesario conocer estos lenguajes. Es poco probable que éstos sean usados en un ambiente Java EE. Si éstos lenguajes van a ser elegidos ir al punto 6.
3. Mencionar JDK 1.7 (esta estrategia es muy útil -> La mayorïa de las compañías están pensando ahora actualizar a Java5) y closures.
En general es suficiente con sólo mencionar el término "closure" en el contexto de Java.
4. Espera una cantidad aleatoria de tiempo. Elige algún tema y trata de iniciar una discusión; SOA vs. ROA, (Ruby on Rails vs. Java EE), Thin vs. Rich, Ajax vs. Rich, (Swing vs. SWT), Netbeans vs. Eclipse, Java EE vs .NET, (SOAP vs. REST) y OSGI y JSR-277. Los que
están entre () son mas graciosos y alargan la conversación.
5. Utiliza todos los términos relacionados con Web 2.0, SOA, etc. No te preocupes del significado: nadie es capaz de definirlos.
6. Sugiere lenguajes más esotéricos como Haskell, Scala o Fortress pero no Malbolge para la realización del proyecto. En general no hay razón para hacer eso (Java funciona bien), pero por qué no?
7. No olvides la generación de código. A veces es suficiente con iniciar una discusión acerca de MDA vs. MDSD. Si nada ocurre pregunta a los desarrolladores acerca de PIM, PSM y transformación de código
etc.
8. Muy importante: menciona cosas como velocidad de equipo, programación de pares, pregunta acerca de Xtreme-programming, Agile, Scrum, Crystal, Test First, Mocking (cuanto más mejor).
Visto en javaHispano.
sábado, 24 de febrero de 2007
Connection refused - Conexion rehusada - Java RMI - Linux Fedora
Me pongo en situación (connection refused, conexion rehusada, java rmi y su madre):
Estás desarrollando un aplicación con Java RMI para linux (una fedora core 6, por ejemplo). Hasta ahora va todo bien, lo has probado en local y perfecto. Vas al siguiente paso, un servidor en una máquina y otro en otra. E intentas acceder desde un cliente de una máquina al servidor de la otra máquina. En el servidor has lanzado el rmiregistry, las opciones con que lances el rmiregistry no nos importan demasiado. El caso es que el registro rmi está lanzado, el servidor ha registrado el objeto y queda a la espera de peticiones. Nuestro cliente, y esto es importante, hace un Naming.lookup y encuentra el objeto en la otra máquina. Es importante que lo encuentre, si no lo encuentra algo estamos haciendo mal, revisa!. Si lo encuentra, entonces vamos a llamar a uno de los métodos del objeto remoto. Y nada más hacer la llamada nos encontramos con este error:
Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at ...
(y lo que sigue, pero para que poner el resto de la pila si con esto nos vale)
Estamos intentando acceder a un objeto en otra máquina, que de hecho hemos encontrado (con el Naming.lookup) pero no nos deja ejecutar uno de sus métodos. Y por lo menos pone Connection refused, porque si tu versión de java está traducida, te pondrá "Conexión rehusada". Piensa en rehusar como en rechazar, quítate de la cabeza nada que tenga que ver con volver a usar!!! (Suele pasar). Bien que es lo que pasa aquí? Pues resumiendo, cuando el cliente ha encontrado el objeto remoto (Naming.lookup) lo que obtiene es una dirección ip para poder acceder a él. Da igual que hayamos accedido al objeto a partir del nombre de la máquina. El rmi lo que hace es devolver una ip, que obtiene del /etc/hosts, para no tener que acceder siempre a ese fichero y ver la ip que corresponde con el nombre de la máquina. Me explico fatal. El tema está en que el fichero /etc/hosts seguramente tengas algo así:
127.0.0.1 localhost mimaquina
Cuando para que te funcione, mimaquina debería apuntar a la ip "real" de tu maquina (/sbin/ifconfig para ver la ip en linux, ipconfig en windows por comando)
Contenido necesario de "etc/hosts" (para Linux Fedora)
127.0.0.1 localhost
192.168.0.xxx mimaquina
Espero que te sirva de utilidad, yo perdí mucho tiempo con este tema, mucho, mucho... Si estás con las prácticas de ASO, ánimo. Si estás con otra cosa, ánimo también.
Un saludo!
Estás desarrollando un aplicación con Java RMI para linux (una fedora core 6, por ejemplo). Hasta ahora va todo bien, lo has probado en local y perfecto. Vas al siguiente paso, un servidor en una máquina y otro en otra. E intentas acceder desde un cliente de una máquina al servidor de la otra máquina. En el servidor has lanzado el rmiregistry, las opciones con que lances el rmiregistry no nos importan demasiado. El caso es que el registro rmi está lanzado, el servidor ha registrado el objeto y queda a la espera de peticiones. Nuestro cliente, y esto es importante, hace un Naming.lookup y encuentra el objeto en la otra máquina. Es importante que lo encuentre, si no lo encuentra algo estamos haciendo mal, revisa!. Si lo encuentra, entonces vamos a llamar a uno de los métodos del objeto remoto. Y nada más hacer la llamada nos encontramos con este error:
Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at ...
(y lo que sigue, pero para que poner el resto de la pila si con esto nos vale)
Estamos intentando acceder a un objeto en otra máquina, que de hecho hemos encontrado (con el Naming.lookup) pero no nos deja ejecutar uno de sus métodos. Y por lo menos pone Connection refused, porque si tu versión de java está traducida, te pondrá "Conexión rehusada". Piensa en rehusar como en rechazar, quítate de la cabeza nada que tenga que ver con volver a usar!!! (Suele pasar). Bien que es lo que pasa aquí? Pues resumiendo, cuando el cliente ha encontrado el objeto remoto (Naming.lookup) lo que obtiene es una dirección ip para poder acceder a él. Da igual que hayamos accedido al objeto a partir del nombre de la máquina. El rmi lo que hace es devolver una ip, que obtiene del /etc/hosts, para no tener que acceder siempre a ese fichero y ver la ip que corresponde con el nombre de la máquina. Me explico fatal. El tema está en que el fichero /etc/hosts seguramente tengas algo así:
127.0.0.1 localhost mimaquina
Cuando para que te funcione, mimaquina debería apuntar a la ip "real" de tu maquina (/sbin/ifconfig para ver la ip en linux, ipconfig en windows por comando)
Contenido necesario de "etc/hosts" (para Linux Fedora)
127.0.0.1 localhost
192.168.0.xxx mimaquina
Espero que te sirva de utilidad, yo perdí mucho tiempo con este tema, mucho, mucho... Si estás con las prácticas de ASO, ánimo. Si estás con otra cosa, ánimo también.
Un saludo!
Suscribirse a:
Entradas (Atom)

