FC5 release notes for java
by Anthony Green
I've been really bad about preparing the FC5 release notes for java. I
wrote the followup up today, which I think covers the number 1 issue.
Comments?
AG
Fedora Core does not include "Java(tm)", but it does include a tools
suite and execution environment based on Free Software technologies
that is capable of building and running many useful programs written
in the Java programming language, including the Eclipse IDE, Tomcat,
and OpenOffice.org.
In addition to the Free Software stack, Fedora Core is designed to let
you install multiple Java implementations and switch between them
using the "alternatives" command line tool. However, every Java
system you install must be packaged using the JPackage Project's
packaging guidelines.
No proprietary Java vendor currently ships their products in JPackage
compatible RPMs. Do not install RPMs from vendors such as Sun
Microsystems, IBM or BEA without first repackaging them using the
appropriate JPackage wrapper or compatibility package. Failure to do
so will lead to unpredictable results.
Once installed properly, however, the root user should be able to
switch between "java" and "javac" implementations using the
"alternatives" command ("alternatives --config java" and "alternatives
--config javac").
Instructions on repackaging proprietary Java implementations may be
found here: http://www.fedorafaq.org/fc3/custom_java.html
AG
17 years, 3 months
Writing Gnome toolbar applet using java?
by Joe Desbonnet
I've got some server monitoring software written in Java. I'd like to
be able to add an icon to the Gnome toolbar for alerts (like the
Redhat Network Alert Notification Tool).
I presume this would involve libgnome-java (?). Has anyone written a
gnome applet in Java before?
Thanks,
Joe.
17 years, 4 months
patch to resurrect LD_PRELOAD hack
by Tom Tromey
This patch to libgcj would let us resurrect the LD_PRELOAD hack. The
idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj
startup, to avoid passing this to sub-processes which may not be
prepared for it.
This is quite ugly and, I think, won't be going into upstream libgcj.
Please comment.
Tom
Index: ChangeLog
from Tom Tromey <tromey(a)redhat.com>
* prims.cc (scrub_ld_preload): New function.
(_Jv_RunMain): Call it.
Index: prims.cc
===================================================================
--- prims.cc (revision 109835)
+++ prims.cc (working copy)
@@ -1339,10 +1339,51 @@
return 0;
}
+// If the PR 13212 workaround is mentioned in LD_PRELOAD, remove it.
+// If we don't remove it, it will be inherited by processes we exec(),
+// and this causes problems on some platforms. Note that this is
+// purely a hack and will go away once we have a new enough version of
+// the GC.
+static void
+scrub_ld_preload ()
+{
+ char *val = getenv ("LD_PRELOAD");
+ if (! val)
+ return;
+
+ char preload[strlen (val) + 1];
+ strcpy (preload, val);
+
+ char result[strlen (preload) + 2];
+ result[0] = '\0';
+
+ char *state = NULL;
+ for (char *word = strtok_r (preload, " ", &state);
+ word;
+ word = strtok_r (NULL, " ", &state))
+ {
+ int len = strlen (word);
+ if (len >= 11 && ! strcmp (word + len - 11, "/pr13212.so"))
+ {
+ // Don't include this one.
+ }
+ else
+ {
+ strcat (result, word);
+ strcat (result, " ");
+ }
+ }
+
+ setenv ("LD_PRELOAD", result, 1);
+}
+
void
_Jv_RunMain (JvVMInitArgs *vm_args, jclass klass, const char *name, int argc,
const char **argv, bool is_jar)
{
+ // Make sure LD_PRELOAD is clean before we might exec a process.
+ scrub_ld_preload ();
+
#ifndef DISABLE_MAIN_ARGS
_Jv_SetArgs (argc, argv);
#endif
17 years, 4 months
proposed rebuild-gcj-db patch
by Tom Tromey
We've had a problem on multiarch hosts where the gcj shared library
caches weren't being updated properly, causing programs to run
interpreted instead.
This patch works around the problem by looping over all the databases
it can find.
Comments? I'd particularly like to hear from Tom (Fitzsimmons), and
Gary...
Tom
Index: ChangeLog
from Tom Tromey <tromey(a)redhat.com>
* rebuild-gcj-db.in: Loop over /usr/lib*.
Index: rebuild-gcj-db.in
===================================================================
RCS file: /cvs/rhug/java-gcj-compat/rebuild-gcj-db.in,v
retrieving revision 1.7
diff -u -r1.7 rebuild-gcj-db.in
--- rebuild-gcj-db.in 16 Nov 2005 00:09:50 -0000 1.7
+++ rebuild-gcj-db.in 20 Jan 2006 23:44:24 -0000
@@ -13,8 +13,16 @@
fi
fi
-dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -p @LIBDIR@`
-dirname $dbLocation | xargs mkdir -p
-@GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -n $dbLocation 64
-find $dbLocation.d @LIBDIR@/gcj -follow -name '*.db' -print0 | \
- xargs -0 @GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -m $dbLocation $dbLocation
+# Rebuild all the standard databases.
+for base in /usr/lib*; do
+ dbLocation=`@GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -p $base`
+ libdir=$base/gcj
+ if ! test -d $dbLocation.d && ! test -d $libdir; then
+ # No shared libraries here.
+ continue
+ fi
+ dirname $dbLocation | xargs mkdir -p
+ @GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -n $dbLocation 64
+ find $dbLocation.d $libdir -follow -name '*.db' -print0 | \
+ xargs -0 @GCJ_BIN_DIR@/gcj-dbtool@gcc_suffix@ -m $dbLocation $dbLocation
+done
17 years, 4 months
Debugging info missing in some packages
by Andrew Haley
I've come across a few RPMS with missing debuginfo and wasted a great
deal of time trying to rebuild to get the debuginfo.
The problem seems to be that some ant scripts force debugging to be
off or perhaps inherited from a property that no-one remembered to
set. This is compounded by the fact that some ant scripts unzip source
archives and then call ant recursively to build them: in such a case
it's very hard to patch build.xml to force debugging=true.
This patch for ecj forces debuginfo always to be generated while
rebuilding an RPM, no matter what ant thinks. I realize it's
something of a kludge, but it's better than the current situation.
When compiling C/C++/etc, RPM passes "-g" in RPM_OPT_FLAGS. An
alternative to this patch might be to scan RPM_OPT_FLAGS for "-g" and
only turn on debugging if it's present. However, I doubt that in
practice it'd make any difference.
Andrew.
--- eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java.orig 2006-01-19 17:53:49.000000000 +0000
+++ eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java 2006-01-19 18:06:32.000000000 +0000
@@ -2405,6 +2405,29 @@
this.times = new long[this.repetitions];
this.timesCounter = 0;
}
+
+ {
+ // If we're building an RPM, force full debugging info to
+ // be generated, no matter what options have been passed
+ // by Ant. This is something of a kludge, but it is far
+ // better than the alternative, which is having class
+ // files with debug info mysteriously missing.
+
+ String RpmPackageName = System.getenv("RPM_PACKAGE_NAME");
+ String RpmArch = System.getenv("RPM_ARCH");
+ String RpmBuildRoot = System.getenv("RPM_BUILD_ROOT");
+ if (RpmPackageName != null && RpmArch != null && RpmBuildRoot != null) {
+ this.options.put(
+ CompilerOptions.OPTION_LocalVariableAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_LineNumberAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_SourceFileAttribute,
+ CompilerOptions.GENERATE);
+ }
+ }
}
private void addNewEntry(final int InsideClasspath, final int InsideSourcepath, ArrayList bootclasspaths, ArrayList classpaths,ArrayList sourcepathClasspaths, String currentClasspathName, ArrayList currentRuleSpecs, int mode, String customEncoding) {
17 years, 4 months
extension directories
by Anthony Green
I have some questions regarding extension directories...
gcj currently looks in /usr/share/java/ext for extensions, which isn't
compatible with JPackage. In fact, this directory doesn't exist in FC.
In JPackage-land, it looks like each JRE will have their own extensions
directory under $JAVA_HOME/lib/ext, and then there's the JPackage
maintained one at /usr/share/java-ext.
The BouncyCastle RPM installs JRE versioned .jar files in directories
under /usr/share/java-ext.
Should java-gcj-compat set gij's java.ext.dirs to
$JAVA_HOME/lib/ext:/usr/share/java-ext ?
How do the proprietary JRE's pick up the contents
of /usr/share/java-ext?
How are any of JREs supposed to find the JPackage bouncycastle jar
files?
Thanks!
AG
17 years, 4 months
freecast fc4/fc5 gcj
by Rudolf Kastl
Hello!
Did anyone yet try to build freecast with gcj?
http://freshmeat.net/projects/freecast/
freecast is a p2p streaming solution supporting e.g. ogg for streaming in a
p2p way.
i think a solution like this would help more low bandwidth people to setup
streaming servers and helps even low bandwidth people to setup internet
radio.
If we want to have our own media i think this is a well worthy and important
piece to get added to extras (which is most probably another discussion).
I would have tried out freecast with gcj myself but i wont have a possiblity
to do so for the next few days so i decided to kick-off this email.
regards,
rudolf kastl
17 years, 4 months
easily building and packaging eclipse plugins
by Benjamin Konrath
Hi,
I've come up with another idea on we can make building and packaging
plugins easier. The general strategy is to make an eclipse plugin that
allows you to build plugins from an archive with a headless eclipse
application. Under the hood, the plugin would simply import the projects
from the archive and then export them as a deployable feature or plugin.
The latter action takes care of building the actual plugins and
features.
Building a feature would look something like this:
java -cp /usr/share/eclipse/startup.jar \
org.eclipse.core.launcher.Main \
-application \
com.redhat.eclipse.pluginbuilder.pluginBuilderApplication \
-archive <path/to/archive/with/eclipse/projects> \
-exportDir <path/to/export/directory> \
-featuree <feature to build>
Eclipse.org plugins would still have to modify their releng scripts to
tar/zip the source after it has been checked out of cvs and provide that
source along with the binaries. Plugins that don't use the releng
process (ie most independently developed plugins on sourceforge and
such) can simply export the projects to a zip or tar archive from within
eclipse or tar/zip the sources that have been checked out of their cvs
repo.
Some advantages to this solution are:
(1) we would be able to easily build plugins that don't use the eclipse
releng process easily
(2) we would be able to build plugins from eclipse.org and 'joe open
source developer' in a consistent manner
(3) it provides a way for eclipse.org plugins to release source
archives which frees eclipse packagers from doing this task.
I have a working proof-of-concept plugin in my svn repo:
http://svn.bagu.org/pluginbuilder/
There are a tonne of problems with this implementation:
* Most of the code in the plugin has been ripped directly out of
eclipse. It would be nice if this application became part of eclipse or
the relevant parts of eclipse were exported properly.
* There is currently no output when the plugins are building, so you
can't really tell if something went wrong or not.
* There is no error handling at all.
Before I proceed, I'd like to get comments from the Fedora and Debian
Eclipse communities. If people like this method, then I will get
comments from the appropriate Eclipse developers and hopefully resolve
some the issues with the current implementation.
Cheers, Ben
17 years, 4 months
updated instructions for generating the cdt tarball
by Benjamin Konrath
Hi,
I updated the instructions for generating the CDT tarball. This method
allows you to generate the tarball as a non-root user. These instructions
have also been placed in 'how-to-generate-the-cdt-tarball.txt' in the
devel branch of the eclipse-cdt cvs module.
Cheers, Ben
++
Generating the cdt tarball
==========================
% mkdir -p temp/home && cd temp
% cvs -d :pserver:anonymous@dev.eclipse.org:/home/tools co \
-r CDT_3_0_1 org.eclipse.cdt-releng/org.eclipse.cdt.releng
% cd org.eclipse.cdt-releng/org.eclipse.cdt.releng
% sed --in-place 's/@cdtTag@/CDT_3_0_1/' maps/cdt.map
% java -cp /usr/share/eclipse/startup.jar \
-Duser.home=../../home \
org.eclipse.core.launcher.Main \
-application org.eclipse.ant.core.antRunner \
-buildfile build.xml \
-DbaseLocation=/user/share/eclipse \
-DdontUnzip=true fetch
% cd .. && tar zcf eclipse-cdt-fetched-src-3.0.1.tar.gz \
org.eclipse.cdt.releng
17 years, 4 months
