java-devel July 2006

java-devel@lists.fedoraproject.org

11 participants
16 discussions

aot-compile-rpm problem
by Anthony Green 23 Aug '06

23 Aug '06

Hi, On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 version is written last, because aot-compile-rpm's LIBDIR is set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm building. The fix is to make sure I just "yum install java-1.4.2-gcj-compat-devel.x86_64". Is this expected behaviour? I don't remember this being a problem for my in the past. Thanks, AG

4 12

Re: ssl connections, cacerts
by Anthony Green 03 Aug '06

03 Aug '06

On Mon, 2006-07-31 at 13:24 -0700, Casey Marshall wrote: > Most GNU/Linux distributions have packages for a list of root > certificates, usually as just a bunch of separate PEM files. Does > Fedora have something like that? Yes. It looks like openssl ships with certificates. kdelibs does as well. Perhaps there are others. > If so, one good way to fix this > would be to generate a cacerts file (using gkeytool) that contains > the same list of certificates, and add that to the GCJ RPM. It is > somewhat preferable for distributions to figure out which root > certificates they want to use, than for Classpath to arbitrarily > decide what certificates to include, IMO. Sounds good. This should probably go in the java-1.4.2-gcj-compat package (our JDK compatibility layer on top of gcj). We could simply "BuildRequire" openssl to generate and package the cacerts files. > Does that make sense? I can explain how to generate such a cacerts > file from a bunch of separate certificates, if you like. That would be great. I've never run gkeytool before. > Additionally, loading cacerts isn't even necessary with Classpath: > Jessie uses an internal list of root certificates (approximately the > same list you'll find by default in e.g. Firefox) if no other > certificates are provided. Nice to see that the RSSOwl people had to > make this crap so "Easy." A bug (or maybe just some harsh words) > upstream is also advisable. Ok. Thanks, AG

3 5

gcjwebplugin has landed in Rawhide
by Thomas Fitzsimmons 03 Aug '06

03 Aug '06

Hi, gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Rawhide last night along with java-1.4.2-gcj-compat-plugin which installs an alternatives-managed "libjavaplugin.so" symlink in /usr/lib/mozilla/plugins. I closed the long-standing "Inclusion of gcjwebplugin" bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537 and updated the release notes with a "Handling Java Applets" section: http://fedoraproject.org/wiki/Docs/Beats/Java Rawhide users can install gcjwebplugin with "yum install java-1.4.2-gcj-compat-plugin". Please try this out, file bugs and comment on the release note additions. The GNU Classpath AWT and Swing code was in a state of flux when the backport that included gcjwebplugin was done (because of a large Java2D rewrite to make the Cairo backend the default), so there are some regressions in AWT and Swing applications for FC6test2. My post-test2 plan for gcjwebplugin is to gage the reaction of Rawhide users, and also to do another GUI backport from GNU Classpath HEAD to Fedora's libgcj, to fix the AWT and Swing regressions. If the reaction turns out to be overly negative, even after the new AWT and Swing backport, we can always make gcjwebplugin not installed by default, for FC6test3. For FC6test2 though, it is installed by default if the Internet group is selected. Tom

4 5

fc6 extras java status
by Anthony Green 01 Aug '06

01 Aug '06

Things are a little ugly in fc6 extras java land... * Azureus makes my computer practically unusable because of libgcj's new SecureRandom implementation. I've filed a bug for a work around here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200653 Mark tells me this is the root cause of some crypto test timeout problems on the autobuilder as well. Casey says that this same code doesn't seem to have a problem on jamvm. * RSSOwl no longer fails to start because of the zip problem (thanks tromey!), but now crashes in _Jv_ClassReader::checkExtends (super = 0x3). I'm rebuilding libgcj with -O0 -g3 to debug. * I've updated jogl to jsr231 1.0 beta 5. The good news is that it builds sans patching! The bad news is that demos crash the X server (like, try resizing the gears demo). I think this is an X problem, so I'm going to push this out anyways because the latest WW2D (and "WW2D plus one", which looks awesome -- http://www.alpix.com/3d/worldwin/WW2d_Java.html) use this version of the jogl API. * kawa is fine. AG

5 13

gnu-crypto & jessie
by Anthony Green 01 Aug '06

01 Aug '06

Do we still need these packages in fc6 or did they get merged into libgcj? Anybody know? Thanks, AG

2 1

ssl connections, cacerts
by Anthony Green 31 Jul '06

31 Jul '06

Now that rssowl is running (thanks aph), I wanted to see if https rss feeds would work (like those provided by bugzilla). Our classpath.security file is messed up, but I think fitzsim just fixed this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200701 When I fix it manually, and try to access an https rss feed, I get... Exception in thread "Load Feed Thread" org.apache.commons.httpclient.HttpClientError: java.security.KeyStoreException: java.io.FileNotFoundException: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/security/cacerts (No such file or directory) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createEasySSLContext(Unknown Source) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.getSSLContext(Unknown Source) at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createSocket(Unknown Source) at org.apache.commons.httpclient.HttpConnection.open(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so) at net.sourceforge.rssowl.dao.ConnectionManager.openConnection(Unknown Source) at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source) at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(Unknown Source) at net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(Unknown Source) at net.sourceforge.rssowl.controller.thread.FeedLoader.run(Unknown Source) We don't have a cacerts file. How is this supposed to work? AG

1 0

[poohba@blkpoohba.dyndns.org: Getting java errors when trying to install limewire]
by Andrew Overholt 31 Jul '06

31 Jul '06

See below from fedora-list. We don't expect limewire to work with what I'm assuming is FC5, right? Has anyone tried it with rawhide? Andrew ----- Forwarded message from Poohba <poohba(a)blkpoohba.dyndns.org> ----- > From: Poohba <poohba(a)blkpoohba.dyndns.org> > To: For users of Fedora Core releases <fedora-list(a)redhat.com> > X-Mailer: Evolution 2.6.0 (2.6.0-1) > Date: Tue, 25 Jul 2006 20:10:20 -0400 > Subject: Getting java errors when trying to install limewire > > Is this because I don't have the correct or all of the java's needed? > > ./LimeWireLinux.bin > Preparing to install... > Extracting the installation resources from the installer archive... > Configuring the installer for this system's environment... > > Launching installer... > > Exception in thread "main" java.lang.NoClassDefFoundError: > com.zerog.lax.LAX > at gnu.java.lang.MainThread.run (libgcj.so.7) > Caused by: java.lang.ClassNotFoundException: com.zerog.lax.LAX not found > in > gnu.gcj.runtime.SystemClassLoader{urls=[file:/tmp/install.dir.14630/InstallerData/,file:/tmp/install.dir.14630/InstallerData/installer.zip], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > at java.net.URLClassLoader.findClass (libgcj.so.7) > at java.lang.ClassLoader.loadClass (libgcj.so.7) > at java.lang.ClassLoader.loadClass (libgcj.so.7) > at java.lang.Class.forName (libgcj.so.7) > at gnu.java.lang.MainThread.run (libgcj.so.7) > > > yum install java* > Loading "installonlyn" plugin > Setting up Install Process > Setting up repositories > core > [1/3] > extras > [2/3] > updates > [3/3] > Reading repository metadata in from local files > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for javacc-demo to pack into transaction set. > javacc-demo-3.2-1jpp_6fc. 100% |=========================| 20 kB > 01:33 > ---> Package javacc-demo.i386 0:3.2-1jpp_6fc set to be updated > ---> Downloading header for java-clearsilver to pack into transaction > set. > ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/i386/java-clears…: [Errno 4] IOError: [Errno ftp error] (111, 'Connection refused') > Trying other mirror. > java-clearsilver-0.10.3-3 100% |=========================| 3.8 kB > 00:00 > ---> Package java-clearsilver.i386 0:0.10.3-3.fc5 set to be updated > ---> Downloading header for javacc to pack into transaction set. > ftp://ftp.tecnoera.com/pub/fedora/linux/core/5/i386/os/Fedora/RPMS/javacc-3…: [Errno 4] IOError: [Errno ftp error] timed out > Trying other mirror. > javacc-3.2-1jpp_6fc.i386. 100% |=========================| 4.9 kB > 00:00 > ---> Package javacc.i386 0:3.2-1jpp_6fc set to be updated > ---> Downloading header for java-1.4.2-gcj-compat-javadoc to pack into > transaction set. > java-1.4.2-gcj-compat-jav 100% |=========================| 887 kB > 00:01 > ---> Package java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh set > to be updated > ---> Downloading header for javacc-manual to pack into transaction set. > javacc-manual-3.2-1jpp_6f 100% |=========================| 5.6 kB > 00:00 > ---> Package javacc-manual.i386 0:3.2-1jpp_6fc set to be updated > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Installing: > java-1.4.2-gcj-compat-javadoc i386 1.4.2.0-40jpp_83rh core 21 > M > java-clearsilver i386 0.10.3-3.fc5 extras > 85 k > javacc i386 3.2-1jpp_6fc core > 915 k > javacc-demo i386 3.2-1jpp_6fc core > 95 k > javacc-manual i386 3.2-1jpp_6fc core > 76 k > > Transaction Summary > ============================================================================= > Install 5 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 22 M > Is this ok [y/N]: y > Downloading Packages: > (1/5): javacc-demo-3.2-1j 100% |=========================| 95 kB > 00:00 > (2/5): java-clearsilver-0 100% |=========================| 85 kB > 00:00 > (3/5): javacc-3.2-1jpp_6f 100% |=========================| 915 kB > 00:03 > (4/5): java-1.4.2-gcj-com 100% |=========================| 21 MB > 00:18 > (5/5): javacc-manual-3.2- 100% |=========================| 76 kB > 00:00 > warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID > 1ac70ce6 > Public key for java-clearsilver-0.10.3-3.fc5.i386.rpm is not installed > Retrieving GPG key from > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > Importing GPG key 0x1AC70CE6 "Fedora Project > <fedora-extras(a)fedoraproject.org>" > Is this ok [y/N]: y > Key imported successfully > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: javacc-manual ######################### > [1/5] > Installing: javacc-demo ######################### > [2/5] > Installing: java-clearsilver ######################### > [3/5] > Installing: javacc ######################### > [4/5] > Installing: java-1.4.2-gcj-compat-javado ######################### > [5/5] > > Installed: java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh > java-clearsilver.i386 0:0.10.3-3.fc5 javacc.i386 0:3.2-1jpp_6fc > javacc-demo.i386 0:3.2-1jpp_6fc javacc-manual.i386 0:3.2-1jpp_6fc > Complete! > > > > -- > fedora-list mailing list > fedora-list(a)redhat.com > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list ----- End forwarded message -----

2 1

Regression in libgcj: spurious IncompatibleClassChangeError with BC-compiled code.
by Andrew Haley 25 Jul '06

25 Jul '06

This happens if a class and its superclass are loaded by the boot classloader. If one if them is in the precompiled database and one isn't, we fail this check: if ( sub->loader != super->loader || !_Jv_ClassNameSamePackage (sub->name, super->name)) { throw_incompatible_class_change_error (sub->getName ()); } We fail this check becasue of this line in natVMClassLoader.cc // Record the defining loader. For the bootstrap class loader, // we record NULL. if (loader != bootLoader) klass->loader = loader; So, at the point of this test: sub->loader != super->loader sub->loader == bootLoader, and super->loader == NULL. All this happens because when a class is loaded by natSharedLibLoader, we do this: void _Jv_sharedlib_register_hook (jclass cls) { cls->protectionDomain = curHelper->domain; cls->loader = curLoader; if (! cls->engine) cls->engine = &_Jv_soleCompiledEngine; curHelper->registerClass(cls->getName(), cls); } note that we always set the loader; we don't check for it being the bootLoader. There are several ways to fix this. We need it for FC6. Andrew. 2006-07-25 Andrew Haley <aph(a)redhat.com> * gnu/gcj/runtime/natSharedLibLoader.cc (init): Don't set curLoader to VMClassLoader::bootLoader. --- natSharedLibLoader.cc~ 2006-07-25 16:47:05.000000000 +0100 +++ natSharedLibLoader.cc 2006-07-25 18:11:25.000000000 +0100 @@ -20,6 +20,8 @@ #include <java/lang/UnsupportedOperationException.h> #include <java/lang/UnknownError.h> +#include <java/lang/VMClassLoader.h> + // If we're using the Boehm GC, then we need this include to override dlopen. #ifdef HAVE_BOEHM_GC // Set GC_DEBUG before including gc.h! @@ -87,7 +89,8 @@ flags = RTLD_GLOBAL | RTLD_LAZY; JvSynchronize dummy1(&java::lang::Class::class$); SharedLibDummy dummy2; - curLoader = loader; + curLoader = ((void*)loader == java::lang::VMClassLoader::bootLoader + ? NULL : loader); curHelper = this; _Jv_RegisterClassHook = _Jv_sharedlib_register_hook; _Jv_RegisterCoreHook = core_hook;

2 2

CDT hover error
by Andrew Overholt 24 Jul '06

24 Jul '06

Hi Jeff, With the latest autotools work you've done (in eclipse-cdt in rawhide), I can't seem to get hover help working. I get this in <workspace>/.metadata/.log: !ENTRY org.eclipse.cdt.ui 4 2 2006-07-24 14:18:24.831 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.cdt.ui". !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.FileLocator.toFileURL(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.Platform.asLocalURL(org.eclipse.core.runtime_3.2.0.v20060603.jar.so) at com.redhat.eclipse.cdt.autotools.ui.LibHover.buildDocPath(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so) at com.redhat.eclipse.cdt.autotools.ui.LibHover.initialize(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor$1.run(CHelpProviderDescriptor.java:106) at org.eclipse.core.runtime.SafeRunner.run(org.eclipse.equinox.common_3.2.0.v20060603.jar.so) at org.eclipse.core.runtime.Platform.run(org.eclipse.core.runtime_3.2.0.v20060603.jar.so) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:111) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:126) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:132) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:152) at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getEnabledMatchedCHelpBooks(CHelpProviderDescriptor.java:156) at org.eclipse.cdt.internal.ui.text.CHelpSettings.getFunctionInfo(CHelpSettings.java:117) at org.eclipse.cdt.internal.ui.CHelpProviderManager.getFunctionInfo(org.eclipse.cdt.ui_3.1.0.200607240538.jar.so) at org.eclipse.cdt.internal.ui.text.c.hover.CDocHover.getHoverInfo(CDocHover.java:71) at org.eclipse.cdt.internal.ui.text.c.hover.BestMatchHover.getHoverInfo(BestMatchHover.java:100) at org.eclipse.cdt.internal.ui.text.c.hover.CEditorTextHoverProxy.getHoverInfo(CEditorTextHoverProxy.java:64) at org.eclipse.jface.text.TextViewerHoverManager$4.run(org.eclipse.jface.text_3.2.0.v20060605-1400.jar.so) Any idea what's going on here? Thanks, Andrew

1 0

where is libjawt.so?
by Anthony Green 24 Jul '06

24 Jul '06

Tom, Jakub, I'm trying to rebuild jogl against the latest devel bits and I don't see where libjawt.so moved to. I only see libgcjawt.so. Pointers? Thanks! AG

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2006