Date: Tue, 2 Jan 2001 12:23:59 +0100 From: Ernst de Haan <ernst@jollem.com> To: FreeBSD Java mailing list <freebsd-java@freebsd.org> Cc: Sebastiaan van Erk <sebster@sebster.com> Subject: Java ports Message-ID: <20010102122359.A786@c187104187.telekabel.chello.nl>
next in thread | raw e-mail | index | archive | help
First of all, a very happy New Year to all of you!
Considering all the discussion on the subject of binary versus source-based
Java ports, it is clear that there are two camps. So perhaps there is room for
both. Let's get all pros and cons of the different options lines up.
BINARY VS SOURCE-BASED
Correct me if I am wrong, but I think these are the pros and cons of both
approaches:
* Source-based
Typically involves downloading source and build files, compiling .java
files to .jar file(s) using either a Makefile or an Ant build file.
* Binary
Typically involves downloading one or more .jar files.
Oh, and IMO, a .jar file is definitely a binary distro, it's *not* half-way
between source and binary, it's simply a binary. But one *some* systems (on
all FreeBSD systems, but not one Java processor-based systems, which I happen
to have one of too) the processor-code (which bytecode is) is converted to
different processor-code, either using a normal interpreter, a JIT or some
other mechanism.
Note that Java programs are not *by definition* portable, and that they are
not guaranteed nor supposed to run the same on all platforms. Most are, and
all "100% Pure Java" programs should. Java programs may make assumptions
w.r.t. path separators, file locations, screen size, locale, character set,
etc, they may contain native code (JNI) etc.
* Pros of source-based:
[1] You can always check the source code before you run the code, one of
the major advantages of FreeBSD over Windows
[2] The choice of the compiler can be left up to the port maintainer
and/or the user (compilers get better and produce better-optimized
code)
[3] The choice of the JDK to compile with can be left up to the
maintainer and/or the user.
[3] Source is always readable for reference purposes (no separate
download)
[4] Operating-system specific settings can be used when building (yes,
this is possible, even Ant supports this, using the "os.name"
property)
[5] System-specific settings can be used when building (perhaps the
suggested "bsd.ant.mk" is a good idea?)
* Cons of source-based:
[1] May be time-consuming to compile the .java files, especially if jikes
is not used.
[2] May be memory-consuming to compile the .java files, this is
especially a problem on a system which is low on memory (like the
mentioned 32 MB system)
[3] Needs a compiler to be installed, some systems may only require a JRE
and some .jar files. At this moment you can't just install a JRE, but
we may consider making this an option, too.
[4] A binary .jar file may be signed by the author.
LOCATION OF JAVA PORTS
Now there was a discussion about where the Java ports should go, too. IMHO
this depends on the port. A simple library, distributed as a single .jar file
would go to ${PREFIX}/share/java/classes/, while a complete application with
a lot of different kinds of files, like the Orion Application Server, should
IMO have it's own subdir under ${PREFIX}. It should not be treated very
differently from any Application Server written in C++, IMHO. The application
might *expect* files to be in a certain location, like the jars in the main
application directory, the config files in config/ or etc/, etc.
EXAMPLES
Let't take a few examples and see what would be the optimal solution to make
everybody happy (or at least most ppl):
* Orion (http://www.orionserver.com)
A closed-source Java application, supposed to be portable.
(other applications in this category are BugSeeker and JBuilder)
* Ant (http://jakarta.apache.org)
An open-source Java application, supposed to be portable. The build
process involves running shell scripts.
* JUMP (http://members.xoom.com/_XMCM/znerd/java/jump/index.html)
An open-source (LGPL) Java library, supposed to be portable, can be
downloaded as a JAR, or using the source code.
(other libraries in this category are JDOM and Xerces-J)
The port for "Orion" has to use the binary .jar files, since there is no
source available. We could attempt to split the standard distribution so the
.jar files could be placed in ${PREFIX}/share/java/classes, but I wonder if we
should attempt this. Why would we?
The port for "Ant" could download a .jar file, or it could build the .jar from
the source. There are advantages to both, as pointed out. We *could* create 2
ports:
* "ant"
(categories: java, devel)
Uses the source code and the shell scripts to build the .jar file(s).
This port would require a JDK (1.1 or higher I think) to build
(BUILD_DEPENDS).
* "ant-bin"
(categories: java, devel)
Just downloads a .jar file, so it's much faster. This port would only
require a JRE to _run_ (RUN_DEPENDS).
Both would, however, need to install an "ant" shell script so it can be run
from a shell by just invoking "ant". While the .jar file could go into
${PREFIX}/share/java/classes/, the ant shell script would need to go in a
different location, either in ${PREFIX}/bin (yuck!) or in ${PREFIX}/ant/bin/
or in ${PREFIX}/share/java/ant/bin/ or something.
Perhaps we could _start_ with an "ant" port and then provide an "ant-bin"
port, as I still prefer the build from source code. After that we may create
the "ant-bin" port (which would actually be easier) and perhaps a JRE too, so
we could make "ant-bin" depend on (JRE || JDK) (1.1 || 1.2 || 1.3).
Finally the open-source libraries, like JUMP, JDOM and Xerces-J. We could take
the same approach as we used for Ant and the like.
Now, let's stop discussing and let's get some real work done! ;)
--
Ernst
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010102122359.A786>