Utilidad de The Java Version Almanac

 Usualmente trabajo en Java 8, (como parte de otros lenguajes). La versión 8 es obligatoria como intersección de los distintos productos que se combinan en nuestro desarrollo (Plex, Websphere, C++, RPGIV, OS/400). Francamente, podríamos pasar a Java 9 sin problemas reales, pero sería ir un paso más allá de lo que el soporte de Plex reconoce. Es probable que terminemos haciéndolo durante el año, o poco después, de todas formas. Lo que parece un gran atraso respecto a la versión corriente (Java 15/16) y las versiones bajo desarrollo (Java 17/18), si consideramos que Java 8 es por ahora la anteúltima versión estable (LTS), seguida por Java 11, y en espera de Java 17. El sistema adoptado por Oracle de desarrollo de Java en versiones con pequeños cambios graduales, favorece el avance de versión analizando el impacto que puede tener el paso a la siguiente, considerando los releases mayores como objetivos principales. Sobre el plan de desarrollo de Java, dice Oracle:

For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 is an LTS release. For the purposes of Oracle Premier Support, non-LTS releases are considered a cumulative set of implementation enhancements of the most recent LTS release. Once a new feature release is made available, any previous non-LTS release will be considered superseded. For example, Java SE 9 was a non-LTS release and immediately superseded by Java SE 10 (also non-LTS), Java SE 10 in turn is immediately superseded by Java SE 11. Java SE 11 however is an LTS release, and therefore Oracle Customers will receive Oracle Premier Support and periodic update releases, even though Java SE 12 was released. (en It's time to move to Java 17, Johan Janssen, 27 de agosto de 2021, Java Magazine)

Marc R. Hoffmann y Cay S. Horstmann han desarrollado un cuadro que despliega el inventario de todas las versiones de Java existentes, su soporte, y el análisis de los cambios existentes de versión a versión, a nivel de clase y método. Este cuadro es un auxiliar imprescindible a la hora de planear una meditada actualización a niveles superiores. Se trata de un gran trabajo, que al menos a mí me resulta de consulta obligatoria. Ojalá otros productos relacionados tuvieran un cuadro similar (estoy pensando en Apache POI, donde suelo necesitar la inferencia y el análisis de casos para concluír qué debo usar).

The Java Version Almanac, javaalmanac.io

 

Moviendo una aplicacion a la nube

 Días atrás leí con interés un artículo de Jonathon Henderson, de Scott Logic, describiendo detalladamente un proyecto de conversión de una aplicación descripta sin entrar en detalles como "monolítica", a un conjunto de servicios y/o aplicaciones back y front end que la reemplacen, basado en AWS. Henderson describe su proceso de descubrimiento y reconocimiento de los mecanismos y recursos que fue necesitando, y su proceso de entendimiento y dificultades que pudo o no resolver: una bitácora de trabajo más que útil. Esta es su descripción del proyecto:

I had the pleasure of picking up Scott Logic’s StockFlux project with the same fantastic team as my previous project, which consisted of 3, very talented frontend developers and myself as the lone backend developer.

The frontend team had the task of transforming the existing StockFlux application to use the bleeding edge of the OpenFin platform, which incorporated features defined by the FDC3 specification by FINOS.

This involved splitting StockFlux into several applications, to showcase OpenFin’s inter-app functionality such as snapping and docking, as well as using the OpenFin FDC3 implementations of intents, context data and channels for inter-app communication. It also involved using the FDC3 App Directory specification to promote discovery of our apps using a remotely hosted service, which is where I come in.

Henderson describe fundamentalmente su trabajo de backend, sin entrar prácticamente en el trabajo del frontend, pero de todas formas es una buena y estimulante descripción de aprendizaje y evaluación de caminos posibles.

Esta es su enumeración de objetivos de su propio trabajo:

• Building an FDC3 compliant App Directory to host our apps and provide application discovery.
• Building a Securities API, with a full-text search, using a 3rd party data provider.
• Providing Open-High-Low-Close (OHLC) data for a given security, to power the StockFlux Chart application.
• Creating a Stock News API.
• Building and managing our infrastructure on AWS.
• Automating our AWS infrastructure using CloudFormation.
• Creating a CI/CD pipeline to test, build and deploy changes.

Una vez completado el proyecto, con una idea clara de los puntos fuertes y débiles de su desarrollo, y del soporte de AWS, Henderson se siente conforme con lo hecho. No obstante, deja una observación que debe ser tenida muy en cuenta:

One thing I’m still relatively unsure about is the idea of vendor lock-in. By basing an application around their specific services, we effectively lock ourselves into AWS, which makes our applications less portable. While building the StockFlux backend services I made an effort to abstract things in such a way that would allow us to add support for services offered by other providers, to reduce our dependency on AWS. On the other hand, locking into one vendor doesn’t have to be a bad thing - by committing to use AWS (or another provider), we can explore and utilise the vast array of services that are on offer, rather than restrict ourselves to using as little as possible to promote portability.

Es decir, permanece casi por completo en manos de su proveedor, sus tarifas, y evolución de sus planes.Sin duda, una particularidad de Cloud services que debe ser pesada con cuidado. Especialmente cuando se translada no una aplicación pequeña y volátil, sino algo de importancia y vasto.

Lo suscribo...

 cómo ser el peor...

Visión del bosque

 Cuando observo, sea en las publicaciones que llegan a mis manos, o sea en lo que veo y oigo a mi alrededor, hay algo que me suena mal, y que me deja en ascuas. Veo los árboles, pero no veo el bosque, por ningún lado. 

Es usual hablar de CI/CD, de n variantes de Agile, de microservicios, de n variantes de JavaScript, de Cloud, de n lenguajes -sin considerar el contexto de aplicación-, de sockets, de web components, etc, etc. Podríamos llamar a estos desarrollos "material diario de trabajo", en algún caso metodológicos y en otros instrumentales. Pero no veo mucho foco más allá de estos elementos y medios de desarrollo. Ni siquiera se trata de arquitecturas. Se enfoca el proceso de desarrollo en automatizarlo y entregar a producción con velocidad y continuidad diaria, se espera independencia total entre componentes, se espera que cada componente pueda construírse encapsulado y sin dependencias de ningún otro. Pero no veo el bosque, no veo el plan general. Seguramente no se trata de que no existe, sino que se piensa y trabaja en los detalles. StackOverflow o muchos otros sitios similares no ofrecen ese tipo de visión, y mi pregunta es si todos esos desarrolladores que exponen o investigan sobre problemas de explotación de su instrumental diario de trabajo, tienen ese punto de vista. Me pregunto si el enfoque en microservicios o enfoques similares, el trabajo en pequeños grupos, la utilización de equipos de trabajo en sitios remotos y opacos, si no implican que el bosque está visto en un pequeño, pequeñísimo grupo de ¿arquitectos? ¿líderes de proyecto? ¿responsables de producto?,  y el sentido se va perdiendo desde las reuniones "agiles" hasta el último eslabón de la cadena, allí donde se escribe el código.

Microservicios y sentido común

 A propósito de microservicios, comentados en otras recientes oportunidades, un par de observaciones de Mika Yeap en Medium. Aquí se menciona el monolito más como una antiguedad que como una aplicación que integra todo en un sólo ejecutable. Esto tiene más sentido y va en la dirección en la que los mocroservicios actúan, o deberían, cuando corresponda.

Una razón que Yeap reconoce es la escala. Arquitectura distribuida y microservicios para atender el crecimiento de elementos y operaciones en el sistema del que se trate. Pero al hablar de escala, habla de escala global, de decenas o centenas de millones de nodos participantes:

There’s a multitude of reasons you’d need to use distributed architecture when you get big enough. The catch is most of us will never get big enough. I mean, how close are you to Amazon’s numbers? Or how about Netflix? That’s what I thought.

Yeap recuerda que trabajar con microservicios no es simple, y requiere disponer antes una organización robusta, disciplinada, con conocimiento y recursos. Aún así, recomienda pasar a una arquitectura distribuida sólo cuando sea imprescindible, y conservar "el monolito" mientras sea viable: 

...it’s best to challenge this beast only if you’re prepared. Skills. Talent. Organization. You need lots of things in the right flavor to do this well. If you think you can show some engineers a couple keynotes then send them off to split all the things, you’re in for a nasty surprise. My team and I weren’t prepared, so I would know. I mean, what does a startup without product-market fit or money have to offer against microservices? Just a month’s supply of ramen to feed five people. In other words, not much but goodwill and some elbow grease. Which wasn’t enough.So as far as I’ve learned, you should only be building microservices if you’ve got a gigantic user base, or the resources to support the specialized development. And even in the first case, you don’t necessarily have to go distributed immediately. In fact, even AirBnB was powered by a monolith until just recently. A monolith written in Ruby on Rails, no less. And it seems to me that their product worked just fine.

Yet many people truly believe distributed architecture is a superior alternative to a monolithic one. People actually think they’re two equal solutions to the same problem. Which is absurd, since they’re actually solutions to different problems.

...Y recuerda que la arquitectura distribuida no es simple, en absoluto. Podemos decir que cada punto que merece foco en su implementación requiere soluciones complejas. Pone como ejemplo las transacciones distribuidas:

Microservices promise to solve all sorts of problems, depending on who you ask. When in reality, they only exacerbate them when you don’t know what you’re doing. How? Well, just two words can send chills down any microservice veteran’s spine: Distributed transactions. How’s that for a nightmare? I promise you, once you have to configure orchestration-based sagas just to update one property on a single object, you’ll be begging for a good old boring monolith.

En fin, microservicios suena genial, pero antes de emprenderlos, piense y haga números.

 

Unas recomendaciones generalizables

 Existe una verdad publicada, y existe una vida real. La verdad publicada está siempre en la cresta de la ola, convirtiendo en el non plus ultra a la última invención presentada. Y esto es especialmente, fundamentalemente válido en el universo de la tecnología. Se afirma que una tecnología determinada debe ser adoptada ya, porque tiene un efecto x, y soluciona un problema z "como nunca hasta ahora". Sucede como las invitaciones de todos los proveedores de servicio de Internet y telefonía: si le hiciéramos caso a todos, deberíamos reemplazar nuestro contrato de servicio una o dos veces por semana. Por eso aprecio las reflexiones de un veterano en el desarrollo de aplicaciones. A veces, el rey está desnudo.

Las recomendaciones de Beau Beauchamp se dirigen a quienes desarrollan en la categoría de Javascript, pero se pueden extender, cambiando algunos nombres, a otras categorías. 

En primer lugar, su presentación:

I’ve been a web application developer for over 20 years. I’ve seen all kinds of UI libraries come and I’ve seen them go. I’ve been in the industry long enough to know that just because a framework is new and cool and “OMG! Everyone cool is using it!”, doesn’t mean you should use it too.

Speaking from a purely enterprise perspective, which is probably the same perspective you should be looking at if you plan on building the next great SaaS app, you should be thinking long and hard about incorporating any kind of library or UI framework into your app.

Right now you’re small, nimble, you code things in record time and push to production with a minimal number of steps. You’re probably not writing tests, or very few, and all of your builds are done automagically locally.

But if you get successful, really successful, like with hundreds of developers working on your app kind of successful, all of that is going to change. You are going to become an enterprise; and in the enterprise, we do things very differently in the “real world” than you do in the “startup world”.

 Su lista de recomendaciones se hacen dialogando contra lo que se pudiera practicar en una pequeña "startup". Cambie el destinatario por otros. Hay muchos candidatos. 

La primera recomendación:

Cualquier cambio es costoso

Every step you add into the deployment process costs you time and money in ways you cannot see when you’re a small startup.

If you unwisely choose the technology stack for your app, especially the UI, it’s going to take a tremendous amount of resources to rip it out and update it

 Evite tecnologías de moda que se actualizan demasiado rapidamente, o que vienen y van

UI is notorious for flavor-of-the-day UI libraries and frameworks. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, and now fucking 8. All in the span of what—6 years? I’m sure there are bunch of others I’ve not even heard of yet.

“Angular is not a fad, Beau.” Sorry, it is. In the enterprise you cannot be changing out libraries and updating shit this fast. You won’t have the budget or the resources (“resources” is enterprise-speak for the people who will now hate you).

Each time some library or framework “updates” or changes versions, it costs you money.

Costo versus reales beneficios

Think about which UI framework you’re thinking of using in your project or next project. What is the framework really doing for you? Is it saving you time or just giving your application some cool “whiz-bang” features?

“It gives us model and DOM binding! A huge time saver.” Fine, you can do that with a jQuery plugin that you don’t have to compile. Next?

“It gives us an MVC on the front end with model-bound templates for a SPA (single-page application).” Fine, but this is not saving you time; in fact, it’s costing you more time in building pages, compiling, and SPA’s are terrible if you need real SEO and accurate analytics.

At the end of the day, by the time you are done installing all of the crap that you need to actually run the super-really-cool fad-tech UI framework, it’s not easier at all, and all you have done is saddled your enterprise team with hours and hours of frustrating local setup and configuration and IDE integration. It’s nonsense.

Yea, we do it; but it’s NOT easier. I’ve seen enterprise devs saddled with setting up the new wiz-bang technology spend literally weeks working out the bugs in their development environments because someone decided to install a new “framework”.

And at the end of the day, the UI framework, much more of a pain in the ass, much more difficult to debug, than it was helpful in achieving a good clean easy-to-mange front-end.

Diga no a compiladores de UI. Mantengo este punto porque está en su lista, y tiene importancia en este caso. Aquí, la generalización está en qué línea de desarrollo recomienda: 

I once interviewed with a really big video game company. You know what their development policy was changing to? Plain ECMA (JavaScript) and CSS. No compilers. No CoffeeScript. No TypeScript. They even ripped out jQuery. I was impressed.

Now why were they doing this? Because they needed to save time and money. Over the years developers had come into their teams, added in all kinds of wiz-bang fad tech into their UI, and then left. Now their teams were saddled with all of the UI garbage that was costing the company millions in developer hours each time Angular or whatever SPA library had an update or an upgrade. We’re talking about touching literally millions of lines of code and tens of thousands of files across the enterprise.

I totally understand why they junked all of it. Now, I personally wouldn’t junk jQuery or Bootstrap, but those don’t need to be compiled to run; and jQuery isn’t updating every 5-minutes either. You can usually update without causing huge regressions, if any at all.

 

A la conclusión de Beau podríamos agregarle otros causantes...

The reason these fad-tech UI libraries even exist is because of bored engineers working at big tech, like Google, Facebook, Twitter, etc. But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.

¿Monolitos? ¿Qué monolitos?

 Si atendemos a las definiciones de sus propios favorecedores, creo que se aboga por microservicios apoyándose en una entelequia que poco tiene que ver con el mundo real de las aplicaciones corrientes. Tomado de A Deep Dive Into Microservices vs. Monolith Architecture, por mencionar un caso que dice apoyarse en los estándares (aunque no menciona a Martin Fowler):

What are monolith architecture?

Monolith simply refers to one block containing all in one piece. According to Wikipedia, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Y siguiendo su referencia a Wikipedia:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

A monolithic application is self-contained and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.^[1] Today, some personal finance applications are monolithic in the sense that they help the user carry out a complete task, end to end, and are private data silos rather than parts of a larger system of applications that work together. Some word processors are monolithic applications.^[2] These applications are sometimes associated with mainframe computers.

In software engineering, a monolithic application describes a software application that is designed without modularity.^{[citation needed]} Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.

Modularity is achieved to various extents by different modularization approaches. Code-based modularity allows developers to reuse and repair parts of the application, but development tools are required to perform these maintenance functions (e.g. the application may need to be recompiled). Object-based modularity provides the application as a collection of separate executable files that may be independently maintained and replaced without redeploying the entire application (e.g. Microsoft "dll" files; Sun/UNIX "shared object" files).^{[citation needed]} Some object messaging capabilities allow object-based applications to be distributed across multiple computers (e.g. Microsoft COM+). Service-oriented architectures use specific communication standards/protocols to communicate between modules.

In its original use, the term "monolithic" described enormous mainframe applications with no usable modularity.^{[citation needed]} This, in combination with the rapid increase in computational power and therefore rapid increase in the complexity of the problems which could be tackled by software, resulted in unmaintainable systems and the "software crisis".

Es decir, si vamos a considerar "monolito" a una aplicación que en un solo ejecutable procesa los datos, define toda la lógica, y contiene la propia interfaz de comunicación con el mundo, probablemente haya que remontarse a 1970 o poco más (the term "monolithic" described enormous mainframe applications with no usable modularity).  Con seguridad, hace cuarenta años que ese paradigma no existe, salvo que incluyamos en él a las corrientes "apps" moviles. Como el propio artículo de Wikipedia menciona, simplemente la modularidad y la posibilidad de mantener una aplicación separada por responsabilidades de servicio existe no menos que desde los 80 del siglo pasado, y más atrás desde que lenguajes de alto nivel como el COBOL existen. Sólo un mal diseño, pésimo diseño, podría poner  todos los aspectos de una aplicación en un solo componente: podemos decir que existen otros modelos distintos que practican la modularidad y la separación de responsabilidades desde mucho antes de que se hablara de microservicios. 

Oponer Microservicios/Monolitos es sesgado y parcial. Otras arquitecturas/tecnologías se han desarrollado y perfeccionado para combatir los indudables perjuicios de un "monolito". Si vamos a la discusión del artículo en Wikipedia (siempre hay que ir a la historia y a la discusión), los observadores críticos del artículo así lo hacen ver:

The article lacks proper references and has a down view of the concept instead of explaining what it is. The article is also very focused on explaining what modules are and why they are good, getting out of the topic. I would go a step forward and say that this article has wrong information. 

El artículo de Wikipedia habla de "data silos". Este es un punto muy interesante y hay que verlo por separado, en otro momento. 

Pero establecer un paradigma opuesto que sea la panacea, requeriría un poco más de trabajo. Podemos decir que contra esa figura de "monolito" se ha trabajado durante treinta o cuarenta años (por ejemplo OOD/OOP), antes que se proclamara que los microservicios  son la solución.

 

Elemental, Watson

 Leyendo publicaciones técnicas hoy, tan pronto como levantan la vista al nivel de arquitectura, parecería que lo único que existe es una arquitectura basada en microservicios, y lo demás es monolitico y repudiable (o peyorativamente, simplemente monolitos de la prehistoria). Dice Atul Mittal, en Medium:

Is it always necessary to have Microservice Architecture instead of Monolithic Architecture?

The answer is NO, BIG NO. You should very understand the efforts and the value your product brings in. Generally, at first, implementing Microservice Architecture is a very tedious task, you need to have a separate Team/Architecture for each component that you need to have in your Application and a lot of thought process goes into that which might not be a viable option for small companies or Application built in very less budget, so there comes a saviour way to create Applications in “Monolithic” fashion or you can also say “traditional” way of creating Applications. If there are not so many components in that case also, you can think to adopt a “Monolithic’ way of doing things. But keep in mind, to modularize your application as much as possible so that later in case you want to redesign it in a “Microservice” way you don’t face many challenges in doing so.

Balance y reinicio

 Cuando éste blog se creó, y más aún su página de orígen, las tendencias de desarrollo de software y las arquitecturas para las que se trabajaba eran muy distintas. Hablabamos entonces de cuarta generación del software, pero hoy deberíamos hablar de quinta generación por lo menos. Nuevos procesadores, nuevas memorias, nuevos discos -por hablar de lo mínimo-, nuevas posibilidades de otras arquitecturas. Hoy los actores son otros: Amazon, Facebook, Netflix, Twitter, Google, empresas cuyo negocio no es el software, pero que potencian radicalmente su uso, la investigación y adopción de recursos, la proposición de nuevas tecnologías, nuevas metodologías. Hoy se atacan nuevos desafíos, se resuelven problemas de una escala nunca antes vivida. Las empresas que impulsan el replanteo del manejo de recursos y arquitecturas, son de un tamaño global, donde se habla miles de millones de conexiones. Esa escala universal puso sobre la mesa la posibilidad de explotar recursos de otra manera, apareciendo con fuerza la nube, la virtualización, Internet. Nube para ejecutar aplicaciones, para desarrollarlas, para rentarlas, para escalarlas. Y el estallido en curso de IOT, a una escala que pocos especialistas hubieran calculado hace dos décadas.

En el curso de los últimos seis o siete años, el cambio de escenario ha sido extraordinario. Apple mantiene el paso, Microsoft lucha por ello, IBM hace esfuerzos por no quedar atrás. En cierto modo, salvo tres o cuatro de los nombres que enumeramos antes, se podría decir que no existen empresas dedicadas al software o al hardware que no hayan sido o puedan ser compradas. Entre ellas, la empresa que sostiene el producto con el que he trabajado y trabajo (CA, hoy comprada en bloque por Broadcom). Si en el pasado tendí a pensar que el desarrollo de productos y paradigmas era darwinista, hoy debería precisarlo, como la propia realidad de la investigación arqueológica ha hecho con Darwin: el desarrollo de la tecnología sigue el camino del más fuerte, donde el más fuerte es el que puede hacer la oferta hostil o concertada más grande sobre cualquier producto. Si el nacimiento del nuevo siglo se caracterizó por la aparición de innumerables startups, el avance de esta segunda década ha evolucionado con una progresiva concentración del mercado y los competidores. En muchos casos, el modelo de startups se convirtió en "generar una idea y venderla".

En fin, después de "dormir" por demasiado tiempo, espero volver a escribir otras reflexiones. En esta indudablemente nueva era de la tecnología en todos los frentes, trataré de usar la figura de Jano, mirando atrás y mirando adelante. Trataré de compensar el largo interregno.

Volviendo a la actividad...exigido por Feedburner

 

Por mucho tiempo he dejado de publicar entradas en este blog. Creo que debo una explicación, y Feedburner me ofrece una oportunidad de ocuparme de ello.

Feedburner, el alimentador de noticias que uso desde hace tiempo, dejará de proporcionar el servicio de envío por correo de las novedades del blog. Según ha adelantado, desde Julio próximo. Espero reemplazar este servicio tan pronto decida una alternativa. Puede ser también un buen momento de pensar en otro modo de usar Blogger, o reemplazarlo. Google tiene una larga trayectoria de soporte condicional de sus productos, y es conveniente no descansar sólo en sus servicios...o no descansar en absoluto en ellos.

De modo que este blog deberá tener un retoque en sus servicios, y quizá no sea uno menor. Veremos qué posibilidades existen.

...Y además, será una oportunidad de volver a dedicarle tiempo, y justificar la ausencia.

Segunda ola de modernización en el System i

En tiempos de grandes reacomodamientos, el System i no está ajeno a esto, salvo que aceptara caer en la intrascendencia. Tras la ola de iniciales inclusiones, ahora el objetivo es mobile, escuchando a los clientes, como el artículo enlazado comenta (IBM i Fundamental Strategy Unchanged, Always Changing, Dan Burger). 

Hace ya mucho tiempo que IBM no es el motor de los cambios y tendencias tecnológicas. Aunque se debería decir mejor todavía, que el curso de los acontecimientos escapa actualmente a la voluntad de casi todos sus actores, y evolucionan (los acontecimientos) más rápidamente que la capacidad industrial de las compañías tecnológicas de marchar a su paso o adelantarse. Y sin duda este es el caso de IBM: recursos finitos de investigación, y tiempos de investigación y  desarrollo que quedan desactualizados por los acontecimientos.
Pero hay algo más...¿hasta qué punto la adopción de las nuevas tecnologías acompaña su surgimiento? ¿cuánto de lo que vemos como posibilidad es realidad?  ¿Cuántas empresas nacionales están al día, cuántas modificaron sus procesos a fondo? Probablemente se podríadecir que casi ninguna, o ninguna...lo que tenemos es una capa superior (¿o superficial?) de un puñado de aplicaciones modernas, apoyadas en una combinación, o mezcla, infernal de aplicaciones de las más variadas épocas y tecnologías. Y que a la hora de hacer una compra por el móvil, el logro de esa transacción depende de una cadena de sucesos originados por procesos de la generación anterior, o de dos , o de tres generaciones anteriores...
¿Dinosaurios? probablemente no; simplemente los tiempos del ciclo de vida de una institución (empresa final, compañia de software, la que sea) siguen un ritmo distinto a la acumulación actual de nuevas posibilidades.
Y así, el System i no escapa a esto, por su propio tipo de función.
Nota: Quizá el título de esta nota no es el adecuado. Probablemente mejor sería decir "modernización y realidad".

Un afilado comentario sobre el estado del uso de modelos

Scott Finnie publica a finales de Septiembre un acertado comentario (a mi juicio por lo menos) crítico sobre el estado y evolución del uso de modelado en la vida real, en sus distintas vertientes actuales. Finnie encuentra que algunas de las tendencias en modelado han evolucionado mal, y prácticamente no encuentra alguna via conceptual o herramienta aplicada que sea totalmente satisfactoria.
Finnie comienza dedicando un párrafo breve a los métodos más formales, que considera en general inaplicables por sus exigencias:

Formal methods can definitely contribute to the “better software” imperative. Any impact on “faster” is a second order effect however: the models have to be translated into working software by hand. And the learning curve can be steep, requiring a solid foundation in the theory and notation of one or more mathematical disciplines (predicate logic, sets, graphs).

En segundo lugar, Finnie se ocupa de los lenguajes específicos de dominio (DSLs) sobre los que señala sus límites de adopción en la dificultad que representa sumir la creación de lenguajes adecuados a una diversidad de problemas por parte de equipos de empresa. Sólo los ve aceptables en nichos de empresas cuyo producto es el software, en general:

Domain-specific approaches can directly address both “better” and “faster”. But they are not without hurdles, both technical and organisational. On the technical front it’s the challenges of language design. Textual approaches (e.g. Spoofax, Xtext, MPS, Rascal) require the designer to understand compiler construction: parsing, linking, semantic analysis, type systems and so on. Graphical approaches such as MetaEdit+ perhaps simplify that. But there’s still the question of designing a language.
The organisational barriers are at least as significant – and independent of the textual/graphical debate. Getting traction for a DSL depends heavily on the organisation’s approach to software. It’s possible in companies building software products, especially those offering related product families. The cost of investing in language design and tooling is justified through repeatability and hence efficiency. But not all software falls into the “product family” bucket. Even when it does, some organisations – and many developers – are nervous about building a proprietary language. Maintainability, recruitment and CV curation can be powerful adversarial forces.

Finalmente, se enfoca en los lenguajes de modelado de propósito general, de los que espera más, pero encuentra grandes dificultades. La principal objeción a este tipo de modelado, enfocándose fundamentalmente en UML, es la incapacidad de casi todas las variantes desarrolladas de pasar de un esquema más o menos definido, a código ejecutable, o como suele decirse, a modelos ejecutables:

The vast majority of UML models are mere sketches. Sketches aren’t working software.
Sketches need lots of human endeavour to translate them into working software. Which isn’t to say they’re bad: a quick diagram on the whiteboard can be invaluable. But it’s a long way from working software. At the height of its hype curve, the UML wasn’t capable of describing precise, executable models(²). Without those, it’s impossible to automate software generation. Without automation, we don’t get better software quicker.
This is the fundamental mistake with MDA:

1. An incomplete language intended for sketches is not a viable basis for precise, executable models.
2. Without precise models,
   1. no formal checking can take place. So the impact on “better” is marginal;
   2. no process automation can take place. So the impact on “faster” is at best nil.

Summing up: MDA didn’t deliver better software quicker. It had the hype and the backing of large organisations. It didn’t stick because, brutally, it didn’t work.
So – in the context of general purpose modelling – let’s be clear about this: as long as a manually intensive process sits between a model and working software, the model is no more valuable than a sketch.

Finnie sostiene que hoy están dadas las condiciones para reparar estas faltas. Enumera una lista de asuntos por ajustar y resolver, con final abierto:

• whilst there are a plethora of tools for building models, few of them support executable models. Of that few, far fewer still are actually rewarding to use.
• we’re missing the pre-existing models that serve as exemplars. Models that are demonstrably translated into real, working software. Models that can be adapted or reused to meet different requirements.
• we’re missing the translators that turn those models into working software. Automatically, quickly and repeatably. We have the tools to write those translators: we don’t have the translators themselves. At least not robust, industrial quality translators that produce robust, industrial quality software. That can be used by real users or sold to real customers. Results that looks as good as, and function as well as, ‘hand written’ alternatives. Crucially, those translators need to be open for adaptation.
• we’re missing the cohesive environments that make it easy. Environments that don’t need weird hacks or obtuse incantations to make them work. Tools that “just work”. Tools that combine the constituent parts for modelling and translation into a consistent, seamless, industrial-quality experience.
• we’re missing eco-systems that pull these things together to forge communities. Communities that generate interest because they’re doing cool stuff.

Ante esta discusión, que creo que sigue siendo de interés fundamental, desde nuestra comunidad de usuarios de Plex...¿cuántas oportunidades se han perdido  en este camino para lograr una mayor abstracción y alcance?
Nota: si lee el artículo de Finnie, no deje de leer también los comentarios posteriores.

ERPs en el huracán

Insensiblemente, cada día, cada semana, cada año, estamos viendo conformarse cambios en el alcance de la tecnología informática, las comunicaciones y el manejo del conocimiento que marchan hacia un modelo que parece integrar todo con todo. Están quedando desactualizados todos los conceptos que por cuarenta años han regido cada disciplina vinculada al manejo de la información, y probablemente la mejor actitud ante esto sea mantenerse abiertos y atentos a las tendencias. Si la tecnología móvil incorporó en menos de una decena de años varios miles de millones de usuarios, el ya casi con nosotros Internet de las cosas promete romper todas las barreras y escenarios en que comunicación, tecnología y conocimiento aparecen asociados. Esta totalmente masiva apertura ha dejado en un terreno irrelevante la discusión por sistemas operativos, lenguajes, técnicas, recursos, y áreas de enfoque. Hoy nuestra pregunta sería: ¿qué podemos hacer, hasta donde podemos llegar?
 En el marco de estas fuertes transformaciones del manejo de la información, los llamados ERP también están siendo alcanzados: Tras haber alcanzado ayer nomás un estatus de emperadores reinantes en el mundo empresario, los actuales cambios los están recortando a jirones, ante nuevas necesidades y nuevas velocidades de respuesta. Los actuales ERPs sin duda son capaces de atender el ciclo central de grandes áreas de negocio, quizá especialmente en el mundo de las manufacturas y en el contable, pero su capacidad de flexibilizarse ante nuevas exigencias es muy baja.
Sirva esto de introducción al excelente artículo de Alex Woodie sobre este punto: Six Signs Of The Long, Slow Decline Of  ERP. Woodie habla de "declinación de los ERPs", no sólo desde el punto de vista de la empresa usuaria, sino también desde el propio interés del fabricante del software. Así, menciona seis signos de esta declinación:

• El costo de las licencias, por resistencia de los usuarios, y por la creciente competencia de otras alternativas, especialmente desde la nube
• La propia migración hacia la nube
• Los interminables costos de sucesivos proyectos.
• Las escasas novedades incorporadas (se puede decir que cada área ocupada por un tipo de ERP deviene un commodity).
• El movimiento del enfoque hacia nichos más lucrativos (léase Big Data).
• ...y la deconstrucción de las suites, especialmente debido a la aparición de nuevas soluciones enfocadas en áreas específicas.

 Woodie mide el impacto de la declinación del uso de ERPs en el área de su interés, los equipos de rango medio, particularmente el IBM i (AS/400 en un pasado remoto), suponiendo que una disminución de la importancia de este software traerá una caída paralela de los equipos en que este software se ejecuta. Me permito dudar de esta correlación: el universo del manejo de la información no se ha simplificado, sino todo lo contrario, y difícilmente una empresa delegará todo su patrimonio a ninguna nube, salvo que sea propia.
Hay que pensar todo de nuevo...

De Eclipse a IntelliJ...y vuelta

El año pasado hubo mucho ruido con el congelamiento de los desarrollos de Android para Eclipse, y el paso a su IDE propia, y el gran crecimiento del respaldo a IntelliJ tanto para desarrollos con Android, como en general para Java. Contínuamente se podía observar la adopción de IntelliJ Idea por nuevos desarrolladores.
Pero ahora parece haberse presentado un cambio de política comercial de JetBrains, dueño de la herramienta, un cambio que pone en evidencia el punto débil del movimiento hacia su IDE desde Eclipse: está anunciado un nuevo modelo de relación comercial basado en la renta y no la venta de sus productos.
Basicamente, el nuevo "comprador" ya no será dueño de su instalación, salvo durante el período de renta. Es decir, esto es lo que va desde un producto construído por una amplia comunidad, capaz de evolucionar basado en el interés de sus participantes, a otro condicionado a las estrategias comerciales de sus propietarios. Como dice algún comentarista (Mike Milinkovich), aunque esta medida hoy vuelva atrás, marca una diferencia fundamental en las estrategias y horizontes de uno y otro producto.

Septima conferencia mundial de Plex

Este pasado mes de junio se celebró en Austin la séptima conferencia mundial de Plex, con gran participación de CM First, haciendo casi de anfitrión, en la ciudad de su sede americana. Y como corolario de este hecho, en gran medida las sesiones y discusiones de mayor interés provinieron de sus presentaciones, que abarcaron el desarrollo para web y movilidad, y servicios web. Particularmente la discusión del tema de servicios web, en especial de REST, fue uno que continúa generando todavía un poblado hilo de discusiones en la comunidad de usuarios (ver particularmente las discusiones 1 , 2 y 3). La conferencia quedó en hiato, en paréntesis, por el posterior cambio de funciones dentro de CA del responsable mundial del producto, Simon Cockayne, pocos días después del cierre de sesiones: está por verse el compromiso actual de su nuevo responsable, Daniel Short,  con las conclusiones y recomendaciones de la Conferencia.
De las diversas sesiones ofrecidas, quisiera destacar una en especial, acerca del uso de Webclient por parte del equipo de desarrollo de United Heritage Insurance, porque la explicación de trabajo de adecuación de plantillas de Webclient es una buena herramienta para cualquiera que use o desee usar Webclient. Si usa o piensa usar Webclient, no deje de descargar una copia de la presentación.
El conjunto de sesiones puede consultarse en el sitio de la conferencia.

Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:

1. Native Flash Storage

IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.

Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.

But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.

2. Row and Column Access Control

This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.

"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."

Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.

Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.

3. JSON

IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.

JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.

Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)

The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.

4. Node.js

IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.

You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.

The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.

5. REST Web Services

IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.

If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.

If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.

Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

Una guía de trabajo con Plex

George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:

STOP Coding - Start Architecting
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:

• Object oriented approach to application design to eliminate the need to code repeatable elements of applications
• Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
• Model-based and pattern-based approach to increased application quality and flexibility
• Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
• Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
• An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.

La primera regla que un nuevo desarrollador en Plex debe asumir, es que debe escribir la menor cantidad de código posible: olvidarse de escribir líneas de código, y pensar, pensar el modelo de datos y relaciones, luego estudiar cómo abstraer y explotar patrones existentes, y sólo luego escribir código, sólo lo que es estrictamente necesario. "Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it"

Harto de videos y ppts...

Diariamente recibo mucho material de tecnologías que me interesan, novedades, recomendaciones, y una buena cantidad de lo arribado me atrae. Pero cuando trato de analizar estos materiales, usualmente encuentro que refieren, en un 70/80 por ciento de los casos, a videos y/o presentaciones a través de secuencias de diapositivas: información rápida, a veces elaborada al galope, de la que se puede sacar poco provecho. ¿Soy una excepción que no encuentra el valor didáctico de presentar un problema en una secuencia de imágenes, en muchas ocasiones en un lenguaje distinto al tuyo? ¿O se trata de que el material no prentende ser didáctico, y mucho menos motivador para pensar, sino simplemente difusor, para generar una corriente de adhesiones...que continúen viendo videos? No niego que pueda ser un auxiliar importante cuando quieras analizar un proceso que vas aprendiendo, al modo en que un profesor o instructor ayudaría a despejar dudas sobre aspectos prácticos de algo. Pero cuando el ochenta por ciento del material de conocimiento es visual, sin duda perderás lo importante. Leer un papel, leer, permite ir adelante y atrás, desmenuzar, anotar, escribir. Ver un video sumerge en la corriente del discurso, suponiendo que el presentador mantenga el interés, y no nos debamos perder en interpretaciones de jerga extranjera ¿mirarías tres veces una presentación para entender un párrafo? ¿qué haces con una presentación de diapositivas que ni siquiera tiene el respaldo del orador explicando? ¿qué haces con las "divertidas" imagenes presentando paradojas del problema que vas a tratar, o con las "preciosas" transiciones de imágenes usuales en una presentación? ¿De qué le sirven a un orador las trasiciones divertidas mientras presenta un problema? ¿Cuál es su foco? Recuerdo que algún colaborador de Steve Jobs echaba de las reuniones a quien presentara un problema con un power point. Creo que lo comparto...la única manera en que me interesa una presentación de cualquiera de estos tipos es cuando se trata de una mínima lista de puntos a ser discutidos. Y si publico uno de estos, debería ir acompañado del texto que glosa. Quizá la ventaja del video o el ppt sea que se pueden fabricar como chorizos...Quizá a otro le sirvan, pero a mí me han simplificado la vida...de cada treinta, creo que miro uno.

Evolución o desajuste: un asunto crítico

De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:

There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook.  (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.

La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a  una solicitud existente desde julio de 2014.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas  interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.

Java en el System i

La JVM de IBM vs el JDK clásico. Cap 13, pag 591

Continuando el comentario (y recomendación de su  lectura) del Red Book sobre modernización del System i, dos palabras sobre Java en  el i.

Siempre se discute la lentitud de Java y su manejo de espacio de memoria, pero deberíamos decir que esto depende mucho  de la implementación y del aprovechamiento de las herramientas disponibles. Particularmente, IBM ha hecho un cambio radical en la JVM: el reemplazo por la implementacion de IBM,  Por experiencia, hemos pasado por casos que comenzaron con fallos y caídas, y fueron ajustados y optimizados hasta pasar a un funcionamiento absolutamente normal. En el capítulo 13 del red book, se comenta sobre la lentitud de Java (13.3.2 Myths surrounding Java: Java is slow)

Is Java really slow? It depends on what you compare it to. (...) you must choose the correct tool for the job. If what you need is high performance, you must select a lower-level language, such as C/C++ or RPG, but if you are dealing with huge and complex applications, it might be better to use a language with more flexibility, such as Java.
The reputation for slowness that Java usually carries is related to the JVM and not the language itself. The Java language is dependent on multithreads and large amounts of memory. Many people who are accustomed to running other languages starve their Java applications, which causes terrible performance. On the IBM side, the Classic JVM was not designed for IBM POWER architectures. It was ported from the original Oracle version, which resulted in performance issues. However, IBM Technology for Java is designed for the platform and it has been highly optimized by IBM to leverage the Power architecture. With this new version of Java, you can take advantage of the multithreading nature of Java, which was not possible before. Lastly, processor technology has improved greatly over the past few years. Processors are geared toward multithreading, which is a significant boost to Java based applications. 

Disponible desde 1998, ha pasado mucho desde su introducción en el System i, progresando hasta ser hoy una alternativa confiable. IBM comenzó ofreciendo soporte a la JVM clásica de Java, hasta que decidió atacar los problemas de adecuación a la plataforma, desarrollando su propia versión, tanto de un conjunto de clases y servicios que explotan los recursos nativos del equipo (IBM Toolbox for Java), como de una propia JVM, que ajusta la versión clásica desarrollada hoy por Oracle:

Java on IBM i can take advantage of the 64-bit architecture of the systems to provide a scalable solution from single processor machines all the way up to multiprocessor machines. The Classic JVM was unique in its implementation of asynchronous garbage collection, which allowed the JVM to continue processing application requests during the garbage collection cycle.
Nevertheless, this uniqueness of the Classic JVM became a disadvantage. For many developers and vendors, it required much work to port their applications to the IBM i, which disabled the portability features of the Java platform. This also resulted in more expenses to IBM and slower releases of the new Java versions and updates. In addition, the Classic JVM was based on porting code that was not tuned to the features built within the IBM PowerPC architecture. Starting in V5R4, IBM i started to move away from the Classic version of Java and support for Classic is now stabilized. Today, Java is delivered on IBM i only through the IBM Technology for Java version.  (...) Initially the IBM Technology for JVM was implemented only on 32-bit architecture, but since IBM i 6.1, the 64-bit version is available for use. This gives more flexibility for developers, allowing them to fit the JVM according to their needs.

Este es un aspecto importante a tener en cuenta: las nuevas ediciones del sistema operativo implementan sólo la versión de Java de IBM. Así, Java 7 es implementada solamente en la versión de IBM. Sin embargo, esto no debería alterar la ejecución de código, sino explotar la posibilidad de usar de manera nativa servicios y posibilidades del sistema operativo y de la base de datos. El "IBM Toolbox for Java" y su equivalente open source JTOpen ofrecen un excelente medio de interactuar con los recursos del sistema.

En nuestro caso, el desarrollo de aplicaciones web con Webclient, que utiliza java como capa intermedia, nos ha dado oportunidad de comprobar la posibilidad de usar java sobre el System i. Básicamente, nuestras aplicaciones se ejecutan sin diferencias (salvo extensiones que concientemente explotan facilidades del sistema) sobre servidores Websphere en System i, iSeries o como se le llame, y sobre servidores Tomcat o Jetty (en este caso sólo para pruebas). Y quisiera decir que, además, las herramientas de análisis de problemas y performance que Websphere ofrece, son superiores al momento de tener que estudiar problemas. Probablemente, la posibilidad de usar Java nativamente es una de las mejores garantías de modernización y explotación del equipo, convirtiéndose en un puente entre el mundo móvil, web y de recursos infinitos que propone IOT, y la potencia de procesamiento y de manejo de datos del i.