Guía de Resolución: Errores de compilación Java al migrar Reportes a PDF (de GX9 a GX18)

1. El Problema: Síntomas y Errores Comunes

Durante la migración de sistemas legacy (GX9) a la versión GX18, específicamente al transformar viejos objetos Report en Procedures que generan PDFs, el compilador de Java puede arrojar errores que bloquean el Build.

Los dos errores más comunes que van a encontrar en el Output son:

Error A: Clases Duplicadas

error: duplicate class: com.gesrec.rcheq_plan_pag__datastore1
final  class rcheq_plan_pag__datastore1 extends DataStoreHelperBase implements ILocalDataStoreHelper

Error B: Símbolo / Método no encontrado (Fallo en la firma del Execute)

error: cannot find symbol
                  new com.gesrec.rplapagcdo(remoteHandle, context).execute( GXv_int1, GXv_char2) ;
                                                                  ^
  symbol:   method execute(int[],String[])
  location: class rplapagcdo

2. ¿Cuándo y por qué ocurre esto?

Estos errores ocurren cuando agarramos un reporte de GX9 y lo modificamos para que emita un PDF en GX18 (por ejemplo, cambiándole el Call Protocol a HTTP).

El motivo técnico: GeneXus guarda en su base de conocimiento (metadata) cómo se comunican los objetos entre sí. Cuando cambiamos un reporte a generador de PDF, su estructura interna en Java cambia radicalmente. Sin embargo, los objetos que lo llaman (el Caller, por ejemplo ptmpimpres) a veces conservan en caché la “vieja” forma de llamarlo (la firma del método execute). Como el objeto llamado ahora es distinto, los parámetros (int[], String[]) ya no coinciden con lo que espera el generador, provocando que se rompa el árbol de dependencias o se dupliquen clases internas al intentar parchear el código.

3. La Solución (Paso a Paso)

Para solucionar esto, debemos configurar el objeto correctamente en sus propiedades y forzar al generador de GeneXus a “olvidar” la metadata vieja, reconstruyendo los archivos físicos (.java y .class) desde cero.

Sigan estos pasos exactos:

1. Aislar el Procedimiento: Vayan a las propiedades del procedimiento problemático que genera el PDF (en este ejemplo, rplapagcdo).

2. Configurar como Main (Permanente): Cambien la propiedad Main Program a True. Al generar un PDF de esta manera, el objeto necesita ser un punto de entrada independiente.

3. Build Exclusivo: Hagan click derecho sobre ese procedimiento y ejecuten Build With This Only. (Esto lo genera de forma aislada, asegurando su nueva estructura).

4. Reconstruir Dependencias: Ejecuten un Build All.

4. ¿Por qué funciona esta solución? (La Lógica interna)

Al cambiar un reporte tradicional a un generador de PDF (especialmente al usar HTTP), su naturaleza cambia: deja de ser una simple rutina interna y pasa a ser un punto de ejecución autónomo.

• Al ponerlo en Main Program = True y hacer Build With This Only, le confirmamos a GeneXus esta nueva naturaleza. El generador descarta cualquier rastro del viejo reporte de GX9 y reconstruye la clase Java de forma 100% independiente y con una estructura limpia.

• Al hacer el Build All posterior, le estamos diciendo al resto de la KB (incluyendo al objeto llamador): “Atención, este objeto ahora es principal e independiente”. Al reevaluar la llamada, GeneXus reescribe la línea del .execute(...) adaptándose a esta nueva arquitectura, lo que soluciona instantáneamente el error cannot find symbol y limpia cualquier clase duplicada generada por la confusión previa.