harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: some ideas
Date Thu, 02 Jun 2005 01:42:40 GMT
>For instance, I implemented the java.awt.color.* package in GNU Classpath.

>I have benchmarked it. On transforms between the predefined color spaces
it >is
>about 20x faster.
>It is also much more accurate. (as benchmarked against the well-regarded
LCMS >library)
>It also uses less memory.

I guess this is a schema that happens very often …
Lol

RB

-----Original Message-----
From: Sven de Marothy [mailto:sven@physto.se]
Sent: Thursday, June 02, 2005 3:44 AM
To: harmony-dev@incubator.apache.org
Cc: enrico.migliore@fatti.com
Subject: Re: some ideas

Hello,
First off, you should read the actual Harmony proposal, footnote #2.

"Historically, there has been wide exposure to VM and class-library-
specific source code that is the property of Sun Microsystems as well
as others, as it is common for commercial J2SE implementations to be
based on licensed Sun code.  We wish to make every effort to ensure
that the licenses and rights of external projects and efforts is
properly respected."

That means that looking at Sun's sources for 'inspiration' is hardly
likely to be allowed. Personally I'm hoping for, and think it's likely,
that Harmony will go with a strict clean-room requirement,
like GNU classpath already does.

Legal or not. If you've looked at Sun's sources, and the commited code turns

out to be similar to code in the JDK (and some of it invariably will,
intentionally or not) the burden of proof is on your side to prove you
didn't copy it.

That is a a very hard thing to prove. Monitoring all commited code for
similarities
to Sun's isn't practical either. Clean-room is IMHO the only viable option.

>"If you are going to contribute source code to GNU Classpath we must
>make sure that you have not studied the source code of the JDK/JRE or
>decompiled any of its classes"
>
>If we don't study how a solid implementation has been built, how can we
>make a better implementation?

I question the sanity of this statement.

Plenty of faster VMs than Sun's have been written without ever looking at
their code.
I doubt Sun themselves looked at anyone else's code either.

As for the class library, well I can speak for my own experience there.

For instance, I implemented the java.awt.color.* package in GNU Classpath.
I have benchmarked it. On transforms between the predefined color spaces it
is
about 20x faster.
It is also much more accurate. (as benchmarked against the well-regarded
LCMS library)
It also uses less memory.

Why should we copy their bad designs?

Plus, you do not need to look at Sun's code to get a pretty good picture of
how their
implementation works. They've been poor enough at seperating implementation
and specification for that. All you need is to look carefully at the API
docs and have
a modicum of deductive reasoning.

/Sven


Mime
View raw message