java-devel July 2005

java-devel@lists.fedoraproject.org

53 participants
53 discussions

Re: Devel Digest, Vol 12, Issue 6
by Soumyadip Modak 08 Aug '05

08 Aug '05

Martin Kauss <bishoph(a)open-xchange.org> wrote > Hi, > > the configure just checks the system dependencies to build the > system. The needed libraries are not checked until the compile > process, JFYI. > > The questions was asked some month ago for a Debian package as well. > I tried to build Open-Xchange some time ago with GNU Classpath, but > specially for mail, necessary methods and functions are just missing. So what I understand is this: (Correct me if I'm wrong) 1. Problems with servlets are solvable with free Java tools, and these are not major showstoppers 2. Base64 and Parserdelegator problems need some work 3. Main problem is that the free Javamail does not implement some methods that are needed by OX. Is it possible for the OX developers to work with the Classpath developers to resolve these problems ? As far as I can understand there is no major bottleneck other than some missing functionality, and I'm sure that the Classpath people would love to have people collaborating with them. :) > We are just providing a collaboration framework and that is our > focus. This means, if the functionality is covered by any other > package than Sun's Javamail package one can build OX with this > packages. > > Currently - AFAIK - this is not possible. > > The other question is what you mean with "extensive free Java tools" > ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ... I generally refer to the Debian Free Software Guidelines for my definition of Free software :) http://www.debian.org/social_contract#guidelines Thanks a lot -- Soumyadip Modak soumyadip.modak(a)gmail.com soumyadip(a)randomink.org http://www.randomink.org/soumyadip

7 14

Is tomcat-connectors-4.0.6 buildable on FC4
by crisppy fernandes 02 Aug '05

02 Aug '05

Hi All can anybody give me some pointer or info related to my problem.. I am facing many issues related to building tomcat-connectors-4.0.6 on FC4 . After solving few problems i have reached a point where its searching for one struct i.e. JDK1_1InitArgs. and after searching more i have come to know that definition of this struct is now removed from source i.e jni.h file So do we have fix for this. or i am missing something. some or any help welcome. Crisppy f. -- Crisppy Fernandes

3 3

Java on Fedora faq
by John M. Gabriele 01 Aug '05

01 Aug '05

It's starting to come along. :) http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora Comments? ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

9 25

RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Boehm, Hans 01 Aug '05

01 Aug '05

There is some code in earlier versions of the GC to do thread registration, but it's very platform specific and thus ugly. I think there wasn't a real facility for Linux. The tricky part of doing this in general is that the GC needs to know the stack bounds for the newly registered thread. It can find the hot end, but the cold end is often hard. GC7 addresses this by providing two ways to get the cold stack end: 1) A generic mechanism that just takes the address of a local. The collector knows how to implement that everywhere. We just provide a function that calls back one of your functions f with a stack address that's guaranteed to be "below" f. Since this is not the actual base of the stack, the GC ends up tracing pointers only in "new" frames. 2) A separate routine that tries to discover the stack base in a platform dependent way. It may fail. (And currently usually does.) I think that for Linux, pthread_getattr_np works for most threads, though perhaps not the main one. (The thread pointer also probably works in many cases.) I'm not sure the JNI primitives can be implemented in terms of (1). Certainly if you use CNI that has different semantics, in that the GC doesn't see pointers "below" you on the stack. We may need (2) to work for gcj. Hans > -----Original Message----- > From: Robin Green [mailto:greenrd@greenrd.org] > Sent: Thursday, July 28, 2005 1:51 PM > To: Anthony Green; Boehm, Hans > Cc: tromey(a)redhat.com; Discussion list for java related > Fedora development > Subject: RE: [fedora-java] rssowl: libgcj bugs that need > fixing for it torun > > > > On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote: > > > [I missed the beginning of this thread initially.] > > > > > > I'm actually trying to work on some of these issues. Some status: > > > > Cool. > > > > Robin - is there a local hack/patch we can apply to swt > and/or rssowl > > to work around this problem until a real fix from Hans > migrates into > > GCC? > > I'm a bit out of my depth here. > > Hans wrote: "Gc7 (even the released, but very experimental > alpha3 version) has a thread registration interface." This > implies that the version in gcc _doesn't_ have a thread > registration interface, or anything that could be hacked > together into one. Is that surmise correct? > > If so, the only other thing I can think of is to spawn a new > registered thread instead of calling AttachCurrentThread, and > somehow translate all C->Java invocations on the unregistered > thread into inter-thread calls onto the new registered > thread. In other words, keep all Java code on a separate thread. Yuck. > > -- > Robin >

2 1

Standard version of JPEGImageDecoder
by Orion Poplawski 29 Jul '05

29 Jul '05

Is there a standard JPEG api that is available with gcj that provides JPEGImageDecoder and the like that are in com.sun.image.codec.jpeg.*? Or at least something comparable? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

2 1

RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Boehm, Hans 28 Jul '05

28 Jul '05

[I missed the beginning of this thread initially.] I'm actually trying to work on some of these issues. Some status: 1) I'm currently hacking on the /proc/self/maps reading code that's already in the GC. The current code actually broke with a kernel change in August 2003 which changed the file format on 64-bit architectures. Unfortunately it didn't break blatantly enough for anyone to notice until now. I have a patch that should probably be integrated into gcj, but it needs a bit more mileage on it. 2) Reading /proc/self/maps reliably in a multithreaded environment seems hard. I'm still trying to understand this better, but there seems to be a design flaw here. Reads can return short, meaning that you don't necessarily get a consistent picture. And AFAICT, both nptl and linuxthreads unmap thread stacks after the thread becomes invisible to the user, so there is no way you can deal with this by user level synchronization. The mappings can change even if all threads that haven't exited are stopped. I currently believe that /proc/self/maps can only shrink asynchronously, so it might be possible to address this by reading it twice. 3) I have code in my gc7 tree to intercept pthread_create as suggested here. My immediate goal is to make it possible to use the gc as a preloadable malloc replacement, even in the multithreaded case. (This seems to require /proc/self/maps, since the dynamic loader seems to have its own malloc, and the objects it allocates point to objects allocated with the later malloc.) I think this is getting close to working, but I'm not quite there. 4) Gc7 (even the released, but very experimental alpha3 version) has a thread registration interface. That's probably a better solution for some of the problems here. (The implementation behind this interface is currently severely lacking in places. But at least there's an interface.) 5) My general plan is to get gc7 slightly more stable, and then set up CVS access to it. Hans > -----Original Message----- > From: Anthony Green [mailto:green@redhat.com] > Sent: Thursday, July 28, 2005 7:47 AM > To: tromey(a)redhat.com > Cc: Boehm, Hans; Discussion list for java related Fedora development > Subject: Re: [fedora-java] rssowl: libgcj bugs that need > fixing for it torun > > > On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote: > > This seems like a reasonable approach when libgcj is linked > into the > > resulting executable. But how can it work if we dlopen() > libgcj and > > then attach a previously-existing thread? > > It can't; this only solves the problem reported. We could > force tricky programmers to do thread registrations > themselves. The PyLucene people probably solved this in some way. > > > I was wondering if there was some /proc-reading approach > (or something > > like that) that we could use to find information about threads. > > Well, I'm guessing that the "[stack]" line > /proc/<pid>/task/<pid>/maps describes the extent of each > stack. Is this an interface we can depend on over all Linux > implementations? (isn't /proc optional during kernel > configuration?) > > AG > > >

3 2

RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Robin Green 28 Jul '05

28 Jul '05

> On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote: > > [I missed the beginning of this thread initially.] > > > > I'm actually trying to work on some of these issues. Some status: > > Cool. > > Robin - is there a local hack/patch we can apply to swt and/or rssowl to > work around this problem until a real fix from Hans migrates into GCC? I'm a bit out of my depth here. Hans wrote: "Gc7 (even the released, but very experimental alpha3 version) has a thread registration interface." This implies that the version in gcc _doesn't_ have a thread registration interface, or anything that could be hacked together into one. Is that surmise correct? If so, the only other thing I can think of is to spawn a new registered thread instead of calling AttachCurrentThread, and somehow translate all C->Java invocations on the unregistered thread into inter-thread calls onto the new registered thread. In other words, keep all Java code on a separate thread. Yuck. -- Robin

1 0

rssowl: libgcj bugs that need fixing for it to run
by Robin Green 28 Jul '05

28 Jul '05

I have also been working in my spare time on packaging rssowl for FC5 [sic]. I can post my .spec file if wanted. Here's my list of unfixed libgcj bugs that need to be fixed before rssowl will run natively reliably. These are both threading bugs. 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211 "Thread.interrupt sometimes causes abort if thread is already dead" This gets hits about 25%-50% of the time on quitting rssowl, and occassionaly also when I press the little red stop button at the bottom of the window. I can provide a backtrace if wanted. Unfortunately rssowl only saves any changes upon quit, so this means that any changes (including preferences and even the record of which feed items have been read) will be lost 25-50% of the time - unacceptable, obviously. 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 "AttachCurrentThread() not working" This is an old bug. It only triggered for me once I rebuilt gcc for Athlon (32bit) with a private threading patch, but now it triggers 100% of the time, every time I try to view the Dilbert comic in rssowl. Again, backtrace available on request. I am convinced that it is a real bug in the existing code, not a bug in my patch. After all, bad memory accesses don't always trigger SIGSEGVs. Sometimes they just cause memory corruptions. So probably, previously it was just causing memory corruptions instead of SIGSEGVs for some subtle reason. Feel free to add to this list. -- Robin

3 4

Re: Odd ClassNotFoundException with RSSOwl
by Andrew Overholt 28 Jul '05

28 Jul '05

Oops, I meant to CC the list. Hi Ben, * Benjamin Pasero <bpasero(a)rssowl.org> [2005-07-25 15:58]: > > the origin of this is most likely "jface.jar" requring parts of > Eclipse's platform Jars. Ah. > I will ask a SWT comitter that told me he once managed to remove the > dependency. He might be able to create a jar for me. That won't really work unless we can patch FC's JFace build stuff to allow the JFace jar in the system to have the same dependency removed. But it's a good step forward. Either way, I've made an SRPM and specfile available for the little hackjob I did on this: http://www.overholt.ca/rssowl/ Things work pretty well for me. The specfile lists things that we need to do. If anyone wants to help, it'd be greatly appreciated. Thanks, Andrew

6 12

gcj and java at LinuxWorld
by Anthony Green 27 Jul '05

27 Jul '05

Just FYI, I'll be giving an extremely short talk on java, gcj, etc as they relate to the Fedora project during the San Francisco LinuxWorld show. It will be in the Fedora booth on Wednesday the 10th at 11am. I'll hang around a little before and after just in case anybody is interested in a discussion. AG

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2005