[kaffe] WARNING: Ugly Monster Mail (but with small overview at the begin ;-)

mle mle at neze.de
Sat Sep 20 02:18:02 PDT 2003


my first real fight with kaffe makes the following problems

     1. Incompatible ZipInputStream.getNextEntry()
     2. Incompatible CodeSource.toString()
     3. Incompatible Permission() constructor
     4. Incompatible java.lang.Permission.elements()
     5. Incompatible SecurityManager
     6. Again: make Kaffe installation moveable on Linux i386 Systems

I tried this with a CVS checkout at
         Sam Sep 20 08:07:02 CEST 2003

Kind Regards


Kaffe's ZipInputStream().getNextEntry() throws IOException if
ZipInputStream is invalid, but SUN's Java 1.4.2 returns null;
kaffes way is better and so I adjusted my code:
             Object oNextEntry;
			try {
				oIS = oBootURL.openStream();
				oNextEntry = new ZipInputStream(oIS).getNextEntry();
			} catch (IOException e2) {
				oNextEntry = null;
Kaffe's new CodeSource(oCodeSourceURL, oCerts); implies NullPointer 
in toString(), if constructed with oCerts == null (and perhaps in other 
but SUN's JRE 1.4.2 don't do that.
Kaffe's new Permission(String s) thrwos execption if called with s="" 
but SUN's JRE don't.
In Kaffe gnu.java.security.provider.DefaultPolicy creates instances of 
java.lang.Permission oPC,
with AllPermissionCollection in oPC.elements(); this Enum don't return 
PermissionCollections in
SUN's JRE (only Permissions are returned, so I have to collect the 
Permissions with:

	 *  This method exists for kaffe compatiblilty
	private static void copyPermissions(
		final PermissionCollection oPC,
		final Vector oDest //
	) {
		final Enumeration oPermEnum = oPC.elements();
		while (oPermEnum.hasMoreElements()) {
			final Object oPerm = oPermEnum.nextElement();
			Log.a.programmerHint(">>>>>  All User Permission: " + oPerm);
			if (oPerm instanceof Permission) {
			} else {
				if (oPerm instanceof PermissionCollection) {
					copyPermissions((PermissionCollection) oPerm, oDest);
				} else {
					throw new Neze.Bug("UNexpeced permisision type: " + oPerm);
I have a "handmade security Mananger and it works everywhere but
not on kaffe, reason: Kaffes java.lang.Securitymanager don't
delegates its check*()-methods to checkPermission(), I verifed this
with a "RMISecurityManager-inspired" KaffeSecurityManager:

  * Created on 20.09.2003
  * Copyright http://neze.de 2003
package de.neze;

import java.io.FileDescriptor;
import java.net.InetAddress;
import java.security.Permission;

  * @author mle
public class KaffeSecurityManager extends SecurityManager {

public KaffeSecurityManager() {

public void checkAccept(String host, int port) {

public void checkAccess(Thread g) {

public void checkAccess(ThreadGroup g) {

public void checkAwtEventQueueAccess() {

public void checkConnect(String host, int port) {

public void checkConnect(String host, int port, Object context) {

public void checkCreateClassLoader() {

public void checkDelete(String file) {

public void checkExec(String cmd) {

public void checkExit(int status) {

public void checkLink(String lib) {

public void checkListen(int port) {

public void checkMemberAccess ( Class clazz, int which ) {

public void checkMulticast(InetAddress maddr) {

public void checkMulticast(InetAddress maddr, byte ttl) {

public void checkPackageAccess(String pkg) {

public void checkPackageDefinition(String pkg) {

public void checkPermission(Permission perm) {

public void checkPermission(Permission perm, Object context) {

public void checkPrintJobAccess() {

public void checkPropertiesAccess() {

public void checkPropertyAccess(String key) {

/* public void checkPropertyAccess(String key, String def) {

public void checkRead(FileDescriptor fd) {

public void checkRead(String file) {

public void checkRead(String file, Object context) {

public void checkSecurityAccess(String action) {

public void checkSetFactory() {

public void checkSystemClipboardAccess() {

public boolean checkTopLevelWindow(Object window) {
	return (true);

public void checkWrite(FileDescriptor fd) {

public void checkWrite(String file) {


Perhaps somebody is intressted on a solution to the
         "Moveable Kaffe installation"-Problem
there are two possiblities and the first one is shorter then this mail:

(1) Modify the scirpts in the INSTDIR of kaffe:


each script starts with prefix

I suggest to modify this lines to
     . $(dirname $0)/prefix_calculator $0 $scriptpath_to_root

in the included bash script you can adjust the variables


with the "real" prefixes calculated based on the location
of the "scriptpath_to_root" and the location of the script $0
and the user-changed configuration ofthe prefixes;
useful bash function are perhaps (from my evm-wrapper of Zaurus):

     # funcFollowlink()
     funcFollowlink() {
         local TARGET=$1
         # if we are called by symlink, follow it to its target
         while test -L "$TARGET" ; do
             # keep dir where the symlink is
             local DIR=$($DIRNAME "$TARGET")
             # ask ls -l about the symlink's target
             local LL_OUT=$($LS -l "$TARGET")
             TARGET=$($EXPR "$LL_OUT" : '.*-> \(.*\)')
             # for relative target, prefix with dir of symlink
             local ABS=$($EXPR "$TARGET" : '/.*')
             if test "$ABS" -eq 0 ; then
         echo "$TARGET"
     # funcCanonicalFileName
     funcCanonicalFileName() {
         local varFile=$1
         if test -e $varFile ; then
             varFile=$(funcFollowlink $1)
     #    else
     #        echo "Warning: Calculate canonical file name not existing" >&2
         if test -d $varFile ; then
             cd $varFile
             cd $($DIRNAME $varFile)
             varFile=$(pwd)/$($BASENAME $varFile)
         cd $varPWD
         echo "$varFile"

As a result you have to add 2 lines of code to each wrapper script,
and you have to write the file prefix_calculator which may have 100
lines or so.

(2) C-Link and  (Additional) Wrapper:

A better solution of course is to write a "C-link" i.e. very small
C-programm which compiles (on windows to 4 kb - I send you Win32
implemtation if you like it).
This programm calls a monster-wrapper as your kaffe-bin:
     monster-wrapper absolute-scriptpath scritp-arguments.
I think that is a much better solution then bash scirpts as the first
lines of my Zaurus script proves (perhaps a better prove is a
document realted to autoconf, which explains on many lines how to
write compatibe shell script -- short version: it is impossible)

     if [ -e /bin/busybox ] ; then
         # Zaurus case
         export DIRNAME="busybox dirname"
         export BASENAME="busybox basename"
         export EXPR="expr"
         export LS="busybox ls"
         # Linux case
         export DIRNAME=dirname
         export BASENAME=basename
         export EXPR=expr
         export LS=ls

(3) Hint unrealted to moveable installation

Another suggestion is: Don't use softlinks in your kaffe installations,
as IBM does with its JDK 1.4.1, this makes it not installable on
Smartcard with FAT file system, and I like to do that:
I have a application launchable form USB-stick Sandisk curiser (256MB)
with SUN JDK for Linux and Qindows and my application runs from this
smartcard on linux, windows and zaurus (and if I become rich some day,
I buy a WinCE device ... :-<).
IBM's JDK is not useable for that purpose :-(.

End of file

More information about the kaffe mailing list