| |
Cuando yo afirmo “Respecto del universo Java, el lenguaje es estrictamente un medio, no un objetivo”, se me antoja que los oyentes asumen un mensaje paraolímpico del tipo “Lo importante es participar”. Y si hablo de arquitecturas de componentes restalla en el ambiente, en un énfasis evidentemente sexual, una sensación plena de insatisfacciones e incapacidades psiquiátricas. ¿Componentes? ¿Qué son componentes? Mejor dicho, ¿qué son componentes software? Pues, querido lector, como diría Becquer, componente … ¡eres tú! Y es que en un entorno, cual es el de la informática, en que para definir una arquitectura 3-tier se pone un ejemplo y donde metodología significa método, aviados vamos con la precisión conceptual de los vocablos. Con todo, ¿no les suena “componente” un tanto a “objeto”? Todavía recuerdo con pasmo mi encuentro, hace años, con decenas de definiciones del término “objeto”, provenientes de celebérrimos autores, que, matizadamente distintas, venían en esencia a afirmar que “un objeto es … cualquier cosa”. De aquí el lector ilustrado deducirá que al ser un componente un objeto [1], en principio un componente es … cualquier cosa también (la herencia, ya saben, quizás en un sentido más práctico del que suponen). ¡Bravo! De nuevo acertó el lector, porque un componente no lo es mientras no pueda ser (o haya sido) usado como pieza de construcción de una estructura colaborativa concreta de componentes, de forma que en este caso la cualificación del medio la otorgará el fin. O sea, que cualquier objeto será un componente sólo respecto de una estructura, área, patrón y/o arquitectura específicos: una rutina es un componente software, como lo es una clase, una biblioteca de clases, un entorno-marco, un programa o un conjunto vertical/horizontal de aplicaciones. Claro que si la definición de un componente queda un tanto lasa, se conoce bien, por el contrario, cómo medir su bondad: un componente software será tanto mejor cuanto más fácilmente pueda integrarse en más y más entornos heterogéneos, usualmente distintos de aquél o aquéllos para los que fue originariamente diseñado. Se busca, con cierta lógica, la genericidad del uso. Además, a un buen componente se le debe exigir una cualidad fundamental: estar ya codificado. Esto es: como coligió San Agustín respecto de Dios, una de las perfecciones es existir. ¡Por supuesto [2]! Uno de los principios más extendido de la Tecnología de Objetos, al afirmar “no reinventemos la rueda”, pondera la necesidad de existencia previa de conjuntos de componentes que no deban ser reinventados. Pero resulta que Java es demasiado joven, y calificar en la actualidad a los applets de genuinos componentes es ganarse una bula de un mes. Aun más: si consideramos, por ejemplo, los distintos componentes existentes a esta fecha en C++ podemos inferir que su bondad es, en el mejor de los casos, lastimosamente mediocre, pues su capacidad de reúso (con las honrosas excepciones de la STL y demás código glorioso) es significativamente baja. ¿Por qué, pues, Java habría de procurar sustantivas mejoras? Pues porque Java es más que un lenguaje: es una plataforma común que sirve de base a la ejecución de aplicativos Java, y como tal plataforma puede embeber arquitecturas específicamente diseñadas para la efectiva integración de componentes y que se repetirán doquiera vaya a ejecutarse código Java. De hecho la esencia de los applets es que pueda asegurarse, mediante la adopción de la plataforma Java como un todo, la existencia en la parte cliente de las clases necesarias para que el applet conste de un muy poco de código y ofrezca un mucho de funcionalidad. Y es que Java tiene muchas posibilidades: desde la rudimentaria concepción de los applets hasta la modificación de la máquina virtual Java, pasando por la creación de APIs de integración y control. De hecho en lo que sigue veremos cómo se han acometido (y en algún caso “cometido”, como diría Lugones) cada una de estas estrategias.
APPLETS, INTERNET E INTRANET
Applets, applets … ¿es realmente tan evidente qué significa, qué representa, qué idea de modularidad o esquema de componentes se esconde tras este vocablo? Patrick Naughton afirma en su obra “The Java Handbook [3] ” que un applet es ”una pequeña aplicación accesible en un servidor Internet, que se transporta por la red, se instala automáticamente y se ejecuta in situ como parte de un documento web”. Oh, sin duda un applet es, por su concepto originario, exactamente lo aquí descrito. Claro que, tras el adecuado uso publicitario de Internet, y puesto que James Gosling, vicepresidente de Sun y padre del Oak/Java, severamente afirma que Java es un lenguaje de programación de propósito general, yo diría que la definición anterior puede reformularse así: “Un applet es una aplicación accesible en servidores Internet/Intranet, que se transporta por la red, se instala automática y encadenamente y se ejecuta in situ como parte de una colaboración cliente/servidor”. Hmm, ¿Oigo quejidos? Siempre pasa cuando menciono el vocablo “Intranet” en ciertos entornos técnicos [4]: se me mira como queriendo decir “No insultes mi inteligencia” y “¿Dónde está la máquina de café?”. Lo cierto es que yo no sé si importa o no que la encapsulación de la tecnología Internet dentro de una organización suponga o no una diferencia conceptual respecto de … ¿qué? ¿Es todo Internet? ¿Lo privado y lo público no casan? ¿Firewalls? ¡Qué más da! Puestos a embrutecernos con los nombres de arraigo comercial, ¿por qué no envilecernos usándolos intensivamente? Así que … ¡Intranets! Bien, decía que en realidad un applet es una porción de código que actualmente (en el sentido más americano) está configurado como la instanciación de una clase derivada de la clase Applet, con unos métodos específicos de arranque, parada, etc., que a su vez está inmersa en la biblioteca gráfica AWT, y ejecutable, por razones de presión publicitaria, mayormente en visores web. Claro que la idea que subyace bajo el applet no tiene por qué observar eternamente esta serie de restricciones. Tal idea básica define un applet como un módulo ejecutable que carece de marco de ejecución propio y que, por tanto, necesita ser llamado en el ámbito de una aplicación externa. Precisamente la modularidad “bien entendida” del applet viene dada por esta independencia del entorno de ejecución, de donde también se deriva su idoneidad como unidad de composición para contenedores apropiados. Se trata, en definitiva, de una porción de “bytecode” que circula libremente [5]por la red y es susceptible de ser utilizada por un “programa” específicamente preparado para manejarla. Claro que este enfoque de estructuración de componentes resulta demasiado rígido o “cautivo”. Además esta integración “ad-hoc” no soluciona el problema de la intercomunicación de componentes/applets, que actualmente se realiza, en general, usando un lenguaje de scripting (como VisualBasicScript o JavaScript ), a cual más propietario e inadecuado. Pero no me malinterpreten: los applets están bien; muy bien, diría yo. He aquí algunos ejemplos:
- Un diálogo de acceso a servicios de red configurable en ejecución.
- En una contabilidad con un kernel básico Java: cualesquiera de los servicios de interfaz y construcción modular en la parte cliente (diálogos de acceso a extractos de cuentas, menúes restringidos sin ficheros externos de parametrización, etc.)
- En una facturación: cada patrón de configuración de lotes, aglutinador de prototipos de transacciones comerciales de productos y/o servicios.
Los applets, pues, son necesarios, pero no suficientes. Y es que su integración con los contenedores correspondientes (Netscape Navigator, Microsoft Internet Explorer, etc.) se basa en una ligazón tan simple como la de la etiqueta HTML <applet></applet>: nada por aquí, nada por allá: realmente hace falta magia para convertir esto en un entorno libre de composición. El lector ya habrá adivinado que el problema principal, aparte del de la integración individual de applets, es el de la interacción entre ellos. Y no sólo hablamos de interacción entre applets, sino más bien de comunicación entre módulos posiblemente codificados en distintos lenguajes. Java no es un lenguaje de programación “distribuido”, aunque proporciona facilidades para la creación y mantenimiento de objetos distribuidos; Java no es, tampoco, un lenguaje de componentes, aunque su plataforma pudiera procurar facilidades para la gestión de éstos. Se trata, pues, de procurar una infraestructura o conjunto de infraestructuras para aprovechar esas facilidades. Y abundando en el asunto del aprovechamiento, veamos ahora cómo Microsoft ha abordado este señalado problema de la integración.
OLE Y ACTIVEX
Lo que sigue es, en breve, un recorrido por la estrategia comercial y tecnológica de Microsoft respecto a Java, y esto supone que primero revisaremos la tecnología de componentes para luego entrar en su relación con Java. Pero, para variar, consideraremos también a Microsoft, como antes a Java, una persona jurídica “mayor” y obviaremos, así, diatribas estomacales para entrar a criticar y, si acaso, agradecer ciertos comportamientos, casuísticamente nobles o no. Así que ¿cuál es esa tecnología? ¿OLE? ¿COM? ¿BG? ¡No, no y no! Ahora es … ¡ActiveX! Pero desgranemos: según Microsoft, ActiveX NO es simplemente un nuevo nombre para OLE, a pesar que OLE y ActiveX están basados en COM (Component Object Model [6]). Si seguimos a la casa madre hay que establecer límites:
- OLE usa COM para proveer servicios de enlazado y embebimiento en documentos compuestos, a fin de favorecer la integración de componentes en aplicativos ofimáticos.
- ActiveX, por otro lado, utiliza COM para proveer una infraestructura, optimizada en velocidad y tamaño, destinada a embeber controles que puedan responder interactivamente a eventos.
Claro que el resto del mundo asume que ActiveX es OLE rebozado de Internet. Las diferencias son tan sutiles que uno necesita revisar y repasar los vocablos en cada caso empleados. De todas maneras no ha lugar para tanta disgresión: se trata de un conjunto de tecnologías (¡Abuelito! gritan los jóvenes del universo Microsnot, http://www.microsnot.com, al reconocer un control OLE) que se han ajustado a un universo donde el transporte por la red (¡La red! Noten la ubicuidad de su adscripción conceptual, como el ente “Jane” en las novelas de Orson Scott Card) impone sus propias restricciones y concesiones.
JAVA Y ACTIVEX
Java es, y ActiveX NO es, un lenguaje, un sistema basado en bytecodes inter-plataforma, un sistema operativo, un entorno con un subconjunto “seguro” o una plataforma. Bien, esto reduce nuestras posibilidades, a la vez que enmadeja nuestra red neuronal. La cuestión es que, para Microsoft, Java y ActiveX son tecnologías complementarias, no competitivas. En esencia, para Microsoft, Java es un lenguaje, mientras que ActiveX es una tecnología de integración. Observe el lector que la coletilla “para Microsoft” quiere significar que al menos existe otra interpretación “para Sun”. Claro que ahora estamos en el universo MS, así que en adelante obviaremos el punto de vista subjetivo (¿Cómo no?). Bien: decíamos que Java proporciona bytecodes interpretables en cualquier plataforma en que se ejecute una máquina virtual Java y un conjunto de interfaces para el acceso a servicios Java, mientras que ActiveX integra objetos creados en distintos lenguajes y posibilita la comunicación entre ellos.
¿PLATAFORMA? ¡NO, GRACIAS!
Microsoft pone mucho énfasis en que ActiveX no es una plataforma [7], sino un conjunto de tecnologías que sirve de fundamento y soporte para los componentes denominados controles ActiveX (naturalmente todos los controles OLE son ahora controles ActiveX, aunque no se cumple la relación inversa -¿o sí?-). Que nadie se sorprenda, con todo, si América no es redescubierta, pues tal amalgama está compuesta por viejos amigos del universo Microsoft: |
|
| |
Claro que … hay mucha riqueza tras esta amalgama (repitan conmigo: “más sabe el diablo por viejo …”): toda la que un usuario actual de la plataforma WinTel (un apócope práctico) reúne en su PC de sobremesa: versatilidad, multitud de aplicativos, soporte de impresoras, infinidad de tipos de letras, etc.
CONJUNCIÓN DE COM Y JAVA
Si damos crédito a Microsoft, aquí se revive la histórica convergencia de Aberlardo y Eloísa, pues parece tratarse de la típica compatibilidad perfecta de las agencias matrimoniales por ordenador:
Atributos |
Java |
COM |
Lenguaje de Programación |
Sí |
No |
Arquitectura de Componentes Independiente del Lenguaje |
No |
Sí |
Máquina Virtual |
Sí |
No |
Simple |
Sí |
Sí |
Robusto |
Sí |
Sí |
Orientado-a-Objetos |
Sí |
Sí |
Independiente de la Plataforma |
Sí |
Sí |
Propósito General |
Sí |
Sí |
Multi-Enhebrado |
Sí |
Sí |
Distribuido |
No |
Sí |
¡Oh! Nada sorprendentemente, COM posee justamente lo que le falta a Java, como también veremos que Java, bajo el vestido, reúne mucho de lo que COM anhela. Claro que esta tabla puede molestar a algunas personas políticamente serias (micro-machismo enhebrado como compañerismo). En fin, veamos qué tal funciona esa vida en común.
¿INTEGRACIÓN? ¿CÓMO?
No se ha modificado el lenguaje Java (no se han añadido nuevas construcciones o palabras reservadas). Sí se ha modificado, empero, (y mejorado, según MS) la Máquina Virtual Java (JVM: Java Virtual Machine), de forma que cualquier applet Java desarrollado en otros entornos se podrá ejecutar en la JVM de Microsoft (MSJVM), pero a la vez se podrá acceder también a objetos COM, pues la misma MSJVM permite tratar a los applets/clases Java como controles ActiveX. Las modificaciones realizadas incluyen soporte de COM, reúso de bibliotecas (suponiendo una capacidad de almacenamiento local, se evita la carga repetida del mismo conjunto de clases), versionamiento (muy relacionada con la anterior, como sistema de gestión de carga de clases), Authenticode (el sistema de verificación digital de bibliotecas), mejor soporte de depuración, un recolector de basura no-conservador y compilación nativa Just-In-Time mediante módulos intercambiables (de forma que puedan ser sustituidos con facilidad por mejores implementaciones). Naturalmente esta estrategia era la única posible: cualquier extensión del lenguaje (y aquí obviaremos los términos de la licencia de Sun) hubiera generado código Java cautivo respecto de la plataforma Wintel, además de suponer un ímprobo trabajo de sincronización respecto de las sucesivas versiones del JDK y, en general, de la plataforma Java de Sun. De esta manera tenemos que Microsoft embebe su implementación de la JVM (nominada por Sun como plataforma Java de referencia para Win32) en un entorno de desarrollo denominado Visual J++ que supone la integración “perfecta” de controles ActiveX y aplicaciones y/o applets Java. Llegados a este punto, el lector se planteará: “Bien, ya he leído lo de la integración y lo de las modificaciones, pero, realmente, ¿cómo casan estas dos cosas? ¿Cuál es el funcionamiento real?”. Bueno, nada mejor que un ejemplo. Imaginemos que usamos en nuestro código un objeto COM como si se tratara de una clase Java (y más adelante veremos cómo esto es posible), y para esto añadimos una pertinente línea “import” a nuestro código. El compilador buscará primero una clase Java con tal nombre en las rutas establecidas en la variable de entorno CLASSPATH y después en el PATH del sistema, y, claro, no encontrará tal clase. Microsoft, sin embargo, ha modificado el compilador Java para que pueda tratar con bibliotecas de tipos, de forma que tras el anterior intento fallido busque “MiControl.tlb” (donde “TLB es el acrónimo de Type Library, a la vez que extensión por defecto de los ficheros de bibliotecas de tipos) en las rutas del CLASSPATH. Tal fichero contiene, entre otras cosas, información sobre la clase “MiControl.java” (en definitiva un envoltorio del objeto OLE/COM/ActiveX) que sería importada convenientemente e integrada en el espacio de nombres de nuestro código como una clase Java más. Si no se encontrara el fichero “tlb”, el compilador entonces buscaría un fichero correspondiente IDL (Interface Definition Language: Lenguaje de Definición de Interfaces) e intentaría construir a partir de él la clase correspondiente. Como puede verse, el compilador está haciendo buena parte del trabajo por nosotros, sin que hayamos tenido que tocar una línea de código.
BENEFICIOS DE LA INTEGRACIÓN
Cualquier control ActiveX codificado con: Visual Basic, Visual C++, PowerBuilder, Borland Delphi, Visual J++, o incluso importado de otros entornos Java, podrá ser utilizado directa y sencillamente por los applets/aplicaciones Java desarrolladas con Visual J++. |
|
| |
La idea es que, una vez que se lancen los visores para Macintosh (en cooperación con Metrowerks y Macromedia) y Unix (en colaboración con Bristol Technology Inc y Mainsoft Corp), y amparado por la explosión de Java, ActiveX pueda convertirse en el estándar interplataforma para la creación y mantenimiento de estructuras de componentes, estén o no codificados en Java. En orden a reforzar esta estrategia, Microsoft ha anunciado repetidas veces su intención de someter ActiveX a un cuerpo independiente de estandarización.
El resultado intencional de este esquema convergente es, claro, intentar desbancar a los competidores en el negocio de arquitecturas de componentes: en concreto a Sun y a su tecnología de componentes denominada “Java Beans”, de la que Microsoft afirma que es una simple promesa (vaporware), mientras que ActiveX es una realidad con más de 1000 controles operativos y que se puede encontrar en millones de aplicativos. Claro que esto lo ponderaremos cuando examinemos los “beans”. De momento veamos las claras ventajas del enfoque Microsoft frente al mero tratamiento de applets en visores:
- Cualquier control ActiveX/OLE/COM puede usarse como se usaría una clase Java.
- Una clase Java puede convertirse en un control ActiveX/OLE/COM.
- La interoperabilidad de controles ActiveX y clases Java hace que su comunicación pueda direccionarse mediante COM, eliminando la obligatoriedad de lenguajes de scripting para tal fin.
Fíjese el lector que los componentes hasta ahora existentes en la plataforma WinTel (OCX, DLL, etc.) dejan de ser “legacy components” para pasar a ser “cooperative components”, de forma que pueden abordarse nuevas tecnologías (singularmente la Tecnología de Objetos), lenguajes (Java, por supuesto) y entornos (Visual J++ y los demás citados) sin perder la inversión realizada en componentes. Esto es, la adopción de la nueva tecnología no conlleva “apresamiento de rehenes”, con lo que la disposición de esta plataforma de integración supone para las empresas una verdadera oportunidad tecnológica. Éstas pueden utilizar todo su arsenal de componentes -bien comprados bien desarrollados- e insertarlos en sus nuevos desarrollos Java, con lo cual, de forma financieramente indolora, establecerán una arquitectura abierta para sus aplicaciones. Ante esto surge, empero, una consideración de aviso: todas las facilidades expuestas en el desarrollo e integración de componentes enfatizarán las debilidades existentes en las fases de análisis y diseño, de manera que la aplicación de métodos de OORA/OOA/OOD deviene decisiva en el aprovechamiento de los recursos de las Tecnologías basadas en Java. Dicho esto y para desintoxicarnos de tanto vocablo, veamos brevemente cómo operar y lograr, desde el único entorno preparado para ello: Microsoft Visual J++, la intercambiabilidad ActiveX/Java.
USO DE ACTIVEX DESDE JAVA
Lo que se necesita es convertir el objeto COM en una o más clases Java, y a tal fin MS Visual J++ provee una herramienta: el “Java Type Library Wizard”, que realiza este trabajo por nosotros. Sólo hay que indicarle cuál de los objetos COM registrados se desea usar, y el asistente/mago creará las clases Java correspondientes. ¿Objetos registrados? Bueno, es muy fácil registrar un objeto OLE/COM/ActiveX (un OCX, por ejemplo): se copia el objeto al directorio Windows y se usa el programa de registro (regsvr32.exe en Win95), cuya finalidad es la de añadir una entrada a la base de datos del sistema (y conjunto de bibliotecas de tipos COM) bajo la clave “\HKEY_CLASES_ROOT\TypeLib”. Tales bibliotecas de tipos son, en breve, mecanismos para almacenar y recuperar información sobre objetos COM: interfaces, clases, etc. El asistente (Java TLB Wizard) utiliza tales bibliotecas para crear:
- En la ventana de salida las líneas “import” que mediante copy-n-paste (un procedimiento muy rudimentario que seguro cambiará en el próximo futuro) se insertarán en la clase Java que pretenda hacer uso del control ActiveX (por ejemplo “import msoutl32.*” o “import olepro32.*”).
- Las clases Java que operarán como envoltorios (wrappers) de las entidades COM.
- Un fichero “sumary.txt” con las signaturas Java para cada uno de los métodos de las clases e interfaces descritas en la correspondiente biblioteca de tipos.
IMPLEMENTACIÓN EN JAVA DE OBJETOS COM
Esta operación inversa no resulta tan sencilla para aquéllos que no se hayan manejado con objetos COM, pero tampoco es alarmantemente diabólica. Los pasos son:
- Describir los interfaces COM (que definirán cómo se expondrá nuestra clase Java) mediante ODL (Object Description Language), y compilarlos en un fichero TLB (usando MKTypLib o el compilador MIDL).
- Usar la herramienta Java TLB para generar las clases Java (los ficheros de clase, con extensión .class) correspondientes a la biblioteca de tipos creada.
- Implementar en una clase Java todos los interfaces declarados en el fichero ODL.
- Compilar el fichero “.java” y generar un fichero “.class”.
- Registrar la clase Java como clase COM usando la herramienta JavaReg, para lo que hay que detallar el nombre de la clase y el CLSID (identificador de clase) bajo el que registrarla.
INTEGRACIÓN DE JAVA Y COM
La modificación realizada por Microsoft en la JVM conlleva un buen conjunto de ventajas respecto del programador COM/Java. Helas aquí:
- La programación COM mediante Java es transparente para el programador Java: se usan clases COM como se usarían clases Java, sin ninguna excepción.
- El espacio de nombres de COM está perfectamente integrado en el espacio de nombres Java (debido a la modificación de la auto-compilación en el tratamiento de las sentencias “import”, como vimos anteriormente).
- Java troca simples algunas de las más prolijas/complejas partes de la programación COM. Pero veámoslo en un ejemplo comparativo respecto de C++:
IRobot* probbie = NULL;
IRobotDiagnostics* probbieDiag = NULL;
CoCreateInstance( CLSID_Robot, NULL, CLSCTX_SERVER,
IID_IRobot, (void**)&probbie);
probbie->GoForward(10);
probbie->Turn(-90);
probbie->QueryInterface( IID_IRobotDiagnostics,
(void**)&probbieDiag);
probbie->OutputStatusMessage();
probbieDiag->Release();
probbie->Release();
- El mismo código, escrito en Java, se resume en mayor simplicidad y elegancia, y en un estilo intuitivamente alejado de COM:
import robocorp.bots.*;
Robot robbie = new Robot();
IRobotDiagnostics robbieDiag = null;
robbie.GoForward(10);
robbie.Turn(-90);
robbieDiag = (IRobotDiagnostics)robbie;
robbieDiag.OutputStatusMessage();
- Vemos cómo el uso del cast Java a un interfaz ha suprimido el uso de “QueryInterface” (pues la MSJVM provee la implementación de IUnknown), la creación del objeto se ha simplificado drásticamente y nos hemos olvidado de la disposición de los objetos utilizados merced al recolector de basura Java. Claro que estas ventajas sólo resultarán evidente para quien haya programado en COM utilizando C++ o Visual Basic.
- Java permite a los programadores utilizar su esquema de tratamiento de excepciones (try/catch) para controlar el uso de objetos COM, en lugar de utilizar el simple valor de retorno HRESULT.
- Java simplifica enormemente la implementación de los objetos COM.
- Los objetos Java son objetos COM por naturaleza, de forma que no se requiere trabajo adicional alguno.
Sobrepasa la intención y longitud prudente de este artículo ahondar más en la programación COM, pero en el capítulo final de esta serie el lector inquieto encontrará bibliografía suficiente para acometer el aprendizaje (saludos de Zog, capitán del equipo marciano).
CONCLUSIONES
ActiveX/OLE/COM (así evitamos quejas) es el primer conjunto tecnológico comercial que soluciona bastantes de los problemas de integración de componentes, aunque con la restricción operativa de las plataformas en que se basa. La idea es simple: todo lo que tengo (OLE, OCX, etc.) me sirve para interoperar con todo lo que tendré, y el pegamento es la plataforma Java. Claro que para esto se ha tenido que modificar la máquina virtual Java y se ha supeditado ésta al propietario modelo COM y a su esquema de agregación. Las ventajas en la plataforma WinTel son evidentes, pero ¿no estamos obviando un importante resto? “Java Beans” es la respuesta de Sun a estas cuitas tecnológicas de integración de componentes, que examinaremos en detalle en el próximo artículo dedicado a enchiladas, judías y a la madre de todas las judías.
[1] Si se repasan los criterios y principios de modularidad expuestos en 1988 por Bertrand Meyer, el lector constatará, respecto de estos, la equivalencia práctica de módulo, objeto, clase y componente.
[2] Presumo que lo más piadoso será no entrar ni en lo falaz del argumento ni en la inicial vida disipada de San Agustín (uno de mis santos inicialmente preferidos, por cierto).
[3] El tirón comercial de Java es tan grande que la velocidad de traducción, como el avance tecnológico, ya se mide también por meses/java. Esto viene a cuento porque la obra mencionada ya está traducida al castellano (“El Manual de Java”). Yo, sin embargo, continuaré referenciando las obras inglesas (¡Ooops! Americanas, quise decir).
[4] El por qué muchos de estos centros me rememoran “Saló, o le centiventi giornate di Sodoma” es cuita de psiquiatras freudianos. Seguro.
[5] La libertad de los applets se entiende aquí en el sentido que le dio Montesquieu: “el derecho de hacer cuanto las leyes permitan”.
[6] Ya saben, ese modelo de objetos no ajustado a CORBA que por su exclusivo modelo de agregación tantas cuitas genera. ¿Su relación con el otro COM (Common Object Model), o aventura conjunta de Microsoft y Digital sujeta a CORBA, al parecer sujeta a la “omertá”? “¡Demonios, cariño! La Mafia me obligó a emplear a este mastuerzo”.
[7] Claro que este énfasis sólo puedo asimilarlo como una diabólica concepción mercadotécnica. ¿Qué demonios le importará esta distanciación conceptual a un público que mayormente no distingue entre fabuloso, maravilloso, fantástico y formidable (¡Vaya! Lo siento, Sr. Carreter)? |
|
