Date: Mon, 19 Nov 2001 10:10:36 -0800 From: John Merryweather Cooper <john_m_cooper@yahoo.com> To: Ernst de Haan <znerd@freebsd.org> Cc: freebsd-java@freebsd.org, freebsd-ports@freebsd.org Subject: Re: A Modest Proposal for Java(tm) dependency selection among ports Message-ID: <20011119101036.A91514@johncoop.MSHOME> In-Reply-To: <200111191317.fAJDHRi12634@zaphod.euronet.nl>; from znerd@freebsd.org on Mon, Nov 19, 2001 at 05:17:27 -0800 References: <20011115130202.E33074@johncoop.MSHOME> <200111161042.fAGAg8V55897@zaphod.euronet.nl> <20011116084005.A40560@johncoop.MSHOME> <200111191317.fAJDHRi12634@zaphod.euronet.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001.11.19 05:17 Ernst de Haan wrote: > John and all, > > > I'm setting up a web page which contains the complete proposal (work > in > progress!) see: > > * http://www.metaverse.nl/~ernst/freebsd-java-proposal-20011116.html > Looks good . . . a big step in the right direction. > > My thought here is that a "black box" application, where the user > could > > care less if it's Java(tm) under the hood, is a very good candidate > for > > a JRE, but the nature of development tools is that they need a JDK > > (debugging sucks without a debugger, etc.) > > Agreed, development tools need the JDK, but we are not going to set up > a > system for just Java-based development tools, but a generic system for > all > Java applications, *including* development tools. The focus should be > on a > clean generic system for Java-based programs. > Precisely, the build environment should accomodate both applications and development tools. Hence, the JRE/JDK knob . . . > Suggestion: First phase will just be applications, and it should cover > the > most common needs. It should separate all current Java-based > applications > from the actual JDK used. Second (or later) phase will then look at > requirements for libraries and at more specific needs, like a Linux > JDK > instead of a FreeBSD JDK. IMHO support for this feature should be > delayed so > we can discuss it a bit more first, and it's not necessary to cover > 90% of > the applications. > Actually, some of us will be interested in development tools, and some of us will be interested in applications. A quick review of freebsd-java (and in particular, the effort going into a native 1.3.1) should indicate that there are plenty of us interested in development tools. And the same can be said for appliations porting too. Phase one should be getting a working bsd.java.mk. Phase two should be getting ALL ports in the tree (or coming in) to use the build environment extentions. Phase three should be to port like crazy to get the desirable development tools and applications into the tree. :) Phase two comes first so we can work the kinks out (there'll be some). Of course, all of these phases can pretty much occur in parallel except the first one. We need to be "born" first. > > In my experience (yours may be different), the dividing line for > most > > apps is whether they work better (or at all) with a Java or Java2 > > JRE/JDK. I've yet to find an app/tool that whines too much about > the > > many variations of Java2 (1.2.x and up), but many are unhappy with > > first generation Java (1.1.8 and before)--and vice versa. Hence, > > following IBM's breakdown--call one set JAVA11 and the other set > > JAVA2. Getting more fine-grained than necessary leads back to the > > current situation--where I effectively have ALL the JDK's installed. > > In reality, two should cover most of the known world. People who > > simply must have every JDK can still install them. :) > > Well, this is just a matter of time. I already know tools that are > explicitly > demanding Java 1.3, at least on FreeBSD. An example is BugSeeker from > Karmira(java/bugseeker and java/bugseeker-demo). Again, I would like > to set > this system up to be generic, I don't want to introduce quirks. *If* > we are > going to want to distinguish between 1.2, 1.3, 1.4, 1.5, 2.0 etc in > the > future, then we should set the system up so that it will be able to > deal with > it when this is reality. > A better way to handle this, IMHO, would be for the JAVA_VER[SION] switch to perform double duty. It would work like this: JAVA_VER would, by default be set to "" entering into the JDK/JRE selection logic. This allows automagical selection of the appropriate version. However, JAVA_VER[SION] could also be manually set to select a specific version. > > My thought here is that a single JDK versus JRE switch can be used > to > > influence the version selection mechanism--and avoid proliferating > > switches unnecessarily. > > Yeah, sounds good to me. I modified my proposal for this. > > > > > WANT_LINUX_JAVA=[yes|no] > > > > same as above except Linux version > Java's > > > > are used and USE_JAVA11 will abort > build. > > > > > > I suggest not introducing this flag in the first phase. We can > discuss > > > it's > > > usefullness later. > > > > I can definitely understand why! But, practically, a user who wants > > Java(tm) only/mostly for her favorite Linux application--Star Office > is > > an example--wants a JRE/JDK that works (I can almost get Star Office > to > > do Java with a Linux JDK--no dice (probably because there's no > emulator > > support) for a native JDK). Of course, the solution is native > versions > > of BOTH the JDK/JRE and the application. At the glacial rate this > is > > happening with Sun, some of us may need to chain themselves to the > > front doors of their main office and chant "Free BSD" until the > > powers-that-be allow native binaries . . . (rant off--sorry) > > Are there any examples of programs in the tree that explicitly demand > a Linux > JDK because they cannot work with a FreeBSD JDK? I don't think so, and > I hope > not, either. I still doubt the importance of this feature for now. > The one I've run into is StarOffice. Probably, these apps will all be LINUX apps themselves. Probably too, they will attempt to interface to the JDK/JRE in a non-standard way (through a plugin, direct linkage to shared libraries, etc.) > > > > JAVA_VER reports Java(tm) detected or built by > > > > USE_JAVA* > > > > > > Hmm, what *exactly* would you like this variable to return as its > > > value? > > > > CLASSPATH and/or environment variable construction for an > install-user > > script on the Makefiles. For example, a whole host of environment > > variables need to be correctly set for my NetRexx port to function. > If > > they're not set correctly, the port acts like it is broken. But > unless > > I get really tyrannical (YOU user SHALL have the following ports > > installed and NO OTHERS . . .) it's not practical to construct such > a > > script. NetRexx will run with ANY of the JDK's. But which one to > > setup? That is the problem. If I know: 1) whether or not it is > linux > > based on the WANT_LINUX_JAVA flag; and 2) what JAVA_VER it is > (1.1.8, > > 1.2.2, etc.), I can construct the necessary environment variables. > In > > fact, for Java2 (if I know Java2 is the target), I can install my > JAR > > file in the EXT portion of the JDK tree and eliminate > setting/changing > > the CLASSPATH (same also with JGNAT). But I don't know, so I can't. > > Yeah, I was keeping this in mind. See my proposal. > One final thought, although the logic to influence preference for native/auto-built JDK/JRE's is wonderful in theory, in practice it locks us into JDK 1.1.8. Sun won't let us build a Java2 binary for distribution at present--and that is a painful practical reality. We should not discriminate against manual builds until such time as we have at least one "full-citizen" native Java2 in the tree capable of binary distribution and/or automatic build. > -- > Ernst > zNerd@freebsd.org > We need some implementation pro-types so we can "play" with the challenges. -- jmc || MacroHard -- \ || the perfection of form over | ----------------------------------|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | || design . . . | =======================================================================/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =======================================================================\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011119101036.A91514>