harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Eclipse doesn't find harmony sources
Date Thu, 26 Apr 2007 16:46:36 GMT
Thanks. FYI HARMONY-3764 was created to track this. The fix just was
committed, so now we should have src-jars for all jars generated by
the build. Actually only sources for kernel classes make sense.
However, I decided to leave other src-jars (for gc_cc, gc_gen and
hythr, with simple stub helpers) for consistency. Hope I didn't break
anything.

Regards,

2007/4/26, Nathan Beyer <ndbeyer@apache.org>:
> On 4/25/07, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> > > > I also can't find the source for kernel.jar. Where is Object.java,
> > > > Class.java, etc.?
> >
> > > Good question. There maybe a missing step here in our build scripts.
> > > All of the other source JARs are part of the "classlib" build, but
> > > kernel.jar is produced (implemented) by the VM, so this would be part
> > > of the "drlvm" build. I'll look into this one.
> >
> > I'm currently fixing various issues in DRLVM build. So I think I can
> > also handle this one too since I'm in context. However, if you want to
> > do it by yourself please go ahead.
>
> Sure, go ahead, you'll probably get to it much faster than I.
> -Nathan
>
> >
> > With Best Regards,
> >
> > 2007/4/25, Nathan Beyer <ndbeyer@apache.org>:
> > > On 4/24/07, Wayne Beaton <wayne@eclipse.org> wrote:
> > > > When you add a JRE to Eclipse, it scans the JRE's directory for JAR files.
> > > > For each JAR file it finds, it looks for corresponding source. It does
so by
> > > > climbing up the containment hierarchy looking for a file named "src.jar"
or
> > > > "src.zip" (if you're curious, see
> > > > org.eclipse.jdt.internal.launching.StandardVMType#getDefaultSystemLibrarySou
> > > > rce()).
> > > >
> > > > Harmony JDK doesn't store is source this way (it seems to include the
> > > > sources alongside the JAR files), so Eclipse doesn't find it (which means
> > > > that if, for example, you browse the class java.lang.String, you get a
> > > > "can't find the source" message in your editor).
> > > >
> > > > Is there a special reason why Harmony sources are represented the way
they
> > > > are? Is there any way to bundle 'em all up into a src.zip file?
> > >
> > > No special reason, that I know of. Personally, I would consider the
> > > JRE's source bundling to be the odd ball (Eclipse source distribution
> > > is also a little weird and a personal pain point, but that's another
> > > story). I would consider packaging sources the way Harmony does a
> > > defacto standard; every JAR has a companion source JAR. In fact build
> > > systems like Maven default to this practice.
> > >
> > > >
> > > > In a related question, I'm not sure that putting them in the "jre" directory
> > > > is the right approach. I tend to think of the JRE directory as containing
> > > > *only* the JRE (i.e. I could yank it out and use it as a JRE) and the
> > > > sources--being part of the JDK--are outside of that directory.
> > > >
> > > > I also can't find the source for kernel.jar. Where is Object.java,
> > > > Class.java, etc.?
> > > >
> > >
> > > Good question. There maybe a missing step here in our build scripts.
> > > All of the other source JARs are part of the "classlib" build, but
> > > kernel.jar is produced (implemented) by the VM, so this would be part
> > > of the "drlvm" build. I'll look into this one.
> > >
> > > > I can understand why you'd want to have the sources in different files.
> > > > Eclipse handles J9 specially. It's probably time to generalize it's
> > > > implementation to handle arbitrary source configurations (perhaps via
> > > > extension point).
> > >
> > > Yes please!
> > >
> > > >
> > > > Wayne
> > > > --
> > > > Wayne Beaton
> > > > The Eclipse Foundation
> > > > wayne.beaton@eclipse.org
> > > > Skype, YIM: waynebeaton
> > > > http://www.eclipse.org
> > > > http://wbeaton.blogspot.com/
> > > > http://www.planeteclipse.org/planet/


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message