harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Date Tue, 04 Jul 2006 14:38:50 GMT
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it.  So we can do ...

As a first step, I suggest that we make drlvm build completely free
from the classlib-related tasks and files, this may help to avoid
further confusion. For example, it doesn't have to copy things like
icu, seralizer, xalan e.t.c. - they are already taken from pre-built
class libraries. If there are no objections, I'm going to submit a
patch which will remove some of that stuff from vm build.

As a last step, one would remove the copying of the classlib binaries
(e.g. deploy.copy_classlib) after we have a top-level build in place.

Thanks,
Andrey.


On 6/23/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>
> On 23 June 2006 at 17:10, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > On 6/23/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > >> >>Pavel Pervov wrote:
> > >> >> Geir,
> > >> >>
> > >> >> What's the first thing we do?
> > >> >> I'd suggest switching the build to 1.5.
> > >> >>
> > >> >> The rest will come shortly :)
> > >>
> > >> >Now that's a plan! :)
> > >
> > >
> > > Hi Geir,
> > >  Actually what Pavel says makes sense. Not sure what plan we need. We could
> > > do it either way. We can make some changes to the class structure, loader,
> > > and the jit/interpreter, and submit a couple of patches. It is not the
> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can switch
> > > the build first. This will break drlvm for a short time, and we can
> > > submit a
> > > couple of bug fixes to get it going again. This way, we will just add the
> > > minimum needed for removing the compiler hack. Whatever way you think makes
> > > sense.
> > >  However, you started this thread with saying "no patch over the wall"
> > > and making this "learning exercise about DRLVM". Where are you going with
> > > this? Do you want to actually enumerate/discuss which source files need to
> > > change and in what way, on this thread so that more people can participate?
> > >
> > > Marginally confused :-)
> > > Rana
> >
> > Just for the record, my goal was to avoid 'moving the goalposts' for
> > drlvm to integrate with the classlib and run the tests, apps, etc.
> >
> > If consensus here is that moving to 5.0 (and thereby delaying that goal)
> > is more desirable then I'm happy to go along with it, though I'm keen to
> > get the entire end-to-end story working soonest.
> >
> > Regards,
> > Tim
>
> My feeling at the moment is that although drlvm and classlib are working
> together[0], it is evident[1] that things are not really integrated.
> I would prefer to see "real integration" before we break[0] things by
> moving to 5.0.
>
> As Geir pointed out recently, we are not just a Class library project,
> so perhaps a change of focus is warranted?  Perhaps if we can agree a
> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
> ... err ... encourage this change of focus?
>
> My prerequisite goals would include things like:
>
> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
> integration - e.g. the static libhyprt.a for instance.[2]
>
> 2) Implement enough of the classlibadapter kernel classes such that
> JCHEVM will run 'ant rebuild' in classlib[3].  We have some difficult
> problems (thread attach) but there is also a lot of low hanging fruit in
> terms of missing or incomplete methods.
>
> 3) Get drlvm loading with the Harmony launcher from Classlib so we
> can have both drlvm and IBM VME around for testing.  I think this is
> important because it will make it easier for people to test with either
> JVM.
>
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it.  So we can do ...
>
> 5) Create the top-level build that can combine the trimmed drlvm deploy
> tree and the classlib deploy tree to produce a working jdk.  (In much
> the same way that we currently combine the classlib and IBM VME.)
>
> 6) Pull out shared dependencies to top-level so we only need one copy.
>
>
> At the moment, I think moving to 5.0 would increase the divide between
> the JVMs and Classlib.
>
> In the meantime there is still plenty of work to do for those that, for
> whatever reasons, don't find these tasks exciting enough - for instance,
> the missing java.lang.Character/java.lang.Math methods[4].
>
> Regards,
>  Mark.
>
> [0] Thanks Geir!
>
> [1] http://issues.apache.org/jira/browse/HARMONY-651
>
> [2] This isn't a criticism; I think these hacks can be justified.
>
> [3] I tried this the other day.  It got to the second (non-comment) line
> of the first ant script before crashing because ClassLoader.getResources()
> isn't implemented yet.
>
> [4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message