[Plplot-devel] Re: [Plplot-cvs] plplot/bindings/java Makefile.am,1.46,1.47

[Alan W. I. <ir...@be...>]

On 2005-07-04 09:32-0000 Andrew Ross wrote:

> Update of /cvsroot/plplot/plplot/bindings/java
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22560/bindings/java
>
> Modified Files:
> 	Makefile.am
> Log Message:
> For some reason the Sun java compiler does not like having a mix of .class
> and .java files in the plplot.jar file. This stopped the examples building
> correctly in their installed location. Fix by removing the .java files
> associated with the Java bindings from plplot.jar. We don't install source
> code for any other bindings, so why should we for Java?

Hi Andrew:

The answer to your last question is for the convenience of the rapidly
expanding free java users community who view the jar file as simply a file
archive which collects a lot that they need (including source) in one
convenient location. The installed jar file will almost certainly be further
distributed by some of our java users as a file archive, and including java
source in it not only is a convenience but also fundamentally expresses our
values as members of the free software community.

Thus, I believe we should use a different approach for getting around this
Sun java limitation.

One possibility I am thinking about is we could go back to the examples
build method we used in the old days where no jar file was used at all in
the process. According to this model, everything we would need for the
examples would be installed somewhere in the install tree as a separate
file.  One advantage of this method is that it removes the binary package
dependency on jar tools such as fastjar, and of course the fundamental
advantage is it works around limitations in the Sun java environment that
apparently have special rules for jar files.

This also means we could completely dispense with the jar file archive
altogether, and that would be okay with me if you think that is the best
approach.

However, I think a better option would be to install a redundant jar file
that collects installed files in one file archive as a convenience for users
who are used to seeing java applications packed up this way. (Note if we
follow this route that makes a build dependency rather than a binary
dependency on jar tools.) That redundant jar file should include both source
and class files for the examples and binding for the free software reasons I
indicated above. The user then has the option to unpack that jar file any
way they like including moving the source code to a different location if
that is what is demanded by their proprietary java environment.

In sum, I want to resist stripping source code from our version of the jar
file simply because the proprietary java environment demands that.  So I
propose not using the jar file in our examples build so that build will work
with both free and proprietary java environments.  That gives us the option
of either dropping the redundant jar archive file completely or simply
providing that archive with both source and class files for the convenience
of our users who have the option (if they are still using proprietary java)
of stripping the source code from it themselves.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________