Thread: Re: [Ikvm-developers] Welcome
Brought to you by:
jfrijters
Menu
▾
▴
ikvm-developers
|
From: Pablo B. <pb...@uo...> - 2003-01-04 17:37:41
|
Thanks a lot for taking your time to set this mailing list! On Sat, 2002-12-28 at 12:33, Jeroen Frijters wrote: > Devise a strategy to get JNI working on Mono. I looked at > Marshal.GetUnmanagedThunkForManagedMethodPtr(), but was unable to get it to > work with a vararg method (which is needed for JNI). At least is it possible to compile SWT to a .NET dll for running it on Linux? I'm very interested on trying it...but ikvm doesn't work on linux right? -- Pablo Baena <pb...@uo...> |
|
From: Jeroen F. <je...@su...> - 2003-01-06 08:09:11
|
Hi Pablo, > Oh! So that's what happened, you haven't noticed the last > part of my mail. It wasn't just a 'thank you' message. :) Oops! Sorry about that. > To quote: > > At least is it possible to compile SWT to a .NET dll for > running it on Linux? I'm very interested on trying it...but > ikvm doesn't work on linux right? At the moment this is not possible, for at least two reasons: 1) ikvm doesn't yet work on Mono 2) My JNI implementation uses Managed C++ which won't work on Mono > And to add something: is there something I can do to make > this happen? I know C# and some C/C++. Do you know JNI? We need get JNI running on Linux. Also, you might consider working on Mono to make sure it is capable of running ikvm sooner. Regards, Jeroen |
|
From: Pablo B. <pb...@uo...> - 2003-01-06 10:11:08
|
> Do you know JNI? We need get JNI running on Linux. Also, you might consider > working on Mono to make sure it is capable of running ikvm sooner. > I don't know JNI. The compiled ik.vm.jni.dll should run on mono although it is written on managed C++. I am making tests already to verify. There seems to be a few issues because of the lower/upper case of the name of assemblies referenced (this is easy to solve). Also, the Microsoft.VisualC.dll is missing on mono (just copying the windows' one works by now). Besides of that, a few other problems arise when trying to run the binaries. I will be tracking and reporting them on mono's bugzilla. Another question: with your actual experience on Java/.NET interoperation, haven't you thought on creating a runtime bridge between Java and .NET like jnbridge? (a commercial product) It would be nice to have something like this to use Java classes directly on .NET without the need to recompile. Much like your netexp utility just the other way around. -- Pablo Baena <pb...@uo...> |
|
From: Jeroen F. <je...@su...> - 2003-01-06 12:05:41
|
Pablo Baena wrote: > I don't know JNI. The compiled ik.vm.jni.dll should run on=20 > mono although it is written on managed C++. No, it won't. It contains both IL and x86 code, and worse, it also = contains the Microsoft C/C++ runtime startup junk (with dependencies on Windows APIs). > Also, the Microsoft.VisualC.dll is=20 > missing on mono (just copying the windows' one works by now). This assembly doesn't contain any code, just a bunch of attributes that = are emitted by the MC++ compiler. So the Windows version will work fine on = Mono, it just won't buy you anything in this instance. > Besides of that, a few other problems arise when trying to=20 > run the binaries. I will be tracking and reporting them on=20 > mono's bugzilla. Please let me know what you find. > Another question: with your actual experience on Java/.NET=20 > interoperation, haven't you thought on creating a runtime=20 > bridge between Java and .NET like jnbridge? (a commercial=20 > product) It would be nice to have something like this to use=20 > Java classes directly on .NET without the need to recompile.=20 > Much like your netexp utility just the other way around. I don't think I see the point of that. Currently, there are two ways you = can use Java classes from .NET with IKVM.NET: 1) Link your (e.g.) C# application with classpath.dll and instantiate a class loader, use that to load .class files and use reflection to call methods or create instances. 2) Statically compile your .class files into an .NET assembly and then = link your C# application with that assembly. I haven't looked at jnbridge, but I assume they generate .NET proxy = classes for the Java classes, we could do the same, but statically compiling = just makes more sense to me. Proxies are slow and have all sorts of = complicated identity issues. Regards, Jeroen |
|
From: Paolo M. <lu...@xi...> - 2003-01-06 12:06:46
|
On 01/06/03 Pablo Baena wrote: > I don't know JNI. The compiled ik.vm.jni.dll should run on mono although > it is written on managed C++. I am making tests already to verify. There The IK.VM.JNI.dll assembly (at least the one I got a few weeks ago) contains x86 code. We don't support running x86 code in mono, only IL (and, besides, we want to support ikvm also on other architectures). I don't know if it's possible to compile that managed c++ code completely to IL (I think there's a switch to do that). > seems to be a few issues because of the lower/upper case of the name of > assemblies referenced (this is easy to solve). Also, the > Microsoft.VisualC.dll is missing on mono (just copying the windows' one > works by now). Writing a replacement for Microsoft.VisualC.dll should be easy, it seems it just contains some attributes... > Besides of that, a few other problems arise when trying to run the > binaries. I will be tracking and reporting them on mono's bugzilla. Thanks. If the managed c++ code can be compiled to IL code we should be able to complete the support in mono to run it. A better solution (since we want to be able to rebuild ikvm in mono as well and we're not going to support compiling managed c++ any time soon) is to write a different jni support assembly for mono. This may require hooks or special handling in the runtime, but I think there should be no problem in implementing them if it's not possible to implement the assembly with the standard P/Invoke mechanism. lupus -- ----------------------------------------------------------------- lu...@de... debian/rules lu...@xi... Monkeys do it better |
|
From: Jeroen F. <je...@su...> - 2003-01-06 13:12:41
|
lupus wrote: > If the managed c++ code can be compiled to IL code we should=20 > be able to complete the support in mono to run it. It can't be. The reason it's in MC++ is because JNI needs to implement a native interface (abstract C+ class). > A better solution (since we want to be able to rebuild ikvm in mono as > well and we're not going to support compiling managed c++ any=20 > time soon) is to write a different jni support assembly for mono. This = > may require hooks or special handling in the runtime, but I think > there should be no problem in implementing them if it's not possible > to implement the assembly with the standard P/Invoke mechanism. The ikvm JNI provider is pluggable (although the interface hasn't = stabilised yet). Whether a fully managed solution will be possible, I don't know. = It depends on whether it's possible to create a unmanaged stub for a vararg function. BTW, even if a fully managed solution is possible, it is = unlikely that the same code will work for Windows and Linux, because the JNI = calling convention will probably be different between the two platforms. Regards, Jeroen |
|
From: Varga Z. <va...@fr...> - 2003-01-06 12:10:34
|
Hi, During the last few months, I tried to make IKVM.NET run on mono. Here is the current status: - the following bugs block IKVM from compiling on mono: http://bugzilla.ximian.com/show_bug.cgi?id=3D35567 http://bugzilla.ximian.com/show_bug.cgi?id=3D33026 http://bugzilla.ximian.com/show_bug.cgi?id=3D30485 All of these bugs can be worked around so the code can be made to compile. - mono can't run IKVM because IKVM relies on the XmlSerializer=20 framework to load map.xml and it is not yet implemented in mono. So I think nothing more can be done until either: - somebody finishes XmlSerializer in mono - or IKVM drops it dependency BTW, why does the map.xml file is needed? Wouldn't be easier to put all this information into a C# class? Like this: fooClass =3D new MapXlm.Classs (); fooClass.Name =3D .... etc. bye Zoltan Pablo Baena <pb...@uo...> =EDrta: >=20 >=20 > > Do you know JNI? We need get JNI running on Linux. Also, you might consider > > working on Mono to make sure it is capable of running ikvm sooner. > >=20 >=20 >=20 > I don't know JNI. The compiled ik.vm.jni.dll should run on mono although > it is written on managed C++. I am making tests already to verify. There > seems to be a few issues because of the lower/upper case of the name of > assemblies referenced (this is easy to solve). Also, the > Microsoft.VisualC.dll is missing on mono (just copying the windows' one > works by now). >=20 > Besides of that, a few other problems arise when trying to run the > binaries. I will be tracking and reporting them on mono's bugzilla. >=20 > Another question: with your actual experience on Java/.NET > interoperation, haven't you thought on creating a runtime bridge between > Java and .NET like jnbridge? (a commercial product) It would be nice to > have something like this to use Java classes directly on .NET without > the need to recompile. Much like your netexp utility just the other way > around. >=20 >=20 > --=20 > Pablo Baena <pb...@uo...> > |
|
From: Jeroen F. <je...@su...> - 2003-01-06 13:12:36
|
Varga Zoltan wrote: > During the last few months, I tried to make IKVM.NET run > on mono. > Here is the current status: > > - the following bugs block IKVM from compiling on mono: > > http://bugzilla.ximian.com/show_bug.cgi?id=3D35567 > http://bugzilla.ximian.com/show_bug.cgi?id=3D33026 > http://bugzilla.ximian.com/show_bug.cgi?id=3D30485 > > All of these bugs can be worked around so the code can be made > to compile. Miguel, can you please take a look at these? > - mono can't run IKVM because IKVM relies on the XmlSerializer > framework to load map.xml and it is not yet implemented > in mono. > > So I think nothing more can be done until either: > - somebody finishes XmlSerializer in mono > - or IKVM drops it dependency I will, at some point, drop the dependency on XmlSerializer (at least at = run time, the static compiler might still require it). > BTW, why does the map.xml file is needed? Wouldn't be easier to > put all this information into a C# class? Like this: > fooClass =3D new MapXlm.Classs (); > fooClass.Name =3D .... XML seemed like a nice format for storing the remapping, and it allows = for easy experimentation. My plan is to move the XML file out of = ik.vm.net.dll and make it a separate file and then have ikvmc (the static compiler) compile it into classpath.dll (in the form of code, not XML). Also, = somewhat farther into the future, I will probably write a Java compiler that = compiles Java source directly to a .NET assembly, this compiler will also require = the remapping information in XML file. Regards, Jeroen |
|
From: ginga(A.E.) <gi...@ki...> - 2003-01-07 15:00:24
|
Hello, > XmlSerializer looks like a big piece of code. I would not know how much > work is required there (I CCed Atsushi and Dietmar that might have an > idea of how big this is). Unfortunately, I haven't ever touched those classes (there are only 3 developers who commited XmlSerializer stuff) and have few knowledge about XML serialization. I've now reviewed current code, and found that those classes are too insufficient to recommend someone to use it right now. Anyway, I'll look into those classes. Thanks, -- Atsushi Enomoto |
|
From: Jeroen F. <je...@su...> - 2003-01-07 08:54:00
|
Miguel de Icaza wrote: > > I will, at some point, drop the dependency on XmlSerializer > (at least at run > > time, the static compiler might still require it). > > XmlSerializer looks like a big piece of code. I would not > know how much > work is required there (I CCed Atsushi and Dietmar that might have an > idea of how big this is). This isn't very important. I can easily remove the dependency on the XmlSerializer, and use System.Xml.XmlDocument instead. > But this wont get IKVM *running* in Mono yet right? No, that requires Reflection.Emit to support AssemblyBuilderAccess.Run (and the AppDomain.TypeResolve event), but it will (hopefully) allow running of statically compiled Java code in Mono. Regards, Jeroen |
|
From: Varga Z. <va...@fr...> - 2003-01-07 10:48:09
|
Hi,
Jeroen Frijters <je...@su...> =EDrta:
> No, that requires Reflection.Emit to support
AssemblyBuilderAccess.Run (and
> the AppDomain.TypeResolve event), but it will (hopefully)
allow running of
> statically compiled Java code in Mono.
>=20
> Regards,
> Jeroen
>=20
I'm willing to write that support in the runtime. In fact,
it is already
half done, but I couldn't test it with IKVM due to the
XmlSerializer
issue.
bye
Zoltan
>=20
>=20
>
|
|
From: Jeroen F. <je...@su...> - 2003-01-07 11:43:52
|
Varga Zoltan wrote: > Jeroen Frijters <je...@su...> =EDrta: > > > No, that requires Reflection.Emit to support > AssemblyBuilderAccess.Run (and > > the AppDomain.TypeResolve event), but it will (hopefully) > allow running of > > statically compiled Java code in Mono. > > I'm willing to write that support in the runtime. In fact, > it is already half done, but I couldn't test it with IKVM > due to the XmlSerializer issue. Cool! That's great to hear. I just checked in a temporary solution so = that the code doesn't depend on XmlSerializer anymore. I haven't tested with Mono, but you might need to comment out the = [Xml...] attributes in remapper.cs Regards, Jeroen |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X