Diario de Programación

Ya he terminado de leer "The Pragmatic Programmer", compañero inseparable en las terrazas de verano de todo "nerd" que se precie.

Para mi gusto se queda demasiado en la superficie y simplemente cuenta cosas que más o menos todos sabemos, pero no aplicamos.

Sin embargo, siempre es bueno ver por escrito todo esto que sabemos y no hacemos, que nos recuerden de vez en cuando las ventajas que tiene y, desde luego, ayuda mucho a aclarar ideas. También da ideas nuevas, cosas que supongo que acabaríamos intuyendo con el tiempo, pero leyendo este libro caemos en la cuenta mucho antes.

Lo más importante que he sacado en claro es el principio de "no te repitas". Yo siempre he tenido claro que el código no se debe repetir, pero en el libro van mucho más allá. No se debe repetir dos veces la misma información no sólo en el código, sino tampoco en la documentación, composición de las bases de datos, etc, etc.

La idea es que si hay un documento que describe cómo son las bases de datos, se deberían poder construir las bases de datos automáticamente a partir de este documento o bien, generar automáticamente este documento a partir de la base de datos. Si además hay código que maneja esa base de datos, mucha parte de este código debería generarse automáticamente. De esta forma, bastaría, por ejemplo, tocar el documento de base de datos para que tanto la base de datos como el código se corrijan automáticamente.

Para poder conseguir esto, es muy importante hacerse scripts que a partir de, por ejemplo, la documentación, genere las sql para crear las bases de datos y el código fuente -en java por ejemplo-, para manejar esa base de datos. En el libro destacan la importancia de perl para este tipo de cosas -lenguaje de script avanzado que permite hacer fácilmente este tipo de cosas- y la importancia de hacer documentación con texto plano, que pueda ser leído o generado fácilmente por estos scripts.

Otra idea muy importante del libro, que posiblemente también sabemos todos y que por pereza no solemos hacer, es que cualquier tarea repetitiva, se debería automatizar. El compilado se debe hacer automáticamente todas las noches. Si al programar repetimos una secuencia de comandos con cierta frecuencia, deberíamos hacer una macro. Si al empezar una nueva clase java la generamos con un esqueleto concreto -comentario de cabecera, comentario de la clase, clase, atributo para usar log4j, etc, etc-, deberíamos tener un scripit o macro que lo haga automáticamente. Nuevamente, cobran importancia los lenguajes de script estilo perl.

Aquí ha salido nuevamente una idea para el trabajo. Un par de compañeros mios empezaron a hacer unos instaladores para los nuevos, de forma que les instalasen en sus PCs el java, el eclipse, el CVS, sacaran los proyectos de CVS, etc, etc, etc. Yo no le dí demasiada importancia, pero efectivamente es algo importante. Hablan de meter catorce personas nuevas y si se hace esta tarea a mano -preparles el entorno de desarrollo en el pc-, es una persona antigua que perderá el tiempo haciendo una y otra vez lo mismo. Es mejor hacer el instalador y usarlo cada vez que llegue uno nuevo. Cuando volvamos de las vacaciones les incordiaré para que terminen el instalador.

Otra idea del libro que me ha llamado la atención, aunque quizás de utilidad menos inmediata, es la necesidad de que los que somos programadores aprendamos lo más posible. Según el libro, deberíamos proponernos -y cumplir- leer una serie de libros al año, aprender un lenguaje nuevo cada año, etc, etc. Es más, para diversificar lo más posible, deberíamos elegir aquello lo más alejado posible del tema que tratamos en el trabajo. Si alguien trabaja con java, puede tratar de aprender perl, si alguien hace aplicaciones de escritorio, debería aprender a hacer aplicaciones web, etc, etc. El ver cómo se resuelven problemas en otros campos puede darte ideas de cómo resolver tus propios problemas en tu campo o simplemente ideas nuevas de cómo hacer las cosas de otra manera.

En fin, un libro interesante, con algunas ideas que no tienen desperdicio.

Hace ya unos años, mi jefa se fue de baja de maternidad. Durante esos meses, me tocó a mi llevar a su grupo de gente, unas seis personas.

El responsable del proyecto que estábamos empezando en ese momento me comentó que en un par de meses iba a venir el cliente y que quería una demo de lo que lleváramos hecho hasta ese momento. Yo, siendo novato en estas tareas de jefe-planificador, insistí mucho en lo que a mí me gustaría saber cómo programador: Qué entraba en la demo y qué no tenía que estar hecho. Tras un par de horas de reunión llegamos a un acuerdo, una serie de cosas hechas con una serie de faltantes, junto con un plazo de tiempo que yo consideraba razonable.

Después de eso hice una planificación por semanas con la gente disponible, para llegar a esa demo en plazo. La planificación era apurada, pero razonable. Además, con intención de aprovechar lo que cada uno sabía hacer, hice algo que se salía de lo normal. En vez de dar una funcionalidad a cada una de las personas, repartí cada funcionalidad entre varios, de forma que cada persona hiciera dentro de esa funcionalidad lo que mejor sabía a hacer. Puse a hacer todos los gráficos al que sabía de gráficos, pequeñas librerías de componentes reutilizables a los más nuevos que desconocían el proyecto, pero sabían programar, etc, etc. El resultado de esta decisión es que el trabajo de uno dependía de que otro acabara previamente el suyo. El que tenía que integrar los gráficos en la ventana principal, tenía que esperar a que el de los gráficos los tuviera acabado. El que necesitaba el componente reutilizable en su parte de código, debía esperar a que este componente estuviera, etc, etc.

Hice una reunión al principio para explicar el objetivo de la demo, el plazo y las tareas que todos tenían asignadas hasta esa fecha. Todos los Lunes hacíamos una reunión para ver cómo íbamos, para ver si Fulanito había acabado su parte para que Menganito pudiera seguir con la suya, rehacer la planificación si era necesario, etc, etc. Yo, por mi parte, también estaba en esa planificación con mis cosas para hacer y era un programador más dentro del equipo -aunque con menos código para hacer y algo más de responsabilidad-. También me encargaba, casi a diario, de hablar con unos y otros y ver si tenían problemas para continuar con su tarea, si necesitaban algo, problemas, etc y trataba de ayudarles.

¿Y qué paso con todo eso?. La demo se cumplió y salió bien, pero lo que más me asombró fue lo que conseguí sin quererlo. La gente empezó, sin pedírselo y ni siquiera insinuárselo, a echar horas extras e incluso me pidieron permiso para venir los sábados: "Estoy a punto de acabar y me falta un poco para dejarlo "niquelado". ¿puedo venir el sábado para terminarlo?". Incluso gente que tenía fama de cumplir estrictamente su horario y ser de los que diez minutos antes de la hora se está preparando para salir, empezaron a quedarse más tiempo según nos acercábamos al fin de semana y se veían apurados para acabar su parte. El Viernes salimos a las dos y media. Algunos llegaron a quedarse hasta las ocho de la tarde, insisto, sin ni siquiera insinuárselo.

Mi conclusión es que la gente, en general, se siente responsable de su trabajo. Si a una persona le das un plazo razonable, pero ajustado, de tiempo para hacer un trabajo y le haces ver la importancia de que su trabajo esté: Un compañero depende de ese trabajo para seguir con el suyo, el jefe le pregunta cómo va y se preocupa de allanarle el camino, etc, esa persona al final tiende a dar todo de sí para que su trabajo esté en el plazo.

Para que una planificación funcione, se cumpla y motive a la gente a seguirla, creo que debería cumplir más o menos los siguientes puntos

1. Un objetivo claro a un plazo no muy largo, uno o dos meses, con una planificación razonable, pero ajustada. Que la gente lo vea posible, pero sin dar opción a perder el tiempo. Si el objetivo es importante, como una visita del cliente o un jefazo, mejor que si es simplemente un objetivo interno que no pasa nada si no se cumple.
2. Tareas asignadas a cada persona a corto plazo, a una semana, por ejemplo. Cada programador debe saber qué tiene que hacer ahora y qué va a hacer después.
3. Las tareas de unas personas deberían ser necesarias para que otras personas puedan realizar las suyas a la semana siguiente. De esta forma, cada persona ve la necesidad de acabar sus tareas en los plazos cortos establecidos y siente que su trabajo es importante y necesario.
4. El "jefe" debe tener también sus tareas en la planificación, que se le vea que trabaja y debe preocuparse de resolver los problemas que tengan los programadores para cumplir sus tareas. De esta forma se refuerza el que los programadores sientan que su trabajo es necesario e importante.
5. Seguimiento de la planificación. Reuniones frecuentes -por ejemplo, una vez por semana- para ver qué hay hecho, retocar la planificación si hace falta, etc. En estas reuniones, si un programador no ha cumplido, sin necesidad de echarle la bronca ni ponerle mala cara, verá que la consecuencia es que hay que retocar la planificación y que otras personas van a tener que retrasar su propio trabajo.

Sin embargo, todo esto también me creó un cargo de conciencia importante. Siempre he sido más currito que jefe y me he identificado más con los curritos que con los jefes. Hacer una planificación de este estilo sabiendo que posiblemente consigas que la gente eche horas extras sin pedírselo, me parece "jugar" con la gente, típico de jefe pérfido, malvado y sobre todo manipulador. De hecho, al que me pidió permiso para venir un sábado le dije que no lo hiciera, que cuando llegaran los hitos importantes con el cliente -entrega del proyecto- ya habría ocasión de quedarse y posiblemente obligados.

También tuve otro tipo de problemas con esta planificación. Una funcionalidad la repartí entre dos personas de carácter fuerte y algo conflictivo. La "estrecha" colaboración entre ambos hizo que acabaran peleándose y no volvieran a hablarse. Supongo que en parte fue culpa mía, que debería haber definido con más detalle el trabajo asignado a cada uno de ellos y la interface entre ambas partes del programa.

Sigo preocupado y dándole vueltas al tema.

Si se hace código reutilizable, tenemos una serie de ventajas, pero también una serie de inconvenientes. Las ventajas son claras:

1. Codificaremos menos en futuros proyectos. En vez de hacer código similar otra vez, podremos instanciar una clase o módulo ya hecho. Nuestros futuros proyectos llevarán menos tiempo de codificación.
2. Con el tiempo tendremos un componente reutilizable fiable y libre de errores. Con el tiempo, esa clase que simplemente instanciamos, tendremos una cierta garantía de que no tiene errores. Nuestros futuros proyectos llevarán menos tiempo en depuración.

Sin embargo, también tiene pegas, y no son tontas.

1. Se pierde más tiempo ahora. Un componente reutilizable se tarda más en hacer. El proyecto que estamos haciendo ahora tardará más.
2. Por otro lado, el código es más críptico y menos intuitivo. Siempre es más fácil un código todo seguido que instanciar una clase configurable a la que debemos pasarle para configurarla un fichero, un patrón estrategía o heredar obligatoriamente de una interface. Depurar esas cosas mientras el componente no es totalmente fiable puede ser un pequeño infierno.
3. Requiere un tiempo de aprendizaje. Si no hemos hecho esos componentes reutilizables nosotros mismos, puede llevar tiempo. Cualquiera que haya intentado utilizar alguna de las librerías que hay por internet -javamail, jasperreport, ibatis, etc- sabe que no es tan sencillo como bajarse la librería y ponerse a codificar.
4. Los componentes reutilizables a veces nos obligan a una gestión de versiones compleja. A veces necesitamos añadir o modificar la funcionalidad de un componente reutilizable para un nuevo proyecto. Por compatibilidad con proyectos anteriores no podemos hacerlos, así que tenemos que empezar a crear versiones del componente reutilizable, o bien apañarnos para hacer las modificaciones sin perder compatibilidad. En el primer caso, si más adelante encontramos errores en el componente reutilizable, tendremos que corregirlos dos veces -o tantas como versiones distintas afectadas por el error tengamos-. En el segundo caso, tendremos que andar cargando con métodos y clases obsoletas. Todos vemos en la API de java la cantidad de métodos obsoletos que hay que no se pueden eliminar por compatibilidad.

Todo esto me lleva a pensar ¿cuál es el punto de compromiso?. ¿En qué punto compensa hacer el componente reutilizable frente a hacer un copy/paste del código anterior?.

Yo hasta hace poco tendía a hacer componentes reutilizables siempre que podía, a pesar del esfuerzo que supone. Actualmente, tras unos años de experiencia con esa política, empiezo a pensármelo dos veces antes de hacer un componente reutilizable. Sobre todo tras ver a compañeros de trabajo heredar código de otros que se han ido, no conocer los componentes reutilizables que se usan en ese código y ver cómo tarda una semana en encontrar un bug tonto, simplemente por no poder seguir el código fácilmente.

También me ha pasado a mí, a pesar de conocer los componentes reutilizables que tenemos. A veces me piden un pequeño cambio de funcionalidad en el proyecto y me basta con una sola línea de código para introducirla, pero me tiro dos días para encontrar dónde y cómo meter esa puñetera línea, precisamente porque el código no se ve a simple vista.

Un ejemplo tonto muy claro. Supongamos que vamos a leer un registro de una tabla de una base de datos. Podemos hacer un código específico que lea el registro y lo meta en un bean de java -con atributos, métodos set() y get()-. Eso sería muy claro en el código, aunque poco reutilizable. Tendríamos que hacer código similar para cada tabla distinta en base de datos.

Su equivalente muy reutilizable y que ahorra código -no hay que hacer ninguna clase- sería un Hashtable. Leemos la tabla y sus metadatos. Usando el nombre del campo como clave del Hashtable, metemos su contenido como valor. Un simple método en una clase al que pasemos en nombre de la tabla a consultar y el where de la consulta puede construirnos el Hashtable de cualquier tabla. Sin embargo, a la hora de depurar o seguir código, cualquiera prefiere tener un bean y ver los métodos get() y set() o los atributos, que andar con un Hastable intentando averiguar con el debugger qué claves tiene y qué valores.

Con el bean, para reutilización, puede usarse la introspección de java, pero a la hora de depurar o seguir el código cualquiera prefiere ver un getValor() que ver un montón de líneas de código extrañas en las que se buscan los atributos y nombres de métodos del bean para invocarlos de forma oscura y críptica.

Siempre que me pongo a programar, aunque sea una tontería, me pasa lo mismo. Me quedo bloqueado.

Como comenté en un post anterior, estoy haciendo un pequeño programa PHP para que la gente pueda apuntar en qué proyectos trabaja durante el mes y cuánto tiempo dedica a ello. Cosas del trabajo.

Me puse a ello. Lo primero, una tabla de base de datos para apuntar a los programadores y una serie de páginas php para que se puedan registrar, hacer login y, por supuesto, para que el administrador pueda administrar esa tabla: añadir, borrar y modificar usuarios.

Todo estupendo hasta este momento.

Iba a ponerme ahora con otra tabla de base de datos en la que se apunten los proyectos en marcha. Por supuesto hay que hacer otra serie de páginas php para administrar esa tabla: crear, borrar o modificar proyectos.

Ahí me he quedado bloqueado.

Es otra vez lo mismo. Otra tabla a la que  hay que hacerle nuevamente tres páginas php para lo mismo de antes, altas, bajas y modificaciones. Lo más cómodo, copy/paste de las de usuarios e ir modificando. Pero copy/paste desde mi punto de vista ¡¡es pecado!!. El código no debería repetirse. Hay que hacer lo posible por extraer lo común a una función o grupo de funciones y reutilizarlas.

Rápidamente, me puse a darle vueltas a la cabeza. Tendría que hacer unos ficheros de configuración que digan cómo son las tablas -o bien mirar directamente los metadatos de la base de datos- y luego hacer tres funciones que me den la página de alta, baja y modificación simplemente pasándoles el nombre de la tabla y qué campos son el identificador principal de la tabla. Seguramente sea necesario algún parámetro más.

Esto, por supuesto, lleva más tiempo que un copy/paste y hacerlo todo a piñón fijo, repitiendo el código cada vez que se presente una tabla. También es más versátil. Si se hace bien, te ahorrará un montón de trabajo cada vez que tengas que hacer una tabla con añadir, borrar y modificar. En contra, también, que el código resultante será mucho menos claro.

Y en eso estoy.

Una aplicación que me podía llevar una o dos semanas a ratos libres -estoy de vacaciones-, me va a llevar:

• unos días para hacer la primera tabla
• otro día para empezar la segunda tabla y ver que el copy/paste me vendría bien pero no quiero usarlo.
• una semana entera para darle vueltas a si hago o no hago la cosa esa común/reutilizable para no utilizar el copy/paste.
• otras dos semanas para ponerme a hacerla y meterme en complicaciones.
• un minuto para mandarlo todo a la mierda. No acabaré el común/reutilizable porque es más complejo de lo que parece y no hago el copy/paste porque es pecado. La aplicación y yo nos quedamos bloqueados.
• Varios meses para estar pensando: "debería acabar eso que tengo a medias…."

Pues eso, ahora mismo estoy en el punto 3, empezando la semana de darle vueltas a ver si hago o no la cosa común/reutilizable. Para este proyectito no merecería seguramente la pena, pero seguro que este proyectito no es el último.

¿No estais hasta las narices de hacer siempre lo mismo, una y otra vez tabla en base de datos, ventana de alta, de modificación y de baja?. ¿Haríais la cosa común/reutilizable?.

Últimamente parece que tengo hormiguillas en el culo. No paro quieto y ando saltando de un tema a otro.

Primero me puse con el tema de perl, para hacer mi conversor de lenguajes. Eso fue cosa del trabajo.

Luego estuve un par de semanas de Rodriguez en casa, sin familia, así que retomé lo de JSP. Tenía los taglibs un poco atascados por una tontería de Maven.

Ahora, de vacaciones, y a ratos perdidos, he retomado lo de PHP que dejé en su día. Estoy intentando hacer una pequeña librería PHP para la validación de sesiones y usuarios. La idea es que haya una serie de páginas PHP que permitan ver una lista de usuarios y añadir, borrar y modificar dichos usuarios. Esta parte está prácticamente acabada.

Luego, haré unas funciones PHP que se puedan llamar desde otra aplicación PHP y que permitan validar una sesión con uno de los usuarios. También se podrá además llamar al conjunto de páginas PHP de usuarios para gestionarlos.

Con esto tengo intención de hacer dos aplicaciones PHP:

• Una para el trabajo, que permita a la gente poner cuántos días del mes han dedicado a qué proyectos.
• Otra para mi página web, que permita añadir comentarios a los tutoriales. Ya la tengo hecha, pero si algún patán mete alguna burrada, el borrado dichos comentarios se hace manejando directamente la base de datos. Quería poner un usuario administrador -yo- que pueda borrar desde el navegador los comentarios de los patanes.

Pues nada, poco a poco y a ver si acabo alguna de ellas antes de que me pique otra hormiguilla en el culo. La del J2EE con EJBs anda por las cercanías ….

En http://www.myjavaserver.com/ te puedes apuntar gratuitamente y te dan un servidor web con jsp -y creo que j2ee- para que hagas tus propios desarrollos y pruebas con estas tecnologías.

Puesto que quieren garantizar que los que se dan de alta son desarrolladores y no van a usar el sitio para otros fines, es muy curioso el mecanismo para comprobarlo. Para darte de alta te ponen primero un pequeño método para rellenar. Debes hacer el código y este debe pasar los test en línea.

De momento es el único servidor gratuito que conozco que ofrece JSP, así que para pruebas y desarrollos, además de instalarte el Tomcat en tu propio PC, es una buena opción.

En el libro "The pragmatic programmer" que estoy leyendo hay un párrafo que me ha llamado mucho la atención.

Básicamente viene a decir que en un grupo de programadores más o menos grande debería haber dos jefes, dos cabezas visibles. Uno es el responsable técnico. El que debe organizar el trabajo de los programadores, dividirlos en grupos y asignarles las tareas. Debe tomar las decisiones técnicas y debe sobre todo vigilar que los grupos de programadores no repitan trabajo.

El otro responsable es el encargado de la gestión, de conseguir las herramientas y medios necesarios para que los programadores trabajen a gusto, llevar la planificación y sobre todo, hacer de interface con la gente ajena al grupo, de forma que los programadores y el responsable técnico puedan centrarse en hacer software.

Lo que más me ha llamado la atención es que sin ser oficial, esta es la forma en la que llevamos mucho tiempo trabajando mi jefa y yo. Ella es la que se encarga siempre más de la gestión y relaciones con el exterior. Casi todas las decisiones técnicas y organizar el trabajo de la gente las ha delegado en mí y ha sido mi responsabilidad extra oficial.

También, de alguna forma, es el origen de muchas empresas que hoy son importantes. Google, Hewlet Packard, Apple, Microsoft, Disney han empezado con dos personas -tradicionalmente en un garaje- haciendo algo, lo que sea. Casualmente, en casi todos esos casos, aunque los dos amigos solían ser técnicos, a uno le iba más la técnica y el otro era un poco mejor relaciones públicas. Vaya, uno era el que curraba y el otro el que conseguía vender el producto.

Y esto me confirma un poco el pensamiento que siempre he tenido. La persona que tiene la cabeza adecuada para "entender punteros", no suele llevarse bien con la gente -y es de los que lee "the pragmatic programmer" en una terraza de verano sin compañía, salvo un café con leche caliente-.

Antes, los oficios eran más o menos hereditarios o para toda la vida. El hijo del herrero, del zapatero, del curtidor aprendían el oficio de su padre o maestro. Cuando llevaban muchos años de aprendices, heredaban el negocio y se convertían en maestros de nuevos aprendices.

Actualmente, todos preferimos a un zapatero que sea un señor mayor, que lleva toda su vida en una zapatería cutre, que a una de esas tiendas de arreglo de zapatos modernas, en las que hay un chico joven en una tienda muy de moda en un centro comercial.

La situación actual con la programación no es muy distinta, ya que se contrata para programar a un recién salido -da igual la titulación, FP, media o superior- Cuando empieza a adquirir algo de experiencia -uno o dos años-, es cuando se empieza a considerar que es un fracasado si sigue programando. Hay que ascenderle y darle responsabilidad de alguna manera. El mismo programador pide dicho "ascenso" o se va a otra empresa a buscarlo. Cuando empieza a adquirir experiencia, lo ponen a diseñar, a llevar un proyecto, de jefe o lo que sea.

Yo llevo años programando -ni me gusta ser jefe ni quiero serlo- y sin necesidad de cambiar de tecnología ni de lenguaje, aprendo cada día nuevas formas de hacer las cosas, descubro nuevos "trucos" del lenguaje de programación que uso. Y lo que es peor, descubro cosas que llevo años haciendo mal y deberían hacerse de otra manera.

Aunque mi conocimiento de lenguajes es limitado -java y C++ para unix-, y aunque mi cabeza quizás no me da para resolver rápidamente un algoritmo complejo, todos estos años programando me han hecho aprender muchos trucos del lenguaje, creo comprenderlos bien y me siento cómodo con ellos. Mi experiencia con la gente nueva, incluso aunque sepan java o C++, es que hay que enseñarles. Los hay más o menos espabilados, pero es raro que vengan con los conceptos claros, con conocimientos profundos del lenguaje, con sus trucos aprendidos. Simplemente, les falta experiencia en la programación con ese lenguaje.

Según lo veo yo, debería haber gente que les guste y se queden muchos años programando, que no consideren que programar muchos años es un fracaso -la mayoría lo piensan-. Estos deberían empezar como aprendices de alguien con varios años de experiencia, como los antiguos aprendices y deberían empezar a hacer código casi casi guiados de la mano. Prácticamente se les debería dar la clase o la función preparada simplemente para rellenar el código interno y deberían ser supervisados por el "maestro" con varios años de experiencia.

De esta forma, poco a poco y sin causar grandes desastres en los proyectos, irían aprendiendo los intríngulis del lenguaje, adquiriendo experiencia e independencia, la forma correcta de hacer las cosas, hasta ser capaces de tirar por sí solos y empezar a "enseñar" a otros nuevos aprendices.

Desgraciadamente, no es así. En los sucesivos proyectos de mi empresa, a lo largo de los años, se mete la pata en lo mismo una y otra vez, porque los que codifican siempre son los nuevos. Los expertos ahora son jefes y no tienen tiempo de meterse con el código. Y los nuevos que codifican lo hacen casi sin ningún tipo de guía y meten la pata en las cosas normales que puede meter la pata uno nuevo una y otra vez, y otra vez y otra vez más: Conexiones a base de datos que se quedan abiertas, hilos que se bloquean, ventanas que se van detrás, interfaces de usuario prácticamente iguales que se comportan distinto, tareas simples que se hacen muy lentas por usar algoritmos ineficientes, código excesivo que se hace con muy buena intención, pero en la práctica no sirve, etc, etc, etc.

Según se muestra en este video, parece que los problemas de los administradores informáticos con los usuarios torpes vienen desde antiguo. Ya los antiguos monjes …

Alucino con lo que se inventa por ahí.

Urgando por la red me he encontrado con un puente PHP/Java. Básicamente es un añadido a PHP de forma que se puede llamar a clases de java desde PHP.

El manejo parece muy sencillo en la página. Simplemente se instancia una clase PHP llamada Java a la que se le pasa en el constructor como String el nombre de la clase Java. La clase PHP creada así tiene todos los métodos de la clase Java y a partir de ahí podemos usarla normalmente como PHP. Un ejemplo copiado de la página

<?php
$v = new Java("java.util.Vector");
$v->add($buf=new Java("java.lang.StringBuffer"));
$buf->append("100");
echo (int)($v->elementAt(0)->toString()) + 2;
?>


En fin, es una cosa que si me preguntan antes de verla diría que es imposible llamar desde php a java -salvo quizás alguna función php para lanzar ejecutables externos-. Va a haber que pensárselo dos veces antes de decir en programación que algo no se puede hacer.