Hello Classpath-Developers,
at aicas GmbH (http://www.aicas.com), we are developing a Java Virtual
Machine, JamaicaVM, that comes with its own (clean room) implementation of
the standard classes. Since this is redundant work (and, as I understand it,
exactely the reason why the GNU Classpath pr
On Thursday 24 October 2002 02:53, Brian Jones wrote:
> Andy Walter <[EMAIL PROTECTED]> writes:
> We're rather free with the CVS access.
Fine.
> We haven't spent a great deal of time optimizing the library for speed
> or memory usage.
No problem. It is, of course,
Hi Chris,
On Thursday 24 October 2002 09:01, Chris Gray wrote:
> On Wed, 23 Oct 2002, Andy Walter wrote:
> > * One thing that shouldn't be unmentioned: Unlike the rest of our current
> > standard classes, the AWT implementation is not completely written by
> > oursel
Hi Mark,
On Thursday 24 October 2002 18:03, Mark Wielaard wrote:
> On Wed, 2002-10-23 at 18:21, Andy Walter wrote:
> > [...] we are very interested in joining your project.
>
> That would be very nice!
I'm glad to see that we are welcome here.
> For license questions y
On Saturday 26 October 2002 06:22, Brian Jones wrote:
> Hey, I guess this answers that nagging question I had about how a JVM
> is supposed to deal with native code memory allocation being somewhat
> outside of the garbage collector arrangement in use...
:-)
Of course, the garbage collector can n
Hi Mark,
On Saturday 26 October 2002 13:26, Mark Wielaard wrote:
>
> We also want to set something like that up for Kissme (or sablevm or
> Orp) and mauve. So that would be a very nice contribution. Then we can
> more easily compare what are VM issues and what are library issues. I
> have already
Hi,
On Sunday 27 October 2002 02:22, Mark Wielaard wrote:
> - java/io/Object*Stream.java. We had these classes merged with libgcj
> but they are diverging again. This is code I don't know much about and
> has some very subtle issues that are easy to get wrong. One thing I like
> about the libgcj v
Hi,
On Monday 28 October 2002 08:52, Jeroen Frijters wrote:
> > To me, avoiding native methods as often as possible is
> > preferable as well.
>
> I agree. I'm not using any JNI in my VM for the Classpath native methods
> (although my VM does support it [but it isn't completely done yet]), for
> o
Hi,
On Thursday 31 October 2002 12:15, Mark Wielaard wrote:
> Has someone actually tried Rudolph with GNU Classpath?
Yes, it is running quite well here. But we replaced many native methods (all
but 5) by Java code. Since Rudolph uses a proprietary interface, this
replacement might be interestin
Hi,
On Thursday 31 October 2002 22:45, Mark Wielaard wrote:
> > [Rudolph + GNU Classpath]
>
> Nice. Do you use any of the non-rudolph java.awt.* packages/classes?
No. Sorry if I got that wrong. We use Classpath, except from AWT and
java.lang, and the modified AWT classes from Rudolph. So far, we
On Tuesday 05 November 2002 00:56, Brian Jones wrote:
> Andy, it does not seem like it will be possible to do a complete merge
> as originally hoped. Even so, it should be possible to work with you
> to include your necessary pieces that provide greater embedded
> functionality.
Yes, of course. S
On Tuesday 05 November 2002 00:01, Mark Wielaard wrote:
> > [Rudolph + GNU Classpath]
>
> I meant did you try any of the awt sub-packages not found in Rudolph?
> e.g. java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.font,
> java.awt.geom, java.awt.im, java.awt.im.spi, java.awt.image.re
Hi Brian,
On Wednesday 06 November 2002 04:48, Brian Jones wrote:
> Someone mentioned they had a method of executing Mauve that would
> appropriately time out and kill the bad VM. I'm guessing some use of
> expect/tcl here. If there is an example I could look at that would be
> great.
We use a
Hi Chris,
On Sunday 10 November 2002 15:57, Chris Gray wrote:
> However it still seems to me that GPL+exception excludes the possibility of
> binary-only distributions, something which we do not wish to exclude.
> Admittedly there seems to be little reason why a systems integrator would
> need to
Hi,
On Sunday 29 June 2003 19:38, Mark Wielaard wrote:
> I will be going to The Libre Software Meeting
> (http://www.libresoftwaremeeting.org/) on Friday July 11th
> and be on LinuxTag on Saterday and Sunday.
> I am meeting Dalibor Topic (of kaffe fame) who will also be on both
> events.
I can be
Hi Sascha,
On Tuesday 08 July 2003 14:54, Sascha Brawer wrote:
> Andy Walter <[EMAIL PROTECTED]> wrote on Tue, 8 Jul 2003 13:09:09 +0200:
> >Saturday, 16:00, booth E40
>
> I'm scheduled to stand at the booth of FSF Europe, but I'll try to find a
> replacement for
On Monday 14 July 2003 18:08, Per Bothner wrote:
> Mark Wielaard wrote:
> > - [NotYetImplementedException]
>
> In the gcj list I suggested UnsupportedOperationException, with a
> refinement:
>
> throw new UnsupportedOperationException (REASON);
> where REASON is a string literal that includes "not
On Tuesday 15 July 2003 15:36, Dalibor Topic wrote:
> >>>- [NotYetImplementedException]
> static String nyi =
> "This method has not yet been implemented in GNU Classpath.\n\n"
> + " The GNU Classpath project would appreciate receiving"
> + " an implementation for it.\n"
>
On Monday 14 July 2003 14:39, Sascha Brawer wrote:
> Mark Wielaard <[EMAIL PROTECTED]> wrote on Mon, 14 Jul 2003 00:46:08 +0200:
> >- Aicas is working on some RMI fixups.
>
> In the context of RMI, maybe not everyone knows that there also exists a
> variant which does RMI over IIOP. It uses the COR
Hi Mark,
On Wednesday 16 July 2003 12:44, Mark Wielaard wrote:
> We don't seem to have real build support for creating JNI header files
> but instead have pre-generated .h files in our include file.
> Why is that? We do seem to detect which javah like program the user has
> installed. On my system
On Thursday 17 July 2003 01:52, Brian Jones wrote:
> "Dr. Torsten Rupp" <[EMAIL PROTECTED]> writes:
> > class-dependencies.conf
>
> Hmm, got any program to contribute that generates these .conf files?
Not yet, sorry. The files read a bit strange in the beginning, but we wanted
to use standard Jav
Hi Brian,
On Friday 26 September 2003 00:43, Brian Jones wrote:
> > [NotYetImplementedException]
>
> Not sure we even need the extra exception type, just finding all the
> spots to throw the UnsupportedOperationException and doing that would
> probably be more than enough.
The motivation is that,
Hi Sascha,
On Friday 26 September 2003 14:38, Sascha Brawer wrote:
> >> > [NotYetImplementedException]
>
> What would you say about defining a special Javadoc tag, such as the
> following?
>
> /**
> * @unimplemented 1.4 Here comes some explanation.
> */
> [class|method|field]
Do you mean additi
Hi Michael,
On Friday 26 September 2003 17:56, Michael Koch wrote:
> I'm for UnsupportedOperationException too because it exists already
> and dont have to invent something new.
>
> A reason against using it is that some methods return UOE by design in
> some situations. That means that i may not
Hi all,
a surprising lot of emails have been sent about that matter. It seems that we
all agree on that throwing *something* would be better than what we have
currently. The attached class is a summary of what as far I understood from
the emails most people here wanted.
Personally, I had prefe
Hi Andrew,
On Monday 29 September 2003 19:40, Andrew Haley wrote:
> Throwing an appropriate message will help, of course, but one of the
> advantages of gcj is that you can pre-link and you know you won't get
> runtime linkage errors -- the linker has resolved everything. Having
> dummy implement
Hi,
I'm sorry for the trouble which was caused by the target layer. Actually, I'm
quite surprised about the massive critique now. When we asked to check it in
more than one year ago, there was very little feedback and the feedback we
got was mainly quite positive.
We are currently preparing th
Hi,
On Saturday 19 March 2005 00:32, Archie Cobbs wrote:
> Who do I ask about building a Debian package for JC?
Are you sure you want to manually create rpm and deb packages? There is some
free software called epm that uses just 1 package description to generate
archives for many Unix systems.
28 matches
Mail list logo