Title: RE: JNI/CNI Revisited
Aaron M. Renn wrote:
[...]
> Needed for java.io (except File)
>
> void nativeInit(); // For any required initialization
>
> void nativeSync(long fd) throws SyncFailedException
I really don't like this model, because i
Hi (CC classpath mailinglist),
On Thu, 2003-02-27 at 17:25, Tom Tromey wrote:
> > "Michael" == Michael Koch <[EMAIL PROTECTED]> writes:
>
> Michael> java.net.DatagramSocketImpl.getOption()
> Michael> java.net.DatagramSocketImpl.setOption()
> Michael> java.net.SocketImpl.getOption()
> Michael>
Per Bothner wrote:
I'm assuming here that the VM guarantees that only one Method object
will ever be created for each declared method in a class.
Why are you assuming this? It is possible the VM internal
data structures are unrelated to java.lang.reflect.Method,
and so it may make sense to create
Hi,
On Fri, 2003-02-28 at 21:58, Archie Cobbs wrote:
> I'm assuming here that the VM guarantees that only one Method object
> will ever be created for each declared method in a class.
I used to think that this would be the optimal thing todo for a VM. But
in reality each Method object returned sh
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
> As a consequence some of the reflect classes have to
> be carefully
> examined to make sure that they do not make the
> assumption that equals
> means same reference. (Note that in contrast each
> Class object should
> have the property they are uniq
Hi,
On Sat, 2003-03-01 at 17:05, Dalibor Topic wrote:
> > (Note that in contrast each
> > Class object should
> > have the property they are unique.)
>
> Unique in the context of the class loader, or unique
> for all class loaders? I think they have to be unique
> in the context of their class lo
Hi,
On Fri, 2003-02-28 at 06:26, Archie Cobbs wrote:
> Below is a subset of my current set of diffs for java.lang.Class.
> I'm sending them just for anyone to look at and for consideration
> for checking in. I think some of them could be useful for classpath.
> I'd be interested to hear what other
Hi,
On Sat, 2003-03-01 at 18:24, Tom Tromey wrote:
> > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>
> Mark> I vote that we add the Miranda methods explicitly to the
> Mark> abstract classes in Classpath that need them.
>
> Don't we only need this to work around gcj bugs? Maybe this
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> I vote that we add the Miranda methods explicitly to the
Mark> abstract classes in Classpath that need them.
Don't we only need this to work around gcj bugs? Maybe this should
only happen in the gcj tree.
In either case, let's mark
> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:
Jeroen> I really don't like this model, because it forces the VM into
Jeroen> using a long for the file descriptor. IMHO a better
Jeroen> alternative would be to have instance methods in
Jeroen> java.io.FileDescriptor that call a static
Hi,
On Wed, 2003-02-26 at 01:25, Archie Cobbs wrote:
> [ warning, random thoughts below... ]
>
> I've been working on a new JVM and trying to figure out how
> modify the "vm/reference" classpath classes into something that
> this JVM particular can support.
Fun! Do you have specific needs that n
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 2003-03-01 at 18:24, Tom Tromey wrote:
> > > "Mark" == Mark Wielaard <[EMAIL PROTECTED]>
> writes:
> >
> > Mark> I vote that we add the Miranda methods
> explicitly to the
> > Mark> abstract classes in Classpath that need
> them.
Tom Tromey ([EMAIL PROTECTED]) wrote:
> Aaron> Looking at native methods used to implement FileDescriptor,
> Aaron> FileInputStream, FileOutputStream, and RandomAccessFile (as
> Aaron> well as a quick glance at FileChannel in NIO), I pulled
> Aaron> together a quick list of potential methods as a s
Mark Wielaard <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Fri, 2003-02-28 at 06:26, Archie Cobbs wrote:
> > Below is a subset of my current set of diffs for java.lang.Class.
> > I'm sending them just for anyone to look at and for consideration
> > for checking in. I think some of them could be usefu
Hi,
On Wed, 2003-02-26 at 10:14, Jeroen Frijters wrote:
> I'm a VM implementer too and I have a few comments. One general point
> is that the current GNU Classpath version is 0.05, this suggests that
> it isn't mature yet so I think VM implementers should expect that the
> VM interface isn't yet s
Jeroen Frijters ([EMAIL PROTECTED]) wrote:
> > void nativeSync(long fd) throws SyncFailedException
>
> I really don't like this model, because it forces the VM into using a
> long for the file descriptor. IMHO a better alternative would be to have
> instance methods in java.io.FileDescriptor tha
Hi,
On Sat, 2003-03-01 at 19:01, Brian Jones wrote:
> Mark Wielaard <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-02-28 at 06:26, Archie Cobbs wrote:
> > > Below is a subset of my current set of diffs for java.lang.Class.
> > > I'm sending them just for anyone to look at and for consideration
> >
Hi,
On Fri, 2003-02-28 at 00:57, Brian Jones wrote:
> Some degree of control needs to be exercised over the reference
> interface or nothing would ever work with Classpath CVS and JVM
> implementors might not enjoy tracking a rapidly moving target.
Yeah. We need some guidelines on how to introduc
Hi,
On Fri, 2003-02-28 at 01:50, Tom Tromey wrote:
> > "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
> Aaron> o Figure out the JNI/CNI situation and merge the native
> Aaron> backends with gcj.
>
> I don't think we should let this hold up Classpath 1.0. libgcj will
> probably continue
Hi,
On Fri, 2003-02-28 at 03:46, Tom Tromey wrote:
> > "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
>
> Brian> Windows POSIX API has both 'int' and 'long' versions of the
> Brian> file I/O functions or I should say 32bit vs 64bit.
>
> I think we were just talking about the file descrip
Hi,
On Fri, 2003-02-28 at 04:17, Stephen Crawley wrote:
> Speaking as the most active Kissme maintainer, and the one on whose
> shoulders the work will fall, I'm wary of changes to the reference
> classes and the native APIs they use. It represents short term /
> high priority work ... and I'd p
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
> "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
> "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
> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
Aaron> Right now Classpath just hardcodes these as FD 0, 1, and 2.
Aaron> Probably not a good idea. The nativeInit() method was one I
Aaron> envisioned being called as part of static initialization a la
Aaron> gcj, and thus it could set up
> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
Jeroen> This allows VMs (such as mine) that don't use an integer as a
Jeroen> file handle, to replace FileDescriptor with a different
Jeroen> implementation, but leave all other i/o classes as is.
Aaron> Can you explain this further? I'm
Aaron> Right now Classpath just hardcodes these as FD 0, 1, and 2.
Aaron> Probably not a good idea. The nativeInit() method was one I
Aaron> envisioned being called as part of static initialization a la
Aaron> gcj, and thus it could set up these values.
Tom> For some reason I assumed your `native
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
Brian> You could do it now, for it is CVS after all... or you could
Brian> wait till GCC 3.3 is released...
Ok. I think I'll wait for the official 3.3 release. If anybody
really wants to see the patch, just ask and I will mail it to you.
Mark Wielaard <[EMAIL PROTECTED]> writes:
> Brian is doing a good job here making sure that we have a new
> release every couple of months (Thansk Brian!).
Hmm... that's the new plan! Release early, release often... etc.
> BTW. I don't know if anybody uses Japhar anymore. If so, what version of
I just looked at a couple of classes (java.net.URI
and java.awt.GridBagLayout) and noticed lots of
unimplemented methods just do nothing or return null.
This has to stop. If an method does not do what it
is supposed to do, then it must throw an exception.
I'll make an exception for a method where
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> I just looked at a couple of classes (java.net.URI
Per> and java.awt.GridBagLayout) and noticed lots of
Per> unimplemented methods just do nothing or return null.
Per> This has to stop. If an method does not do what it
Per> is supposed
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> That sounds fine. I'd suggest bringing the issue up on the Classpath
Tom> list; we could add this to the Classpath hacking guide.
And, duh, you did and I didn't see the CC.
Sorry about that.
Brian, I took a quick look at the hacking gui
A possible refinement:
throw new UnsupportedOperationException ("not implemented");
This makes it clear that it's an unimplemented feature,
rather than the usual collections invalid call.
The string "not implemented" also makes it easy for
our tools to search for, so we can generate more useful s
Per Bothner ([EMAIL PROTECTED]) wrote:
> I just looked at a couple of classes (java.net.URI
> and java.awt.GridBagLayout) and noticed lots of
> unimplemented methods just do nothing or return null.
>
> This has to stop. If an method does not do what it
> is supposed to do, then it must throw an e
> "John" == John Leuner <[EMAIL PROTECTED]> writes:
John> It would be nice if someone could write a TODO for the AWT and
John> GTK peers code.
Here's my list:
* Some Java code is missing. See classpath/1.4 comparison page.
GridBagLayout is the big one.
* Make sure the tree lock is proper
Tom Tromey <[EMAIL PROTECTED]> writes:
> > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Tom> That sounds fine. I'd suggest bringing the issue up on the Classpath
> Tom> list; we could add this to the Classpath hacking guide.
>
> And, duh, you did and I didn't see the CC.
> Sorry abou
36 matches
Mail list logo
