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
> "Thomas" == Thomas Aeby <[EMAIL PROTECTED]> 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,
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,
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 envi
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, fro
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 no
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
> "Elias" == Elias Martenson <[EMAIL PROTECTED]> 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 tha
fre 2004-03-12 klockan 03.07 skrev Tom Tromey:
> > "Elias" == Elias Martenson <[EMAIL PROTECTED]> 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 ha
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 ja
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
Mark,
[EMAIL PROTECTED] 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 jo
> "Elias" == Elias Martenson <[EMAIL PROTECTED]> 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 sa
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
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 ar
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-C
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
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,
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
tor 2004-03-11 klockan 18.44 skrev Mark Howard:
> 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 th
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 als
21 matches
Mail list logo
