From owner-freebsd-java Tue Jan 2 3:25:21 2001 From owner-freebsd-java@FreeBSD.ORG Tue Jan 2 03:25:13 2001 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from heinz.jollem.com (c104187.upc-c.chello.nl [212.187.104.187]) by hub.freebsd.org (Postfix) with ESMTP id 0EE9837B400 for ; Tue, 2 Jan 2001 03:25:09 -0800 (PST) Received: (from ernst@localhost) by heinz.jollem.com (8.11.1/8.11.1) id f02BNxS00904; Tue, 2 Jan 2001 12:23:59 +0100 (CET) (envelope-from ernst) Date: Tue, 2 Jan 2001 12:23:59 +0100 From: Ernst de Haan To: FreeBSD Java mailing list Cc: Sebastiaan van Erk Subject: Java ports Message-ID: <20010102122359.A786@c187104187.telekabel.chello.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ernst@heinz.jollem.com Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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