Hemos estado recabando en distintos sitios para así tener para ti la respuesta para tu inquietud, en caso de alguna difcultad puedes dejarnos la inquietud y te contestaremos con gusto.
Solución:
Mi empresa también está intentando migrar a Java desde RPG.
- No estamos intentando utilizar un JRE en un cliente ligero, nos estamos moviendo a aplicaciones web entregadas a través de un navegador. Esto puede implicar (eventualmente) reemplazar nuestros viejos escáneres POS por algunos de los más nuevos basados en PC.
- Me han informado (los arquitectos de la empresa) que la JVM en el sistema operativo iSeries lo hace tiene algunos problemas de rendimiento. Personalmente, no sé cuáles son estas limitaciones. En nuestro caso, la migración ha implicado la asignación de un recurso AIX, que se supone que es mucho mejor: hable con su representante de IBM sobre si solo necesita comprar la licencia del sistema operativo (solo programo en la cosa, no me involucro en hardware).
- Consulte la respuesta a la pregunta 1. En un contexto más amplio, en el que intenta actualizar el navegador (o cualquier otro recurso), esto generalmente se maneja con licencias empresariales; la mayoría tendrá opciones para permitir actualizaciones forzadas y remotas.
Algunas otras notas:
- Debería poder pasar a usar solo .NET, aunque es posible que necesite diferente hardware / particiones para ejecutar el entorno. Puede hablar con DB2 de esa manera, al menos. El único beneficio que tiene Java es que se ejecutará en el mismo sistema operativo / hardware que la base de datos.
- He visto una aplicación de raspado de pantalla aquí (estaba en VB.NET, pero estoy bastante seguro de que se aplica el ejemplo). El raspado de pantalla se logró poniendo / colocando personajes en posiciones específicas en las pantallas (el equivalente a
substring()). Esa podría ser solo la API que estábamos usando; creo que he oído hablar de soluciones que pudieron leer los nombres de los campos. Sin embargo, también se basó en el flujo del programa RPG para su lógica y, por lo demás, no se podía mantener. - La mayoría de los programas de RPG que he visto y escrito tienden a ser una violación de MVC, lo que significa que no puede hacer nada menos que pruebas de integración: el historial y la arquitectura del lenguaje en sí (y algunos desarrolladores) prefieren que todo (acceso a archivos a la visualización en pantalla) estar en un archivo. Esto también hará que intentar envolver RPG para llamadas de forma remota sea efectivamente imposible. SI ha separado correctamente todo en Programas de servicio, deberían ser capaz de resumirlos (como el equivalente a una llamada de método nativo, casi) de manera ordenada; desafortunadamente, no he visto nada aquí que no tienda a depender de uno o más trucos que no se sostienen para el uso típico de la Web (por ejemplo, utilizando un archivo en QTEMP para controlar la ejecución del programa; la sesión en el iSeries desaparece efectivamente cada vez que se solicita una nueva página …).
- Java como lenguaje tiende a promover una mejor separación del código (tenga en cuenta que se puede usar mal de la misma manera), ya que no tiene la historia de los juegos de rol. En general, puede ser útil pensar en Java como un lenguaje donde todo es un programa de servicio, donde todos los parámetros se pasan con
VALUEcolocar,OPTIONS(*nopass : *omit)está prohibido,CONSTse recomienda generalmente, y la mayoría de los parámetros son de tipoDS(estructura de datos: este es un tipo distinto en RPG) y se pasa por puntero. Los parámetros de nivel de módulo están mal vistos, si están a favor de encapsular todo, ya sea en estructuras de datos pasadas o en los propios procedimientos del programa de servicio.STATICtiene un uso algo diferente en Java, lo que hace que la variable sea global y no está disponible dentro de los procedimientos. - RPG es un poco más simple que Java, en general, y la programación OO es un paradigma bastante diferente. Aquí hay algunas cosas que probablemente hagan tropezar a los desarrolladores que migran a Java:
- Las matrices en RPG comienzan en 1. Las matrices en Java comienzan en 0.
- Java no tiene parámetros de ‘salida’ y todos los tipos primitivos se pasan por valor (copiados). Esto significa que la edición de un número entero no será visible en los métodos de llamada.
- Java no tiene codificación empaquetada / firmada, por lo que traducir hacia / desde números / cadenas es más complicado. El tipo de fecha en Java también tiene algunos problemas serios (incluye tiempo, más o menos), y es mucho más difícil cambiar de manera significativa a / desde una representación de carácter.
- Es más difícil leer / escribir archivos en Java, incluso cuando se usa SQL (y olvídese de usar E / S nativas directamente con Java); sin embargo, esto se puede mitigar un poco con un buen marco.
- No existen
ENDxxoperadores en Java, todo usa corchetes () para especificar el inicio / final de los bloques. - Todo en Java está en formato libre y no hay especificaciones en columnas de ningún tipo (aunque todavía se requieren firmas de procedimientos). No hay un límite estricto en la longitud de la línea, aunque se recomiendan ~ 80 caracteres. Las herramientas (el gratis algunos, incluso) son mejores, punto y, en general, mucho más útiles (aunque es posible que los expuestos a SEU tarden un poco en acostumbrarse a ellos). También hay enormes bibliotecas gratuitas disponibles para descargar.
- los
=El signo no es sensible al contexto en Java como lo es en RPG, es siempre utilizado para las asignaciones. Usa los dobles iguales,==operador para comparaciones de valores en Java. - Los objetos (estructuras de datos) no se pueden comparar de manera significativa con
==– a menudo necesitará implementar un método llamadoequals()en lugar de. - Las cadenas no son mutables, no se pueden cambiar. Todas las operaciones realizadas en cadenas (ya sea en la clase / estructura de datos en sí o desde bibliotecas externas) devuelven referencias completamente nuevas. Y sí, se consideran cadenas estructuras de datos, no tipos de valor, por lo que no puede compararlos con
==cualquiera. - No hay equivalentes incorporados al
/copydirectivas del precompilador. Intentar implementarlos es usar Java incorrectamente. Debido a que estos se usan generalmente para tratar con código ‘repetitivo’ (definiciones de variables o código común), es mejor tratar esto en la arquitectura. Las definiciones variables (TODAS las especificaciones D, en realidad) se manejarán conimportoimport staticdeclaraciones, mientras que las variantes de código común generalmente son manejadas por un marco, o definiendo una nueva clase.
Estoy seguro de que hay muchas otras cosas por ahí, avíseme si tiene alguna otra pregunta.
Distribuir y gestionar un cliente gordo sería una auténtica pesadilla.
La solución ideal es una aplicación web basada en Java alojada en el iSeries. Las estaciones de trabajo acceden a sus aplicaciones a través de un navegador web como ASP.NET.
He estado usando Grails Framework para modernizar y crear nuevas aplicaciones y está funcionando de maravilla.
Cuando IBM dice que debería pasar a Java / J2EE, probablemente debería trasladar sus aplicaciones a aplicaciones web como sus aplicaciones web asp.net. Probablemente debería utilizar una interfaz rica en funciones como JSF o GWT.
Las aplicaciones web no tienen que preocuparse por los problemas de JRE, ya que solo necesita un navegador estándar.
Sin embargo, no conozco RPG y no conozco la estrategia de migración sugerida.
Si te gustó nuestro trabajo, tienes el poder dejar una noticia acerca de qué le añadirías a este ensayo.
¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)