Hello,

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

mle

-------------------------------------------------------------------------
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 exception
in toString(), if constructed with oCerts == null (and perhaps in other situations),
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) {
                                oDest.addElement(oPerm);
                        } 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:

$INSTDIR/kaffe-1.1.1/kaffe/scripts

each script starts with prefix
    ...
    prefix="@prefix@"
    exec_prefix="@exec_prefix@"
    ...

I suggest to modify this lines to
    ...
    prefix="@prefix@"
    exec_prefix="@exec_prefix@"
    ...
    scriptpath_to_root=".."
    . $(dirname $0)/prefix_calculator $0 $scriptpath_to_root

in the included bash script you can adjust the variables

    prefix
    exec_prefix

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
                TARGET="$DIR/$TARGET"
            fi
        done
        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
        fi
        varPWD=$(pwd)
        if test -d $varFile ; then
            cd $varFile
            varFile=$(pwd)
        else
            cd $($DIRNAME $varFile)
            varFile=$(pwd)/$($BASENAME $varFile)
        fi
        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"
    else
        # Linux case
        export DIRNAME=dirname
        export BASENAME=basename
        export EXPR=expr
        export LS=ls
    fi

(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


_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Reply via email to