Hi all.
I thought I would post a short "heads up" message
to let everyone know about the new Java compiler
regression testing project hosted by the
kind folks at IBM that brought you the Jikes
Java compiler. The Jacks project is a
"sister project" to Jikes, it seeks to provide
a test suite to te
>>> <[EMAIL PROTECTED]> 28-Jun-00 9:42:01 PM >>>
>The Classpath GPL+exception is actually a step backwards
>as far as Kaffe compatibility goes. It is even more liberal than
>the LGPL.
Yes. Licences are the problem which seems silly doesn't it. It's all
done under the aegis of GNU so why not
Stuart Ballard ([EMAIL PROTECTED]) wrote:
> 4) Classpath is multi-VM, Kaffe's libraries are (of course) designed for
> Kaffe only. Classpath doesn't yet have a Kaffe port, although
> periodically people suggest one and it's generally regarded as a good
> idea if someone would actually do it.
I d
Nic Ferrier wrote:
>
> Absoluely! I'm working on an HttpURLConnection that does pipelining,
> I don't know Classpath already has an implementation but if it hasn't
> I would like to donate the same class to both projects.
>
> It seems mad to me to have any duplication of effort within the free
Rizsanyi Zsolt writes:
> this is a fix for the class java.text.Format
>
> The method java.lang.Object parseObject(String) should throw
> ParseException.
> So it should look out like this:
>
> public Object parseObject(String source) throws ParseException{
> ParsePosition pp = new ParsePos
Archie Cobbs wrote:
>
> * The conversion of floats or doubles to strings does not completely
> conform to Sun's spec. For example, Double.toString() will display
> the double 0x400B as "3.3999" instead of "3.4".
>
> If you would like to work on improving this c
>>> <[EMAIL PROTECTED]> 28-Jun-00 8:24:44 PM >>>
>Note: libgcj is under the GPL with an exception clause; it's
>certainly compatible with Kaffe's GPL. As of a few months
>ago, I believe the copyright is held by the FSF.
Absoluely! I'm working on an HttpURLConnection that does pipelining,
I do
Stuart Ballard writes:
> Is the conversion from a float or double to a String in Java supposed to
> be 100% deterministic and give identical results from one implementation
> to another?
Yes... emphasis on "supposed to"..
> I notice that System.out.println(Math.E) gives a slightly different
> r
Is the conversion from a float or double to a String in Java supposed to
be 100% deterministic and give identical results from one implementation
to another?
I notice that System.out.println(Math.E) gives a slightly different
result under Kaffe from JDK1.1, and since Math.E is a compiletime
cons
[warning - long post]
Hi,
I've just finished porting Japize (my public-API-dumper) to use the
Jode.bytecode library, which (a) can make a correct determination about
compiletime constants, and (b) makes it possible to run against classes
from a different java implementation.
I've been testing t
For I don't have cvs access, I'm sending you this fix by mail.
Please somebody incorporate it:
this is a fix for the class java.text.Format
The method java.lang.Object parseObject(String) should throw
ParseException.
So it should look out like this:
public Object parseObject(String source) thr
11 matches
Mail list logo