Java ジェネレーターで生成されたアプリケーションで使用されている GeneXus 標準クラスのプロジェクトは、こちらの GitHub 上で公開されるようになりました。
ここでは、この移行に関するメリットと、考慮すべき互換性の問題について説明します。
GeneXus SA は、Java 標準クラスのプロジェクトを GitHub に移行してオープンソース化することにより、生成されたアプリケーションのコードの品質の改善、拡張や進化の簡素化、セキュリティの強化、ビルドやデプロイメントの向上を目指しています。
生成されたコードの互換性は保証されています。ただし、標準クラスに非対応の実装を何らかの形で使用する場合は、互換性の問題を引き起こす可能性がある特殊な条件を考慮する必要があります。
非互換性は Java コードのコンパイル時に検出されます。
外部モジュールを使用する場合は、新しいバージョンを取得する必要があります。同様に、これらのクラスにアクセスする外部オブジェクトを使用する場合は、新しいバージョンを取得する必要があります。最後に、新しいバージョンの GeneXus を使用して [ すべてリビルド ] 操作を実行します。
変更は次の互換性に影響します:
- GeneXus で生成されたプログラム。
互換性の問題を回避するために、対応するバージョンの GeneXus で更新されたものが該当します。
解決方法: 新しいバージョンの GeneXus を使用して [ すべてリビルド ] 操作を実行します。
- GeneXus ナレッジベースのオブジェクトで記述されたネイティブコード。Java コマンドまたは非標準関数 ( [ Functions ] プロパティを Allow Non Standard Functions に設定) を使用する場合に起こります。
Java コマンドと非標準関数のいずれについても、オブジェクトナビゲーションで警告付きで報告されます。このケースの非互換性については、新しいバージョンの GeneXus で [ すべてリビルド ] を実行するときにも言及されます。
解決方法: 新しい関数署名を使用して再びビルドを実行します。
- 以前のバージョンの GeneXus で生成されたプログラム。以前のバージョンの GeneXus で配布モジュール (「GeneXus のモジュール配布」を参照) を使用するときに影響が出る可能性があります。
このケースでは、非互換性は実行時にのみ発生します。
解決方法: 新しいバージョンの GeneXus を使用して新しいバージョンのモジュールを生成および配布し、それをターゲットのナレッジベースにインストールします。
- 標準クラスに基づく旧式実装を内部的に使用する Java 外部オブジェクト (EO)。
このケースでは、非互換性は実行時にのみ発生します。
解決方法: 新しい関数署名を使用してコードを修正し、新しいクラスに対してコンパイルを行い、新しいバージョンの EO を再配布して使用します。
注: これらの手順に従わないと、実行時エラーが発生する可能性があります。そのため、最初に新しいバージョンの外部モジュールまたは外部オブジェクトを取得することをお勧めします。次に、 [ すべてリビルド ] を実行して、正常に完了したらアプリケーションを配布します。
次に、問題を伴うコード例と修正後のコードを示します。
1)
context.getClientPreferences().getPath() // OK
ClientPreferences prefs = context.getClientPreferences(); // エラー
ClientPreferences prefs = (ClientPreferences) context.getClientPreferences(); // OK
2)
旧コード (エラー)
java [ !&WebAppPath! ] = context.getHttpContext().getRequest().getRealPath("/").replaceAll("\\\\","/");
新コード (OK)
java [ !&WebAppPath! ] = ((com.genexus.internet.HttpContext)context.getHttpContext()).getRequest().getRealPath("/").replaceAll("\\\\","/");
3)
旧コード (エラー)
public String getUSE_ENCRYPTION() {
return context.getClientPreferences().getUSE_ENCRYPTION();
}
public boolean hasPreferenceByKey(String key) {
return context.getClientPreferences().propertyExists(key);
}
新コード (OK)
public String getUSE_ENCRYPTION() {
return com.genexus.Application.getClientPreferences().getUSE_ENCRYPTION();
}
public boolean hasPreferenceByKey(String key) {
return context.getPreferences().propertyExists(key);
}
特にこのコードは GeneXus の標準関数 (Configuration Manager) を使用して解決できるようになったことに留意してください。
このリファクタリングプロセスで使用されるようになったインターフェースの一部については、今後の進化と互換性維持が約束されています。
詳細については、プロジェクトの Readme (https://github.com/genexuslabs/JavaClasses#genexus-standard-classes-for-java) を参照してください。
このリファクタリングに伴い、すべてのコードを最終的に 1 つの gxclassR.jar に組み込むのではなく、今後は、gxclassR.jar に加え、gxmail.jar、gxmaps.jar、gxoffice.jar、gxsearch.jar なども使用することになります。
デプロイ時にはこの変更を考慮する必要があります。GeneXus にデプロイ用として用意されているツールおよび MSBuild タスクでは、この点が考慮され、必要なライブラリがデプロイされるようになっています。
注: Java コマンドで参照されるクラスについては、デプロイ時に自動的に組み込まれることはなく、手動でデプロイパッケージに組み込む必要があります。
モジュールやライブラリの詳細については、GitHub プロジェクトの Readme (https://github.com/genexuslabs/JavaClasses#modules) を参照してください。
GeneXus でのデプロイの詳細については、アプリケーションのデプロイに関するドキュメントを参照してください。
デバッグにも影響があります。リファクタリングの結果として、gxclassD.jar が不要になりました (すでに存在していません)。
Java 標準クラスのプロジェクトの詳細については、https://github.com/genexuslabs/JavaClasses#genexus-standard-classes-for-java を参照してください。
この Readme では、クラスをローカルに構築する方法などが説明されています。
この機能は GeneXus 16 Upgrade 4 以降で利用できます。
|