> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
[ DataOutputStream ]
Aaron> Those shared methods can die, IMO. They don't do much. The
Aaron> allocation is an interesting point. Classpath does it to avoid
Aaron> doing what gcj does: namely do tons of single byte writes.
Aaron> This w
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>> http://gcc.gnu.org/java/libgcj-classpath-compare.html
Mark> BTW Tom, when are you going to enable the automatic updater of that
Mark> page? It is already a bit out of sync with reality again.
I'll try to do it soon. I wanted to get th
Hi,
On Thu, 2003-02-27 at 04:19, Aaron M. Renn wrote:
> Hi. I've been looking at the Classpath / GCJ merge status here:
>
> http://gcc.gnu.org/java/libgcj-classpath-compare.html
BTW Tom, when are you going to enable the automatic updater of that
page? It is already a bit out of sync with realit
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
Brian> Between gcj and classpath there is a difference of opinion on
Brian> whether to drop into native code (CNI) at every opportunity or
Brian> not and I think it has affected the way some things are
Brian> handled.
There don't seem to be
Brian Jones wrote:
I'd like to see our I/O implementation handle 64-bit filesystems and
all the native libs be 64-bit compatible (i.e. no assuming pointers
are ints, file handles are ints, etc.).
GCJ uses the "magic" class type gnu.gcj.RawData as essentially
a non-GC'd 'void *' pointer. This may n
Brian Jones wrote:
I have noticed that for a good deal of CNI code it is quite straight
forward to turn it into C or C++ based JNI instead. There was a Perl
script that someone purported to do some of this a while ago. I'm
tempted to play with it a bit.
That would be great, but surprising. I wou
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> One problem is that it is not just the native methods that are different.
> I think it would be relatively easy to write a CNI and a JNI version of
> the code as there is not a huge amount of native code to write for
> IO and networking. The problem i
Tom Tromey <[EMAIL PROTECTED]> writes:
> > "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
>
> Aaron> For #1, I have no idea what has been decided regarding native code.
> Aaron> Last I checked, we still had a JNI/CNI deadlock going on.
>
> I'm resigned to the fact that we'll need dual i
Tom Tromey ([EMAIL PROTECTED]) wrote:
> Aaron> For #1, I have no idea what has been decided regarding native code.
> Aaron> Last I checked, we still had a JNI/CNI deadlock going on.
>
> I'm resigned to the fact that we'll need dual implementations of
> certain native code. The Gtk AWT peers I imp
> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
Aaron> For #1, I have no idea what has been decided regarding native code.
Aaron> Last I checked, we still had a JNI/CNI deadlock going on.
I'm resigned to the fact that we'll need dual implementations of
certain native code. The Gtk AWT
Hi. I've been looking at the Classpath / GCJ merge status here:
http://gcc.gnu.org/java/libgcj-classpath-compare.html
specifically, java.io. Of the un-merged classes, I group them as follows:
1. Classes Doing Native I/O
---
FileDescriptor
File
FileInputStream
FileOutput
11 matches
Mail list logo
