Re: SableVM and Classpath

Hi,
Thanks for your answer.

To me this sounds like it really is only then a matter of=20
manpower...since the past need not have a significant consequence on the=20
future.

As SableVM moves from being about innovation to seriously being=20
considered for an actual product (hint hint), I think it will increase=20
productivity if you can resolve the final issues and do away with the=20
SableVM-specific classpath.

How much of an effort are we talking about?

Regards,

Philippe Laporte
Software=20

Gatespace Telematics
F=C3=B6rsta L=C3=A5nggatan 18
41328 G=C3=B6teborg
Sweden
Phone: +46 702 04 35 11
Fax:   +46 31 24 16 50
Email: [email protected]



Grzegorz B. Prokopski wrote:

>Hi Philippe,
>
>+++ Philippe Laporte [08/12/05 15:53 +0100]:
> =20
>
>>Hi,
>>   Why is it that SableVM redistributes Classpath? What=20
>>SableVM-specific tweaks are required into Classpath? Or what's the stor=
y?
>>   =20
>>
>
>There's a few reasons.
>
>Historically, especially when SableVM was being built by Etienne Classpa=
th
>was changing just too rapidly for a single person to both keep up with i=
t and
>still develop a whole JVM.  Writing a JVM, especially one with so many
>fine-tuned and deeply rethought state-of-the-art features as SableVM is =
hard
>work and requires incredible focus and big amount of time.  So it was a =
must
>at that moment to just freeze SableVM's class libraries and first develo=
p
>a working version of SableVM with them.  SableVM 1.0.0 shipped with an a=
lmost
>2 years old Classpath IIRC.
>
>Secondly, especially at the beginning, the VM interface in GNU Classpath=
 was
>far from being stable (it's *much* better now), and so to make SableVM w=
ork
>with it quite some changes must have been done.  A still noticable trend=
 is
>that in SableVM's Classpath we tend to do more on "java side", even if i=
t's
>sometimes slightly slower than a native implementation would be.  But it=
's
>easier to maintain.
>
>Thirdly, it's not something I like to get back to, but we didn't always
>agree with Classpath developers over some issues.  It was often taking a=
 lot
>of time and effort (on both sides - SableVM Project and GNU Classpath
>Project) to get to a satysfying solution.  At some point it was just too
>much for a project like ours where the main focus is on the JVM.
>
>Finally, because SableVM is about innovation, having our own copy of cla=
ss
>libraries allows us to easily and quickly make any changes we find neces=
sary.
>
>HTH,
>
>		Grzegorz B. Prokopski
>
>PS: Also note that in our new "All-in-one" distribution model, which
>SableVM SDK is, a slightly modified copy of class libraries is one of
>the many packages that are distributed together to create a coherent and
>functional Java development and runtime environment.
>
> =20
>