ikvm-developers

[Ikvm-developers] Newbie question on calling Java from .NET

[Ola S. <ola...@lc...>]

Hello,

We are starting up a project which will use several Java-API's locally
and EJB's on remote servers for computaionally expensive tasks. What I
want to do is create the GUI in VB.NET and call hibernate-enabled
java-procedures to do all the work. We would very much appreciate if
someone experienced could give us a hint on the following questions:

1) Is IKVM what we are looking for?

2) What is the disadvantage/difference of using J#.NET?

3) How does IKVM differ from, for example, J-integra (ja.net) where you
bridge java to .NET/COM?

4) Is it possible to call EJB:s on remote machines using IKVM, or more
specific, is it possible to call java-code that interacts with remote
EJB's?

5) Is there a tutorial for VB.NET calling java using IKVM?

6) Is this setup something you would recommend us avoiding?

Thank you for your help!

   .../Ola

Re: [Ikvm-developers] Newbie question on calling Java from .NET

[Kevin G. <kg...@gm...>]

I think that using IKVM to run Java code which calls remote EJBs would
be a great architecture. Unfortunately I don't think that it will work
yet because GNU classpath is not complete regarding J2EE.

I would love to hear that someone has gotten this architecture to work.

I doubt that you can call EJBs with J# because J# only implements Java
1.1 which is ancient now. The '2' in J2EE refers to 'Java 2' which was
marketing-speak for Java 1.2.

The beauty of IKVM is that everything running in the process is .NET
byte codes running in the .NET virtual machine. With a bridging
solution like JIntegra, you run both the .NET VM and the Java VM in
the same process, with some complicated code to marshal between them.
It is a more bloated, more expensive, less stable, and less reliable
solution. But it is also more general and does not rely on alpha/beta
stage projects like IKVM and GNU classpath.

- kevin

On Fri, 02 Jul 2004 14:23:20 +0200, Ola Spjuth <ola...@lc...> wrote:
> 
> Hello,
> 
> We are starting up a project which will use several Java-API's locally
> and EJB's on remote servers for computaionally expensive tasks. What I
> want to do is create the GUI in VB.NET and call hibernate-enabled
> java-procedures to do all the work. We would very much appreciate if
> someone experienced could give us a hint on the following questions:
> 
> 1) Is IKVM what we are looking for?
> 
> 2) What is the disadvantage/difference of using J#.NET?
> 
> 3) How does IKVM differ from, for example, J-integra (ja.net) where you
> bridge java to .NET/COM?
> 
> 4) Is it possible to call EJB:s on remote machines using IKVM, or more
> specific, is it possible to call java-code that interacts with remote
> EJB's?
> 
> 5) Is there a tutorial for VB.NET calling java using IKVM?
> 
> 6) Is this setup something you would recommend us avoiding?
> 
> Thank you for your help!
> 
>    .../Ola
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Ikvm-developers mailing list
> Ikv...@li...
> https://lists.sourceforge.net/lists/listinfo/ikvm-developers
>

Re: [Ikvm-developers] Newbie question on calling Java from .NET

[Brian S. <bsl...@no...>]

On Jul 2, 2004, at 9:15 AM, Kevin Gilpin wrote:

> The beauty of IKVM is that everything running in the process is .NET
> byte codes running in the .NET virtual machine. With a bridging
> solution like JIntegra, you run both the .NET VM and the Java VM in
> the same process, with some complicated code to marshal between them.
> It is a more bloated, more expensive, less stable, and less reliable
> solution. But it is also more general and does not rely on alpha/beta
> stage projects like IKVM and GNU classpath.

It is my understanding that JNIBridge does basically the same thing. 
Can anyone verify that?

This issue is exactly what got me excited about IKVM in the first 
place! :)

Re: [Ikvm-developers] Newbie question on calling Java from .NET

[Kevin G. <kg...@gm...>]

If it has the letters 'JNI' in the name then yes it must do the same
thing. It would be a native DLL that implements JNI methods that can
talk to COM.

I bet you could make it work by IKVM-ing the part of the Sun JDK
classes that implement RMI and J2EE. If these classes don't use any
native code (and I don't see why they would),  they would run a lot
better than the GNU Classpath counterparts.

- kevin

On Fri, 2 Jul 2004 09:40:55 -0400, Brian Sletten <bsl...@no...> wrote:
> 
> 
> On Jul 2, 2004, at 9:15 AM, Kevin Gilpin wrote:
> 
> > The beauty of IKVM is that everything running in the process is .NET
> > byte codes running in the .NET virtual machine. With a bridging
> > solution like JIntegra, you run both the .NET VM and the Java VM in
> > the same process, with some complicated code to marshal between them.
> > It is a more bloated, more expensive, less stable, and less reliable
> > solution. But it is also more general and does not rely on alpha/beta
> > stage projects like IKVM and GNU classpath.
> 
> It is my understanding that JNIBridge does basically the same thing.
> Can anyone verify that?
> 
> This issue is exactly what got me excited about IKVM in the first
> place! :)
> 
>

Re: [Ikvm-developers] Newbie question on calling Java from .NET

[Ola S. <ola...@lc...>]

Thank you for your comments.

I think my problem is quite common for people writing java for Windows.
I have these constraints:

* I must be able to use some java API's.
* I'd prefer to build my business logic in java.
* I would like to be able to talk to EJB's (or some other remote
containers for distributing java code). Maybe web-services.

I want to build a simple/fast GUI and VB.NET would be ideal.
If this is not possible, too complex, too expensive or unstable, I guess
the only option is to create a java-GUI (using Swing I suppose). But my
app will run on Windows, I dont't like the java look-and-feel, and
developing java-GUI's is not as swift as creating a VB-app (not that I
know of, but I have no experience in visual java development).

Maybe there are some visual tools for java GUI development, and maybe I
can integrate some new look-and-feel (jgoodies.com, javootoo.com), but
then I have to learn all these new technologies and will not get the RAD
that VB.NET provides. Does anyone have an opinion on this? Should I
develop in .NET with IKVM or some bridge, or should I try a visual
development studio for java GUI's and implement an XP-look-and-feel? All
suggestions welcome!

Regards,

   .../Ola


On Fri, 2004-07-02 at 16:10, Kevin Gilpin wrote:
> If it has the letters 'JNI' in the name then yes it must do the same
> thing. It would be a native DLL that implements JNI methods that can
> talk to COM.
> 
> I bet you could make it work by IKVM-ing the part of the Sun JDK
> classes that implement RMI and J2EE. If these classes don't use any
> native code (and I don't see why they would),  they would run a lot
> better than the GNU Classpath counterparts.
> 
> - kevin
> 
> On Fri, 2 Jul 2004 09:40:55 -0400, Brian Sletten <bsl...@no...> wrote:
> > 
> > 
> > On Jul 2, 2004, at 9:15 AM, Kevin Gilpin wrote:
> > 
> > > The beauty of IKVM is that everything running in the process is .NET
> > > byte codes running in the .NET virtual machine. With a bridging
> > > solution like JIntegra, you run both the .NET VM and the Java VM in
> > > the same process, with some complicated code to marshal between them.
> > > It is a more bloated, more expensive, less stable, and less reliable
> > > solution. But it is also more general and does not rely on alpha/beta
> > > stage projects like IKVM and GNU classpath.
> > 
> > It is my understanding that JNIBridge does basically the same thing.
> > Can anyone verify that?
> > 
> > This issue is exactly what got me excited about IKVM in the first
> > place! :)
> > 
> >

[Ikvm-developers] IKVM and ClassPath Commercial Usage?

[Jonathan P. <jp...@ny...>]

Jeroen,

It's still not clear to me whether it is permitted for IKVM users to use
IKVM and ClassPath in a commercial closed source product. I realize that the
IKVM license allows this, but IKVM requires the modified version of the
classpath library. Any users of IKVM would still be subject to both
licenses, and it looks to me like the classpath license exception doesn't
provide for using it with IKVM.

Their clarification says: "When GNU Classpath is used unmodified as the core
class library for a virtual machine, compiler for the java languge, or for a
program written in the java programming language it does not affect the
licensing for distributing those programs directly."

Clearly, IKVM users are using a modified version of Classpath, and for a
virtual machine for .NET languages and not necessarily java, and for
programs written in other languages than java. 

You might want to make it clear on the IKVM site that using IKVM with
classpath requires that you adhere to the classpath license as well.

I think you might want to try again to get the classpath team to extend
their exception to cover usage of your modified binary version of ClassPath
with IKVM to allow IKVM users to use it to develop unrestricted closed
source products since I don't think including the modified ClassPath dll as
a separate DLL is covered by the classpath exception.

Jonathan