Java変換プロジェクト

[n-isaka]

opensource COBOL開発者各位

お疲れ様です。
現在、我々のチームでopenosurce COBOLでのCOBOLのコンバート先として、C言語だけでなく、Javaコードを出力できるようにすることを考えています。

目的として、以下2点があります。

• 昨今増えてきているJavaのシステムとの親和性を向上し、クラウド、マイクロサービスへの適用を考える
• 日本国内ではCOBOLからJavaへの移行の需要が増えており、その中で利用できるようにしたい

開発内容について、opensourcecobol内に別途リポジトリを作成して共有したいと考えています。
ご意見有りましたら、コメントお願いいたします。

--
We would like to update opensource COBOL to generate Java code not only C code

because,

• I want to improve the affinity with the Java system
• I want to help migration, migrate from COBOL to Java

I'm thinking of create new repositoy and publish development.

what's your opinion.

[GitMensch]

I've thought about this multiple times.
There are different things to consider. Most importantly: What is the goal, which you've stated.

To achieve this with a minimal impact and maximum stability (rewriting libcob [and possibly even cobc] would be a very long big task) I'd suggest integrating a JNI "interface" consisting of:

• java classes to provide the same set of functions that the C interface has
• java classes that will start the runtime if needed, and possibly providing an API to adjust the runtime settings
• java classes to wrap the conversions needed (especially concerning String objects but also the wrapper types like Integer)
• adjustments in libcob to provide a JNI "call-in" method and set a flag if started from java - if this was the case then all runtime exceptions in libcob must be returned as a java exception (so add an exception class in java, too)

This will allow anyone to call COBOL modules from JAVA, using primitive types and their Wrapper Objects.

A relative small change to cobc will allow to create a "java wrapper" source file that provides access to a COBOL program and methods for each external entry point. To do so it will use the java classes from step 1.

When this is finished it would theoretically be possible to change the code generation of cobc to directly create java source files (and also optionally to use cobc to compile them) but this would only be reasonable if the runtime is converted to Java, too. Despite the work it will definitely slow down the runtime by numbers.

In any case I invite you to work on this within the GnuCOBOL project using current "trunk" as start (on a new branch).
This way it is easier for others that know the system to get involved when wanted, it likely has a bigger test audience and there are a lot of things that will ease different parts (like the parameter conversion and setting of runtime options).

What do you think about this?

[n-isaka]

Thanks for your feedback.
I think also good implements JNI Interface.

I forgot to say, in Japan, Everyone want Java code strongly!
So we plan to add cobc's Java options (like --java) and develop JAVA libcob.

In my think, we edit only typeck and codegen in compiler.
And create new library JAVA libcob, but similar C libcob.

we are considering follows for Java and COBOL cooperation.

• We create JAVA INTERFACE CLASS.
  Java class which INTERFACE is implemented is called by CALL function from java created from COBOL.

• We prepared functions, write Java code into COBOL source code.

• All arguments between Java and COBOL are only String or Integer(double).

In any case I invite you to work on this within the GnuCOBOL project using current "trunk" as start (on a new branch).

It is attractive proposal for me.
But also GPLv3 issues are under discussion, so please wait a moment.

[n-isaka]

Hello,

I made it.
https://github.com/opensourcecobol/opensourcecobol4j

[GitMensch]

That's an interesting new repo. It looks like it uses a different approach than the old one outlined above.
Can you share more about the approach actually used now and also about the process you did to go from opensourcecobol to opensourcecobol4j?

Note: I assume the README is not up to date, it specifies a not existing directory "cobj" and not include the "libcob" directory.

[n-isaka]

My first thought was to include Java functionality as a feature of opensource COBOL.
However, since the implementation became complicated, I chose to create a new repository as a separate repository, giving priority to developability.

About approach:
We aimed to make Java without changing the functions and logic of opensource COBOL.
Regarding how to hold data, we have created a class that operates byte type and made it accessible so that Java can handle it in much the same way as the C version.
The compiler also outputs Java code in a 1:1 relationship with the C version.
(Although there is a difference in the order of code output)

P.S.
I will update the README together later.