Difference between revisions of "Java Configuration Design Update"

Revision as of 00:00, June 30, 2014

This page describes a potential update to the Java support code in Gentoo and Funtoo Linux, with the intention of simplifying java-config code and also making it more correct and better integrated with Portage itself. The proposal intends to address deficiencies in the current design of java-utils-2.eclass while maintaining its useful features and avoiding a full rewrite. Rather than replace the current system with more code, the goal is to simplify the existing code while retaining functionality.

Design Challenges

The current Java eclasses have some very interesting and powerful features, yet are lacking in some areas.

Dependency Handling

Currently, java-utils-2.eclass uses depend-java-query to automatically select the most optimal Java VM for building. This is a sophisticated feature that is intended to be 'smart', yet it has some flaws. These flaws are fixable:

While JVM auto-selection is smart, it is not always correct -- it doesn't use Portage's API, but instead uses regexes to parse the currently-executing ebuild's DEPEND string. Ideally, Portage API would be used to always generate a completely correct result.

Related to the regex issue, the code in depend-java-query is complex as it tries to duplicate some functionality that could be handled better by Portage's API.

Atoms

Currently, eselect java-vm and java-config have their own "atoms" that they use to identify Java virtual machines, which seems to be ${PN}-${SLOT}. But why create a new kind of atom? Portage already has atoms, and we should try to use them if they work for us. So this proposal will also attempt to "merge in" support for Portage-style naming of Java VMs.

Proposal

This proposal involves a minor upgrade to the java-config settings for a JVM -- adding a PORTAGE_ATOM setting to the file, which allows the java-config atom to be linked to the Portage atom:

/usr/share/java-config-2/vm/oracle-jdk-bin-1.7 (bash source code) - Java-config settings

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-java/oracle-jdk-bin/files/oracle-jdk-bin-1.7.env,v 1.2 2011/11/17 22:49:56 caster Exp $

VERSION="Oracle JDK 1.7.0.60"
JAVA_HOME="/opt/oracle-jdk-bin-1.7.0.60"
JDK_HOME="/opt/oracle-jdk-bin-1.7.0.60"
JAVAC=${JAVA_HOME}/bin/javac
PATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin"
ROOTPATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin"
LDPATH="${JAVA_HOME}/jre/lib/amd64/:${JAVA_HOME}/jre/lib/amd64/xawt/:${JAVA_HOME}/jre/lib/amd64/server/"
MANPATH="/opt/oracle-jdk-bin-1.7.0.60/man"
PROVIDES_TYPE="JDK JRE"
PROVIDES_VERSION="1.7"
BOOTCLASSPATH="${JAVA_HOME}/jre/lib/resources.jar:${JAVA_HOME}/jre/lib/rt.jar:${JAVA_HOME}/jre/lib/sunrsasign.jar:${JAVA_HOME}/jre/lib/jsse.jar:${JAVA_HOME}/jre/lib/jce.jar:${JAVA_HOME}/jre/lib/charsets.jar:${JAVA_HOME}/jre/classes"
GENERATION="2"
ENV_VARS="JAVA_HOME JDK_HOME JAVAC PATH ROOTPATH LDPATH MANPATH"
VMHANDLE="oracle-jdk-bin-1.7"
BUILD_ONLY="FALSE"
PORTAGE_ATOM="dev-lang/oracle-jdk-bin-1.7.0.60"

@@ Line 13: / Line 13: @@
 * Related to the regex issue, the code in <tt>depend-java-query</tt> is complex as it tries to duplicate some functionality that could be handled better by Portage's API.
-=== Atoms ====
+=== Atoms ===
 Currently, <tt>eselect java-vm</tt> and <tt>java-config</tt> have their own "atoms" that they use to identify Java virtual machines, which seems to be <tt>${PN}-${SLOT}</tt>. But why create a new kind of atom? Portage already has atoms, and we should try to use them if they work for us. So this proposal will also attempt to "merge in" support for Portage-style naming of Java VMs.