Is third party code included in langtools sources?

[Andrew John Hughes]

On 20/08/2008, Yulia Novozhilova <Yulia.Novozhilova at sun.com> wrote:
> Hi,
>  sorry for not responding earlier.
>  Here is more qualified answer on your question:
>
>  Jan Lahoda wrote:
>
> > Hi,
> >    the javac in the langtools repository is currently more a command line
> tool than a Java parser suitable for an IDE. The NetBeans' fork contains a
> lot of changes that make the parser more IDE friendly. An example for all:
> the javac works in "phases" - it first parses the source, then attributes
> classes/methods/fields declarations, then attributes the "bodies" of
> methods, etc. The vanilla javac will not continue to another phase if there
> was an compilation error in the previous phase. This behavior is
> unacceptable for IDE, so we have patched the parser to execute "all" phases
> even in presence of errors.
> >
> > The long-term intent is to merge (ideally all) NetBeans patches into the
> vanilla javac, but the progress is quite slow.
> >
> > I think there are also "latency" problems - even if all the NetBeans
> patches would be adopted into the JDK7 langtools today, it would still take
> a long time before it would get into the packages (I think at least - if you
> are producing package only for "releases", than the changes would be visible
> either after OpenJDK7 would be released or after OpenJDK6 would adopt these
> changes, which both would take some time). Something similar would be true
> for any further change we would do.
> >
> > Hope this answers your question,
> >    Jan
> >

That does; it establishes that there is a third copy of langtools used
for NetBeans that wasn't clear from your initial e-mail.

>  Anyway, my goal is to create a package for javaparser that is needed for
> NetBeans. And I have an aggressive timetable.
>  So, could you please, provide me with information about third party code.
>  Is it difficult? I believe langtools  repository doesn't contain any third
> party code and THIRD_PARTY_README and ASSEMBLY_EXCEPTION
>  can be removed.
>

You should check with Sun legal -- IANAL. From the files in the
OpenJDK7 tree, it would seem that all the Java files are under the GPL
and copyrighted to Sun with the exception of one (
src/share/sample/javac/processing/src/CheckNamesProcessor.java) which
appears to be BSD licensed.  Most tests don't seem to include
copyright information.  There doesn't appear to be any third-party
code mentioned by the THIRD_PARTY_README, which appears to largely be
stuff from the JDK.

I think you need to keep the ASSEMBLY_EXCEPTION as it allows pure GPL
code to be linked with GPL+Classpath exception code, and most of the
code uses the Classpath exception.

'it allows licensees and sublicensees of Sun's GPL2 OpenJDK Code to
build an executable that includes those portions of necessary code that Sun
could not provide under GPL2 (or that Sun has provided under GPL2 with the
Classpath exception).'

>  Thanks,
>  Yulia
>
>
>  Andrew John Hughes wrote:
>
> > On 18/08/2008, Yulia Novozhilova <Yulia.Novozhilova at sun.com> wrote:
> >
> >
> > > Hi,
> > >
> > >  Andrew John Hughes wrote:
> > >
> > >
> > >
> > > > The more obvious question for me is why NetBeans needs a fork of this
> > > > in the first place.  The Debian OpenJDK team have already gone through
> > > > the extensive task of verifying this code legally to package OpenJDK
> > > > 6, which is now in unstable and testing:
> > > >
> > > >
> > > >
> > > >
> > >
> http://release.debian.org/migration/testing.pl?package=openjdk-6
> > >
> > >
> > > > Having another copy in another package seems ludicrous and a
> > > > duplication of existing work.
> > > >
> > > >
> > > >
> > > >
> > >  There are users who want to use NetBeans but don't want to install
> openjdk.
> > >  (you can find an example here:
> > >
> https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/258844)
> > >  They already have sun-java6-jdk installed and expect NetBeans to work
> on
> > > it.
> > >  That is why NetBeans needs a fork of the code included into openjdk.
> > >
> > >  Thanks,
> > >  Yulia
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > It doesn't explain why a fork is needed.  It just says that NetBeans
> > has to be able to work against either the langtools from OpenJDK or
> > the proprietary Sun JDK.  As I read it, a fork solution is suggesting
> > a third alternative, namely to include another different copy of the
> > langtools for NetBeans.
> >
> > In short, what is the reason NetBeans can't just work against the
> > tools.zip in either JDK?
> >
> >
>
>


-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8