A problem in native methods implementation of GtkToolkit
Hi, A class, gnu.java.awt.peer.gtk.GtkToolkit, has serveral native methods including gtkInit() and gtkMain(). The native implementation in gnu_java_awt_peer_gtk_GtkToolkit.c declares a variable of "static jclass gtktoolkit" which is assigned by JNI call, (*env)->FindClass(env, "gnu/java/awt/peer/gtk/GtkMainThread") in gtkInit(). A problem is that gtktoolkit is used in gtkMain() while it is remained as a local reference, so that it might occur errors. I think gtktoolkit should be a global reference. How about this?
Re: A problem in native methods implementation of GtkToolkit
Hi, > A class, gnu.java.awt.peer.gtk.GtkToolkit, has serveral native methods > including gtkInit() and gtkMain(). > The native implementation in gnu_java_awt_peer_gtk_GtkToolkit.c > declares a variable of "static jclass gtktoolkit" which is assigned by > JNI call, (*env)->FindClass(env, > "gnu/java/awt/peer/gtk/GtkMainThread") in gtkInit(). > > A problem is that gtktoolkit is used in gtkMain() while it is remained > as a local reference, so that it might occur errors. > > I think gtktoolkit should be a global reference. That's correct. I'll fix this. Thanks. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
Re: Classpath 0.96 Imminent
Hi, > > > After I posted that I realized that I could have made a Firefly > > > reference and suggested "Too pretty to die"... I don't know if any > > > Classpath hackers are browncoats though. I'd have chosen 'Too old to rock'n'roll, Too young to die' ;-) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
Re: Classpath 0.96 Imminent
On Wednesday 17 October 2007 02:20:13 you wrote: > Hi, > > My congratulations on the release! Sorry I've been absent the last > couple of months; I'm back at school and it's been sucking up all my time. > > > After I posted that I realized that I could have made a Firefly > > reference and suggested "Too pretty to die"... I don't know if any > > Classpath hackers are browncoats though. > > I got the reference, and for the record, that would have been an > *amazing* release name!!! =) > > Francis We'll put it in the pot for 0.97... -- Andrew :)
Re: Classpath 0.96 Imminent
Il giorno mer, 17/10/2007 alle 12.33 +0200, Roman Kennke ha scritto: > Hi, > > > > After I posted that I realized that I could have made a Firefly > > > > reference and suggested "Too pretty to die"... I don't know if any > > > > Classpath hackers are browncoats though. > > I'd have chosen 'Too old to rock'n'roll, Too young to die' ;-) * "Better to burn our than to fade away" * "Beautiful as a rock on a cop's face" [1] * "The great rock 'n' code swindle" Mario :) [1] Punk is... -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: [EMAIL PROTECTED] pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wednesday 17 October 2007 16:27:38 you wrote:
> Andrew John Hughes writes:
> > On Wednesday 17 October 2007 15:14:44 you wrote:
> > > Andrew John Hughes writes:
> > > > On Monday 15 October 2007 10:09:02 Andrew Haley wrote:
> > > > > Andrew John Hughes writes:
> > > > > > Our com.sun.tools.javac.Main wrapper fails in the majority
> > > > > > of cases (e.g. via Ant) because of a lack of a bootclasspath.
> > > > > > With this patch I can build code via ant using this wrapper.
> > > > > >
> > > > > > Changelog:
> > > > > >
> > > > > > 2007-10-12 Andrew John Hughes <[EMAIL PROTECTED]>
> > > > > >
> > > > > > PR classpath/33385:
> > > > > > * tools/com/sun/tools/javac/Main.java:
> > > > > > Add bootclasspath and 1.5 options so the compiler
> > > > > > can run.
> > > > >
> > > > > Oddly, we've been building via Ant for years now, without needing
> > > > > this patch. You're doing something wrong.
> > > >
> > > > Have you looked at the referenced bug? All I'm doing is running
> > > > 'ant' which I assume should work. I've not seen this work since it
> > > > went into Classpath in February, so perhaps something got broken
> > > > then. I have to use these options to run ecj externally FWIW.
> > >
> > > Then something is wrong with your configuration.
> > >
> > > ecj uses System.getProperty("java.home") to find rt.jar. The most
> > > likely cause of your problem is that you have not correctly set this
> > > property.
> > >
> > > The code looks like this:
> > >
> > >if (bootclasspaths.size() == 0) {
> > >
> > > ...
> > >
> > >if (getJavaHome() != null) {
> > > File[] directoriesToCheck = new File[] {
> > > new File(getJavaHome(), "lib") //$NON-NLS-1$
> > > };
> > > File[][] systemLibrariesJars =
> > > getLibrariesFiles(directoriesToCheck); if (systemLibrariesJars !=
> > > null) {
> >
> > So presumably JAVA_HOME should be set?
>
> No, you shouldn't have to set it yourself, although you may choose to
> do so. Your Java VM should set the java.home system property to point
> to your Java installation directory. If running ecj doesn't find
> rt.jar it is a problem with your JRE's installation.
>
Right, but this can be meaningless in some cases e.g. cacao and jamvm may not
be installed in the same place as the class library. It only really works
when everything is predetermined by some overarching Java environment as with
gcj. For example, with cacao and classpath, I have to manually put something
together to emulate the JDK tree.
> > rt.jar seems to be in jre/lib so the above would fail presumably.
>
> I don't understand why you say this. If rt.jar is in
> /jre/lib then it will succeed.
>
I get that from the construction of the File object above which appends lib to
the value of java.home and not jre/lib.
> Andrew.
Thanks,
--
Andrew :)
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Andrew John Hughes writes: > On Wednesday 17 October 2007 16:27:38 you wrote: > > Andrew John Hughes writes: > > > On Wednesday 17 October 2007 15:14:44 you wrote: > > > > > > So presumably JAVA_HOME should be set? > > > > No, you shouldn't have to set it yourself, although you may choose to > > do so. Your Java VM should set the java.home system property to point > > to your Java installation directory. If running ecj doesn't find > > rt.jar it is a problem with your JRE's installation. > > Right, but this can be meaningless in some cases e.g. cacao and > jamvm may not be installed in the same place as the class library. > It only really works when everything is predetermined by some > overarching Java environment as with gcj. For example, with cacao > and classpath, I have to manually put something together to emulate > the JDK tree. So that is a correct installation. This isn't just for ecj: other java packages expect to be able to find rt.jar under java.home. It's not just ecj. You're fixing the bug so that ecj works, but you're not fixing the fundamental problem. This problem is the fact that Java apps assume that rt.jar is under java.home. > > > rt.jar seems to be in jre/lib so the above would fail presumably. > > > > I don't understand why you say this. If rt.jar is in > > /jre/lib then it will succeed. > > > > I get that from the construction of the File object above which appends lib > to > the value of java.home and not jre/lib. I don't understand. java.home is suppoed to point to a valid jre. Andrew.
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wed, 2007-10-17 at 16:51 +0100, Andrew Haley wrote: > > I get that from the construction of the File object above which appends > lib to > > the value of java.home and not jre/lib. > > I don't understand. java.home is suppoed to point to a valid jre. That's true. But a normal CACAO or JamVM installation does not have a jre/ directory, as we follow the GNU rules. - twisti
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Christian Thalinger writes: > On Wed, 2007-10-17 at 16:51 +0100, Andrew Haley wrote: > > > I get that from the construction of the File object above which appends > > lib to > > > the value of java.home and not jre/lib. > > > > I don't understand. java.home is suppoed to point to a valid jre. > > That's true. But a normal CACAO or JamVM installation does not have a > jre/ directory, as we follow the GNU rules. Sure, but real-world Java applications assume a particular layout. Maybe they shouldn't, but they do. It's not just ecj that makes this assumption to find things. The easiest fix is to install a few symlinks in the appropriate places. You can't tell me that GNU rules disallow this, surely. Andrew.
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wed, 2007-10-17 at 17:12 +0100, Andrew Haley wrote: > > That's true. But a normal CACAO or JamVM installation does not > have a > > jre/ directory, as we follow the GNU rules. > > Sure, but real-world Java applications assume a particular layout. > Maybe they shouldn't, but they do. It's not just ecj that makes this > assumption to find things. The easiest fix is to install a few > symlinks in the appropriate places. You can't tell me that GNU rules > disallow this, surely. I know they do and a long time ago we tried to mimic a JDK directory structure when installing, but we removed all that code (I think because of Debian's rules, but not sure about that). Normally distribution packagers care about this JRE-layout (as we call it): http://packages.debian.org/sid/cacao/alpha/filelist CACAO also has a --with-jre-layout configure option where we search for the classes and for the libraries at runtime, relative to the binary (just as HotSpot does). - twisti
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wed, Oct 17, 2007 at 07:44:24PM +0200, Christian Thalinger wrote: > On Wed, 2007-10-17 at 17:12 +0100, Andrew Haley wrote: > > > That's true. But a normal CACAO or JamVM installation does not > > have a > > > jre/ directory, as we follow the GNU rules. > > > > Sure, but real-world Java applications assume a particular layout. > > Maybe they shouldn't, but they do. It's not just ecj that makes this > > assumption to find things. The easiest fix is to install a few > > symlinks in the appropriate places. You can't tell me that GNU rules > > disallow this, surely. > > I know they do and a long time ago we tried to mimic a JDK directory > structure when installing, but we removed all that code (I think because > of Debian's rules, but not sure about that). > > Normally distribution packagers care about this JRE-layout (as we call > it): > > http://packages.debian.org/sid/cacao/alpha/filelist > > CACAO also has a --with-jre-layout configure option where we search for > the classes and for the libraries at runtime, relative to the binary > (just as HotSpot does). It would be great if cacao (or any another free runtime) puts the according symlinks in some configurable place like /usr/lib/jvm/java-$JAVAVERSION-$NAME in addition to the normal install into into the $PREFIX (normally /usr in distros). Cheers Michael
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi, On 10/17/07, Michael Koch <[EMAIL PROTECTED]> wrote: > > It would be great if cacao (or any another free runtime) puts the > according symlinks in some configurable place like > /usr/lib/jvm/java-$JAVAVERSION-$NAME in addition to the normal install > into into the $PREFIX (normally /usr in distros). > Something like: /usr/lib/jvm/java-1.5.0-jamvm /usr/lib/jvm/java-1.5.0-jamvm/bin /usr/lib/jvm/java-1.5.0-jamvm/lib /usr/lib/jvm/java-1.5.0-jamvm/jre /usr/lib/jvm/java-1.5.0-jamvm/jre/bin /usr/lib/jvm/java-1.5.0-jamvm/jre/lib ? Rob. > > Cheers > Michael > >
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wed, Oct 17, 2007 at 07:14:05PM +0100, Robert Lougher wrote: > Hi, > > On 10/17/07, Michael Koch <[EMAIL PROTECTED]> wrote: > > > > It would be great if cacao (or any another free runtime) puts the > > according symlinks in some configurable place like > > /usr/lib/jvm/java-$JAVAVERSION-$NAME in addition to the normal install > > into into the $PREFIX (normally /usr in distros). > > > > Something like: > > /usr/lib/jvm/java-1.5.0-jamvm > /usr/lib/jvm/java-1.5.0-jamvm/bin > /usr/lib/jvm/java-1.5.0-jamvm/lib > /usr/lib/jvm/java-1.5.0-jamvm/jre > /usr/lib/jvm/java-1.5.0-jamvm/jre/bin > /usr/lib/jvm/java-1.5.0-jamvm/jre/lib In general yes, but this should be all directories with needed links inside, not the directories being symlinked itself. This would make it much more flexible for distros. Cheers, Michael
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi Michael, On 10/17/07, Michael Koch <[EMAIL PROTECTED]> wrote: > On Wed, Oct 17, 2007 at 07:14:05PM +0100, Robert Lougher wrote: > > > Something like: > > > > /usr/lib/jvm/java-1.5.0-jamvm > > /usr/lib/jvm/java-1.5.0-jamvm/bin > > /usr/lib/jvm/java-1.5.0-jamvm/lib > > /usr/lib/jvm/java-1.5.0-jamvm/jre > > /usr/lib/jvm/java-1.5.0-jamvm/jre/bin > > /usr/lib/jvm/java-1.5.0-jamvm/jre/lib > > In general yes, but this should be all directories with needed links > inside, not the directories being symlinked itself. This would make it > much more flexible for distros. > Yes, of course :) Anybody see any problems with making a symlink from rt.jar to glibj.zip, i.e. /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar -> /usr/local/classpath/share/classpath/glibj.zip ? Probably a stupid question, but as far as I'm aware (I'm at work and can't look), glibj.zip doesn't have a manifest or index file, but the META-INF directory is optional in the Jar file format... This could be done during install, as long as Classpath was already installed. Thanks, Rob. > > Cheers, > Michael >
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hello Robert, On Wed, Oct 17, 2007 at 07:44:21PM +0100, Robert Lougher wrote: > Anybody see any problems with making a symlink from rt.jar to glibj.zip, i.e. > > /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar -> > /usr/local/classpath/share/classpath/glibj.zip ? > > Probably a stupid question, but as far as I'm aware (I'm at work and > can't look), glibj.zip doesn't have a manifest or index file, but the > META-INF directory is optional in the Jar file format... > > This could be done during install, as long as Classpath was already installed. Yes, I see currently no reason against this. Cheers, Michael
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi Michael, > On Wed, Oct 17, 2007 at 07:44:21PM +0100, Robert Lougher wrote: > > Anybody see any problems with making a symlink from rt.jar to glibj.zip, > > i.e. > > > > /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar -> > > > > /usr/local/classpath/share/classpath/glibj.zip ? > > > > Probably a stupid question, but as far as I'm aware (I'm at work and > > can't look), glibj.zip doesn't have a manifest or index file, but the > > META-INF directory is optional in the Jar file format... > > > > This could be done during install, as long as Classpath was already > > installed. > > Yes, I see currently no reason against this. > Great! I'll see if I can get this done for the next release (which has been "ready" for a month, but something always crops up at the last minute!). Thanks, Rob. > > Cheers, > Michael >
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
On Wednesday 17 October 2007 19:57, Robert Lougher wrote: > Hi Michael, > > > On Wed, Oct 17, 2007 at 07:44:21PM +0100, Robert Lougher wrote: > > > Anybody see any problems with making a symlink from rt.jar to > > > glibj.zip, i.e. > > > > > > /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar -> > > > > > > /usr/local/classpath/share/classpath/glibj.zip ? > > > > > > Probably a stupid question, but as far as I'm aware (I'm at work and > > > can't look), glibj.zip doesn't have a manifest or index file, but the > > > META-INF directory is optional in the Jar file format... > > > > > > This could be done during install, as long as Classpath was already > > > installed. > > > > Yes, I see currently no reason against this. > > Great! I'll see if I can get this done for the next release (which > has been "ready" for a month, but something always crops up at the > last minute!). > > Thanks, > Rob. > > > Cheers, > > Michael Yeah that symlink seems fine, it's exactly what I do to provide rt.jar. I've had to fake this for building JikesRVM: http://developer.classpath.org/mediation/BuildingJikesRvmWithClasspath -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net pgpUaOtckmKI2.pgp Description: PGP signature
