sablevm-developer — SableVM developer mailing list

[Sablevm-developer] Re: Java-Gnome: jni or cni

[Thomas A. <ae...@gr...>]

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

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Thomas A. <ae...@gr...>]

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

Re: [Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Etienne G. <gag...@uq...>]

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/

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Cedric B. <ce...@be...>]

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

[Sablevm-developer] Classpath 0.08 import request

[Grzegorz B. P. <ga...@de...>]

Hi Etienne, hi everybody,

Mark has worked long in the night to put the last fixes together and
test them (apparently we should have GNU CP releases more often as it
apparently mobilizes everyone ;-) Thanks to that and the efforts of
regiments of generous hackers we now have the new, shiny GNU
Classpath 0.08!

It'd be great to have it imported and merged into "staging" rather
sooner than later. SableVM 1.1.1 release should follow shortly,
preferably in no longer than a week. There's been plenty of fixes
from which I personally want to try out the AWT/GTK peers improvements
and the regexp stuff (should help ant quite a lot). See the original
announcement for the complete list.

Cheers,

				Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

Re: [Sablevm-developer] Errno usage considered harmful?!

[Stephen C. <s1...@me...>]

"Grzegorz B. Prokopski" <ga...@de...> writes:

> 1. If I add:
>   #include <errno.h>
>   extern int errno;
> I get such warning:
>   java_lang_ProcessImpl.c:24: warning: function declaration isn't a
> prototype

If you are really concerned about systems whose errno.h doesn't
declare errno, wrap the variable declaration in a !defined(errno)
check.  This is what bash (not to mention GNU errno.h) does.  I
suppose you'd get a warning if you had -Wredundant-decls on and
weren't building with threads, but I don't think you do.

On GNU, when you are using threads, errno expands to a function call
(__errno_location) that returns a pointer, which is then dereferenced.

--
Stephen Compall or s11 or sirian

The best thing about growing older is that it takes such a long time.

bullion Fortezza class struggle lynch Becker spy bootleg Telex Saddam
Hussein wire transfer AMW high security bce Manfurov PGP

RE: [Java-gnome-developer] Re: [Sablevm-developer] Re: [kaffe] Ja va-Gnome: jni or cni

[Jeffrey M. <Jef...@Br...>]

> Mark,
> 
> ch...@ki... said:
> > On Thursday 11 March 2004 18:44, Mark Howard wrote:
> > > The big question is: should we switch to CNI?
> >
> > No.
> 
> I agree with Chris 100%.  [Or perhaps I should say 110% :-)]
> 
> JNI is the standard for portably calling C / C++ from Java.  It works
> well enough for the job.  Implementing CNI instead does your users a
> major disservice by tying them to Java implementations that support
> CNI.   
> 
> Actually, I reckon that the same argument applies to java-gnome in
> general.  Anyone who uses the java-gnome libraries in a GUI-based Java
> application is risking tying that application into GNOME.  By 
> contrast,
> if they use Swing or SWT, they can easily port the 
> application across a
> wide range of supported platforms.

But this is the point of the whole project.  Our goal is to target
gnome and gtk environments.  java-gnome is for writing applications
that target the gnome desktop environment.  As a result, we have
many classes that are designed to provide the developer the type
of integration that they would expect on a platform if they were
using c or c++.

> 
> [There is a counter-argument that says that java-gnome will maximise
> integration with GNOME's look and feel, etc.  My counter to 
> that is that
> this is not the highest priority for most Java projects.  For most,
> immediate portability or avoiding platform/vendor tie-in are 
> equally, if
> not more important.  Otherwise they'd probably be using .NET on a
> Windows machine ;-)]
> 
> I'm assuming, without any evidence, that the java-gnome plans don't
> include backends to graphics libraries other than the 
> gtk/gnome ones. If
> that's wrong, java-gnome is not quite so bad.  However, I still reckon
> it would be risky to use java-gnome (instead of Swing or SWT) 
> in a major
> Java development project.  (For a start, the project would be 
> screwed if
> java-gnome faded away.)  IMO, this really leaves java-gnome 
> as only being 
> useful for minor Java applications for the GNOME platform.  At which 
> point I would ask myself "why bother"?
> 
> I note your issues re JNI vs CNI performance, code size and ease of
> development. I suggest that the first two issues will rarely 
> much to the
> end users of software that uses java-gnome.  The third issue will only
> impact on the tiny group of people who develop and maintain java-gnome
> itself.  Most developers should be working in the pure Java space.
> [Think of it this way ... if Sun had perceived these to be 
> major issues
> for their customers, they would probably have replaced JNI by now!]
> 
> -- Steve
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Momchil V. <ve...@fa...>]

>>>>> "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

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Elias M. <el...@al...>]

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

[Sablevm-developer] Re: [kaffe] Java-Gnome: jni or cni

[Chris G. <ch...@ki...>]

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

Re: [Sablevm-developer] Re: [kaffe] Java-Gnome: jni or cni

[<li...@lo...>]

Hi,

> Anyone who uses the java-gnome libraries in a GUI-based Java
> application is risking tying that application into GNOME.  By contrast,
> if they use Swing or SWT, they can easily port the application across a
> wide range of supported platforms.

Let me point that I can run popular GTK apps such as Gimp or Ethereal outside
Gnome, and even under Windows, MacOS and OS/2. There's no reason I shouldn't be
able to do this with JavaGnome. Just someone has to patch the bindings and
autoconf for these environments. :-)

GTK was born to be portable across different windowing systems and graphics
subsystems. So it should be as portable as Swing and SWT. The differente is on
current implementations, the priorities of each group of developers and who
supports each one (JavaGnome would be far more popular if a big company such as
IBM promoted it on his apps).

I also see a big value on the fact I can learn GTK for Java and use basically
the same Classes and API for Python, Perl or PHP. Swing and SWT won't give
that, and sometimes Java won't the the better tool.

The real portability you get depends on your goals and ability to enginner an
application. For instance, SWT supports OLE Controls. If you use this, your app
will run only under Windows. Eclipse itself uses that, and other native
features, that's the reason you download a plataform-linux and a
plataform-windows (else you would donwnload just swt-linux and swt-windows,
besides a common plataform, just like the commmon jdt). Why couldn't I create
an app that provides a Gnome panel applet module, or a vfs module, and don't
include them (or provide plataform-specific substitutes) for Windows?


> [There is a counter-argument that says that java-gnome will maximise
> integration with GNOME's look and feel, etc.  My counter to that is that
> this is not the highest priority for most Java projects.  For most,
> immediate portability or avoiding platform/vendor tie-in are equally, if
> not more important.  Otherwise they'd probably be using .NET on a
> Windows machine ;-)]

Well, these prioriries may change shorter than expected. Many java apps today
include customized Swing lafs to look more like Windows XP, provide native
Windows installers (installshield and the like), create Windows desktop icons
and Start menu entries, configure file associations on Windows explorer, etc.
When Linux gains a significative market share on the desktop, vendors will want
the same level of "integraton" with the Gnome desktop, and JavaGnome will
becode sudenlly very usefull to them.

Even Sun is doing hard work to make Swing apps more like Windows native ones,
but is failing miserably with the gtk laf. :-( this will change if their
JavaDesltop System gets market share, because it is Gnome based.

There's no real, marketable app which is completely WORA. There are apps on
which you strive to maximize the portable code and minimize the
plataform-dependent code. JavaGnome is valid way to do this, an alternative to
Swing or SWT. And there are apps where you don't mind it runs only on a
specific plataform. Having standard, OSS ways to to that is better than having
just proprietary ones or limiting yourself to the OS systemcalls.


[]s, Fernando Lozano

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Tom T. <tr...@re...>]

>>>>> "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

Re: [Sablevm-developer] Re: [kaffe] Java-Gnome: jni or cni

[Stephen C. <cr...@ds...>]

Mark,

ch...@ki... said:
> On Thursday 11 March 2004 18:44, Mark Howard wrote:
> > The big question is: should we switch to CNI?
>
> No.

I agree with Chris 100%.  [Or perhaps I should say 110% :-)]

JNI is the standard for portably calling C / C++ from Java.  It works
well enough for the job.  Implementing CNI instead does your users a
major disservice by tying them to Java implementations that support
CNI.   

Actually, I reckon that the same argument applies to java-gnome in
general.  Anyone who uses the java-gnome libraries in a GUI-based Java
application is risking tying that application into GNOME.  By contrast,
if they use Swing or SWT, they can easily port the application across a
wide range of supported platforms.

[There is a counter-argument that says that java-gnome will maximise
integration with GNOME's look and feel, etc.  My counter to that is that
this is not the highest priority for most Java projects.  For most,
immediate portability or avoiding platform/vendor tie-in are equally, if
not more important.  Otherwise they'd probably be using .NET on a
Windows machine ;-)]

I'm assuming, without any evidence, that the java-gnome plans don't
include backends to graphics libraries other than the gtk/gnome ones. If
that's wrong, java-gnome is not quite so bad.  However, I still reckon
it would be risky to use java-gnome (instead of Swing or SWT) in a major
Java development project.  (For a start, the project would be screwed if
java-gnome faded away.)  IMO, this really leaves java-gnome as only being 
useful for minor Java applications for the GNOME platform.  At which 
point I would ask myself "why bother"?

I note your issues re JNI vs CNI performance, code size and ease of
development. I suggest that the first two issues will rarely much to the
end users of software that uses java-gnome.  The third issue will only
impact on the tiny group of people who develop and maintain java-gnome
itself.  Most developers should be working in the pure Java space.
[Think of it this way ... if Sun had perceived these to be major issues
for their customers, they would probably have replaced JNI by now!]

-- Steve

Re: [Sablevm-developer] prepare_code.m4.c format request

[Chris P. <chr...@ma...>]

Etienne Gagnon wrote:
> Chris Pickett wrote:
> 
>> I would like to request in advance a format for prepare_code.m4.c that 
>> will minimize changes against the prepare_code.m4.c in my sandbox.
>>
>> I know there are a few ways to do things.  I've been using the 
>> following when only certain portions of a file need be m4'ed.
> 
> 
> Seems quite reasonable to me.  How about documenting this under /doc?

okay, that and a couple of other comments are added to /doc/m4macros.txt 
in my sandbox.

i'll make a tag with all these changes at some point (will take a few weeks)

cheers,
chris

[Sablevm-developer] Re: [kaffe] Java-Gnome: jni or cni

[Per B. <pe...@bo...>]

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/

[Sablevm-developer] Re: [kaffe] Java-Gnome: jni or cni

[Chris G. <ch...@ki...>]

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

[Sablevm-developer] Re: Java-Gnome: jni or cni

[Per B. <pe...@bo...>]

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/

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Alessandro P. <al...@ni...>]

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

[Sablevm-developer] Re: Java-Gnome: jni or cni

[Anthony G. <gr...@re...>]

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.

[Sablevm-developer] Personal - Yes (Re: Java-Gnome: jni or cni)

[Zenaan H. <ze...@fr...>]

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

[Sablevm-developer] Re: [Java-gnome-developer] Java-Gnome: jni or cni

[Elias M. <el...@al...>]

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

Re: [Sablevm-developer] On the 1.1.1 release and further

[David <db...@cs...>]

On Thu, Mar 11, 2004 at 10:04:09AM -0500, Etienne Gagnon wrote:
> Grzegorz B. Prokopski wrote:
> >Another thing is SableJIT release. It's up to David when it happens,
> >but I think we shouldn't wait too long with releasing this code as a
> >_development_ release. We can even do it along 1.1.1, why not? I think
> >that this way David (and we all) could get some bugreports from the
> >users or/and gain confidence that SableJIT is actually usable in
> >the real, wild world ;-) And for some people word "JIT" is magical...
>=20
> I do not want to see SableJIT code under the /sablevm project tree befo=
re
> the interface to the JIT is cleaned up and made into a minimal one,
> instead of the "scattered all over the place" current status [unless I
> am wrong and this has already been fixed].

It is getting smaller and smaller but not minimal yet.

Agree with the SableJIT "add-on".

David

> I really want SableVM's source
> code to remain as clean and easy to read/modify as possible.
>=20
> I see SableJIT as an "add-on".  It's source code should reside mostly
> (i.e. 99,9%) under the /sablejit project tree.  The additional 0.1% sho=
uld
> really be some very minimal changes in very few files (and very few pla=
ces)
> in SableVM's source code.
>=20
> SableVM's inlined engine should remain the default interpreter engine, =
as
> it is by far the most portable engine, and even sometimes the fastest
> engine.  But, I am all in favor of making SableJIT an official add-on t=
hat
> is released along SableVM, and set the build scripts so that a configur=
e
> option would actually generate a SableVM+SableJIT combination (but not =
by
> default).
>=20
> So, in the long term, I do not see the /sablejit tree disappearing.  I =
think
> that SableJIT should remain distributed separately in sablejit-x.y.z.ta=
r.gz
> (where x.y.z matches sablevm's & sablevm-classpath's).
>=20
> Etienne
>=20
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] Java-Gnome: jni or cni

[Mark H. <mh...@de...>]

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

Re: [Sablevm-developer] On the 1.1.1 release and further

[Etienne G. <gag...@uq...>]

Grzegorz B. Prokopski wrote:
> Another thing is SableJIT release. It's up to David when it happens,
> but I think we shouldn't wait too long with releasing this code as a
> _development_ release. We can even do it along 1.1.1, why not? I think
> that this way David (and we all) could get some bugreports from the
> users or/and gain confidence that SableJIT is actually usable in
> the real, wild world ;-) And for some people word "JIT" is magical...

I do not want to see SableJIT code under the /sablevm project tree before
the interface to the JIT is cleaned up and made into a minimal one,
instead of the "scattered all over the place" current status [unless I
am wrong and this has already been fixed].  I really want SableVM's source
code to remain as clean and easy to read/modify as possible.

I see SableJIT as an "add-on".  It's source code should reside mostly
(i.e. 99,9%) under the /sablejit project tree.  The additional 0.1% should
really be some very minimal changes in very few files (and very few places)
in SableVM's source code.

SableVM's inlined engine should remain the default interpreter engine, as
it is by far the most portable engine, and even sometimes the fastest
engine.  But, I am all in favor of making SableJIT an official add-on that
is released along SableVM, and set the build scripts so that a configure
option would actually generate a SableVM+SableJIT combination (but not by
default).

So, in the long term, I do not see the /sablejit tree disappearing.  I think
that SableJIT should remain distributed separately in sablejit-x.y.z.tar.gz
(where x.y.z matches sablevm's & sablevm-classpath's).

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] prepare_code.m4.c format request

[Etienne G. <gag...@uq...>]

Chris Pickett wrote:
> I would like to request in advance a format for prepare_code.m4.c that 
> will minimize changes against the prepare_code.m4.c in my sandbox.
> 
> I know there are a few ways to do things.  I've been using the following 
> when only certain portions of a file need be m4'ed.

Seems quite reasonable to me.  How about documenting this under /doc?

Etienne
-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/