ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: J#... why? [ off topic ]
Date Wed, 09 Jan 2002 05:33:27 GMT

----- Original Message -----
From: "Joseph S. Barrera III" <>
To: "'Ant Users List'" <>
Sent: Tuesday, January 08, 2002 15:23
Subject: J#... why? [ off topic ]

> Since a lot of people have been asking WHY I would
> want to use J# for anything, I supposed I should
> explain.
> We have a large J2EE project that is all written
> (obviously) in Java. It runs in either the Weblogic
> or the Websphere app servers. (None of our customers
> is interested in running a free appserver.)

Can I just point out the Hp bluestone app server is high quality and
*free*;, and it comes with a GUI deployment tool that
is ant based? Paying for an app server is, now like, paying for a web server
or a text editor. It's commodity infrastructure.

> Our customers now are asking to run the app on .NET,
> for two reasons: one, because they'd like to not
> have to pay for an app server, and two, because they'd
> like to extend it with .NET components rather than
> EJBs, and have it access data via ADO.NET instead of
> JDBC, and so forth.

right. I am kind of neutral on JDBC, and definately dubious about many
aspects of j2ee, but have you noticed that every time MS brings out some
version of their toolchain, they rework their database connectivity story?
ODBC, RDO, ADO, OLEDB (so chatty it doesnt work out of proc, let alone over
the wire), now we have ADO.NET. Which is interesting, its whole XML
marshalled stuff model is good for some long haul tasks, but no good for
tight coupling of stuff.

> So we're trying to figure out how to do this without
> abandoning all our Java code. J# seems like the obvious
> solution. Yes, there are various problems, like the
> 1.1.x compat issue, but those can be solved. I hope.

J# will only do a subset of the current java platform, and although it is a
full .net language, integration is a lot more seamful than in C#. Yet the
languages are similar enough that I could move some complex Java algorithms
related to geode modelling and datum translation (lots of trig, basically)
from Java to C# in an evening. All you need is a lookup table of datatypes,.
Eric G's book and the .NET package library in a window.

You could keep core algorithms in java with front ends customised for java
and .net use; this could keep R&D costs at slightly less than double,
provided JUnit or your own test framework works.  But if you really have
done full J2EE, with CMP or BMP ej beans, session beans, struts front end,
then you are not going to have a simple port, you will get partway with j#
and then end up with writing webform and winforms front ends, back
ends, WMI management...etc. And since nobody can afford to maintain two
codebases, you are ultimately going to be stuck in the .NET world if that is
what your customers want.

> The only alternative I can think of is to keep compiling
> the app into actual java byte codes, and then use JNI
> to access the .NET bits. We may end up having to do that,
> but I would think that a customer who asks for .NET
> would rather that the whole thing ran in .NET.

There are rumours of a Java to C# source migration tool; it probably isnt
that hard, especially given there already is a funky little C# to VB or back
tool which just decompiles MSIL into the appropriate language...MS could do
one which compiled down java and output C#. And since you can import the j#
libraries into C# (it is the only way to work Zip files), you can still use
your favourite java packages.

But the alternative is run your J2EE code on a free app server (see above),
use the Apache libraries to talk SOAP+attachments, and say 'works with
.NET'. That way you get to use ant for your build and deploy process.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message