Re: Java Security classes available
Hi, I'll take care of this. -Patrik Patrik Reali http://www.reali.ch/~patrik/ --On Sonntag, 14. März 2004 11:15 +0100 Ewout Prangsma [EMAIL PROTECTED] wrote: Hi all, In JNode (a Java OS using a derived classpath version) we've implemented the Java Security architecture. During the implementation several bugs in classpath have been fixed. If you need them, feel free to get them from our CVS server (http://cvs.sourceforge.net/viewcvs.py/jnode after a SF delay) or contact me. The following classes have been fixed / created gnu.java.security.PolicyFile gnu.java.security.actions.GetBooleanAction gnu.java.security.actions.GetIntegerAction gnu.java.security.actions.GetPropertiesAction gnu.java.security.actions.GetPropertyAction gnu.java.security.actions.GetPolicyAction gnu.java.security.actions.InvokeAction gnu.java.security.actions.SetPropertyAction java.awt.Toolkit java.io.FilePermission java.net.SocketPermission java.security.CodeSource java.util.TimeZone java.util.Locale java.util.PropertyPermission The implementation of the access control itself can be found in: org.jnode.vm.VmAccessController org.jnode.vm.VmAccessControlContext Regards Ewout ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: currentClassLoader problem
Thanks for the response Andrew. Index: java/lang/ClassLoader.java === + static private final native ClassLoader getClassLoader0(Class c); Shouldn't this be a VMClassLoader method rather than a new native method in ClassLoader? Thanks, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: currentClassLoader problem
Andrew,
I just realized that this code isn't in the Classpath version at all.
David
Index: java/lang/VMSecurityManager.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/VMSecurityManager.java,v
retrieving revision 1.2
diff -c -2 -p -r1.2 VMSecurityManager.java
*** java/lang/VMSecurityManager.java 5 Dec 2002 00:49:29 - 1.2
--- java/lang/VMSecurityManager.java 15 Mar 2004 09:54:54 -
*** class VMSecurityManager
*** 55,63
// FIXME this implementation is a bit wrong too -- the docs say we
// must also consider ancestors of the system class loader.
Class[] classStack = getClassContext ();
for (int i = 0; i classStack.length; i++)
{
ClassLoader loader = classStack[i].getClassLoader();
! if (loader != null)
return loader;
}
--- 55,64
// FIXME this implementation is a bit wrong too -- the docs say we
// must also consider ancestors of the system class loader.
+ ClassLoader systemClassLoader =
VMClassLoader.getSystemClassLoader();
Class[] classStack = getClassContext ();
for (int i = 0; i classStack.length; i++)
{
ClassLoader loader = classStack[i].getClassLoader();
! if (loader != null loader != systemClassLoader)
return loader;
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Bugs #7123, Bad results for QuadCurve2D.solveQuadratic
Hi all, any opinions about what to do about Classpath Bug #7123? Bad results for QuadCurve2D.solveQuadratic https://savannah.gnu.org/bugs/?func=detailitemitem_id=7123 Would it be correct to amend the API documentation, saying that correct results cannot be expected for input coefficients that have no exact representation in IEEE 754? -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
More ClassLoader problems
There seems to be some general confusion, concerning the bootstrap classloader, which is often represented as null, and the system or application classloader - as returned by ClassLoader.getSystemClassLoader - which is never null. For example, the class docs for java.lang.Class states: Arrays with identical type and number of dimensions share the same class (and null system ClassLoader, incidentally). First the system classloader is not null. Second, arrays have the same classloader as their element type which is null only if the element type is a primitive of itself loaded by the bootstrap loader. Then in the docs for Class.getClassLoader() it again incorrectly states If it was loaded by the system classloader this method will return null. system should be bootstrap. Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Bugs #7123, Bad results for QuadCurve2D.solveQuadratic
Would it be correct to amend the API documentation, saying that correct results cannot be expected for input coefficients that have no exact representation in IEEE 754? That would be reasonable IMO. I'm pretty sure that some of the QuadCurve2D testcases fail with Sun's J2SE 1.4.2 on my Intel / Linux machine at home. [I'll recheck ... ] -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Dumb build error
Just tried to build 0.8. After a minor .configure problem I got around by install libgtk2.0devel running make caused the following problem: [EMAIL PROTECTED]:~/devel/classpath/classpath-0.08$ make Making all in lib make[1]: Entering directory `/home/adam/devel/classpath/classpath-0.08/lib' top_builddir=.. /bin/sh ./gen-classlist.sh standard /usr/bin/gcj --bootclasspath '' -classpath ..:../external/jaxp/source:../vm/current:.: -C -d . @classes ../java/security/cert/X509Certificate.java:143: error: Class `java.security.cert.X509Certificate' can't subclass interface `java.security.Certificate'. public abstract class X509Certificate extends Certificate implements X509Extension ^ gcj --version gcj (GCC) 3.3.3 (Debian) The rest of the output from .configure follows: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking for a BSD-compatible install... /usr/bin/install -c checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag CXX to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag F77 to libtool checking
Re: Dumb build error
Hi Adam, On Tue, 2004-03-16 at 04:13, Adam Young wrote: /usr/bin/gcj --bootclasspath '' -classpath ..:../external/jaxp/source:../vm/current:.: -C -d . @classes ../java/security/cert/X509Certificate.java:143: error: Class `java.security.cert.X509Certificate' can't subclass interface `java.security.Certificate'. public abstract class X509Certificate extends Certificate implements X509Extension ^ gcj --version gcj (GCC) 3.3.3 (Debian) That is strange. I have gcj (GCC) 3.3.3 (Debian 20040306) which doesn't show that error. Somehow your gcj version gets java.security.Certificate and java.security.cert.Certificate confused. Could you try rewriting it to X509Certificate extends java.security.cert.Certificate explicitly? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Dumb build error
Am Dienstag, 16. März 2004 08:41 schrieb Mark Wielaard: Hi Adam, On Tue, 2004-03-16 at 04:13, Adam Young wrote: /usr/bin/gcj --bootclasspath '' -classpath ..:../external/jaxp/source:../vm/current:.: -C -d . @classes ../java/security/cert/X509Certificate.java:143: error: Class `java.security.cert.X509Certificate' can't subclass interface `java.security.Certificate'. public abstract class X509Certificate extends Certificate implements X509Extension ^ gcj --version gcj (GCC) 3.3.3 (Debian) That is strange. I have gcj (GCC) 3.3.3 (Debian 20040306) which doesn't show that error. Somehow your gcj version gets java.security.Certificate and java.security.cert.Certificate confused. Could you try rewriting it to X509Certificate extends java.security.cert.Certificate explicitly? yeah, I just tried with gcj 3.3.3 and 3.5.0 here too and all was fine. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
