harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven de Marothy <s...@physto.se>
Subject RE: some ideas
Date Thu, 02 Jun 2005 11:05:16 GMT
On Thu, 2005-06-02 at 10:42 +0900, Renaud BECHADE wrote:
> I guess this is a schema that happens very often…
> Lol

It does happen quite a bit though. I'll admit that there are plenty of
parts in Classpath which are pretty poorly implemented. And there are
parts of Sun's implementation which seem very good. 

But there are still parts which seem to be completely brain-dead, and
there is plenty of room for improvement.

Free java has several inherent benefits, such as:

* Hindsight. Old APIs can be implemented on top of new ones (e.g.
java.io is implemented on java.nio in Classpath). 

We also have actual usage cases of the API available at the time of
implementation. We can make optimizations towards the most common cases.

* Specialists. We're more likely to attract people with special interest
in certain areas towards implementing those areas. A hacker with such an
interest will always do a better job than one who doesn't.

* Native. We can use existing FOSS native libraries to a larger extent
than Sun is willing to. For instance, in addition to Classpath's pure
java implementation of java.math, Kaffe has a GNU MP-based one, which
outperforms both Classpath and Sun significantly.

Another example of that is that Classpath has a java.nio.charset
provider based on the iconv library, which is faster than Sun's for
character-conversion of buffers >2kb or so. (the native call has, of
course, larger overhead, so it's slower on small buffers.)

Anyway, my main point stands: I see no implementation-strategy benefits
from looking at Sun's sources. Only the opposite. It can easily close
your mind to more original ideas which may be better.


> -----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

View raw message