Java standard classes moved to GitHub - Benefits and Compatibility aspects

Official Content

The project of the GeneXus Standard Classes used by applications generated with the Java generator is now publicly available in this GitHub space!
This article describes some of the benefits and compatibility issues to consider in this regard.

By moving the Java Standard Classes project to GitHub and making it open source GeneXus SA aims to improve the quality of the code, simplify its extensibility and evolution, enhance security, and provide better build and deployment for generated applications. 

Compatibility Aspects

The compatibility of the generated code is guaranteed. However, you should consider special conditions, which may cause compatibility issues if you somehow use an implementation that the standard classes no longer provide.

The incompatibilities will be detected at compilation time of the Java code.

If you use external modules, you must obtain new versions of it; if you use External object, you should get new versions of External Objects too, if they access these classes. Finally, perform a Rebuild All operation with the new version of GeneXus.

The changes affect the compatibility of: 

  • GeneXus-generated programs. 
    They have been updated in the corresponding version of GeneXus to avoid compatibility issues.
    Solution: Perform a Rebuild All operation with the new version of GeneXus.
  • Native code, written in objects of a GeneXus KB. This happens when using the JAVA command or non-standard functions (by setting the Functions property to Allow Non Standard Functions). 
    Both JAVA commands and non-standard functions are reported with a warning in the objects navigation; also, the incompatibilities of this case will be noted when performing a Rebuild All with the new version of GeneXus.
    Solution: Use the new function signature and perform a Build again.
  • Programs generated with previous versions of GeneXus. This can happen when using a distributed module (read Modules Distribution in GeneXus) with a previous version of GeneXus.
    In this case, incompatibilities occur only at runtime.
    Solution: Generate and distribute, with the new version of GeneXus, a new version of the module and install it in the target KB(s).
  • Java External Object (EO) that internally uses obsolete implementations from the standard classes.
    In this case, incompatibilities occur only at runtime.
    Solution: Correct the code using the new function signature, compile against the new classes, re-distribute a new version of the EO, and use it.

Note: Not following these steps can cause runtime errors. Therefore, it is recommended to first obtain the new versions of the external modules or objects. Next, perform a Rebuild All and, when it is successfully completed, distribute the application.


Here are examples of code with problems and the code that fixes them:


context.getClientPreferences().getPath()  // OK
ClientPreferences prefs = context.getClientPreferences();  // ERROR
ClientPreferences prefs = (ClientPreferences) context.getClientPreferences(); // OK



java [!&WebAppPath!] = context.getHttpContext().getRequest().getRealPath("/").replaceAll("\\\\","/");


java [!&WebAppPath!] = ((com.genexus.internet.HttpContext)context.getHttpContext()).getRequest().getRealPath("/").replaceAll("\\\\","/");


    public String getUSE_ENCRYPTION() {
        return context.getClientPreferences().getUSE_ENCRYPTION();
    public boolean hasPreferenceByKey(String key) {
        return context.getClientPreferences().propertyExists(key);


    public String getUSE_ENCRYPTION() {
        return com.genexus.Application.getClientPreferences().getUSE_ENCRYPTION();
    public boolean hasPreferenceByKey(String key) {
        return context.getPreferences().propertyExists(key);

Note that this code, in particular, can now be solved with GeneXus standard functions (Configuration Manager).

Agreement on Compatibility from now on

Interfaces started to be used in this refactoring process, and GeneXus SA commits evolving some of them maintaining compatibility.
More information about this in the project's readme at

Aspects to consider when deploying the application (Deployment)

Thanks to this refactoring, instead of all the code ending in a single gxclassR.jar, now there is a gxclassR.jar and also a gxmail.jar, gxmaps.jar, gxoffice.jar, and gxsearch.jar, among others.

This changes must be considered at deployment time. The tool and MSBuild tasks for deployment in GeneXus take this into account, deploying the required libraries.

Note: The classes referenced by JAVA commands are not considered to be automatically included during deployment, so you must take care that they get included in the deployment packages.  

There is more information about the modules and libraries in the GitHub project readme:

More information about the deployment in GeneXus, in the document on Application deployment.

Improvements for troubleshooting

Debugging has also been affected. As a result of the refactoring, gxclassD.jar is no longer necessary (it doesn't even exist anymore).

More technical information

You can read more about the Java Standard Classes project at
That readme explains, among other things, how to build the classes locally.


This feature is available since GeneXus 16 upgrade 4.