java-devel December 2005

java-devel@lists.fedoraproject.org

20 participants
36 discussions

Eclipse and Tomcat - where?
by Dan Thurman 20 Dec '05

20 Dec '05

Hi Folks, I finally am ready to test by application on Fedora using Eclipse and I am at the point where I am trying to run my web-application using Tomcat. Of course, the Tomcat dialog box pops up and asks where the Tomcat installation directory is.... ugh.... I have NO CLUE! On windows, Tomcat is installed by Eclipse so I dont have to figure this out.... but on Fedora, seems like I do. Can someone tell me what to do? Thanks! Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005

2 1

RFC: peephole vs RTX_FRAME_RELATED_P
by Andrew Haley 19 Dec '05

19 Dec '05

On i386 we replace (add sp -4) with (push reg). This generates faster and smaller code. However, we are not copying RTX_FRAME_RELATED_P from the old instructions to the new, and so we are not emitting unwind information for the stack pointer adjustment. The breaks stack traces on gcj, and I suspect it breaks a bunch of stuff elsewhere too. This very crude patch sets RTX_FRAME_RELATED_P on every one of the new instructions if any of the old instructions had RTX_FRAME_RELATED_P set. It seems to do the trick, but I suspect there must be a more subtle way to do it. Can anyone suggest a neater way to do this? Without this patch, for java.lang.Throwable.Throwable(java.lang.String) we get 00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>: a326a8: 56 push %esi a326a9: 53 push %ebx a326aa: 50 push %eax <=== ** This is the insn generated by peephole ** a326ab: e8 00 00 00 00 call a326b0 <java.lang.Throwable.Throwable(java.lang.String)+0x8> a326b0: 5b pop %ebx 00058f08 0000001c 0003252c FDE cie=000269e0 pc=00a328f8..00a3292e Augmentation data: 00 00 00 00 DW_CFA_advance_loc: 1 to 00a328f9 DW_CFA_def_cfa_offset: 8 DW_CFA_advance_loc: 1 to 00a328fa DW_CFA_def_cfa_offset: 12 DW_CFA_offset: r3 at cfa-12 DW_CFA_offset: r6 at cfa-8 DW_CFA_nop after the patch, we get 0005946c 00000020 000328e4 FDE cie=00026b8c pc=00a326a8..00a326de Augmentation data: 00 00 00 00 DW_CFA_advance_loc: 1 to 00a326a9 DW_CFA_def_cfa_offset: 8 DW_CFA_advance_loc: 1 to 00a326aa DW_CFA_def_cfa_offset: 12 DW_CFA_advance_loc: 1 to 00a326ab DW_CFA_def_cfa_offset: 16 DW_CFA_offset: r0 at cfa-16 DW_CFA_offset: r3 at cfa-12 DW_CFA_offset: r6 at cfa-8 Here's a trivial test case: public class Hello { public static void main(String[] args) { System.out.println("Hello, World!"); new Throwable().printStackTrace(); } } $ ~/gcc/install/bin/gcj Hello.java --main=Hello -g $ LD_LIBRARY_PATH=~/gcc/install/lib ./a.out Hello, World! java.lang.Throwable at Hello.main (Hello.java:5) Andrew. 2005-12-19 Andrew Haley <aph(a)redhat.com> * recog.c (peephole2_optimize): Copy RTX_FRAME_RELATED_P from old instructions to new instructions. Index: recog.c =================================================================== --- recog.c (revision 108424) +++ recog.c (working copy) @@ -3107,6 +3107,7 @@ int match_len; rtx note; bool was_call = false; + bool frame_related = false; /* Record this insn. */ if (--peep2_current < 0) @@ -3122,6 +3123,14 @@ try = peephole2_insns (PATTERN (insn), insn, &match_len); if (try != NULL) { + { + rtx old_insn = insn; + for (i = 0; i <= match_len; ++i) + { + frame_related |= RTX_FRAME_RELATED_P (old_insn); + old_insn = NEXT_INSN (old_insn); + } + } /* If we are splitting a CALL_INSN, look for the CALL_INSN in SEQ and copy our CALL_INSN_FUNCTION_USAGE and other cfg-related call notes. */ @@ -3179,6 +3188,16 @@ break; } + if (frame_related) + { + rtx new_insn = try; + while (new_insn != NULL_RTX) + { + RTX_FRAME_RELATED_P (new_insn) = true; + new_insn = NEXT_INSN (new_insn); + } + } + i = match_len + peep2_current; if (i >= MAX_INSNS_PER_PEEP2 + 1) i -= MAX_INSNS_PER_PEEP2 + 1;

1 0

Re: [fedora-java] rawhide issues
by Andrew Haley 19 Dec '05

19 Dec '05

Jakub Jelinek writes: > On Mon, Dec 19, 2005 at 04:34:33PM +0000, Andrew Haley wrote: > > Looking further, I realize that my analysis is quite wrong. The "push > > %eax" is promptly followed by "pop %ebx", so a CFA offset of 12 is > > correct. D'oh! > > > > This is what comes of doing my thinking in public... Still, I have > > discovered this problem is tune=i386 specific. I'll continue looking. > > > > > > 00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>: > > a326a8: 56 push %esi > > a326a9: 53 push %ebx > > a326aa: 50 push %eax > > a326ab: e8 00 00 00 00 call a326b0 <java.lang.Throwable.Throwable(java.lang.String)+0x8> > > a326b0: 5b pop %ebx > > Well, call here does the push and pop %ebx pops it. So this sequence > still decreases %esp by 12 bytes. Yeah -- I was right first time. I think I'm going to keep quiet 'til I've solved the problem! :-) Andrew.

1 0

rawhide issues
by Anthony Green 19 Dec '05

19 Dec '05

I see the following issues with rawhide (on x86) right now... * I'm not getting any stack traces, just <<No stacktrace available>> * Eclipse fails and the log contains the following errors (with no stacktraces): java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context: org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION java.lang.Exception: Cannot initialize Update Configurator java.lang.IllegalStateException: Bundle initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active. * aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1. I can't see where this comes from. Any ideas? AG

4 9

Re: [fedora-java] JacORB build problem
by Anthony Green 19 Dec '05

19 Dec '05

On Thu, 2005-12-15 at 14:55 -0800, Jesse Keating wrote: > Anthony, were you able to get it to build using this patch? I applied > the patch but when I push it through beehive it still doesn't build > right. > > http://porkchop.redhat.com/beehive/logs/jacorb-665762-x86_64-ls20-bc2-14.bu… Yes, I'm definitely able to build on x86. I just tried again now with gcc-java-4.1.0-0.7. No problemo. AG

2 3

Default Java on Linux
by David Walluck 17 Dec '05

17 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just wanted to bring everyone's attention to Sun bug #6211006 (Default Java of Linux) <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6211006>. The initial bug was posted about a year ago, but a comment was added as recently as 7 months ago. I am not sure if some of these statements are lies or just genuine misunderstandings from the developers. For example, in the comments for bug #4680244 (RPM does not follow LSB or filesystem hierachy (sic)) <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4680244>, it seems clear that the issue is just being avoided (successfully, for over 2 years now). However, in the comments for the more recent bug, there appears to be some possible genuine misunderstandings of RPM and Linux. For example, is the bug author not aware that you can create multiple packages from the same spec file, that you can include documentation inline, that you can avoid multi-line macros by calling a script...? In any case, the comment about update-alternatives (missing on Suse) is in fact wrong. Because rpms are not provided for Mustang yet as far as I know, I guess there is no way to even find out how this bug can be marked as closed. My main issue for writing is that bug #4680244 refers people to #6211006 (now closed). But #4680244 has been a top 25 RFE for a long time (currently it is the #5 most-wanted RFE). I fear, based on the comments for bug #6211006, that nothing has changed, and now it will only draw attention away from the JPackage RFE. What's more, the idea of ``forcing'' the most recent jdk to be default is actually a step back, that is, if I understand correctly. Despite the quoting of some RPM documentation, the description of the actual proposed solution is left vague, presumably because whatever they do will not be made public/open. - -- Sincerely, David Walluck <david(a)zarb.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDo6XkarJDwJ6gwowRAiTAAJ0fksl8B7iEREyc7iQxmK2Ny7BzTwCfYtCk Ldgev8IdRrg00EePxxbPL8s= =3JUo -----END PGP SIGNATURE-----

2 1

still missing /usr/bin/rebuild-gcj-db
by John W. Himpel 16 Dec '05

16 Dec '05

All, I am missing this file. The archives mention: java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh Those are installed. Here are my "java" rpms # rpm -qa | fgrep java struts11-javadoc-1.1-1jpp_7fc jakarta-taglibs-standard-javadoc-1.1.1-4jpp_1fc.1.1 java-1.5.0-sun-1.5.0.04-1jpp java-1.5.0-sun-devel-1.5.0.04-1jpp javacc-3.2-1jpp_3fc ant-javamail-1.6.2-3jpp_14fc gcc-java-4.0.2-8.fc4 struts-javadoc-1.2.4-2jpp_3fc java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh java-1.5.0-sun-plugin-1.5.0.04-1jpp jakarta-taglibs-standard-javadoc-1.1.1-4jpp_1fc ant-javamail-1.6.5-0jpp_1fc Is there a workaround or fix? Thanks. John

3 3

JacORB build problem
by Anthony Green 16 Dec '05

16 Dec '05

The rawhide JacORB doesn't build with gcj 4.1 because of incompatibilities between libgcj's org.omg.CORBA and JacORB's org.omg.CORBA. The JacORB code is referring to org.omg.CORBA fields that only appear in the JacORB version of these classes, and there's no way to override libgcj's built-in version at build time. This problem is similar to the xml-commons-apis problem we've discussed here and in bugzilla. AG

4 8

Re: [fedora-java] JacORB build problem
by Gary Benson 16 Dec '05

16 Dec '05

Jesse Keating wrote: > On Wed, 2005-12-14 at 22:10 -0800, Anthony Green wrote: > > It's not pretty, but the attached patch lets the jacorb RPM build. > > Presumably other java alternatives have no problem building this. > > I wonder why? > > > > > At runtime, as Mark said, these classes are BC-compiled and can > > > be overridden via extdirs. > > > > Jacorb already intalls a "java" wrapper called "jaco" that does > > this. > > > > Gary - please consider adding the attached patch for jacorb. > > Anthony, were you able to get it to build using this patch? I > applied the patch but when I push it through beehive it still > doesn't build right. I tried patching the extra exceptions away, but now it's giving wierd exceptions from gnu.CORBA.ObjectCreator. The override definitly seems not to have happened. Are these classes definitly BC-compiled? Cheers, Gary

1 0

[Fwd: Re: [Fwd: Re: [fedora-java] JacORB build problem]]
by Mark Wielaard 14 Dec '05

14 Dec '05

Hi, I asked Audrius, who wrote the org.omg corba implementation for GNU Classpath to take a look at this. He isn't subscribed to the list so I forward his reply (attached). Thanks for looking into this Audrius. For those interested in free Corba, Audrius will give a Developer Talk on the implementation during Fosdem 26/27 Februari in the GNU Classpath hacker room. We are still working on the full program and still looking for more exciting talks/presentations/demos (we don't have anybody presenting the gcj related improvements Fedora Core 5 yet, hint...) http://lists.gnu.org/archive/html/classpath/2005-11/msg00122.html Cheers, Mark

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel December 2005