Thread: [Sablevm-developer] Java-Gnome: jni or cni
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Mark H. <mh...@de...> - 2004-03-11 18:03:13
|
Dear Java Developers, I am writing to you on behalf of the java-gnome project for advice regarding a major change we are currently considering. I apologise if this is off topic for this mailing list but we really need input and you are the most knowledgeable open source java developers; it may also help determine whether we will be using your projects in the future. Sorry for cross posting - we think members of each list are likely to have different opinions on this topic and want to hear them all. The big question is: should we switch to CNI? Java-Gnome is a set of libraries for creating GTK/GNOME based applications in java. It is different from SWT in that it aims to implement the entire gnome libraries so will be able to create applications with integrate fully with gnome. It is different from swing in that it is completely free and has a high quality graphical interface builder tool (glade). At the moment, java-gnome uses jni to communicate with the gtk/gnome libraries. This works well with good performance but makes the build process very difficult and also makes the task of application developers more difficult since they are trying to support many jvms. The current discussions can be found at [1] and [2]. I will try to summarise some of the main points below.=20 [1] http://sourceforge.net/mailarchive/forum.php?forum_id=3D5689 (subject: What's next) [2] http://sourceforge.net/mailarchive/forum.php?forum_id=3D11301 (subject: What's next, migration to cni, topic for discussion) Migration to CNI thread contains details of three options with exaple code. Our users - gnome/linux apps - always have gcc; rarely have a jvm - embedded - want as small as possible (but java-gnome might not be suitable anyway). Need a jvm for security/sandboxing? - Windows - nobody has tried yet but everyone likes the idea=20 (would a CNI approach ever work on windows?) JVM support JNI supports most JVMs. The library has to be compiled with two compilers (gcc + "javac"), which is tricky CNI requires everything to be compiled with GCJ, including applications. This means that some features found only in sun's latest jvm will not be available (in particular, classpath is quite outdated) Performance JNI runs slower (although it is probably fast enough for basic gui's, IMHO. But not e.g. complex TreeModelFilters) Size JNI produces large bindings Ease of development JNI is harder to develop Entry barrier/learning curve -compilation Most users have to compile java-gnome. This requires both gcc and javac. For applications, it requires javac. Java developers are used to javac.=20 -use Eclipse, debuggers, other java tools Java developers know (and like?) these. open source ones are probably better once people get to know them. eclipe use (+debug/profile) may still be possible with the cdt plugin for eclipse. Alternative java guis - we want people to choose java-gnome: * Java-Gnome * Classpath's Swing * Sun's Swing * IBM's SWT also, we want gnome developers to choose java-gnome :)=20 Combined CNI & JNI approach (possibly generating code) Added complexity for us and our build process. Worst of both worlds? Would not be possible to optimise for either cni or jni. Please see java-gnome ml archives for details - then suggest something else if you have an idea of another way to do this. Java-Gnome developers are currently unsure about what to do. We like the idea of cni but it sounds risky. That's why we're asking for your input. Thank you in advance for taking the time to read this and hopefully responding. http://java-gnome.sf.net --=20 .''`. Mark Howard : :' : `. `' http://www.tildemh.com=20 `- mh...@de... | mh...@ti... | mh...@ca...=20 |
|
From: Chris G. <ch...@ki...> - 2004-03-12 00:30:01
|
On Thursday 11 March 2004 18:44, Mark Howard wrote:
> Dear Java Developers,
>
> I am writing to you on behalf of the java-gnome project for advice
> regarding a major change we are currently considering. I apologise if
> this is off topic for this mailing list but we really need input and you
> are the most knowledgeable open source java developers; it may also
> help determine whether we will be using your projects in the future.
> Sorry for cross posting - we think members of each list are likely to
> have different opinions on this topic and want to hear them all.
>
> The big question is: should we switch to CNI?
No.
> Java-Gnome is a set of libraries for creating GTK/GNOME based
> applications in java. It is different from SWT in that it aims to
> implement the entire gnome libraries so will be able to create
> applications with integrate fully with gnome. It is different from swing
> in that it is completely free and has a high quality graphical interface
> builder tool (glade).
>
> At the moment, java-gnome uses jni to communicate with the gtk/gnome
> libraries. This works well with good performance but makes the build
> process very difficult and also makes the task of application developers
> more difficult since they are trying to support many jvms.
I'm a bit puzzled by this statement. Almost all VMs support JNI, and the few
that don't (e.g. Jaos) cannot run C++ code in any shape or form (but Jaos can
run Oberon code with 0 overhead :->). So if you want to support many JVMs
then JNI is the way to go.
Of course if you want to restrict your code to running on only one Java
implementaion then this will in a sense make your life simpler. It will of
course also make life simpler for anyone planning to use a different
implementaion -- they don't need to take the time to evaluate your solution.
Frankly this sounds to me like the worse kind of embrace-and-extend; it will
result in the emergence of a set of "Java" programs which run only on certain
implementations of Java. Hm, hasn't that been tried before?
Some people inside Sun seem to think that open source Java is a Bad Idea,
because it risks fragmenting the language. Until today, I thought they were
just imagining things ...
Stay cool everyone,
Chris
--
Chris Gray ch...@ki...
+32 477 599 703
|
|
From: Per B. <pe...@bo...> - 2004-03-12 00:42:52
|
Chris Gray wrote: > On Thursday 11 March 2004 18:44, Mark Howard wrote: >>The big question is: should we switch to CNI? > > No. Though I'm obviously in the CNI "camp", I tend to agree. But I think the folloup-question is: should java-gnome switch from JNI-only implementation to some kind of dual JNI-or-CNI mechanism. I.e. explore ways to reduce the overhead of JNI when CNI is avaliable. I suggested one approach in my previous email (which may be waiting for moderator approval on the kaffe and java-gnome lists). -- --Per Bothner pe...@bo... http://per.bothner.com/ |
|
From: Chris G. <ch...@ki...> - 2004-03-12 09:38:57
|
On Friday 12 March 2004 01:23, Per Bothner wrote:
> Chris Gray wrote:
> > On Thursday 11 March 2004 18:44, Mark Howard wrote:
> >>The big question is: should we switch to CNI?
> >
> > No.
>
> Though I'm obviously in the CNI "camp", I tend to agree.
>
> But I think the folloup-question is: should java-gnome
> switch from JNI-only implementation to some kind of dual
> JNI-or-CNI mechanism. I.e. explore ways to reduce the
> overhead of JNI when CNI is avaliable. I suggested one
> approach in my previous email (which may be waiting for
> moderator approval on the kaffe and java-gnome lists).
A JNI-or-CNI approach such as you outlined would be fine.
The choice for java-Gnome should be independent of the choice of VM. If you
can meet a client's needs using java-Gnome and a free VM, go for it. But
when shit happens, and some system component you never even knew existed
turns out to need some JDK 1.5 functionality which Classpath doesn't have,
you should be able to switch VMs without having to throw away the whole GUI
that's been developed. Explaining to the customer that the free
implementation needs time to catch up on functionality that's only recently
been defined is one thing; explaining that your "Java" GUI bindings don't run
on standard Java is quite another.
In a more optimistic scenario, if Gnome is ported to a platform but there is
no CNI-based VM for that platform yet, it should be possible for java-Gnome
apps to run on that platform immediately.
In general I believe it should be possible to mix free and non-free software;
if the solution ends up being 100% free then so much the better, but if you
try to force that from the start you may end up with 0%. This appears also
to be the Classpath philosophy (otherwise the licence would be straight GPL).
--
Chris Gray ch...@ki...
+32 477 599 703
|
|
From: Elias M. <el...@al...> - 2004-03-11 19:22:50
|
tor 2004-03-11 klockan 18.44 skrev Mark Howard: > Dear Java Developers, >=20 > I am writing to you on behalf of the java-gnome project for advice > regarding a major change we are currently considering. I apologise if > this is off topic for this mailing list but we really need input and you > are the most knowledgeable open source java developers; it may also > help determine whether we will be using your projects in the future. > Sorry for cross posting - we think members of each list are likely to > have different opinions on this topic and want to hear them all. >=20 > The big question is: should we switch to CNI? I'm not a contributor (yet?), and I'm currently merely playing around with Java-GNOME. However, I like it very much. I am what could be considered an expert Java programmer. This is, however, not the place to publish ones resum=C3=A9. I do have 7 years of Ja= va development experience. Reading peoples suggestions calling for CNI makes me very frightened. I'll try to explain why: In the current environment, Sun controls Java. I am not going to go into whether this is good or not, but this is the way it is. Sun releases a new version of java every 18 months or so, and every time they do there are huge improvements. With 1.4 we got the IO channels, giving us multiplexed IO and memory mapped files. 1.5 gives us the largest set of improvements to Java we have ever seen, including generics, covariant return types, shared VM's, etc... GCJ and CLASSPATH has to play the catchup game all the time, and I don't think I can even use the 1.4 IO channels in it yet. Even if you don't use the new features yourself, what are you going to do if your JDBC driver uses some new features? Don't forget that one of the great strengths of Java is it's great open source community where you can find pretty much every component you'd ever want freely downloadable. Going CNI-only would severely limit the number of 3'rd party component you'd be able to integrate. The fact that Java is heavily dynamic (sandboxed execution, etc...) is an enormous advantage, and I fail to see how an experienced Java developer who uses these things could ever even consider turning the back on everything that is Java, just to gain a little perceived performance. Speaking of performance advantage, has anyone even done any benchmarking to decide how much of a performance difference we're talking about here? Since Java is dynamic, I can, at runtime, detect whether Java-GNOME is available, and select a Java-GNOME or a Swing-based user interface at runtime. This makes it possible to ship an app that is both native GNOME, and completely cross-platform (naturally, the practicality of this depends heavily on the type of application). This app can still use the same features available to all application running on the Java platform. Another thing: with Linux making more and more inroads into the enterprise, things like JMX become increasingly important. How would you go about hooking a GCJ-compiled application into a JMX container? My guess it would be difficult at beast, if not completely impossible. That's just one of many examples. In summary, I don't think many of the pro-CNI people really use Java to its fullest extent. I certainly want all the 1.5 features =5Fand=5F Java-GNOME. If Java-GNOME went CNI-only I myself would probably go back to Swing. Regards Elias M=C3=A5rtenson |
|
From: Alessandro P. <al...@ni...> - 2004-03-11 23:32:58
|
I'm not a contributor too, but I'm a (quite experienced) java developer. I just want to subscribe everything Elias wrote on this mail, I completely agree. Thanks, Alex On Thu, 2004-03-11 at 20:04, Elias Martenson wrote: > tor 2004-03-11 klockan 18.44 skrev Mark Howard: > > Dear Java Developers, > >=20 > > I am writing to you on behalf of the java-gnome project for advice > > regarding a major change we are currently considering. I apologise if > > this is off topic for this mailing list but we really need input and = you > > are the most knowledgeable open source java developers; it may also > > help determine whether we will be using your projects in the future. > > Sorry for cross posting - we think members of each list are likely to > > have different opinions on this topic and want to hear them all. > >=20 > > The big question is: should we switch to CNI? >=20 > I'm not a contributor (yet?), and I'm currently merely playing around > with Java-GNOME. However, I like it very much. > I am what could be considered an expert Java programmer. This is, > however, not the place to publish ones resum=E9. I do have 7 years of J= ava > development experience. >=20 > Reading peoples suggestions calling for CNI makes me very frightened. > I'll try to explain why: >=20 > In the current environment, Sun controls Java. I am not going to go int= o > whether this is good or not, but this is the way it is. Sun releases a > new version of java every 18 months or so, and every time they do there > are huge improvements. With 1.4 we got the IO channels, giving us > multiplexed IO and memory mapped files. 1.5 gives us the largest set of > improvements to Java we have ever seen, including generics, covariant > return types, shared VM's, etc... GCJ and CLASSPATH has to play the > catchup game all the time, and I don't think I can even use the 1.4 IO > channels in it yet. >=20 > Even if you don't use the new features yourself, what are you going to > do if your JDBC driver uses some new features? Don't forget that one of > the great strengths of Java is it's great open source community where > you can find pretty much every component you'd ever want freely > downloadable. Going CNI-only would severely limit the number of 3'rd > party component you'd be able to integrate. >=20 > The fact that Java is heavily dynamic (sandboxed execution, etc...) is > an enormous advantage, and I fail to see how an experienced Java > developer who uses these things could ever even consider turning the > back on everything that is Java, just to gain a little perceived > performance. >=20 > Speaking of performance advantage, has anyone even done any benchmarkin= g > to decide how much of a performance difference we're talking about here= ? >=20 > Since Java is dynamic, I can, at runtime, detect whether Java-GNOME is > available, and select a Java-GNOME or a Swing-based user interface at > runtime. This makes it possible to ship an app that is both native > GNOME, and completely cross-platform (naturally, the practicality of > this depends heavily on the type of application). This app can still us= e > the same features available to all application running on the Java > platform. >=20 > Another thing: with Linux making more and more inroads into the > enterprise, things like JMX become increasingly important. How would yo= u > go about hooking a GCJ-compiled application into a JMX container? My > guess it would be difficult at beast, if not completely impossible. > That's just one of many examples. >=20 > In summary, I don't think many of the pro-CNI people really use Java to > its fullest extent. I certainly want all the 1.5 features _and_ > Java-GNOME. If Java-GNOME went CNI-only I myself would probably go back > to Swing. >=20 > Regards >=20 > Elias M=E5rtenson >=20 >=20 |
|
From: Zenaan H. <ze...@fr...> - 2004-03-11 22:32:42
|
On Fri, 2004-03-12 at 04:44, Mark Howard wrote: > The big question is: should we switch to CNI? My experience is running through some of the java-gnome tutorials, using gcj to compile 'native executables'. I just used whatever defaults were there, and from what you say below it is currently jni. I could go so far. I had a bit of an issue when trying to use xercesj - I think I might have needed to unroll the jar files or something, and I switched to .class file production, rather than native compilation, and things woked again. I could go back to native when I switched back to jdom. If going to cni will make things work more flawlessly/ seamlessly, that would be a great step I'd say, from a learning something new (and the newbie) perspective. And from reading the gcj info docs on CNI (both a year or two ago, and a couple of months ago again) had me drooling. Essentially the promise is seamless integration with C++ (and I guess 'hence C'). So, +1 for CNI from me, albeit a limited experience perspective. > JVM support > JNI supports most JVMs. The library has to be compiled with two > compilers (gcc + "javac"), which is tricky > CNI requires everything to be compiled with GCJ, including applications. > This means that some features found only in sun's latest jvm will not be > available (in particular, classpath is quite outdated) This doesn't bother me personally. If something is important enough, I'm happy to start hacking on classpath to achieve what I need. > Performance > JNI runs slower (although it is probably fast enough for basic gui's, > IMHO. But not e.g. complex TreeModelFilters) Another +1 for CNI. > Size > JNI produces large bindings Not an issue for me. I guess it would be for embedded dev's. > Ease of development > JNI is harder to develop I would vote for the more seamless option, from a newbies point of view. At the end of the day, I want the least build chain hassle as possible. Those developing for Windows might have other priorities though I guess... > Entry barrier/learning curve > -compilation > Most users have to compile java-gnome. This requires both gcc and javac. > For applications, it requires javac. Java developers are used to javac. > -use > Eclipse, debuggers, other java tools > Java developers know (and like?) these. open source ones are probably > better once people get to know them. > eclipe use (+debug/profile) may still be possible with the cdt plugin > for eclipse. I've been a full time Java developer (more recently, I have to say "sort of") since pre-Java-1.0 and Windows 95 - some 8 years ago. Over those first couple of years, I got my first real taste of proprietary software lockin, with respect to the garbage collector, and trying to debug the software I was part of developing at the time: I could see so clearly that if I'd had source code, I could have written a GUI object count list for the GC (each .new, add one to the count of that class) - and then could have added in-memory hierarchy navigation, etc. This was not an option given Java's (GC) binary status. We had the option to spend thousands per developer seat to get source code, or make do. Due to the financial situation of the company, we had to make do. To this day I have been pissed at SUN. I realise it was of course my choice to use 'cool' propritatary product (Java running in Netscape/ IE) that produced those frustrations. So now I am a little more informed, and damned if I have to use proprietary products again. I want *Free Software* thank you very much! I want *control* over the source code - the ability to instrument, modify, etc. and to have others be allowed to do that so we can actually work together (my gosh, what a concept!). So, my vote is for gcj/cni. > Combined CNI & JNI approach (possibly generating code) > Added complexity for us and our build process. > Worst of both worlds? > Would not be possible to optimise for either cni or jni. > Please see java-gnome ml archives for details - then suggest something > else if you have an idea of another way to do this. One thing I think would be great to see, at least on Debian, is a distro-wide consistent built/ deployment model for Java - where everything is Free Software and everything is compiled in the same way - and for performance reasons I'd like that to be CNI. > Java-Gnome developers are currently unsure about what to do. We like the > idea of cni but it sounds risky. That's why we're asking for your input. > Thank you in advance for taking the time to read this and hopefully > responding. Perhaps you can put up a sign "Free Software Bigots Welcome". There's plenty out there... cheers zenaan |
|
From: Anthony G. <gr...@re...> - 2004-03-11 23:05:03
|
On Thu, 2004-03-11 at 09:44, Mark Howard wrote: > The big question is: should we switch to CNI? As much as I like CNI, and want to promote gcj usage, and to the extent that supporting both CNI and JNI is not an option, then I believe that java-gnome should stick with JNI. I don't believe there are immediate technical reasons for preferring JNI over CNI, however, I feel that the case for making java-gnome available to the largest possible community of developers is very compelling. History backs this up. Look at Gnome-GCJ (CNI bindings) -vs- java-gnome (JNI bindings). While the Gnome-GCJ technology was really cool, I think the limited audience for this package was instrumental in it's lagging behind java-gnome. For developers who are just learning about CNI and are excited about programming with it, you will still be able to write application code with CNI. CNI and JNI _do_ mix. AG -- Anthony Green <gr...@re...> Red Hat, Inc. |
|
From: Per B. <pe...@bo...> - 2004-03-11 23:42:39
|
I think it is a good idea to keep JNI support, but provide
CNI using a hybrid approach.
For example we can replace:
JNIEXPORT void JNICALL Java_org_gnu_gnomevte_Terminal_vte_1terminal_1feed
(JNIEnv *env, jclass klass, jint handle, jbyteArray data, jint length){
BODY
}
by:
NATIVE_METHOD(org.gnu.gnomevte.Terminal,
void vte_terminal_feed (jclass klass, jint handle,
jbyteArray data, jint length))
{
BODY
}
or (more editor-friendly):
NATIVE_METHOD(org.gnu.gnomevte.Terminal) void
vte_terminal_feed (jclass klass, jint handle,
jbyteArray data, jint length)
{
}
then a pre-processor can generate the JNI or CNI headers.
Note this would have to be an intelligent pre-processor, that
goes beyond cpp, since it needs to "mangle" method names etc.
The generated CNI code might be:
void
org::gnu::gnomevt::Terminal::vte_terminal_feed
(jclass klass, jint handle, jbyteArray data, jint length)
{
JNIEnv *env
= _Jv_GetJNIEnvNewFrame(&org::gnu::gnomevte::Terminal::class$);
BODY
}
The preprocessor only needs to call _Jv_GetJNIEnvNewFrame if the
env parameter is used, of course.
This initial step still uses JNI for the method bodies, but
it is still a performance improvement (since we don't need the
Java-to-JNI trampoline), and simplifies usage compare to true JNI,
since the native code can be linked in the same library as the
Java code. Performance-critical methods can contain #ifdef CNI
sections. We can also incrementally improve the preprocessor wit
extra functionality. For example many of the JNI callback functions
are just wrappers for CNI functions, so a simple conversion can
convert those, possibly removing the need for the JNIEnv
variable.
--
--Per Bothner
pe...@bo... http://per.bothner.com/
|
|
From: Etienne G. <gag...@uq...> - 2004-03-13 18:01:56
|
Per Bothner wrote: > ... > then a pre-processor can generate the JNI or CNI headers. > ... My main worry is that the programmers using these macros might not take the good approach to JNI programming (which consists of "caching" method and field ID's) if some macro hides method/field accesses. Also, from a readability point of view, any Java programmer that uses JNI regularly will not recognize JNI code [but this is not really critical ;-)]. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Tom T. <tr...@re...> - 2004-03-12 02:38:54
|
>>>>> "Elias" == Elias Martenson <el...@al...> writes: Elias> Going CNI-only would severely limit the number of 3'rd Elias> party component you'd be able to integrate. You can mix and match CNI and JNI in a single process. This happens any time you use JNI in libgcj. Maybe you meant to say that going CNI only would mean that you couldn't use java-gnome on non-libgcj runtimes, which is true. Elias> The fact that Java is heavily dynamic (sandboxed execution, etc...) is Elias> an enormous advantage, and I fail to see how an experienced Java Elias> developer who uses these things could ever even consider turning the Elias> back on everything that is Java, just to gain a little perceived Elias> performance. This is a common misconception of what gcj is all about. It's true that the AOT compiler is the centerpiece of the gcj approach. And it is also true that historically this meant less than perfect compatibility with the Java specification. However, it has always been our plan to provide a complete, compatible Java system. This year we are making great strides in this area. In particular the new binary compatibility ABI will let us erase the few remaining semantic differences; in essence gcj will look like a sort of caching JIT more than a pure AOT compiler. Second, for me at least, the primary consideration isn't the features, the performance, or any facet of the implementation (including even AOT compilation if it comes to that). The primary thing is freedom. Based on what you say, it sounds like we have different priorities here. Tom |
|
From: Elias M. <el...@al...> - 2004-03-12 09:49:51
|
fre 2004-03-12 klockan 03.07 skrev Tom Tromey: > >>>>> "Elias" =3D=3D Elias Martenson <el...@al...> writes: >=20 > Elias> Going CNI-only would severely limit the number of 3'rd > Elias> party component you'd be able to integrate. >=20 > You can mix and match CNI and JNI in a single process. This happens > any time you use JNI in libgcj. Maybe you meant to say that going CNI > only would mean that you couldn't use java-gnome on non-libgcj > runtimes, which is true. You misunderstood what I said. You seem to believe that I'm putting down the efforts of the GCJ project. What I meant was that if I have a 3'rd party component, say a high-performance JDBC driver, which happens to use JDK 1.4 IO channels, JDBC 3.0 rowsets and JDK 1.5 code instrumentation, I want to be able to use it with Java-GNOME. If GCJ was a requirement for Java-GNOME, then I would have to wait until you guys support JDK 1.5. Considering the fact you aren't even up to 1.4 level yet, I think I'd have to wait a long time. I'm not dissing the GCJ efforts at all. GCJ has some advantages and some disadvantages. Whether you should use it depends on the circumstances. In particular, current PDA's need it, as has been proven on this mailing list. > Elias> The fact that Java is heavily dynamic (sandboxed execution, etc...= ) is > Elias> an enormous advantage, and I fail to see how an experienced Java > Elias> developer who uses these things could ever even consider turning t= he > Elias> back on everything that is Java, just to gain a little perceived > Elias> performance. >=20 > This is a common misconception of what gcj is all about. >=20 > It's true that the AOT compiler is the centerpiece of the gcj > approach. And it is also true that historically this meant less than > perfect compatibility with the Java specification. To be fair, I'm quite amazed at the results you have achieved so far. The goal should always be to reach 100% compatibility, which is extra hard when one has to play catchup all the time. Are you involved in the JCP at all? > However, it has always been our plan to provide a complete, compatible > Java system. This year we are making great strides in this area. In > particular the new binary compatibility ABI will let us erase the few > remaining semantic differences; in essence gcj will look like a sort > of caching JIT more than a pure AOT compiler. I'm aware of this. However, the discussion is not really about AOT vs. VM execution. It's not even about GCJ vs. JDK. It's abut CNI vs. JNI. GCJ does JNI and CNI. Other platforms do JNI only. Based on this the choice should be pretty clear, don't you think? > Second, for me at least, the primary consideration isn't the features, > the performance, or any facet of the implementation (including even > AOT compilation if it comes to that). The primary thing is freedom. > Based on what you say, it sounds like we have different priorities > here. Not at all. Unless we define freedom differently. :-) My focus is "freedom of choice". I want to be able to choose the Sun JVM, at least at the current point in time. Other people (esp. the PDA people) wants to choose GCJ. Regards Elias M=C3=A5rtenson |
|
From: Momchil V. <ve...@fa...> - 2004-03-12 10:02:07
|
>>>>> "Elias" == Elias Martenson <el...@al...> writes: Elias> fre 2004-03-12 klockan 03.07 skrev Tom Tromey: >> Second, for me at least, the primary consideration isn't the features, >> the performance, or any facet of the implementation (including even >> AOT compilation if it comes to that). The primary thing is freedom. >> Based on what you say, it sounds like we have different priorities >> here. Elias> Not at all. Unless we define freedom differently. :-) My focus is Elias> "freedom of choice". I want to be able to choose the Sun JVM, at least Elias> at the current point in time. Other people (esp. the PDA people) wants Elias> to choose GCJ. How about asking Sun to support CNI then ? Because it's they who limit your "freedoom of choice", by supporting only one (the technically inferior, AIUI) interface. ~velco |
|
From: Cedric B. <ce...@be...> - 2004-03-13 06:56:03
|
Momchil Velikov wrote: > How about asking Sun to support CNI then ? > >Because it's they who >limit your "freedoom of choice", by supporting only one (the >technically inferior, AIUI) interface. > > Bleah They technically cannot support it. CNI doesn't work with precise copying collectors, AFAIK. Cedric |
|
From: Etienne G. <gag...@uq...> - 2004-03-13 16:38:38
|
Momchil Velikov wrote: > How about asking Sun to support CNI then ? Because it's they who > limit your "freedoom of choice", by supporting only one (the > technically inferior, AIUI) interface. Who says that JNI is technically inferior than CNI technically? As a JVM specialist, I can say that it is not clearcut. JNI is by far the most flexible of the two *binary* interfaces, giving much more freedom to the JVM implementer. It is far from easy (if it is at all possible) to get CNI to support things like precise moving garbage collectors (such as copying/compacting collectors), or allowing for non-traditional object layouts (bidirectional, split objects, etc.). In fact, CNI imposes a deep dependency between a JVM and a CNI library. For example, if a CNI implementation was adapted to support a bidirectional object layout, then a compiled CNI library would only work with JVMs that implement this bidirectional object layout. JNI, on the other hand, allows a compiled JNI library to work with any JVM, regardless of the internal JVM organization (object layout, GC, etc). JNI is preperly a "binary interface" between a library and a JVM. CNI, on the pther hand, is a mix of a binary interface, and a C++ level programming interface that requires specific compiler support. Depending on your needs, you can argue that each of JNI and CNI is technically superior. As for the initial question of this thread: > The big question is: should we switch to CNI? Unless the java-gnome project wants to restrict java-gnome to work with gcj/gij, or wants to provide CNI implementations for other JVMs [;-)] and is willing to provide several binary packages for each platform (one per JVM that supports a different CNI implementation), I recommend that they use the JNI binary interface for their library, for maximum compatibility with Free (and non-free, if they care) JVMs. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Thomas A. <ae...@gr...> - 2004-03-13 17:07:35
|
On Fri, 2004-03-12 at 03:07, Tom Tromey wrote: [just jumping in] > The primary thing is freedom. > Based on what you say, it sounds like we have different priorities > here. This is one of the core questions: Is some library that will only work with one single Java-lookalike-but-GPL'd runtime environment more free than a library which does work together with pretty every JVM around including free and non-free VMs? It's a question of what your notion of "free" actually is ... Best regards, Tom ---------------------------------------------------------------------------- Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26 4180040 Internet: ae...@gr... PGP public key available ---------------------------------------------------------------------------- The more laws and order are made prominent, the more thieves and robbers there will be. -- Lao Tsu |
|
From: Thomas A. <ae...@gr...> - 2004-03-13 17:48:15
|
On Thu, 2004-03-11 at 18:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
Actually you already know the answer. Will you rename the "java-gnome"
project to "gcj-gnome"? If not, stay with JNI, if yes, do this step
with all consequences - you are talking about a library, then, which
will not be available to generic Java programs/developers. One will
then have to decide
1) do I write a platform-independent Java program obeying Java
standards and do not use gcj-gnome
or
2) do I write a GCC-program in Java language and make use of
gcj-gnome
(note the difference in writing a Java program and writing a program
in Java language)
From my point of view 2) is a silly decision, anyway - if you give up
the advantages of the Java environment in the design phase of a software
project you are better off with using C++ (or whatever else), anyway.
Why would one prefer Java - maybe because there are plenty of 3rd-party
class libraries around, the code is platform-independent (somehow :-)),
there are plenty of development tools around, because of its dynamic
class loading, because of all this J2EE stuff around, etc. ... So if you
know from the start of your project that you won't be able to make use
of all this stuff (since most of it won't run with gcj, anyway) why
would you choose Java at all? Certainly not because of its syntax, I
assume, and certainly not because of Gnome, since building Gnome apps
does certainly never require you to use Java.
My personal motivation for using Java and GCJ is that my software
actually runs natively compiled with gcj as well as with pretty every
bytecode JVM. In order to achieve this I had to avoid many available
3rd-party libraries (like e.g. JNDI), had to put much effort in solving
issues with others (e.g. find out that the MySQL and PostgreSQL JDBC
stuff still works even when you omit the few classes GCJ won't compile).
I certainly - in search for liberty and freedom to use the environment
that works best for me - won't ever choose to use a library that nails
my app to one single available Java environment, especially if this one
single Java environment is far to offer complete Java support and hence
must be considered a risk factor from the start.
So ask yourself the question for who you actually build java-gnome
(or gcj-gnome) and if you really want to make such efforts for a few
people if you can actually reach maybe 50 times more people with little
more effort.
You already answered this question:
> Alternative java guis - we want people to choose java-gnome:
Unless your name's Microsoft(TM) you should not expect you can
successfully promote people using a library which is incompatible
with everything than one single development/runtime approach out
of a hundred others they might want to choose.
Best regards,
Tom
----------------------------------------------------------------------------
Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
4180040
Internet: ae...@gr... PGP public key
available
----------------------------------------------------------------------------
The more laws and order are made prominent, the more thieves and
robbers there will be.
-- Lao Tsu
|
|
From: Momchil V. <ve...@fa...> - 2004-03-13 19:33:18
|
>>>>> "Thomas" == Thomas Aeby <ae...@gr...> writes:
Thomas> On Thu, 2004-03-11 at 18:44, Mark Howard wrote:
>> The big question is: should we switch to CNI?
Thomas> Actually you already know the answer. Will you rename the
Thomas> "java-gnome" project to "gcj-gnome"? If not, stay with
Thomas> JNI, if yes, do this step with all consequences - you are
Thomas> talking about a library, then, which will not be available
Thomas> to generic Java programs/developers. One will then have to
Thomas> decide
Thomas> 1) do I write a platform-independent Java program
Thomas> obeying Java standards and do not use gcj-gnome
Thomas> or
Thomas> 2) do I write a GCC-program in Java language and make
Thomas> use of gcj-gnome
Bullshit, sorry. The choice is already made -- to write a GNOME
program. It is unlikely an environement, which has GNOME to not have
gcj.
Thomas> (note the difference in writing a Java program and writing
Thomas> a program in Java language)
And you note the differencees between:
a) a Java program and a GNOME program written in the Java language.
b) a Java/GNOME API and its implementation.
Nothing precludes you from using an alternative implementation of
the Java GNOME binding.
|
|
From: Thomas A. <ae...@gr...> - 2004-03-13 20:00:21
|
On Sat, 2004-03-13 at 20:33, Momchil Velikov wrote: > Bullshit, sorry. Thanks for your politeness. I don't think that anything coming after such a sentence is worth discussing. Best regards, Tom ---------------------------------------------------------------------------- Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26 4180040 Internet: ae...@gr... PGP public key available ---------------------------------------------------------------------------- Neurotic (n.) : One who builds castles in the air. Psychotic (n.) : One who lives in them. Psychiatrist (n.) : The one who collects the rent. |
×
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