libraries in C# and Java

[jeff]

We have a library written in Java that we need to port to .NET (and
we need to maintain both versions of the library). I've done some
preliminary research on approaches to this but none of them are
satisfactory. Here's what I've found so far:

- byte code conversion: converts Java classes to .NET assemblies.
Looked at ikvm which is open source, doesn't look mature enough.
Also requires runtime support which is a negative for us due to the
extra overhead.

- bridge technology: uses some kind of proxy generator and provides a
communications channel between the Java app and the .NET app. Looked
at JNBridge, a commercial solution. This won't work for us because
part of our library requires high performance and we don't want the
overhead of crossing contexts and marshalling data.

- language conversion: convert Java to C#. Looked at Microsoft's
Java Language Conversion Assistant (beta version 3). This is a one
way conversion and requires lots of hand tweaking, so there's the
price of performing an initial port, plus the extra cost of
maintaining two versions. Artinsoft provides a way of customizing
the JCLA conversion process (which in theory could reduce the amount
of code that needs to be manually edited) but they seem to be aiming
this at one time conversions (they charge based on lines of code).

Are there any other approaches or solutions out there?
Thanks...

-- jeff

[Steve McLellan]

"jeff" <ms**********@xoxy.net> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...

We have a library written in Java that we need to port to .NET (and
we need to maintain both versions of the library). I've done some
preliminary research on approaches to this but none of them are
satisfactory. Here's what I've found so far:

- byte code conversion: converts Java classes to .NET assemblies. [snip]
- bridge technology: uses some kind of proxy generator .... [snip]
- language conversion: convert Java to C#. [snip]
Are there any other approaches or solutions out there?
Thanks...

Hi,

Given the case that you don't want to use a converter because of the
performance hit, and don't want to maintain separate code bases, I don't see
an option at all. It might be worth asking why you need to convert, given
that from what you've said, you don't intend to use anything specific to
..NET, or its capabilities (and without separate code, you won't be able to
do anything that Java can't and vice versa). What's the reason you need to
port?

Steve

[Steve McLellan]

Sorry - just reread the question. I'm guessing you want to sell to a
customer already using .NET (or internal in an existing .NET context). If
this is the case, most of what I said isn't relevant, though would still
imagine that maintaining performance AND the original code base will
probably not be possible except in very trivial cases.

Steve

"Steve McLellan" <sjm AT fixerlabs DOT com> wrote in message
news:O8**************@tk2msftngp13.phx.gbl...

"jeff" <ms**********@xoxy.net> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...

We have a library written in Java that we need to port to .NET (and
we need to maintain both versions of the library). I've done some
preliminary research on approaches to this but none of them are
satisfactory. Here's what I've found so far:

- byte code conversion: converts Java classes to .NET assemblies.

[snip]

- bridge technology: uses some kind of proxy generator ....

[snip]

- language conversion: convert Java to C#.

[snip]

Are there any other approaches or solutions out there?
Thanks...

Hi,

Given the case that you don't want to use a converter because of the
performance hit, and don't want to maintain separate code bases, I don't
see an option at all. It might be worth asking why you need to convert,
given that from what you've said, you don't intend to use anything
specific to .NET, or its capabilities (and without separate code, you
won't be able to do anything that Java can't and vice versa). What's the
reason you need to port?

Steve

[jeff]

Correct, we need to provide the library to customers in both
environments. I believe there are some companies out there
that sell libraries for both environments, and I'd like to find
out how they do that (it's possible that they just live with
maintaining two separate code bases).

"Steve McLellan" <sjm AT fixerlabs DOT com> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...

Sorry - just reread the question. I'm guessing you want to sell to a
customer already using .NET (or internal in an existing .NET context). If
this is the case, most of what I said isn't relevant, though would still
imagine that maintaining performance AND the original code base will
probably not be possible except in very trivial cases.

[Chris R. Timmons]

"jeff" <ms**********@xoxy.net> wrote in
news:u2**************@TK2MSFTNGP10.phx.gbl:

We have a library written in Java that we need to port to .NET
(and we need to maintain both versions of the library). I've
done some preliminary research on approaches to this but none of
them are satisfactory. Here's what I've found so far:

- byte code conversion: converts Java classes to .NET
assemblies. Looked at ikvm which is open source, doesn't look
mature enough. Also requires runtime support which is a negative
for us due to the extra overhead.

- bridge technology: uses some kind of proxy generator and
provides a communications channel between the Java app and the
.NET app. Looked at JNBridge, a commercial solution. This
won't work for us because part of our library requires high
performance and we don't want the overhead of crossing contexts
and marshalling data.

- language conversion: convert Java to C#. Looked at
Microsoft's Java Language Conversion Assistant (beta version 3).
This is a one way conversion and requires lots of hand
tweaking, so there's the price of performing an initial port,
plus the extra cost of maintaining two versions. Artinsoft
provides a way of customizing the JCLA conversion process (which
in theory could reduce the amount of code that needs to be
manually edited) but they seem to be aiming this at one time
conversions (they charge based on lines of code).

Are there any other approaches or solutions out there?
Thanks...

Jeff,

Have you considered J# instead of C#? You may want to repost your
question in microsoft.public.dotnet.vjsharp. The denizens of that
group might have a better perspective on maintaining two Java
codebases.

Two other approaches to consider when maintaining two codebases are
to use a preprocessor (a la C and C++), or an active code generator.

The preprocessor of most C and C++ compilers can be hijacked to
produce output for any kind of text file. For example, this source
code can be run through the Microsoft cl.exe compiler using the /EP
switch (preprocess only, and direct output to stdout):

// Hello.java
// Compile with "cl hello.java /EP"

#define HELLO

#ifdef HELLO
Hello, world!
#else
No hello.
#endif

// Output is:
// Hello, world!
The drawback to this approach is the code can quickly become a mess
with all of those #defines.

Active code generators are discussed in the book "Pragmatic
Programming", on pp. 102-106.

http://www.codegeneration.net/tiki-r...hp?articleId=9
http://www.codegeneration.net/tiki-i...lsIntroduction

--
Hope this helps.

Chris.
-------------
C.R. Timmons Consulting, Inc.
http://www.crtimmonsinc.com/

[jeff]

"Chris R. Timmons" <crtimmons@X_NOSPAM_Xcrtimmonsinc.com> wrote in message
news:Xn**********************************@207.46.2 48.16...

"jeff" <ms**********@xoxy.net> wrote in
news:u2**************@TK2MSFTNGP10.phx.gbl:

Jeff,

Have you considered J# instead of C#? You may want to repost your
question in microsoft.public.dotnet.vjsharp. The denizens of that
group might have a better perspective on maintaining two Java
codebases.
Chris, thanks for taking the time to think about some alternative
approaches.

We looked into J# but it is based on an outdated version of Java (1.1.4)
which would also require us to back-port our software (also, it's
unclear where Microsoft is headed with J#, if anywhere).
Two other approaches to consider when maintaining two codebases are
to use a preprocessor (a la C and C++), or an active code generator.
I've used a preprocessor for C/C++ and it seems reasonable when you've
got a program in one language that is targeting different products or platforms.
Not so sure about using a preprocessor to mix different languages.
Also, we use IDEs for all our development, so there isn't any good way
of introducing new constructs without completely confusing the IDE.

Active code generators are discussed in the book "Pragmatic
Programming", on pp. 102-106.

http://www.codegeneration.net/tiki-r...hp?articleId=9
http://www.codegeneration.net/tiki-i...lsIntroduction

I will take a look at the articles. I did glance at the first one and it does
confirm our goal of wanting a single codebase instead of two.

-- jeff

[Justin Lee]

There is another way to do it I think. But I'm not too sure about the status
of it. You'll have to ask them directly.

Java.NET
http://www.remotesoft.com/javanet/

It's simply the Java language ported as a .NET language which supports JDK
1.3 and above. But as I said, there isn't much information on it. So, simply
compile your current Java codes into the .NET IL.

Hope that helps.

"jeff" wrote:

We have a library written in Java that we need to port to .NET (and
we need to maintain both versions of the library). I've done some
preliminary research on approaches to this but none of them are
satisfactory. Here's what I've found so far:

- byte code conversion: converts Java classes to .NET assemblies.
Looked at ikvm which is open source, doesn't look mature enough.
Also requires runtime support which is a negative for us due to the
extra overhead.

- bridge technology: uses some kind of proxy generator and provides a
communications channel between the Java app and the .NET app. Looked
at JNBridge, a commercial solution. This won't work for us because
part of our library requires high performance and we don't want the
overhead of crossing contexts and marshalling data.

- language conversion: convert Java to C#. Looked at Microsoft's
Java Language Conversion Assistant (beta version 3). This is a one
way conversion and requires lots of hand tweaking, so there's the
price of performing an initial port, plus the extra cost of
maintaining two versions. Artinsoft provides a way of customizing
the JCLA conversion process (which in theory could reduce the amount
of code that needs to be manually edited) but they seem to be aiming
this at one time conversions (they charge based on lines of code).

Are there any other approaches or solutions out there?
Thanks...

-- jeff

[jeff]

"Justin Lee" <Ju*******@discussions.microsoft.com> wrote in message
news:3D**********************************@microsof t.com...

There is another way to do it I think. But I'm not too sure about the status
of it. You'll have to ask them directly.

Java.NET
http://www.remotesoft.com/javanet/

It's simply the Java language ported as a .NET language which supports JDK
1.3 and above. But as I said, there isn't much information on it. So, simply
compile your current Java codes into the .NET IL.

Thanks for the reference, I will check it out.

-- jeff