Re: fosdem devroom schedule published
Dalibor Topic wrote: Hi, the schedule for the free Java devroom at FOSDEM is now online. See http://robilad.livejournal.com/59529.html and http://fosdem.org/2010/schedule/tracks/freejava for details. There has been a small change on Saturday - we'll be in Room AY: http://fosdem.org/2010/schedule/rooms/ay We're still in room AW1.125 on Sunday: http://fosdem.org/2010/schedule/rooms/aw1.125 cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:dalibor.to...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels Vorsitzender des Aufsichtsrates: Martin Häring
fosdem devroom schedule published
Hi, the schedule for the free Java devroom at FOSDEM is now online. See http://robilad.livejournal.com/59529.html and http://fosdem.org/2010/schedule/tracks/freejava for details. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:dalibor.to...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
FOSDEM devroom request accepted
alibor Topic wrote: Hi, I expect to hear back from the FOSDEM devroom team whether the request was accepted (or denied) sometime next week, according to the published schedule. [3] Here's what the FOSDEM devroom team e-mailed me today: Your request for a devroom at FOSDEM 2010 has been accepted, and we will put the following at your disposal: - room AW1.125 with 76 seats, - a video projector with VGA cable, - wireless internet, for 2 days: - on Saturday 6th February from 13:00 to 19:00 and - on Sunday 7th February from 09:00 to 17:00 [...] Yay! OK, with that out of the way, it's same procedure as every year: * there is a wiki page with the basic information: http://wiki.debian.org/Java/DevJam/2010/Fosdem * there is a wiki page where talk proposals go: http://wiki.debian.org/Java/DevJam/2010/FosdemProposedTalks Talk slots are either for 15 or 30 minutes. Like in the past years, we'll group related talks into blocks, in order to allow for some breaks between blocks of sessions. You can submit more then one proposal if you wish. If we run out of slots (happened a couple of times in previous years), not all submissions will get picked - so please try to make your submission sound like a great pick. The call for submissions runs for four weeks until Sunday, January 3rd 2010. You'll know if your talk was picked by January 6th, 2010. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:dalibor.to...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
Re: Some slides from the Free Java Meeting at Fosdem
Mark Wielaard wrote: Dalibor linked them all from the wiki and when there are more presentations available we will add them (if you gave a presentation and also want to link to your slides please do add them or ping one of us to upload them for you): http://wiki.debian.org/Java/DevJam/2009/Fosdem In other words: If you gave a talk at the Java Libre dev room, haven't put up your slides there yet, because you don't want really to fiddle with uploading attachments to the wiki (what's my pass again?, how does linking attachments work? etc.), just send your slides to me in a private reply to this post, and I'll take care of the upload linking it from the main wiki page above asap. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:dalibor.to...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring
Re: JavaVM description for OpenJabaco ?
theUser BL wrote: Hi! But where can I find documentations about .class files? How are they are structures and so on? In the JVM specification, 2nd edition, for example. There is quite a bunch of literature explaining the workings of bytecode and the class file format, depending on the background you're after, from compiler design books, over interactive introductions, to formal methods. cheers, dalibor topic
Re: Jikes RVM 3.0.0 released
On 08/08/08 23:12, Mario Torre wrote: Il giorno gio, 07/08/2008 alle 22.43 +0100, Ian Rogers ha scritto: We're very happy to announce the release of Jikes RVM version 3.0.0. The road towards 3.0 began just about two years ago and a large number of people, both on the core team and from our user community at large, have contributed to making it a success. Thank You! Cool! Congratulations! Congrats from me as well, keep up the great work! cheers, dalibor topic
Re: Other class libraries
Andrew John Hughes wrote: Unfortunately, such suppositions aren't worth much in legal terms (and let's get the obvious IANAL disclaimer in here before I say any more). As we discussed a little on IRC earlier today, it's actually quite a ridiculous situation that GNU Classpath and OpenJDK are just about under the same license, but because of that 'or later' clause, they are incompatible. Ideally, we would have imported a lot of OpenJDK code into GNU Classpath when it was released. Filling the holes in GCJ, for example, with Sun code would probably be a faster method of getting a TCK-passing implementation on non-x86/x86_64 platforms, assuming that such a combination counts as 'sufficiently derived'. In an ideal world, both would be under GPLv3 and we'd share code between the two as intended. On the other side, I've not seen as much code as I'd expect (like the AWT peers) move into OpenJDK either, but I think this is less legal and more process related. Dalibor, could you give us something from Sun's side on this issue? I'm not sure on which one: * whether combining a GPLd VM with OpenJDK class library would be sufficiently derived as far ar the OCTLA goes? Yes, please see the GB minutes http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath exception are incompatible? IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 regardless of what later later versions say in classpath's case. * whether classpath or openjdk will be under GPLv3? It's always hard to predict the future, but I guess a lot of that will depend on the ongoing work the FSF is doing to unify the exception language around gcc, when it is ready for public review, and how it turns out - don't understimate the scope of that work, it's been going on for a long time, as readers of the autoconf lists know. It will also depend on what the actual effects of the v3 version of the exceptions would be on v2 only users, or VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module scenarios, or Kaffe. * whether FSF will accept GPLv2+Classpath exception code from openjdk into classpath? Hard to say. I'm not quite sure what we'd gain from duplicating the same code in several places though - if we want to turn classpath into an icedtea like wrapper around bits and pieces from openjdk, we can do that without copying and pasting openjdk code over into another repository (we've got enough third party code in classpath as it is, imho). if there are bits from openjdk that make sense to depend on as a 'source plug' for classpath, then we could go the icepick route, for example, and wrap them up accordingly. * whether gcj will lose its own copy of classpath and be able to use an installed one or an alternative class library? Hard to say. But it's basically the pragmatic reason why openjdk code hasn't flown into classpath: it wouldn't look very good to have gplv2 only code in a gplv3 gcc/gcj. That's a policy decision forced by the current architecture of gcj - if the tight coupling between the class library and gcj was removed (see JamVM, Cacao, etc.), that particular dilemma would not present itself as such. I hope we can come to a decent resolution on this, but I think the issue does need to be discussed openly and as soon as possible. I don't really see a pressing need to discuss classpath's licensing while the FSF is working on an update of the license, which will hopefully be available for (public) review soon. cheers, dalibor topic
Re: Other class libraries
Robert Schuster wrote: Unfortunately, such suppositions aren't worth much in legal terms (and let's get the obvious IANAL disclaimer in here before I say any more). If that is the problem couldn't we get an official stance from Sun that prevents that? Something saying: if some part of code from GNU Classpath looks similar to code in OpenJDK the FSF is not sued for copyright infringement. Dalibor? IANAL, but that wouldn't seem to be very useful in practice - it would be an attempt to have a very vague 'technical' solution for the lack of working 'social' ones. For Classpath, fortunately, we have a working social solution: Mark ;) In general, if you are not completely sure about whether you can contribute a specific piece of code to GNU Classpath, please ask Mark about it. He gets to set the bright lines of what's an acceptable contribution policy for Classpath, and he's done a remarkably good job at that as the project's maintainer, I think. an ideal world, both would be under GPLv3 and we'd share code between the two as intended. On the other side, I've not seen as much code as I'd expect (like the AWT peers) move into OpenJDK either, but I think this is less legal and more process related. Dalibor, could you give us something from Sun's side on this issue? I am a bit confused about Sun's attitude towards (L)GPLv3. I hope http://www.sun.com/software/opensource/java/faq.jsp#g34 helps, for the time being that the FSF is working on the draft update of the exception language for V3. Once that's finished, I think it would make a lot of sense to evaluate what the effects would be for the existing scenarios of VMs using GNU Classpath, and the same for OpenJDK, and hopefully come to the same conclusions, due to a mutually fruitful discussion of the implications of the license during its (public) drafting/comment process. But the FSF has not started that comment process yet (and I'm sure the FSF has good reasons to take its time to do it right), so there is not much one can really say about it. If you are looking for a broader, independent evaluation of Sun's attitude to GPLv3, Palamida, the site tracking GPLv3 conversions, lists Sun as a significant adopter of GPLv3 in GPLv3's first six months, at http://gpl3.blogspot.com/2007/12/gplv3-year-in-review.html cheers, dalibor topic
Re: Other class libraries
dalibor topic wrote: Andrew John Hughes wrote: Dalibor, could you give us something from Sun's side on this issue? I'm not sure on which one: * whether combining a GPLd VM with OpenJDK class library would be sufficiently derived as far ar the OCTLA goes? Yes, please see the GB minutes http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . And I should point out that that bit is the only thing I can give you from Sun's side. Anything below that is my personal opinion as a Classpath developer - I'm posting this so that people don't get confused between the multiple hats I'm wearing here, when I say 'we' below. We as in 'we, the classpath developers'. I was posting from my Kaffe.org address, but I'm not sure a lot of people would catch something that subtle. cheers, dalibor topic * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath exception are incompatible? IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 regardless of what later later versions say in classpath's case. * whether classpath or openjdk will be under GPLv3? It's always hard to predict the future, but I guess a lot of that will depend on the ongoing work the FSF is doing to unify the exception language around gcc, when it is ready for public review, and how it turns out - don't understimate the scope of that work, it's been going on for a long time, as readers of the autoconf lists know. It will also depend on what the actual effects of the v3 version of the exceptions would be on v2 only users, or VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module scenarios, or Kaffe. * whether FSF will accept GPLv2+Classpath exception code from openjdk into classpath? Hard to say. I'm not quite sure what we'd gain from duplicating the same code in several places though - if we want to turn classpath into an icedtea like wrapper around bits and pieces from openjdk, we can do that without copying and pasting openjdk code over into another repository (we've got enough third party code in classpath as it is, imho). if there are bits from openjdk that make sense to depend on as a 'source plug' for classpath, then we could go the icepick route, for example, and wrap them up accordingly. * whether gcj will lose its own copy of classpath and be able to use an installed one or an alternative class library? Hard to say. But it's basically the pragmatic reason why openjdk code hasn't flown into classpath: it wouldn't look very good to have gplv2 only code in a gplv3 gcc/gcj. That's a policy decision forced by the current architecture of gcj - if the tight coupling between the class library and gcj was removed (see JamVM, Cacao, etc.), that particular dilemma would not present itself as such. I hope we can come to a decent resolution on this, but I think the issue does need to be discussed openly and as soon as possible. I don't really see a pressing need to discuss classpath's licensing while the FSF is working on an update of the license, which will hopefully be available for (public) review soon. cheers, dalibor topic
Re: Other class libraries
Andrew John Hughes wrote: 2008/6/25 dalibor topic [EMAIL PROTECTED]: Well I suppose the question is more 'how much OpenJDK is needed to be substantially derived?' It's hard to draw a minimum requirement line, so I guess it'll be a case-by-case decision, when necessary. I think a the majority of regular cases are obvious, though. Is the TCK license available for general consumption yet? Sure, it's been available since August 2007: http://*openjdk*.java.net/legal/*openjdk*-*tck*-*license*.pdf I'm slightly less perturbed by aph telling me that you do actually get source code. The fact that a myth to the contrary could permeate to me just shows the problems with such NDA stuff... ;) You'll have to check out the GB meeting's notes for more specific details on the NDA stuff. To say I'm not happy it's there would be an euphemism, but as far as TCK NDA stuff goes, it has been clarified by Sun in the discussin with the GB and stripped down to a very specific form. cheers, dalibor topic
Re: Building the VM classes
Christian Thalinger wrote: On Tue, 2008-05-13 at 09:45 +0100, Andrew John Hughes wrote: That was my understanding. Apart from making the code messier, it doesn't do any harm, it's just difficult to maintain if we don't build it with the 1.4 options. OK, I think it's a good idea. In particular on old systems / systems only with jikes as the bootstrap option (Cygwin atm.). cheers, dalibor topic
Re: Classpath OpenJDK
OneGuy schrieb: Hi, Since it was suggested on GCJ list to ask this question here, I will post it here. Is it possible for Classpath to use parts of code from OpenJDK? For example, there are performance probems with Classpath's regex package and StreamTokenizer. In cases like these, where OpenJDK has better implementation, why not copy and use the code that is better (30x faster in case of regex) ? It is possible, and you can merge them as much as you like, and publish merged versions yourself. That's part of what the BrandWeg project by Andrew Hughes is about, and you're most welcome to help out on it. In FSF's case, we'd like to keep our code under GPLv2 or any later version, to allow the Classpath project to be upgraded to GPLv3 or any later version by any user, while in OpenJDK's case, we're on GPLv2 exclusively. The FSF is reluctant to add code to GNU Classpath that would make an eventual upgrade to GPLv3 harder than necessary, as the FSF strongly prefers GPLv3 to GPLv2. It's a policy issue, rather than a licensing issue, per se. Also, on a side note, why can't Classpath OpenJDK merge? Both projects do the same thing They could merge, it's just a lot of work to actually perform a manual, best of breed merge on two such large, independently developped codebases, doing all the developers that have done the work on them justice. When we merged Kaffe with Classpath, we eventually just ended up replacing large chunks of Kaffe's code with Classpath's code, regardless whether it was technically better or worse, simply to avoid having to maintain it ourselves. That worked, socially, because most of the developers of the class library in Kaffe had by then moved on to other projects, and the next generation saw a clear need to perform the merge. In Classpath's case, the need for a merge withing Classpath is offset by the ability of VM authors to do any merge they want in their own projects, and adapt the VMs to work with OpenJDK's class libraries, without having to adopt OpenJDK's policies, just like they don't have to adopt FSF's policies. So we're currently seeing several different approaches being experimented with in different VM projects, including OpenJDK, where Andrew is working on a stable VM interface to make plugging different VMs into OpenJDK easier. cheers, dalibor topic
Re: Building classpath with ecj
Trevor Harmon wrote: On Mar 23, 2008, at 4:32 AM, Audrius Meskauskas wrote: The ecj startup script does not respect the -J-X options. Check where is the script is with 'which ecj', then look into contents of that file. It is a text file in .sh format. The most straightforward way is to correct it manually, adding -J-Xmx768M at the place where the script invokes java virtual machine. That fixed it. Classpath now compiles for me with ecj. Thanks! Great! Thanks for packaging Classpath for OS X. cheers, dalibor topic
Re: Inconvertible types error in EnumSet.java
Robert Lougher wrote: P.S. Changing the subject, this is one of my concerns with the change to the VM interface for the new VM reflection classes. If JamVM moves to the new interface it breaks the ability to use JamVM/Classpath-0.92 as a bootstrap... I don't think that's a huge problem: * you can pass the GNU classpath configure script the path to a precompiled glibj.zip to avoid having to compile the class library using ecj in the first place (best option, in my opinion, as it breaks the circle nicely) * you can use another runtime to run ecj to build classpath (good thing we don't suffer from a lack of VMs :) * you can (cross) compile ecj to native code/CIL/* and use that to run ecj to build classpath i.e. even if someone desperately wants to recompile GNU classpath during the bootstrap, they have plenty of options. It's just a matter of documenting them properly. cheers, dalibor topic
Re: Inconvertible types error in EnumSet.java
Trevor Harmon wrote: Okay this is something that has confused me. classpath seems to have a dependency on jamvm, but jamvm seems to have a dependency on classpath. How is this not circular? You can pass in a prebuilt glibj.zip to configure, without having to mess around with ecj on your target platform. You can also use Sun's javac, or gcj + ecj, or IKVM, or Cacao, or Kaffe up to 1.1.7, which came with it's own copy of gnu classpath, and so on. There is no lack of options for bootstrapping a classpath build, if that's what you really need to do, rather that making sure your distribution ships the latest one, and using that instead. :) cheers, dalibor topic
Re: questions about classpath
le quang wrote: Hi, everybody! I'm learning about classpath project to build kaffe VM. My problem is how i add java libraries into classpath program to compile them as java packages. Please give me a advice! Thank you! Hi, you should be able to just 'drop in' your new files into the classpath java javax gnu org sun directories, the build process should automatically detect them, and consider them when rebuilding classpath. If your libraries are in a different package, you need to add it to lib/gen-classlist.sh.in cheers, dalibor topic
Re: [cp-patches] Re: [PATCH] classpath doc typos
Tom Tromey wrote: Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes: Ralf Tested 'make docs info dvi pdf html' in classpath/doc. OK for trunk? Ralf If yes, will somebody push this upstream into classpath for me? Yes, this is ok. Thanks. Did Dalibor put it in Classpath? If not, let me know, and I will do it. Yeah, committed both to classpath. cheers, dalibor topic
Re: [cp-patches] Re: [PATCH] classpath doc typos
Ralf Wildenhues wrote: PING two classpath doc patches: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01022.html I had to look up what the extra @s do: http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Ending-a-Sentence.html#Ending-a-Sentence http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Not-Ending-a-Sentence.html#Not-Ending-a-Sentence looks fine for classpath. http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01021.html looks fine for classpath. I'll commit them for you to classpath. cheers, dalibor topic
[commit-cp] classpath ChangeLog doc/cp-hacking.texinfo doc/...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/03/09 16:28:58 Modified files: . : ChangeLog doc: cp-hacking.texinfo cp-tools.texinfo cp-vmintegration.texinfo Log message: ralf's doc cleanups 2008-03-09 Ralf Wildenhues [EMAIL PROTECTED] * doc/cp-hacking.texinfo: Fix some typos. * doc/cp-tools.texinfo: Likewise. * doc/cp-vmintegration.texinfo: Likewise. 2008-03-09 Ralf Wildenhues [EMAIL PROTECTED] * doc/cp-hacking.texinfo: Fix spacing after periods. * doc/cp-tools.texinfo: Likewise. * doc/cp-vmintegration.texinfo: Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9545r2=1.9546 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/cp-hacking.texinfo?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/cp-tools.texinfo?cvsroot=classpathr1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/cp-vmintegration.texinfo?cvsroot=classpathr1=1.5r2=1.6
Re: Summer of Code Ideas
Andrew John Hughes wrote: Below is a short list of ideas we could propose for GNU Classpath for this year's Google Summer of Code. Additions/comments welcome. I'd also like to know if there's anything you'd be willing to mentor. * Support Batik This was mentioned on IRC last night. Don't know much more about it though. Dalibor, do you have the contact details of the person you were speaking to about it? I'd assume it was Ruud from http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-dev/200803.mbox/[EMAIL PROTECTED] CC:ed. I'd add: * glib as the native layer We could simplify the portability glue code by using glib underneath. We're using glib implicitly in the GTK peers already, and it would let us delegate the responsibility for portability wrappers out of classpath, while at the same time making the native code work transparently on win32. * rewrite Qt peers using jambi Our Qt peers are rotting away, and that means it's time for someone to come in and rewrite them. Qt Jambi are the official bindings for Qt for Java code, so it could be both fun and useful to rewrite our Qt based AWT peers in pure Java. cheers, dalibor topic
Re: [kaffe] Removed GMP math?
Alan Eliasen wrote: Dalibor Topic wrote: On a side note, Andrew Hughes has just cleaned up and merged in Raif's patch, so it would be nice if you Alan could give Classpath's CVS head a shot and see if it works for you. Thanks very much! I had hoped to be able to test it out, but I might not have time for a while. Dalibor, I appreciate your thoughtful discussion of the tradeoffs of keeping or removing GMP from Kaffe, and I agree that integrating it into Classpath is a good solution, if we can test it and keep it up-to-date, and make sure it can be built for a variety of platforms. Great, thanks for kicking off the discussion, Alan, and providing the final drop of incentive for the patch to get merged in. I have been contributing performance enhancements to the OpenJDK project for the java.math.BigInteger class, but I haven't looked to see how my algorithms compare to those in Classpath. Is there any problem with me contributing patches to both projects? I've seen your patches on the OpenJDK lists, so I'd like to say thanks for improving OpenJDK. There is no problem with contributing to both OpenJDK and Classpath, as long as the code you are contributing is different, which should be trivial to comply with, as Classpath's and OpenJDK implementations are written by different people, so they should be reasonably different internally. That's the easy part. If you for some reason want to contribute the same code to both projects, then you need to be aware of a slight quirk in the different ways the GNU Classpath operates and OpenJDK operates: While FSF's contributor agreement insists on exclusive FSF ownership of code contributed to GNU Classpath, requiring you to transfer your authorship rights to the FSF, Sun uses the SCA for the OpenJDK project, which only requires sharing those rights with Sun. Since Sun reserves the right to license the OpenJDK code out to proprietary software vendors under non-free licenses, and FSF's contributor agreement does not let the FSF do such a thing, letting the FSF have exclusive rights onand the code you wrote and afterwards wanting to see it enter into OpenJDK, too, is a good way to make a lot of work for Mark Wielaard, the GNU Classpath maintainer, to try to figure out a way to make it happen using FSF's grantback provisions from the FSF contributor agreement, for example. Since Mark is a very busy man, I'd rather not spend his time on licensing discussions with the FSF, as those can take quite a while, and the FSF is quite busy at the moment working out other legalese, like updating the GPL exception language for V3 for the autotools projects, who've been forced to keep using v2 for their last releases ... so we haven't actually had a piece of code within GNU Classpath that someone pushed hard enough yet to have to try to figure out a way to deal with FSF's exclusive ownership of code in GNU Classpath and use the grantback procedure to make it work ouandt for OpenJDK. I assume that a lot of us in GNU Classpath would like to avoid that discussion as long as possible, as it is about boring legalese, and the amount of code it would concern directly seems to be fairly small and shrinking as OpenJDK's binary encumbrances shrink away. If the FSF moved away in the future from requiring exclusive ownership of the code to sharing rights on the code with the contributors, it would be a lot easier, of course, as then the order of contributions wouldn't matter. But that's another longish discussion about legalese and free software idealism, for which the GNU Classpath lists aren't the perfect forum. As far as I can tell from FSF's contributor agreement, the safe easy way to get the same code in both projects is to contribute it to OpenJDK first, sharing the copyright with Sun, so that they can do whatever things they feel the need to do (like update the license to v3), letting you keep your authorship rights, and afterwards pushing the patch to GNU Classpath, assigning your authorship rights to the FSF, so the FSF can do whatever things it feels the need to do (like update the license to v3). Complicated? You bet. That's presumably why no one really pushed hard for it. ;) cheers, dalibor topic
Re: [cp-patches] RFC: Separate reflection classes into a VM interface
Christian Thalinger wrote: On Sun, 2008-03-02 at 02:08 +, Andrew John Hughes wrote: This patch separates out common methods from the reflection VM interfaces (Field, Constructor, Method) so that they are provided in Classpath itself, and only native methods now appear in new VMField, VMMethod and VMConstructor classes in the VM interface. There is a lot of duplicate code in these classes that is currently left to the VM to maintain, resulting in large parts of these files in the VM being verbatim copies of the reference implementation and dependent on package-private Classpath methods. Comments please. I think that is a very good idea, as these reflection class were the only ones without a VM-interface class. I'd like to have that in. Yes, please. cheers, dalibor topic
Re: [kaffe] Removed GMP math?
Alan Eliasen wrote: Jim Pick wrote: What's New In Kaffe 1.1.9 * Removed support for native big math. I have to admit, I was *very* disappointed when I saw this. The fact that Kaffe could use the best-of-breed GMP libraries to perform operations with very large BigIntegers was the sole reason that I used and advocated Kaffe. It was the one place where programs run under Kaffe could be enormously, incredibly faster than other JVMs, often by factors of 1000 or even 100,000. The algorithms that replaced it are *vastly* slower for very large numbers. Hi Alan, You're right, and it was a hard decision to make. I've thought about it for a while, and I hope my explanation and proposed resolution below will make some sense. Why was this done? It constitutes a severe performance regression for many programs, and was already switchable so that it could be compiled in and used or not used at runtime if desired, or completely omitted from compilation if you didn't want it. Indeed. What I want though, is to see the GMP-based math code enter GNU Classpath, so that it gets maintained collaboratively, and becomes a shared feature among all the different GNU Classpath based VMs, rather than something only Kaffe is good at. The huge problem with maintaining class library code in Kaffe, rather than GNU Classpath, and GMP big math is a slice of very useful class library code, is that it ends up not being in sync with the rest of the class library, and does not get the level of shared attention between VM projects that code residing in GNU Classpath gets. For example, the Java classes used by the GMP big math implementation in Kaffe differed in the exported APIs from those in GNU Classpath, and there was no bandwidth for an effort to try and maintain them in sync with the API jumps in javax.math from 1.4 (what they approximately implement in Kaffe) to 1.5 (GNU classpath's level). That's a real maintenance problem, and from the level of volunteer activity around Kaffe, I think that the Kaffe project does not have the bandwidth to maintain class library code unless it is shared with other implementations, beside that from a social point of view, having free VMs compete on VM features, rather than class library features that could and absolutely *should* be shared is a lot healthier for the free VM community. So I consider this to be an ugly, but necessary cut, for the long term health of the GMP math bindings: the GNU Classpath project has seen a set of patches by Raif Naffah, http://search.gmane.org/?query=28664author=patch%40naffah-raif.namegroup=sort=relevanceDEFAULTOP=andquery= around GNU Classpath's PR 28664, that have not been merged in for, as far I can tell, the lack of someone of your level of understanding of the problems having a javax.math that uses GMP solves in practice, and how much more efficiently it solves them, to push for the code to get proper review, and be included in GNU Classpath as an option. What you'd get out of pushing GNU Classpath developers to pick up Raif's patches that got dropped on the floor, is a lot more choice regarding the VM you'd be able to use for your work, i.e. you wouldn't be 'stuck' with Kaffe, and could alternatively use IKVM, Cacao, JamVM, gcj, JikesRVM, if their performance or other characteristics suit your work better. While I am working very hard at implementing faster algorithms for the OpenJDK project, my best algorithms are still factors of about 100 times slower than Kaffe/GMP for many large numbers, and nothing one could do in Java could ever match their performance. You're right, of course. How much trouble would it be for whoever removed these parts to revert those changes? I think they were removed without concern for the people who use Kaffe for this very reason, and this reason alone. For me, and the people that use Kaffe/GMP for work in number theory, this is a heartbreaking regression, and one that, quite frankly, makes Kaffe rather unsuitable for my use, as it tends to be about 20-25 times slower than other JVMs for most other programs. I removed them myself, so I offer to produce a patch for you against the 1.1.9 source tarball, that adds Kaffe's GMP code back in, rather then reverting the commit. I think that GMP math needs to find a home in GNU Classpath sooner rather than later, and I don't want to delay that process, so I'd ask you to champion the inclusion of Raif's patch into GNU Classpath, so that we can make sure that Kaffe 1.1.10 and GNU Classpath 0.98 will work out of the box for your needs without regression. Would that work for you? A patch for now from me, and you taking the lead on pushing Raif's code into Classpath? cheers, dalibor topic
Re: [kaffe] Removed GMP math?
Per Bothner wrote: Dalibor Topic wrote: Indeed. What I want though, is to see the GMP-based math code enter GNU Classpath, so that it gets maintained collaboratively, and becomes a shared feature among all the different GNU Classpath based VMs, rather than something only Kaffe is good at. GMP-based math code *is* in ClassPath. The implementation of java.lang.BigInteger was designed so that it could make use of GMP's lower MPN layer. This is (or at least was when I wrote it) the lower-lever layer that did the actual computation, without memory allocation. And this is the layer partly implemented in assembler. On a side note, Andrew Hughes has just cleaned up and merged in Raif's patch, so it would be nice if you Alan could give Classpath's CVS head a shot and see if it works for you. cheers, dalibor topic
Re: brandweg hacking session on friday
Dalibor Topic wrote: Ian Rogers wrote: Dalibor Topic wrote: Andrew John Hughes wrote: Thanks for organising this. I should arrive in Brussels around 4pm on the Friday, so will probably be available around an hour from then I guess (given time to find the hotel and check in, etc.). My preference would be for somewhere with food and drink, but depends on the time we have and the ease of finding such a place. I'll leave that up to those who know Brussels better than I... ;) Should we meet at the BXL at Grand Place from 5pm on? I take it that someone has a laptop or something, if we want this to be a practical session? Sure, I'll bring mine along, and a checkout of the classpath, openjdk and brandweg trees. ;) Hi, apologies for my delay in responding. I will be available all day Friday, so I'd suggest we start earlier (I'm coming to Brussels on the Thursday). I should have wifi access in the Hotel Barry. Could we meet in the morning, maybe at the Hotel Barry? I'm not sure yet how early I'll be able to show up, but I'll post as soon as I know. I'll be in Brussels from 12h on. So I'd either suggest meeting at Hotel Barry at 12:30, or that we meet at Brussels Centraal train station, (my train from Luxembourg arrives 11:47), grab some food, and move over to Hotel Barry to hack on BrandWeg afterwards, until 5pm, and then to move over to BXL. cheers, dalibor topic
Re: brandweg hacking session on friday
Andrew John Hughes wrote: I'll be arriving at Midi about 4pm and then heading towards Hotel Barry to checkin, so I can meet you there if that's where you're going to start hacking. Dalibor, is your number still the same as for last year? Mine is. +49 177 26 64 192. cheers, dalibor topic
Re: brandweg hacking session on friday
Dalibor Topic wrote: Andrew John Hughes wrote: I'll be arriving at Midi about 4pm and then heading towards Hotel Barry to checkin, so I can meet you there if that's where you're going to start hacking. Dalibor, is your number still the same as for last year? Mine is. +49 177 26 64 192. (My phone number was 'out there' on the FOSDEM preparation wiki pages in the last couple of years, so it's as good as public, anyway ;) cheers, dalibor topic
Re: brandweg hacking session on friday
Ian Rogers wrote: Dalibor Topic wrote: I'll be in Brussels from 12h on. So I'd either suggest meeting at Hotel Barry at 12:30, or that we meet at Brussels Centraal train station, (my train from Luxembourg arrives 11:47), grab some food, and move over to Hotel Barry to hack on BrandWeg afterwards, until 5pm, and then to move over to BXL. cheers, dalibor topic Hi, well the hotel barry is pretty (very) basic but the wifi seems ok (just used it for a skype conversation without any noticeable break up). I'm in room xx and my phone number is +44 xxx xxx . Is the centraal train station the midi train station? If so, I should be able to find my way there and loiter at about noon. I like to eat food too, so I'd suggest we meet, eat and then hack. OK. Rather than hunting each other on train stations (as it turns out that I'll be coming over by car with friends), I'd suggest that we meet at the Grand Place at 12:30, in front of the Cafe de BXL, and then decide where to move on to wrt to food, and hacking. Just FYI I have a few objectives that I'd like to work towards from the hacking: 1) get a Jikes RVM build configuration that can work with BrandWeg 2) test ECJ and x10c with BrandWeg 3) look at making the java.math configuration of BrandWeg pluggable between the Classpath and OpenJDK versions (a couple of benchmarks hit java.math code and it would be nice to rule it out as a source of performance loss). I imagine this could spark some conversation on how we track code in BrandWeg, acknowledgements, how to configure choices like this. 4) think of any other problems like number 3 Sounds fun to me, I'm looking forward to it. cheers, dalibor topic
Re: brandweg hacking session on friday
Ian Rogers wrote: Dalibor Topic wrote: Andrew John Hughes wrote: Thanks for organising this. I should arrive in Brussels around 4pm on the Friday, so will probably be available around an hour from then I guess (given time to find the hotel and check in, etc.). My preference would be for somewhere with food and drink, but depends on the time we have and the ease of finding such a place. I'll leave that up to those who know Brussels better than I... ;) Should we meet at the BXL at Grand Place from 5pm on? I take it that someone has a laptop or something, if we want this to be a practical session? Sure, I'll bring mine along, and a checkout of the classpath, openjdk and brandweg trees. ;) Hi, apologies for my delay in responding. I will be available all day Friday, so I'd suggest we start earlier (I'm coming to Brussels on the Thursday). I should have wifi access in the Hotel Barry. Could we meet in the morning, maybe at the Hotel Barry? I'm not sure yet how early I'll be able to show up, but I'll post as soon as I know. cheers, dalibor topic
Re: Classpath's doubleToLongBits
Christian Thalinger schrieb: On Mon, 2008-02-18 at 04:03 +0100, Dalibor Topic wrote: This one turned out to be a lot more fun to track down. It's pretty easy to rewrite the test whether to swap words in a jdouble: put -0.0 into a jvalue's jdouble element, and if the correspoding jlong bitstream is 0, you have to swap the words. It's a way of dynamically doing what the fdlibm #defines do, but it works out the same way: swap on arm-debian-oabi. But that didn't fix the breakage. So I played around some more, and eventually, it turned out that kaffe's classfile constant parser was working fine, and I was reading in doubles the way arm's FPU expected them laid out, it turned out the interpreter was working ok, too, and so on. But the breakage was still there. Turning the way, for example, the double constants were parsed around, and doing it the 'wrong' way, fixed some regression tests, but broke others. Similarly, reassembling doubles in the interpreter from words the 'wrong' way had the same effect with other tests. So I had to examine things a bit more closely with jcf-dump. It turned out that, since I was using a glibj.zip compiled on an x86-linux host, the constant in the class java.lang.Double were laid out correctly. But in the tests classes compiled on the arm-oabi-linux platform using ecj on gcj-4.3, double constants were laid out incorrectly, with their words swapped, as a comparison with the tests compiled on x86-linux with ecj on gcj showed. So, current Kaffe CVS head interpreter works on arm-oabi-linux without regressions. The regressions Kiyo-san has seen are caused by buggy compilers (jikes / ecj on gcj). And I'll move on to comitting the jit patches for arm-linux next. That sounds like it was a lot of work. Did you change anything new in GNU Classpath or should I test the current CVS version I wrote a patch using the -0.0d 0L hack described above to detect whether we should switch words in a double, but it turned out not to be necessary, so current CVS is fine (and contains no related changes). cheers, dalibor topic
Re: brandweg hacking session on friday
Andrew John Hughes wrote: Thanks for organising this. I should arrive in Brussels around 4pm on the Friday, so will probably be available around an hour from then I guess (given time to find the hotel and check in, etc.). My preference would be for somewhere with food and drink, but depends on the time we have and the ease of finding such a place. I'll leave that up to those who know Brussels better than I... ;) Should we meet at the BXL at Grand Place from 5pm on? I take it that someone has a laptop or something, if we want this to be a practical session? Sure, I'll bring mine along, and a checkout of the classpath, openjdk and brandweg trees. ;) cheers, dalibor topic
brandweg hacking session on friday
hi all, so, since a couple of us want to get some development done on Friday, I wanted to ask around who's coming and when, so please reply when you'll be around on Friday, if you're interested in poking around at making this merge work out. That's how we'll figure out time. There are two easy options for locations: a) squatting in someone's hotel (rooms) for a few hours (mhm, wifi!) b) taking over a cafe downtown and doing the work there (mhm, waffles!) or a combination of both (wifi waffles!). Preferences, ideas, etc? fire away, dalibor topic
Re: Classpath's doubleToLongBits
Christian Thalinger schrieb: On Fri, 2008-02-08 at 12:25 +0100, Dalibor Topic wrote: Yeah, that's why I'd like to go step by step, and first slash the VM interface methods I can slash, and then implement it with ieee754.h as an option, (adding a #define BIG_ENDIAN __BIG_ENDIAN for the broken glibc versions). I'll make sure to post the native patches for comments first, as I don't have access to a VFP box. OK, I hope I still have access to this box, but I'll try to test them. This one turned out to be a lot more fun to track down. It's pretty easy to rewrite the test whether to swap words in a jdouble: put -0.0 into a jvalue's jdouble element, and if the correspoding jlong bitstream is 0, you have to swap the words. It's a way of dynamically doing what the fdlibm #defines do, but it works out the same way: swap on arm-debian-oabi. But that didn't fix the breakage. So I played around some more, and eventually, it turned out that kaffe's classfile constant parser was working fine, and I was reading in doubles the way arm's FPU expected them laid out, it turned out the interpreter was working ok, too, and so on. But the breakage was still there. Turning the way, for example, the double constants were parsed around, and doing it the 'wrong' way, fixed some regression tests, but broke others. Similarly, reassembling doubles in the interpreter from words the 'wrong' way had the same effect with other tests. So I had to examine things a bit more closely with jcf-dump. It turned out that, since I was using a glibj.zip compiled on an x86-linux host, the constant in the class java.lang.Double were laid out correctly. But in the tests classes compiled on the arm-oabi-linux platform using ecj on gcj-4.3, double constants were laid out incorrectly, with their words swapped, as a comparison with the tests compiled on x86-linux with ecj on gcj showed. So, current Kaffe CVS head interpreter works on arm-oabi-linux without regressions. The regressions Kiyo-san has seen are caused by buggy compilers (jikes / ecj on gcj). And I'll move on to comitting the jit patches for arm-linux next. cheers, dalibor topic
Re: [cp-patches] RFC: Move to AC_PROG_JAVAC and remove the old cruft
Andrew John Hughes wrote: This patch makes Classpath use the AC_PROG_JAVAC macros from the autoconf archive, as Kaffe now does (see Dalibor's recent patches). Instead of detecting both ecj and javac, the build will now test for ecj, javac and gcj in that order, and use the first one. It tests the chosen compiler for 1.5 compatibility (a local extension) and we also retain the -J test. You can override the choice with JAVAC=compiler of choice and add options with JAVACFLAGS=flags of choice. ChangeLog: 2008-02-10 Andrew John Hughes [EMAIL PROTECTED] * NEWS: Mention javah and javac build changes. * configure.ac: Call AC_PROG_JAVAC and CLASSPATH_JAVAC_MEM_CHECK instead of CLASSPATH_FIND_JAVAC. * examples/Makefile.am: Simplify compiler choice to just use JAVAC. * lib/Makefile.am: Likewise, but with JAVAC_MEM_OPT too. * m4/ac_prog_javac.m4: New file. * m4/ac_prog_javac_works.m4: Likewise. * m4/acinclude.m4: (CLASSPATH_FIND_JAVAC): Removed. (CLASSPATH_WITH_GCJ): Removed. (CLASSPATH_CHECK_GCJ): Removed. (CLASSPATH_WITH_JIKES): Removed. (CLASSPATH_CHECK_JIKES): Removed. (CLASSPATH_WITH_KJC): Removed. (CLASSPATH_CHECK_KJC): Removed. (CLASSPATH_WITH_ECJ): Removed. (CLASSPATH_CHECK_ECJ): Removed. (CLASSPATH_WITH_JAVAC): Removed. (CLASSPATH_CHECK_JAVAC): Removed. (CLASSPATH_JAVAC_MEM_CHECK): Added. * tools/Makefile.am: Simplify compiler choice to just javac. Very cool. This should allow us to move to use straight automake java support at least for the examples, and tools, rather than using our own manual compiler flag assembly, source file listing and CVS directory purging scripts. Oh, and to rewrite the 1.5 checks in terms of AC_JAVAC_TRY_COMPILE. ;) cheers, dalibor topic
Re: [cp-patches] FYI: Fix path in JNI check script
Andrew John Hughes wrote: This fixes a problem in the build introduced by Dalibor's latest patch. The check_jni_methods script is generated using @top_builddir@, which is a relative path that will be '..' from scripts (where check_jni_methods lives). However, Dalibor's patch also calls the script from native/jni which has a @top_builddir@ of ../../. Thus, when it comes time to run the script, it can't find the include files as the script uses the wrong relative path: make[3]: Entering directory `/home/andrew/builder/classpath/native/jni' /bin/sh ../../scripts/check_jni_methods.sh grep: ../include/*.h: No such file or directory Found a problem with the JNI methods declared and implemented. This patch fixes it by using abs_top_builddir instead. There is still a remaining minor issue in that the header files aren't generated in the build directory of a parallel build if they exist in the source directory. Thanks, Andrew, for spotting and fixing it so quickly. And sorry for introducing it ... cheers, dalibor topic
Re: [cp-patches] FYI: generate headers in build dir, rather than source dir
Andrew John Hughes wrote: Also we still seem to be looking for a javah, which means we are now reliant on its existence for a successful build. Given we bundle gjavah, couldn't we build tools first and then invoke this? This wasn't possible before, but we now rely on compilers with VM requirements anyway. I'd prefer not to use the tools we build during the build, as that makes the build more fragile: both a bug in the VM and in our tools code could bring it down. Separating potential causes of build failure is a good thing for the poor souls who get to debug them. ;) cheers, dalibor topic
[cp-patches] FYI: check for gjavah-4.3
Hi all,
I've added a check for gjavah-4.3.
cheers,
dalibor topic
2008-02-10 Dalibor Topic [EMAIL PROTECTED]
* m4/acinclude.m4 (CLASSPATH_CHECK_JAVAH)[USER_JAVAH]:
Check for gjavah-4.3.
Index: m4/acinclude.m4
===
RCS file: /sources/classpath/classpath/m4/acinclude.m4,v
retrieving revision 1.29
diff -u -p -r1.29 acinclude.m4
--- m4/acinclude.m4 8 Feb 2008 23:26:20 - 1.29
+++ m4/acinclude.m4 10 Feb 2008 20:07:21 -
@@ -221,7 +221,7 @@ AC_DEFUN([CLASSPATH_CHECK_JAVAH],
AC_PATH_PROG(USER_JAVAH, $1)
fi
else
-AC_PATH_PROGS([USER_JAVAH],[gjavah gjavah-4.2 gjavah-4.1 gcjh-wrapper-4.1 gcjh-4.1 gcjh javah])
+AC_PATH_PROGS([USER_JAVAH],[gjavah gjavah-4.3 gjavah-4.2 gjavah-4.1 gcjh-wrapper-4.1 gcjh-4.1 gcjh javah])
fi
if test x${USER_JAVAH} = x; then
[cp-patches] FYI: removed unused --with-classpath option
hi all,
I've removed the unused --with-classpath option, since it does the same
thing (afaict), as --with-glibj-zip does. This fixes the build for
builds using --with-glibj-zip, too.
cheers,
dalibor topic
2008-02-10 Dalibor Topic [EMAIL PROTECTED]
* lib/Makefile.am (compile_classpath), include/Makefile.am (JAVAH):
Replaced USER_CLASSLIB with PATH_TO_GLIBJ_ZIP.
* m4/acinclude.m4 (CLASSPATH_WITH_CLASSLIB)[--with-classpath]:
Removed unused option. It's superceded by --with-glibj-zip.
Index: include/Makefile.am
===
RCS file: /sources/classpath/classpath/include/Makefile.am,v
retrieving revision 1.84
diff -u -p -r1.84 Makefile.am
--- include/Makefile.am 9 Feb 2008 21:16:19 - 1.84
+++ include/Makefile.am 10 Feb 2008 20:51:52 -
@@ -4,7 +4,7 @@ DISTCLEANFILES = jni_md.h config-int.h $
ARG_JNI_JAVAH = -jni
ARG_CLASSPATH_JAVAH = -bootclasspath
-JAVAH = $(USER_JAVAH) $(ARG_JNI_JAVAH) $(ARG_CLASSPATH_JAVAH) ../lib:$(USER_CLASSLIB)
+JAVAH = $(USER_JAVAH) $(ARG_JNI_JAVAH) $(ARG_CLASSPATH_JAVAH) ../lib:$(PATH_TO_GLIBJ_ZIP)
CLASSDIR = lib
SOUND_H_FILES = \
Index: lib/Makefile.am
===
RCS file: /sources/classpath/classpath/lib/Makefile.am,v
retrieving revision 1.140
diff -u -p -r1.140 Makefile.am
--- lib/Makefile.am 28 Dec 2007 17:35:35 - 1.140
+++ lib/Makefile.am 10 Feb 2008 20:51:52 -
@@ -5,7 +5,7 @@ JAVA_DEPEND = java.dep
## this file and restart the make process again
sinclude $(JAVA_DEPEND)
-compile_classpath = $(vm_classes):$(top_srcdir):$(top_srcdir)/external/w3c_dom:$(top_srcdir)/external/sax:$(top_srcdir)/external/relaxngDatatype:$(top_srcdir)/external/jsr166:.:$(USER_CLASSLIB):$(PATH_TO_ESCHER)
+compile_classpath = $(vm_classes):$(top_srcdir):$(top_srcdir)/external/w3c_dom:$(top_srcdir)/external/sax:$(top_srcdir)/external/relaxngDatatype:$(top_srcdir)/external/jsr166:.:$(PATH_TO_GLIBJ_ZIP):$(PATH_TO_ESCHER)
# handling source to bytecode compiler programs like gcj, jikes and kjc
if FOUND_ECJ
Index: m4/acinclude.m4
===
RCS file: /sources/classpath/classpath/m4/acinclude.m4,v
retrieving revision 1.30
diff -u -p -r1.30 acinclude.m4
--- m4/acinclude.m4 10 Feb 2008 20:18:57 - 1.30
+++ m4/acinclude.m4 10 Feb 2008 20:51:53 -
@@ -234,28 +234,6 @@ dnl CLASSPATH_WITH_CLASSLIB - checks for
dnl ---
AC_DEFUN([CLASSPATH_WITH_CLASSLIB],
[
- AC_ARG_WITH([classpath],
- [AS_HELP_STRING(--with-classpath,specify path to a classes.zip like file)],
- [
-if test x${withval} = xyes; then
- # set user classpath to CLASSPATH from env
- AC_MSG_CHECKING(for classlib)
- USER_CLASSLIB=${CLASSPATH}
- AC_SUBST(USER_CLASSLIB)
- AC_MSG_RESULT(${USER_CLASSLIB})
- conditional_with_classlib=true
-elif test x${withval} != x test x${withval} != xno; then
- # set user classpath to specified value
- AC_MSG_CHECKING(for classlib)
- USER_CLASSLIB=${withval}
- AC_SUBST(USER_CLASSLIB)
- AC_MSG_RESULT(${withval})
- conditional_with_classlib=true
-fi
- ],
- [ conditional_with_classlib=false ])
- AM_CONDITIONAL(USER_SPECIFIED_CLASSLIB, test x${conditional_with_classlib} = xtrue)
-
AC_ARG_WITH([vm-classes],
[AS_HELP_STRING(--with-vm-classes,specify path to VM override source files)], [vm_classes=$with_vm_classes],
[vm_classes='${top_srcdir}/vm/reference'])
[commit-cp] classpath ChangeLog m4/acinclude.m4
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/02/10 20:18:58 Modified files: . : ChangeLog m4 : acinclude.m4 Log message: 2008-02-10 Dalibor Topic [EMAIL PROTECTED] * m4/acinclude.m4 (CLASSPATH_CHECK_JAVAH)[USER_JAVAH]: Check for gjavah-4.3. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9496r2=1.9497 http://cvs.savannah.gnu.org/viewcvs/classpath/m4/acinclude.m4?cvsroot=classpathr1=1.29r2=1.30
[commit-cp] classpath ChangeLog include/Makefile.am lib/Mak...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/02/10 23:28:12 Modified files: . : ChangeLog include: Makefile.am lib: Makefile.am m4 : acinclude.m4 Log message: 2008-02-10 Dalibor Topic [EMAIL PROTECTED] * lib/Makefile.am (compile_classpath), include/Makefile.am (JAVAH): Replaced USER_CLASSLIB with PATH_TO_GLIBJ_ZIP. * m4/acinclude.m4 (CLASSPATH_WITH_CLASSLIB)[--with-classpath]: Removed unused option. It's superceded by --with-glibj-zip. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9497r2=1.9498 http://cvs.savannah.gnu.org/viewcvs/classpath/include/Makefile.am?cvsroot=classpathr1=1.84r2=1.85 http://cvs.savannah.gnu.org/viewcvs/classpath/lib/Makefile.am?cvsroot=classpathr1=1.140r2=1.141 http://cvs.savannah.gnu.org/viewcvs/classpath/m4/acinclude.m4?cvsroot=classpathr1=1.30r2=1.31
Re: [cp-patches] RFC: remove generated headers from include
Dalibor Topic wrote: Sounds good as a first step, I'll check in a patch to include/Makefile.am etc. later to make sure the headers are generated in the build dir, and that distcheck passes. Committed. cheers, dalibor topic
[cp-patches] FYI: generate headers in build dir, rather than source dir
hi all, the attached patch makes sure that the headers are generated in the build dir, rather than in the source dir. cheers, dalibor topic 2008-02-09 Dalibor Topic [EMAIL PROTECTED] * native/jni/Makefile.am (all-local): Call check_jni_methods.sh directly. * scripts/Makefile.am (EXTRA_DIST): Removed check_jni_methods.sh. * include/Makefile.am (SOUND_H_FILES, GST_PEER_H_FILES) (XMLJ_H_FILES, GTKPEER_H_FILES, QTPEER_H_FILES) (GCONF_PREFS_FILES, H_FILES): Don't generate header files in the source directory, as it may not be writeable. (DISTCLEANFILES) Added H_FILES. * configure.ac (AC_CONFIG_FILES): Added scripts/check_jni_methods.sh. * scripts/check_jni_methods.sh: Removed. Moved over to .. * scripts/check_jni_methods.sh.in: New file. Added top_srcdir and top_builddir where necessary. Index: configure.ac === RCS file: /sources/classpath/classpath/configure.ac,v retrieving revision 1.221 diff -u -p -r1.221 configure.ac --- configure.ac 8 Feb 2008 22:26:47 - 1.221 +++ configure.ac 9 Feb 2008 21:12:54 - @@ -976,6 +976,7 @@ scripts/classpath.spec lib/Makefile lib/gen-classlist.sh lib/copy-vmresources.sh +scripts/check_jni_methods.sh tools/Makefile examples/Makefile examples/Makefile.jawt Index: include/Makefile.am === RCS file: /sources/classpath/classpath/include/Makefile.am,v retrieving revision 1.83 diff -u -p -r1.83 Makefile.am --- include/Makefile.am 18 Aug 2007 15:23:12 - 1.83 +++ include/Makefile.am 9 Feb 2008 21:12:54 - @@ -1,6 +1,6 @@ include_HEADERS = jni.h jni_md.h jawt.h jawt_md.h -DISTCLEANFILES = jni_md.h config-int.h +DISTCLEANFILES = jni_md.h config-int.h $(H_FILES) ARG_JNI_JAVAH = -jni ARG_CLASSPATH_JAVAH = -bootclasspath @@ -8,118 +8,118 @@ JAVAH = $(USER_JAVAH) $(ARG_JNI_JAVAH) $ CLASSDIR = lib SOUND_H_FILES = \ -$(top_srcdir)/include/gnu_javax_sound_midi_alsa_AlsaPortDevice.h \ -$(top_srcdir)/include/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.h \ -$(top_srcdir)/include/gnu_javax_sound_midi_alsa_AlsaMidiDeviceProvider.h \ -$(top_srcdir)/include/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.h \ -$(top_srcdir)/include/gnu_javax_sound_midi_dssi_DSSISynthesizer.h +gnu_javax_sound_midi_alsa_AlsaPortDevice.h \ +gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.h \ +gnu_javax_sound_midi_alsa_AlsaMidiDeviceProvider.h \ +gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.h \ +gnu_javax_sound_midi_dssi_DSSISynthesizer.h GST_PEER_H_FILES = \ -$(top_srcdir)/include/gnu_javax_sound_sampled_gstreamer_io_GstAudioFileReaderNativePeer.h \ -$(top_srcdir)/include/gnu_javax_sound_sampled_gstreamer_io_GstInputStream.h \ -$(top_srcdir)/include/gnu_javax_sound_sampled_gstreamer_lines_GstNativeDataLine.h \ -$(top_srcdir)/include/gnu_javax_sound_sampled_gstreamer_lines_GstPipeline.h +gnu_javax_sound_sampled_gstreamer_io_GstAudioFileReaderNativePeer.h \ +gnu_javax_sound_sampled_gstreamer_io_GstInputStream.h \ +gnu_javax_sound_sampled_gstreamer_lines_GstNativeDataLine.h \ +gnu_javax_sound_sampled_gstreamer_lines_GstPipeline.h XMLJ_H_FILES = \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeDocument.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeXPathNodeList.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeDocumentType.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeProcessingInstruction.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeTypeInfo.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeNodeList.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeNotation.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeXPathResult.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeElement.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeEntity.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeNode.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeXPathExpression.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeNamedNodeMap.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeDocumentBuilder.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_dom_GnomeAttr.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_sax_GnomeLocator.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_sax_GnomeXMLReader.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_transform_GnomeTransformer.h \ -$(top_srcdir)/include/gnu_xml_libxmlj_transform_GnomeTransformerFactory.h +gnu_xml_libxmlj_dom_GnomeDocument.h \ +gnu_xml_libxmlj_dom_GnomeXPathNodeList.h \ +gnu_xml_libxmlj_dom_GnomeDocumentType.h \ +gnu_xml_libxmlj_dom_GnomeProcessingInstruction.h \ +gnu_xml_libxmlj_dom_GnomeTypeInfo.h \ +gnu_xml_libxmlj_dom_GnomeNodeList.h \ +gnu_xml_libxmlj_dom_GnomeNotation.h \ +gnu_xml_libxmlj_dom_GnomeXPathResult.h \ +gnu_xml_libxmlj_dom_GnomeElement.h \ +gnu_xml_libxmlj_dom_GnomeEntity.h \ +gnu_xml_libxmlj_dom_GnomeNode.h \ +gnu_xml_libxmlj_dom_GnomeXPathExpression.h
Re: [cp-patches] RFC: Double.doubleToLongBits simplified
Ian Rogers schrieb: Dalibor Topic wrote: Hi all, I've implemented doubleToLongBits without requring a VMDouble method of the same name. It would let us remove one method from the VM interface for the next version, and the corresoponding native code. OK to commit? (I'd do the equivalent patch for Float, too). * java/lang/Double.java (doubleToLongBits): Simplified. cheers, dalibor topic Hi, if this life makes things easier for you then its a good thing. The Jikes RVM already does this at the VMDouble level, and just has a doubleAsRawLongBits magic/native method. So, I'm not sure if this change shouldn't be pushed down into VMDouble, or at least if it is done in Double the obsolete doubleToLongBits call in VMDouble should be removed. Yeah, I'll do the latter, as there is no point in having this method in the VM interface if we can do it (and the methods its implementation invokes) in Java. Same for Float and the int conversion method. cheers, dalibor topic
Re: [cp-patches] RFC: Double.doubleToLongBits simplified
Christian Thalinger wrote: On Fri, 2008-02-08 at 12:23 +0100, Dalibor Topic wrote: Yeah, I'll do the latter, as there is no point in having this method in the VM interface if we can do it (and the methods its implementation invokes) in Java. Same for Float and the int conversion method. I completely agree. Thanks for the feedback. I've committed the patch, and will send the remaining changes FYI soon, with the native code changes RFC after that. cheers, dalibor topic
[cp-patches] FYI: announce VM interface change
Hi all, this patch completes the update to the VM interface by adding an entry into the NEWS file. cheers, dalibor topic 2008-02-08 Dalibor Topic [EMAIL PROTECTED] * NEWS: Documented removal of floatToIntBits and doubleToLongBits from VM interface. Index: NEWS === RCS file: /sources/classpath/classpath/NEWS,v retrieving revision 1.187 diff -u -r1.187 NEWS --- NEWS 16 Oct 2007 20:28:28 - 1.187 +++ NEWS 8 Feb 2008 18:39:33 - @@ -1,5 +1,9 @@ New in release 0.97 +Runtime interface changes: + +* Removed VMFloat.floatToIntBits amd VMDouble.doubleToLongBits. + New in release 0.96.1 (Oct 16, 2007) * Small compile, configure and build fixes.
[cp-patches] FYI: removed floatToIntBits from vm interface
Hi all,
as discussed in another thread, I've applied the attached patch.
cheers,
dalibor topic
2008-02-08 Dalibor Topic [EMAIL PROTECTED]
* vm/reference/java/lang/VMFloat.java (floatToIntBits): Removed
unused
method.
* native/jni/java-lang/java_lang_VMFloat.c
(Java_java_lang_VMFloat_floatToIntBits): Removed unused function.
* include/java_lang_VMDouble.h: Regenerated.
* doc/cp-vmintegration.texinfo (java.lang.VMFloat): Removed
unused method floatToIntBits. (java.lang.VMDouble): Use similar
text to text used for floatToRawIntBits for doubleToLongBits.
Index: doc/cp-vmintegration.texinfo
===
RCS file: /sources/classpath/classpath/doc/cp-vmintegration.texinfo,v
retrieving revision 1.3
diff -u -p -r1.3 cp-vmintegration.texinfo
--- doc/cp-vmintegration.texinfo 8 Feb 2008 17:42:57 - 1.3
+++ doc/cp-vmintegration.texinfo 8 Feb 2008 18:32:17 -
@@ -526,8 +526,8 @@ compiler, and is specific to the compile
of doubles.
@itemize @bullet
[EMAIL PROTECTED] @code{doubleToRawLongBits(double)} -- Same as the above, but preserves
-NaNs.
[EMAIL PROTECTED] @code{doubleToRawLongBits(double)} -- Converts the double to the IEEE 754
+bit layout, preserving NaNs.
@item @code{longBitsToDouble(long)} -- This is the inverse of the last method,
preserving NaNs so that the output of one can be fed into the other without
data loss.
@@ -550,10 +550,8 @@ implementation optional.
@code{VMFloat} provides native support for the conversion of floats.
@itemize @bullet
[EMAIL PROTECTED] @code{floatToIntBits(float)} -- Converts the float to the IEEE 754
-bit layout, collapsing NaNs to @code{0x7fc0}.
[EMAIL PROTECTED] @code{floatToRawIntBits(float)} -- Same as the above, but preserves
-NaNs.
[EMAIL PROTECTED] @code{floatToRawIntBits(float)} -- Converts the float to the IEEE 754
+bit layout, preserving NaNs.
@item @code{intBitsToFloat(int)} -- This is the inverse of the last method,
preserving NaNs so that the output of one can be fed into the other without
data loss.
Index: include/java_lang_VMFloat.h
===
RCS file: /sources/classpath/classpath/include/java_lang_VMFloat.h,v
retrieving revision 1.2
diff -u -p -r1.2 java_lang_VMFloat.h
--- include/java_lang_VMFloat.h 28 May 2004 17:27:55 - 1.2
+++ include/java_lang_VMFloat.h 8 Feb 2008 18:32:17 -
@@ -1,16 +1,15 @@
/* DO NOT EDIT THIS FILE - it is machine generated */
+#include jni.h
+
#ifndef __java_lang_VMFloat__
#define __java_lang_VMFloat__
-#include jni.h
-
#ifdef __cplusplus
extern C
{
#endif
-JNIEXPORT jint JNICALL Java_java_lang_VMFloat_floatToIntBits (JNIEnv *env, jclass, jfloat);
JNIEXPORT jint JNICALL Java_java_lang_VMFloat_floatToRawIntBits (JNIEnv *env, jclass, jfloat);
JNIEXPORT jfloat JNICALL Java_java_lang_VMFloat_intBitsToFloat (JNIEnv *env, jclass, jint);
Index: native/jni/java-lang/java_lang_VMFloat.c
===
RCS file: /sources/classpath/classpath/native/jni/java-lang/java_lang_VMFloat.c,v
retrieving revision 1.8
diff -u -p -r1.8 java_lang_VMFloat.c
--- native/jni/java-lang/java_lang_VMFloat.c 2 Jul 2005 20:32:55 - 1.8
+++ native/jni/java-lang/java_lang_VMFloat.c 8 Feb 2008 18:32:18 -
@@ -42,28 +42,6 @@ exception statement from your version. *
/*
* Class: java_lang_VMFloat
- * Method:floatToIntBits
- * Signature: (F)I
- */
-JNIEXPORT jint JNICALL
-Java_java_lang_VMFloat_floatToIntBits
- (JNIEnv * env __attribute__ ((__unused__)),
- jclass cls __attribute__ ((__unused__)), jfloat value)
-{
- jvalue u;
- jint e, f;
- u.f = value;
- e = u.i 0x7f80;
- f = u.i 0x007f;
-
- if (e == 0x7f80 f != 0)
-u.i = 0x7fc0;
-
- return u.i;
-}
-
-/*
- * Class: java_lang_VMFloat
* Method:floatToRawIntBits
* Signature: (F)I
*/
Index: vm/reference/java/lang/VMFloat.java
===
RCS file: /sources/classpath/classpath/vm/reference/java/lang/VMFloat.java,v
retrieving revision 1.3
diff -u -p -r1.3 VMFloat.java
--- vm/reference/java/lang/VMFloat.java 11 May 2007 08:07:46 - 1.3
+++ vm/reference/java/lang/VMFloat.java 8 Feb 2008 18:32:18 -
@@ -67,21 +67,6 @@ final class VMFloat
* Convert the float to the IEEE 754 floating-point single format bit
* layout. Bit 31 (the most significant) is the sign bit, bits 30-23
* (masked by 0x7f80) represent the exponent, and bits 22-0
- * (masked by 0x007f) are the mantissa. This function collapses all
- * versions of NaN to 0x7fc0. The result of this function can be used
- * as the argument to codeFloat.intBitsToFloat(int)/code to obtain the
- * original codefloat/code value.
- *
- * @param value the codefloat/code to convert
- * @return the bits of the codefloat/code
- * @see #intBitsToFloat(int
[cp-patches] FYI: simplified floatToIntBits
Hi all,
as discussed in a previous thread, I've committed the attached patch.
cheers,
dalibor topic
* java/lang/Float.java (floatToIntBits): Simplified.
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/lang/Float.java
===
RCS file: /sources/classpath/classpath/java/lang/Float.java,v
retrieving revision 1.37
diff -u -r1.37 Float.java
--- java/lang/Float.java 12 Oct 2007 08:50:50 - 1.37
+++ java/lang/Float.java 8 Feb 2008 18:14:58 -
@@ -526,7 +526,10 @@
*/
public static int floatToIntBits(float value)
{
-return VMFloat.floatToIntBits(value);
+if (isNaN(value))
+ return 0x7fc0;
+else
+ return VMFloat.floatToRawIntBits(value);
}
/**
Re: [cp-patches] RFC: remove generated headers from include
Mario Torre schrieb: I'm going to commit this patch if ok. Thanks, Mario 2008-02-08 Mario Torre [EMAIL PROTECTED] * configure.ac: --enable-regen-header option now enabled by default. * include/gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer.h: Removed. * include/gnu_java_awt_peer_gtk_CairoGraphics2D.h: Removed. * include/gnu_java_awt_peer_gtk_CairoSurface.h: Removed. * include/gnu_java_awt_peer_gtk_ComponentGraphics.h: Removed. * include/gnu_java_awt_peer_gtk_ComponentGraphicsCopy.h: Removed. * include/gnu_java_awt_peer_gtk_FreetypeGlyphVector.h: Removed. * include/gnu_java_awt_peer_gtk_GdkFontPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GdkGraphicsEnvironment.h: Removed. * include/gnu_java_awt_peer_gtk_GdkPixbufDecoder.h: Removed. * include/gnu_java_awt_peer_gtk_GdkRobotPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GdkScreenGraphicsDevice.h: Removed. * include/gnu_java_awt_peer_gtk_GtkButtonPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkCanvasPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkCheckboxMenuItemPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkCheckboxPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkChoicePeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkClipboard.h: Removed. * include/gnu_java_awt_peer_gtk_GtkComponentPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkEmbeddedWindowPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkFileDialogPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkFramePeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkGenericPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkImage.h: Removed. * include/gnu_java_awt_peer_gtk_GtkLabelPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkListPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkMenuBarPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkMenuComponentPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkMenuItemPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkMenuPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkPanelPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkScrollPanePeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkSelection.h: Removed. * include/gnu_java_awt_peer_gtk_GtkTextAreaPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkTextFieldPeer.h: Removed. * include/gnu_java_awt_peer_gtk_GtkToolkit.h: Removed. * include/gnu_java_awt_peer_gtk_GtkVolatileImage.h: Removed. * include/gnu_java_awt_peer_gtk_GtkWindowPeer.h: Removed. * include/gnu_java_awt_peer_qt_MainQtThread.h: Removed. * include/gnu_java_awt_peer_qt_QMatrix.h: Removed. * include/gnu_java_awt_peer_qt_QPainterPath.h: Removed. * include/gnu_java_awt_peer_qt_QPen.h: Removed. * include/gnu_java_awt_peer_qt_QtAudioClip.h: Removed. * include/gnu_java_awt_peer_qt_QtButtonPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtCanvasPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtCheckboxPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtChoicePeer.h: Removed. * include/gnu_java_awt_peer_qt_QtComponentPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtDialogPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtEmbeddedWindowPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtFileDialogPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtFontMetrics.h: Removed. * include/gnu_java_awt_peer_qt_QtFontPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtFramePeer.h: Removed. * include/gnu_java_awt_peer_qt_QtGraphics.h: Removed. * include/gnu_java_awt_peer_qt_QtImage.h: Removed. * include/gnu_java_awt_peer_qt_QtLabelPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtListPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtMenuBarPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtMenuComponentPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtMenuItemPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtMenuPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtPanelPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtPopupMenuPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtScreenDevice.h: Removed. * include/gnu_java_awt_peer_qt_QtScrollbarPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtScrollPanePeer.h: Removed. * include/gnu_java_awt_peer_qt_QtTextAreaPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtTextFieldPeer.h: Removed. * include/gnu_java_awt_peer_qt_QtToolkit.h: Removed. * include/gnu_java_awt_peer_qt_QtVolatileImage.h: Removed. *
[cp-patches] FYI: removed VMDouble.doubleToLongBits from vm interface
Hi all,
as discussed on the list, I've removed the method.
cheers,
dalibor topic
2008-02-08 Dalibor Topic [EMAIL PROTECTED]
* m4/acinclude.m4 (CLASSPATH_CHECK_JAVAH) [USER_JAVAH]: Check
for gjavah-4.2
and gjavah-4.1.
2008-02-08 Dalibor Topic [EMAIL PROTECTED]
* vm/reference/java/lang/VMDouble.java (doubleToLongBits): Removed
unused method.
* native/jni/java-lang/java_lang_VMDouble.c
(Java_java_lang_VMDouble_doubleToLongBits):
Removed unused function.
* include/java_lang_VMDouble.h: Regenerated.
* doc/cp-vmintegration.texinfo (java.lang.VMDouble): Removed
unused method doubleToLongBits.
Index: doc/cp-vmintegration.texinfo
===
RCS file: /sources/classpath/classpath/doc/cp-vmintegration.texinfo,v
retrieving revision 1.2
diff -u -p -r1.2 cp-vmintegration.texinfo
--- doc/cp-vmintegration.texinfo 19 Feb 2007 14:42:46 - 1.2
+++ doc/cp-vmintegration.texinfo 8 Feb 2008 17:39:49 -
@@ -526,8 +526,6 @@ compiler, and is specific to the compile
of doubles.
@itemize @bullet
[EMAIL PROTECTED] @code{doubleToLongBits(double)} -- Converts the double to the IEEE 754
-bit layout, collapsing NaNs to @code{0x7ff8L}.
@item @code{doubleToRawLongBits(double)} -- Same as the above, but preserves
NaNs.
@item @code{longBitsToDouble(long)} -- This is the inverse of the last method,
Index: include/java_lang_VMDouble.h
===
RCS file: /sources/classpath/classpath/include/java_lang_VMDouble.h,v
retrieving revision 1.3
diff -u -p -r1.3 java_lang_VMDouble.h
--- include/java_lang_VMDouble.h 16 Apr 2005 09:19:54 - 1.3
+++ include/java_lang_VMDouble.h 8 Feb 2008 17:39:50 -
@@ -1,16 +1,15 @@
/* DO NOT EDIT THIS FILE - it is machine generated */
+#include jni.h
+
#ifndef __java_lang_VMDouble__
#define __java_lang_VMDouble__
-#include jni.h
-
#ifdef __cplusplus
extern C
{
#endif
-JNIEXPORT jlong JNICALL Java_java_lang_VMDouble_doubleToLongBits (JNIEnv *env, jclass, jdouble);
JNIEXPORT jlong JNICALL Java_java_lang_VMDouble_doubleToRawLongBits (JNIEnv *env, jclass, jdouble);
JNIEXPORT jdouble JNICALL Java_java_lang_VMDouble_longBitsToDouble (JNIEnv *env, jclass, jlong);
JNIEXPORT jstring JNICALL Java_java_lang_VMDouble_toString (JNIEnv *env, jclass, jdouble, jboolean);
Index: m4/acinclude.m4
===
RCS file: /sources/classpath/classpath/m4/acinclude.m4,v
retrieving revision 1.27
diff -u -p -r1.27 acinclude.m4
--- m4/acinclude.m4 14 Jan 2008 14:36:34 - 1.27
+++ m4/acinclude.m4 8 Feb 2008 17:39:50 -
@@ -221,7 +221,7 @@ AC_DEFUN([CLASSPATH_CHECK_JAVAH],
AC_PATH_PROG(USER_JAVAH, $1)
fi
else
-AC_PATH_PROGS([USER_JAVAH],[gjavah gcjh-wrapper-4.1 gcjh-4.1 gcjh javah])
+AC_PATH_PROGS([USER_JAVAH],[gjavah gjavah-4.2 gjavah-4.1 gcjh-wrapper-4.1 gcjh-4.1 gcjh javah])
fi
if test x${USER_JAVAH} = x; then
Index: native/jni/java-lang/java_lang_VMDouble.c
===
RCS file: /sources/classpath/classpath/native/jni/java-lang/java_lang_VMDouble.c,v
retrieving revision 1.18
diff -u -p -r1.18 java_lang_VMDouble.c
--- native/jni/java-lang/java_lang_VMDouble.c 11 Jan 2008 22:14:31 - 1.18
+++ native/jni/java-lang/java_lang_VMDouble.c 8 Feb 2008 17:39:50 -
@@ -112,16 +112,15 @@ Java_java_lang_VMDouble_initIDs (JNIEnv
/*
* Class: java_lang_VMDouble
- * Method:doubleToLongBits
+ * Method:doubleToRawLongBits
* Signature: (D)J
*/
JNIEXPORT jlong JNICALL
-Java_java_lang_VMDouble_doubleToLongBits
+Java_java_lang_VMDouble_doubleToRawLongBits
(JNIEnv * env __attribute__ ((__unused__)),
jclass cls __attribute__ ((__unused__)), jdouble doubleValue)
{
jvalue val;
- jlong e, f;
val.d = doubleValue;
@@ -135,33 +134,6 @@ Java_java_lang_VMDouble_doubleToLongBits
val.j = SWAP_DOUBLE(val.j);
#endif
- e = val.j 0x7ff0LL;
- f = val.j 0x000fLL;
-
- if (e == 0x7ff0LL f != 0L)
-val.j = 0x7ff8LL;
-
- return val.j;
-}
-
-/*
- * Class: java_lang_VMDouble
- * Method:doubleToRawLongBits
- * Signature: (D)J
- */
-JNIEXPORT jlong JNICALL
-Java_java_lang_VMDouble_doubleToRawLongBits
- (JNIEnv * env __attribute__ ((__unused__)),
- jclass cls __attribute__ ((__unused__)), jdouble doubleValue)
-{
- jvalue val;
-
- val.d = doubleValue;
-
-#if defined(__IEEE_BYTES_LITTLE_ENDIAN)
- val.j = SWAP_DOUBLE(val.j);
-#endif
-
return val.j;
}
Index: vm/reference/java/lang/VMDouble.java
===
RCS file: /sources/classpath/classpath/vm/reference/java/lang/VMDouble.java,v
retrieving revision 1.3
diff -u -p -r1.3 VMDouble.java
--- vm/reference/java/lang/VMDouble.java 2 Jul 2005 20:33:08 - 1.3
+++ vm/reference/java
Re: Classpath's doubleToLongBits
Christian Thalinger schrieb: On Fri, 2008-02-08 at 00:26 +0100, Dalibor Topic wrote: I've looked a bit closer at the 3 ARM OABI errors, in particular at the errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fef we get 0x7fef. The current GNU Classpath implementation of Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, whenever __ARMEL__ is defined. That makes the DoubleConst test fail for Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of time trying to get it right on his ARM systems, I didn't want to mess with the corresponding file in fdlibm. So I wrote another implementation of the function, using ieee754.h (part of glibc). Basically, it boils down to shifting the bits from the bitfields to the right places inside the jlong. Easy. Unfortunately, that didn't work on arm OABI debian sid either. It turned out that glibc has a bug in the iee754.h header file, that comes to bite one on arm OABI. Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch attached. Meanwhile, that still means that those 3 tests fail until glibc is fixed. So ... I'll send in a couple of patches to the classpath patches list to first rewrite the doubleToLongBits in Java (and the same for Float), removing it from the VM interface, and then, I'll send in a patch to add the ieee754.h way of dealing with fetching the bits to the current way. Does that sound useful? That sounds actually very good, if it works on all configurations. I can remember we had a lot of problems to get these functions right on an Arm system with VFP. For more problems see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800 Yeah, that's why I'd like to go step by step, and first slash the VM interface methods I can slash, and then implement it with ieee754.h as an option, (adding a #define BIG_ENDIAN __BIG_ENDIAN for the broken glibc versions). I'll make sure to post the native patches for comments first, as I don't have access to a VFP box. cheers, dalibor topic
Re: Remove the generated headers from include dir?
Mario Torre wrote: Il giorno ven, 08/02/2008 alle 18.33 +0100, Dalibor Topic ha scritto: Does that sound like a useful build system change? cheers, dalibor topic Is something I also wanted to do, if no one object, I would go. Please go for it. cheers, dalibor topic
[commit-cp] classpath ChangeLog doc/cp-vmintegration.texinf...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/02/08 18:34:55 Modified files: . : ChangeLog doc: cp-vmintegration.texinfo include: java_lang_VMFloat.h native/jni/java-lang: java_lang_VMFloat.c vm/reference/java/lang: VMFloat.java Log message: 2008-02-08 Dalibor Topic [EMAIL PROTECTED] * vm/reference/java/lang/VMFloat.java (floatToIntBits): Removed unused method. * native/jni/java-lang/java_lang_VMFloat.c (Java_java_lang_VMFloat_floatToIntBits): Removed unused function. * include/java_lang_VMDouble.h: Regenerated. * doc/cp-vmintegration.texinfo (java.lang.VMFloat): Removed unused method floatToIntBits. (java.lang.VMDouble): Use similar text to text used for floatToRawIntBits for doubleToLongBits. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9485r2=1.9486 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/cp-vmintegration.texinfo?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/include/java_lang_VMFloat.h?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-lang/java_lang_VMFloat.c?cvsroot=classpathr1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMFloat.java?cvsroot=classpathr1=1.3r2=1.4
Remove the generated headers from include dir?
As I'm running into trouble getting gjavah / gcjh to overwrite the header files in the include dir (which seems to just work with Javah), I'd like to propose that Classpath adopts the JNI header generation model we use in Kaffe: simply always call (g/c/k)javah on the required files and drop the in the include dir in the build dir. There is little point in shipping the headers inside Classpath as now we have gjavah, gcjh, etc. in recent enough versions in the distributions. That would allow us to both simplify the build system a bit, and to remove 100+ generated header files from Classpath's CVS and tarball. Does that sound like a useful build system change? cheers, dalibor topic
[commit-cp] classpath ChangeLog NEWS
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/02/08 18:40:49 Modified files: . : ChangeLog NEWS Log message: 2008-02-08 Dalibor Topic [EMAIL PROTECTED] * NEWS: Documented removal of floatToIntBits and doubleToLongBits from VM interface. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9486r2=1.9487 http://cvs.savannah.gnu.org/viewcvs/classpath/NEWS?cvsroot=classpathr1=1.187r2=1.188
[commit-cp] classpath ChangeLog java/lang/Double.java
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/02/08 16:39:31 Modified files: . : ChangeLog java/lang : Double.java Log message: 2008-02-08 Dalibor Topic [EMAIL PROTECTED] * java/lang/Double.java (doubleToLongBits): Simplified. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9482r2=1.9483 http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Double.java?cvsroot=classpathr1=1.43r2=1.44
[cp-patches] RFC: Double.doubleToLongBits simplified
Hi all,
I've implemented doubleToLongBits without requring a VMDouble method of
the same name. It would let us remove one method from the VM interface
for the next version, and the corresoponding native code. OK to commit?
(I'd do the equivalent patch for Float, too).
* java/lang/Double.java (doubleToLongBits): Simplified.
cheers,
dalibor topic
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/lang/Double.java
===
RCS file: /sources/classpath/classpath/java/lang/Double.java,v
retrieving revision 1.43
diff -u -r1.43 Double.java
--- java/lang/Double.java 12 Oct 2007 08:50:50 - 1.43
+++ java/lang/Double.java 8 Feb 2008 00:18:01 -
@@ -518,7 +518,10 @@
*/
public static long doubleToLongBits(double value)
{
-return VMDouble.doubleToLongBits(value);
+if (isNaN(value))
+ return 0x7ff8L;
+else
+ return VMDouble.doubleToRawLongBits(value);
}
/**
Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)
Dalibor Topic wrote: Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. I've looked a bit closer at the 3 ARM OABI errors, in particular at the errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fef we get 0x7fef. The current GNU Classpath implementation of Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, whenever __ARMEL__ is defined. That makes the DoubleConst test fail for Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of time trying to get it right on his ARM systems, I didn't want to mess with the corresponding file in fdlibm. So I wrote another implementation of the function, using ieee754.h (part of glibc). Basically, it boils down to shifting the bits from the bitfields to the right places inside the jlong. Easy. Unfortunately, that didn't work on arm OABI debian sid either. It turned out that glibc has a bug in the iee754.h header file, that comes to bite one on arm OABI. Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch attached. Meanwhile, that still means that those 3 tests fail until glibc is fixed. So ... I'll send in a couple of patches to the classpath patches list to first rewrite the doubleToLongBits in Java (and the same for Float), removing it from the VM interface, and then, I'll send in a patch to add the ieee754.h way of dealing with fetching the bits to the current way. Does that sound useful? cheers, dalibor topic
[cp-patches] FYI: reversal of reversed
Hi all,
as discussed on IRC with tromey, I've applied the attached patch.
cheers,
dalibor topic
2008-01-25 Dalibor Topic [EMAIL PROTECTED]
* tools/gnu/classpath/tools/native2ascii/Native2ASCII.java
(createParser): Removed unused reversed misspelling. Use
Native2ASCII.ReverseHelp instead of Native2ASCII.ReversedHelp.
* resource/gnu/classpath/tools/native2ascii/messages.properties
(Native2ASCII.ReverseHelp): New, renamed from ...
(Native2ASCII.ReversedHelp): Removed.
(Native2ASCII.ReversedHelpCompat): Removed.
Index: resource/gnu/classpath/tools/native2ascii/messages.properties
===
RCS file: /sources/classpath/classpath/resource/gnu/classpath/tools/native2ascii/messages.properties,v
retrieving revision 1.2
diff -u -p -r1.2 messages.properties
--- resource/gnu/classpath/tools/native2ascii/messages.properties 24 Jan 2008 18:28:42 - 1.2
+++ resource/gnu/classpath/tools/native2ascii/messages.properties 25 Jan 2008 19:17:23 -
@@ -40,5 +40,5 @@ Native2ASCII.Usage=Usage: native2ascii [
Native2ASCII.EncodingHelp=encoding to use
Native2ASCII.EncodingArgName=NAME
Native2ASCII.EncodingSpecified=encoding already specified
-Native2ASCII.ReversedHelp=convert from encoding to native
-Native2ASCII.ReversedHelpCompat=alias for -reverse (deprecated)
+Native2ASCII.ReverseHelp=convert from encoding to native
+
Index: tools/gnu/classpath/tools/native2ascii/Native2ASCII.java
===
RCS file: /sources/classpath/classpath/tools/gnu/classpath/tools/native2ascii/Native2ASCII.java,v
retrieving revision 1.6
diff -u -p -r1.6 Native2ASCII.java
--- tools/gnu/classpath/tools/native2ascii/Native2ASCII.java 24 Jan 2008 18:28:42 - 1.6
+++ tools/gnu/classpath/tools/native2ascii/Native2ASCII.java 25 Jan 2008 19:17:23 -
@@ -101,17 +101,7 @@ public class Native2ASCII
encoding = argument;
}
});
-result.add(new Option(reverse, Messages.getString(Native2ASCII.ReversedHelp)) //$NON-NLS-1$ //$NON-NLS-2$
-{
- public void parsed(String argument) throws OptionException
- {
-reversed = true;
- }
-});
-
-// We mistakenly added the extra d in reversed; now we don't
-// want to remove it, for backward compatibility.
-result.add(new Option(reversed, Messages.getString(Native2ASCII.ReversedHelpCompat)) //$NON-NLS-1$ //$NON-NLS-2$
+result.add(new Option(reverse, Messages.getString(Native2ASCII.ReverseHelp)) //$NON-NLS-1$ //$NON-NLS-2$
{
public void parsed(String argument) throws OptionException
{
[commit-cp] classpath ChangeLog resource/gnu/classpath/tool...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/01/25 19:21:07 Modified files: . : ChangeLog resource/gnu/classpath/tools/native2ascii: messages.properties tools/gnu/classpath/tools/native2ascii: Native2ASCII.java Log message: reversal of reversed 2008-01-25 Dalibor Topic [EMAIL PROTECTED] * tools/gnu/classpath/tools/native2ascii/Native2ASCII.java (createParser): Removed unused reversed misspelling. Use Native2ASCII.ReverseHelp instead of Native2ASCII.ReversedHelp. * resource/gnu/classpath/tools/native2ascii/messages.properties (Native2ASCII.ReverseHelp): New, renamed from ... (Native2ASCII.ReversedHelp): Removed. (Native2ASCII.ReversedHelpCompat): Removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9476r2=1.9477 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/gnu/classpath/tools/native2ascii/messages.properties?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/native2ascii/Native2ASCII.java?cvsroot=classpathr1=1.6r2=1.7
Re: [cp-patches] RFC: adding -reverse to gnative2ascii
Mario Torre wrote: This patch adds the -reverse option to gnative2ascii as described here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=103 The user can pass either option, if both are present one is simply ignored, I first added an exception, but I guess it's better to just ignore the redundant option rather that stop the application. I'd suggest removing the redundant option. The official docs at http://java.sun.com/javase/6/docs/technotes/tools/solaris/native2ascii.html don't have a -reversed, just a -reverse, so I assume it was a typo anyway. cheers, dalibor topic
Re: [cp-patches] Patch: FYI: -reverse argument for native2ascii
Tom Tromey wrote: I'm checking this in to Classpath and libgcj. Sun's native2ascii accepts -reverse, while we accept -reversed. This changes Classpath to conform. This bug came from the IcedTea build: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=103 Tom ChangeLog: 2008-01-24 Tom Tromey [EMAIL PROTECTED] * resource/gnu/classpath/tools/native2ascii/messages.properties (Native2ASCII.ReversedHelpCompat): New. * tools/gnu/classpath/tools/native2ascii/Native2ASCII.java (createParser): Add -reverse. Update -reversed. Please remove it instead, as no one is using it according to google or Koders. 0 hits for gnative2ascii reversed on Google, and Ant does not support reversion with the Kaffe/Classpath native2ascii. cheers, dalibor topic
Re: [cp-patches] RFC: adding -reverse to gnative2ascii
Mario Torre wrote: Il giorno gio, 24/01/2008 alle 19.30 +0100, Dalibor Topic ha scritto: I'd suggest removing the redundant option. The official docs at http://java.sun.com/javase/6/docs/technotes/tools/solaris/native2ascii.html don't have a -reversed, just a -reverse, so I assume it was a typo anyway. cheers, dalibor topic Agree, but not needed anymore :) Anyway, I was thinking that someone could use that option in scripts, that's why I left it in place. According to Google and Koders, no one is. There is no point in crufting up Classpath when there are no documented users, in my opinion. cheers, dalibor topic
Re: Free Java Meeting @ FOSDEM 2008 - Confirmed
Audrius Meskauskas wrote: I will come, also. What about the beer? Or we should now be sad? Awesome, make sure to add yourself to the wiki ... I am sure the beer will be great as every year ;) cheers, dalibor topic
[cp-patches] FYI: patch for avr32 support
Hi all, I've committed the patch for avr32 support from our bug tracker from Leen Toelen, Bug 34518. 2008-01-13 2007-12-18 Leen Toelen [EMAIL PROTECTED] * native/fdlibm/ieeefp.h: Added avr32 support. cheers, dalibor topic This simple patch against 0.96.1 adds support for the atmel avr32 processor. diff -rup ../classpath-0.96.1.default/native/fdlibm/ieeefp.h ./native/fdlibm/ieeefp.h --- ../classpath-0.96.1.default/native/fdlibm/ieeefp.h 2006-04-19 19:55:13.0 +0200 +++ ./native/fdlibm/ieeefp.h2007-12-18 09:32:55.0 +0100 @@ -87,6 +87,10 @@ #define __IEEE_LITTLE_ENDIAN #endif +#ifdef __AVR32__ +#define __IEEE_BIG_ENDIAN +#endif + #ifdef __MIPSEL__ #define __IEEE_LITTLE_ENDIAN #endif Regards, Leen
[commit-cp] classpath ChangeLog native/fdlibm/ieeefp.h
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 08/01/13 17:33:50 Modified files: . : ChangeLog native/fdlibm : ieeefp.h Log message: patch for avr32 support 2008-01-13 2007-12-18 Leen Toelen [EMAIL PROTECTED] * native/fdlibm/ieeefp.h: Added avr32 support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9469r2=1.9470 http://cvs.savannah.gnu.org/viewcvs/classpath/native/fdlibm/ieeefp.h?cvsroot=classpathr1=1.8r2=1.9
Re: [cp-patches] Cleanup: reduce temporary object creation
Stefan Huehner schrieb: Patch minimizes the number of temporary objects which are created and disposed of at the same time 2008-01-09 Stefan Huehner stefan at huehner.org * gnu/classpath/jdwp/event/ExceptionEvent.java, * gnu/java/awt/peer/gtk/GtkMainThread.java: use Boolean.TRUE|FALSE instead of new Boolean(true|false) * gnu/java/rmi/server/ConnectionRunnerPool.java, * gnu/xml/aelfred2/XmlParser.java, * gnu/xml/libxmlj/dom/GnomeXPathResult.java, * gnu/xml/stream/XIncludeFilter.java: use Integer|Double|Charater.toString(var) instead of new Integer|Double|Character(var).toString() Thank you, Stefan, your patch looks fine to me. cheers, dalibor topic
Re: [cp-patches] Cleanup: const correctnes in native code
Stefan Huehner schrieb: Remove some casts which discard the const from strings when not needed. Found by compiling with -Wwrite-strings and -Wcast-qual 2008-01-09 Stefan Huehner stefan at huehner.org native/jni/java-io/java_io_VMObjectStreamClass.c, native/jni/java-lang/java_lang_VMDouble.c, native/jni/java-net/java_net_VMInetAddress.c: don't discard const by casting (const char *) to (char *) when it's not needed. looks fine to me, too. cheers, dalibor topic
Re: Quality control and FOSS rant
Mark Wielaard wrote: You are more than welcome to actually join any of the free software projects (GNU Classpath, OpenJDK, IcedTea, BrandWeg, GCJ, Kaffe, etc) and really participate in the community and shape its directions. What has the Kaffe project done to deserve such draconian punishment? Throwing more people on a late project won't fix it ... :) cheers, dalibor topic
Re: Quality control and FOSS rant
Andy Tripp wrote: Also, as FOSS developers start to contribute to OpenJDK, I'm already seeing suggestions for changes where the rationale seems to be because that's how FOSS projects do things, with of course the underlying assumption that that makes it a reasonable approach. That's how discussions with incomplete information work, people make assumptions, then discuss them, and come to conclusions based on the new information they receive during the discussion. At the end of the day, cool code beats heated discussions, so people who care about their ideas deeply, will simply go out and implement them. Discussing actual code beats discussing ideas, since the properties of the code can be measured, while properties of ideas are necessarily speculative. Properties of administrative processes can be measured by the quality of the output, and the output from Sun's processes is able to run more applications than the output of other processes (Classpath, Harmony, etc.), so Sun's process seems to work just fine for producing this kind of software. Naturally, opening up the code base leads to opportunities to reevaluate such processes in light of the further goals of the project, and to optimize them accordingly. Sun ended up switching its OpenJDK development team away from (non-free) TeamWare to (FOSS) Mercurial, for example, and that's been, for all I've heard from Sun's engineers at conferences and on IRC, a reasonable and quite useful thing to do, beside being the way things are done in FOSS projects (use the best FOSS tools to get the job done). Similarly, Sun now has the opportunity to reevaluate the code review tools and the bug tracker used for (Open)JDK, and to improve their processes further to allow collaboration to happen at more interaction points more easily, than is currently viable. Unfortunately, such infrastructural progress, as necessary as it is as OpenJDK evolves to tear down the 'fourth wall' [1], is nothing the FOSS community outside Sun can really help much with, other than contributing to the discussion of different alternatives, as only Sun's engineers can really know how their processes need to work to fit well with what they are doing at their day jobs, beside OpenJDK (the non-open JDK product, for example). cheers, dalibor topic [1] http://en.wikipedia.org/wiki/Fourth_wall
Re: Happy New Year
Robert Lougher wrote: Hi, Wishing everybody a Happy New Year. Hopefully this will be the year where people will realise that a community developed Java is better than an open-sourced, but closed process, Java :) Happy new year, too! Hacking the closed process will be a fun thing to do this year. cheers, dalibor topic
[cp-patches] FYI: build fixes for arm-wince
Hi all,
I've patched Classpath up so that it can be compiled with the arm-wince
cegcc toolchain.
cheers,
dalibor topic
2007-12-28 Dalibor Topic [EMAIL PROTECTED]
* configure.ac (AC_CHECK_HEADERS): Check for
netinet/in_systm.h, netinet/ip.h and net/if.h
for Windows CE.
* native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c:
Guard net/if.h include statement. Use unsigned int
instead of u_int.
* native/jni/java-nio/gnu_java_nio_VMChannel.c:
Guard sys/mman.h include statement.
* native/jni/java-nio/gnu_java_nio_VMSelector.c:
Guard sys/select.h include statement.
* native/jni/java-nio/javanio.c:
Guard sys/select.h include statement.
* native/jni/java-nio/javanio.h:
Include sys/time.h.
* native/jni/native-lib/cpio.c:
Guard chmod call by S_IWRITE, since it's not
defined in the arm-wince toolchain.
* native/jni/native-lib/cpnet.h:
Guard netinet/in_systm.h and netinet/ip.h
include statements.
? doc/cp-install.texinfo
Index: configure.ac
===
RCS file: /sources/classpath/classpath/configure.ac,v
retrieving revision 1.219
diff -u -r1.219 configure.ac
--- configure.ac 6 Nov 2007 13:38:40 - 1.219
+++ configure.ac 15 Nov 2007 11:02:48 -
@@ -368,6 +368,7 @@
dnl On that system, sys/ioctl.h will not include sys/filio.h unless
dnl BSD_COMP is defined; just including sys/filio.h is simpler.
dnl Check for crt_externs.h on Darwin.
+ dnl Check for netinet/in_systm.h, netinet/ip.h and net/if.h for Windows CE.
AC_CHECK_HEADERS([unistd.h sys/types.h sys/config.h sys/ioctl.h \
asm/ioctls.h \
inttypes.h stdint.h utime.h sys/utime.h sys/filio.h \
@@ -378,7 +379,8 @@
sys/mman.h \
magic.h \
sys/event.h sys/epoll.h \
- ifaddrs.h])
+ ifaddrs.h \
+ netinet/in_systm.h netinet/ip.h net/if.h])
AC_EGREP_HEADER(uint32_t, stdint.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to 1 if you have uint32_t]))
AC_EGREP_HEADER(uint32_t, inttypes.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to 1 if you have uint32_t]))
Index: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c
===
RCS file: /sources/classpath/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c,v
retrieving revision 1.15
diff -u -r1.15 gnu_java_net_VMPlainSocketImpl.c
--- native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c 25 Jun 2007 00:05:33 - 1.15
+++ native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c 15 Nov 2007 11:02:53 -
@@ -51,7 +51,9 @@
#endif
#include netinet/in.h
#include netinet/tcp.h
+#ifdef HAVE_NET_IF_H
#include net/if.h
+#endif
#include errno.h
#include stdlib.h
#include stdio.h
@@ -416,7 +418,7 @@
#ifdef HAVE_INET6
int result;
const char *str_ifname = JCL_jstring_to_cstring (env, ifname);
- u_int if_index;
+ unsigned int if_index;
if ((*env)-ExceptionOccurred (env))
{
@@ -433,7 +435,7 @@
}
result = setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_IF,
- (u_int *) if_index, sizeof(if_index));
+ (unsigned int *) if_index, sizeof(if_index));
JCL_free_cstring(env, ifname, str_ifname);
Index: native/jni/java-nio/gnu_java_nio_VMChannel.c
===
RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v
retrieving revision 1.21
diff -u -r1.21 gnu_java_nio_VMChannel.c
--- native/jni/java-nio/gnu_java_nio_VMChannel.c 24 Jun 2007 23:45:40 - 1.21
+++ native/jni/java-nio/gnu_java_nio_VMChannel.c 15 Nov 2007 11:02:53 -
@@ -43,7 +43,9 @@
#include config-int.h
#include sys/types.h
+#ifdef HAVE_SYS_MMAN_H
#include sys/mman.h
+#endif
#include sys/socket.h
#include sys/stat.h
#include sys/uio.h
Index: native/jni/java-nio/gnu_java_nio_VMSelector.c
===
RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMSelector.c,v
retrieving revision 1.12
diff -u -r1.12 gnu_java_nio_VMSelector.c
--- native/jni/java-nio/gnu_java_nio_VMSelector.c 26 Nov 2006 20:51:57 - 1.12
+++ native/jni/java-nio/gnu_java_nio_VMSelector.c 15 Nov 2007 11:02:53 -
@@ -41,8 +41,9 @@
#if defined(HAVE_SYS_TYPES_H)
#include sys/types.h
#endif
-
+#if defined(HAVE_SYS_SELECT_H)
#include sys/select.h
+#endif
#include sys/time.h
#include string.h
Index: native/jni/java-nio/javanio.c
===
RCS file: /sources/classpath/classpath/native/jni/java-nio/javanio.c,v
retrieving revision 1.5
diff -u -r1.5 javanio.c
--- native/jni/java-nio/javanio.c 11 Apr 2007 21:37:35 - 1.5
+++ native/jni/java-nio/javanio.c 15 Nov 2007 11:02:53 -
@@ -45,7 +45,9 @@
#include unistd.h
#include sys/types.h
#include sys/socket.h
+#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
+#endif
#include sys
[cp-patches] FYI:build fix for Cygwin
Hi all,
the attached patch adds a few more tools to FASTJAR detection code, and
fixes a build problem when using Sun's JDK 1.6 jar on Windows/Cygwin due
to the ' ' in C:\Program Files\one-thing-or-another path.
cheers,
dalibor topic
2007-12-28 Dalibor Topic [EMAIL PROTECTED]
* m4/acinclude.m4 (CLASSPATH_WITH_GLIBJ): Use
AC_PATH_PROGS instead of AC_PATH_PROG to check
for FASTJAR as fastjar, gjar or jar. Add braces
to AC_PATH_PROGS arguments.
* tools/Makefile.am (TOOLS_ZIP),
lib/Makefile.am (collections.jar, glibj.zip):
Quote FASTJAR in case it's in a path with
whitespace.
Index: lib/Makefile.am
===
RCS file: /sources/classpath/classpath/lib/Makefile.am,v
retrieving revision 1.139
diff -u -r1.139 Makefile.am
--- lib/Makefile.am 4 Nov 2007 01:56:17 - 1.139
+++ lib/Makefile.am 26 Dec 2007 18:51:21 -
@@ -45,7 +45,7 @@
$(JCOMPILER) `$(FIND) $(COLLECTIONS_PREFIX) -name '*.java' -type f -print`
#endif
if test $(FASTJAR) != ; then \
- $(FASTJAR) cf $@ $(COLLECTIONS_PREFIX); \
+ $(FASTJAR) cf $@ $(COLLECTIONS_PREFIX); \
else \
echo fastjar not found collections.jar; \
fi
@@ -94,7 +94,7 @@
glibj.zip: classes compile-classes resources
if test $(ZIP) != ; then $(ZIP) -r -D glibj.zip gnu java javax org sun META-INF /dev/null; fi
- if test $(FASTJAR) != ; then $(FASTJAR) cf glibj.zip gnu java javax org sun META-INF; fi
+ if test $(FASTJAR) != ; then $(FASTJAR) cf glibj.zip gnu java javax org sun META-INF; fi
endif # USE_PREBUILT_GLIBJ_ZIP
Index: m4/acinclude.m4
===
RCS file: /sources/classpath/classpath/m4/acinclude.m4,v
retrieving revision 1.23
diff -u -r1.23 acinclude.m4
--- m4/acinclude.m4 16 Oct 2007 14:06:23 - 1.23
+++ m4/acinclude.m4 26 Dec 2007 18:51:21 -
@@ -275,7 +275,7 @@
FASTJAR=${withval}
AC_MSG_RESULT([${FASTJAR}])
],
- [AC_PATH_PROG(FASTJAR, fastjar)])
+ [AC_PATH_PROGS([FASTJAR], [fastjar gjar jar])])
dnl We disable ZIP by default if we find fastjar.
if test x${FASTJAR} != x; then
ZIP=
Index: tools/Makefile.am
===
RCS file: /sources/classpath/classpath/tools/Makefile.am,v
retrieving revision 1.41
diff -u -r1.41 Makefile.am
--- tools/Makefile.am 12 Sep 2007 09:40:29 - 1.41
+++ tools/Makefile.am 26 Dec 2007 18:51:21 -
@@ -181,12 +181,12 @@
## First add classpath tools stuff.
(cd classes; \
if test $(ZIP) != ; then $(ZIP) -r ../$(TOOLS_ZIP) .; fi; \
- if test $(FASTJAR) != ; then $(FASTJAR) cf ../$(TOOLS_ZIP) .; fi; \
+ if test $(FASTJAR) != ; then $(FASTJAR) cf ../$(TOOLS_ZIP) .; fi; \
cd ..)
## Now add ASM classes.
(cd asm; \
if test $(ZIP) != ; then $(ZIP) -u -r ../$(TOOLS_ZIP) .; fi; \
- if test $(FASTJAR) != ; then $(FASTJAR) uf ../$(TOOLS_ZIP) .; fi; \
+ if test $(FASTJAR) != ; then $(FASTJAR) uf ../$(TOOLS_ZIP) .; fi; \
cd ..)
rm -rf classes
[commit-cp] classpath configure.ac native/jni/java-net/gnu_...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/12/28 17:49:56 Modified files: . : configure.ac native/jni/java-net: gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio: gnu_java_nio_VMChannel.c gnu_java_nio_VMSelector.c javanio.c javanio.h native/jni/native-lib: cpio.c cpnet.h Log message: build fixes for arm-wince 2007-12-28 Dalibor Topic [EMAIL PROTECTED] * configure.ac (AC_CHECK_HEADERS): Check for netinet/in_systm.h, netinet/ip.h and net/if.h for Windows CE. * native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c: Guard net/if.h include statement. Use unsigned int instead of u_int. * native/jni/java-nio/gnu_java_nio_VMChannel.c: Guard sys/mman.h include statement. * native/jni/java-nio/gnu_java_nio_VMSelector.c: Guard sys/select.h include statement. * native/jni/java-nio/javanio.c: Guard sys/select.h include statement. * native/jni/java-nio/javanio.h: Include sys/time.h. * native/jni/native-lib/cpio.c: Guard chmod call by S_IWRITE, since it's not defined in the arm-wince toolchain. * native/jni/native-lib/cpnet.h: Guard netinet/in_systm.h and netinet/ip.h include statements. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/configure.ac?cvsroot=classpathr1=1.219r2=1.220 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c?cvsroot=classpathr1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c?cvsroot=classpathr1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_VMSelector.c?cvsroot=classpathr1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/javanio.c?cvsroot=classpathr1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/javanio.h?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpio.c?cvsroot=classpathr1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpnet.h?cvsroot=classpathr1=1.5r2=1.6
[commit-cp] classpath ChangeLog
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/12/28 17:54:57 Modified files: . : ChangeLog Log message: added missing changelog entry CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9454r2=1.9455
[commit-cp] classpath ChangeLog lib/Makefile.am m4/acinclud...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/12/28 17:35:35 Modified files: . : ChangeLog lib: Makefile.am m4 : acinclude.m4 tools : Makefile.am Log message: build fix for cygwin 2007-12-28 Dalibor Topic [EMAIL PROTECTED] * m4/acinclude.m4 (CLASSPATH_WITH_GLIBJ): Use AC_PATH_PROGS instead of AC_PATH_PROG to check for FASTJAR as fastjar, gjar or jar. Add braces to AC_PATH_PROGS arguments. * tools/Makefile.am (TOOLS_ZIP), lib/Makefile.am (collections.jar, glibj.zip): Quote FASTJAR in case it's in a path with whitespace. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9453r2=1.9454 http://cvs.savannah.gnu.org/viewcvs/classpath/lib/Makefile.am?cvsroot=classpathr1=1.139r2=1.140 http://cvs.savannah.gnu.org/viewcvs/classpath/m4/acinclude.m4?cvsroot=classpathr1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/Makefile.am?cvsroot=classpathr1=1.41r2=1.42
Re: [kaffe] Free Java Meeting @ FOSDEM 2008 - Confirmed
Mark Wielaard wrote: Hi All, We got confirmation of the Fosdem organizers and they granted us a developer room during Fosdem 2008! http://fosdem.org/2008/ Saturday and Sunday 23-24 February in Brussels, Belgium. Note that to add your name or ideas for the program to http://wiki.debian.org/Java/DevJam/2008/ you will need to register on the Debian wiki as a user first http://wiki.debian.org/UserPreferences before you are allowed to edit the page. Thanks, Mark, I'll be there! cheers, dalibor topic
Re: GNU Classpath 0.96 Staying Alive released
Andrew John Hughes wrote: We are proud to announce the release of GNU Classpath 0.96 Staying Alive Coming a little late, but nevertheless: Thanks to Andrew and team for the release! cheers, dalibor topic
[cp-patches] FYI: build fix for arm linux cross compilation using gcc 3.3.2
Hi all, the attached patch adds a missing include statement. cheers, dalibor topic 2007-10-22 Dalibor Topic [EMAIL PROTECTED] * native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c: Include config-int.h for uint32_t. ? classpath-fdlibm-warning-and-build-fix.diff Index: native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c === RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c,v retrieving revision 1.3 diff -u -r1.3 gnu_java_nio_EpollSelectorImpl.c --- native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c 23 Sep 2006 06:44:14 - 1.3 +++ native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c 22 Oct 2007 17:41:28 - @@ -44,6 +44,8 @@ #include sys/epoll.h #endif /* HAVE_SYS_EPOLL_H */ +#include config-int.h + #include gnu_java_nio_EpollSelectorImpl.h #include jcl.h #include errno.h
[commit-cp] classpath ChangeLog native/jni/java-nio/gnu_jav...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/10/22 17:43:51 Modified files: . : ChangeLog native/jni/java-nio: gnu_java_nio_EpollSelectorImpl.c Log message: 2007-10-22 Dalibor Topic [EMAIL PROTECTED] * native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c: Include config-int.h for uint32_t. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9426r2=1.9427 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c?cvsroot=classpathr1=1.3r2=1.4
Re: Need help to understand Classpath's license
Laurent Debacker wrote: Hello, Salut Laurent, By reading the GPL exception at http://www.gnu.org/software/classpath/license.html, I came across the following term: As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules. Does it mean that classpath can be linked against other libraries which do not call classpath, Yes. or that programs can be linked against the classpath (given that the apllication is a module which is not derived from or based on this library). In the later case, the application is certainly Yes. based on the API, but not on the implementation indeed. My concern is the following one: given a non-GPL application compiled against a static API whose implementation is not provided during the compilation process, and an implementation of the library released under the classical GPL. Irrelevant for Classpath, as it is not released under 'classical GPL'. Indeed, given a compiled java application, can I run it given a GPL class library? Yes. See Freedom 0. [skipped a bunch of questions about trolltech and bash] Any suggestion is welcome :) Well, this should have been as good as any. ;) If you want to have answers to further questions, you may want to consult FSF's licensing and compliance lab. They can help you figure out how the GNU Classpath license works in your specific usage scenario, much faster than constructing hypothetical examples on this mailing list can. Please consult http://www.fsf.org/licensing for details on how to request their services. cheers, dalibor topic
[cp-patches] FYI: build warning fix for cygwin
Hi all, the attached patch fixes many warnings on cygwin, and makes classpath build there again. cheers, dalibor topic 2007-09-27 Dalibor Topic [EMAIL PROTECTED] * native/fdlibm/dtoa.c: Include mprec.h after system includes. * native/fdlibm/mprec.h [_EXFUN]: Only define _EXFUN if it is not already defined. Index: native/fdlibm/dtoa.c === RCS file: /sources/classpath/classpath/native/fdlibm/dtoa.c,v retrieving revision 1.6 diff -u -r1.6 dtoa.c --- native/fdlibm/dtoa.c 19 Sep 2007 13:31:18 - 1.6 +++ native/fdlibm/dtoa.c 26 Sep 2007 20:23:59 - @@ -26,9 +26,9 @@ [EMAIL PROTECTED] or research!dmg */ -#include mprec.h #include string.h #include stdlib.h +#include mprec.h static int _DEFUN (quorem, Index: native/fdlibm/mprec.h === RCS file: /sources/classpath/classpath/native/fdlibm/mprec.h,v retrieving revision 1.10 diff -u -r1.10 mprec.h --- native/fdlibm/mprec.h 14 Sep 2006 10:10:28 - 1.10 +++ native/fdlibm/mprec.h 26 Sep 2007 20:23:59 - @@ -294,7 +294,9 @@ #define _SIGNED signed #define _DOTS , ... #define _VOID void +#ifndef _EXFUN #define _EXFUN(name, proto) name proto +#endif /* !EXFUN */ #define _DEFUN(name, arglist, args) name(args) #define _DEFUN_VOID(name) name(_NOARGS) #define _CAST_VOID (void)
[commit-cp] classpath ChangeLog native/fdlibm/dtoa.c native...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/27 12:33:39 Modified files: . : ChangeLog native/fdlibm : dtoa.c mprec.h Log message: 2007-09-27 Dalibor Topic [EMAIL PROTECTED] * native/fdlibm/dtoa.c: Include mprec.h after system includes. * native/fdlibm/mprec.h [_EXFUN]: Only define _EXFUN if it is not already defined. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9396r2=1.9397 http://cvs.savannah.gnu.org/viewcvs/classpath/native/fdlibm/dtoa.c?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/native/fdlibm/mprec.h?cvsroot=classpathr1=1.10r2=1.11
Re: [cp-patches] FYI: removed unused private constructors
Andrew John Hughes wrote: On Friday 21 September 2007 23:15:45 Dalibor Topic wrote: Hi all, the attached patch removes a bunch of unused private constructors. cheers, dalibor topic 2007-09-21 Dalibor Topic [EMAIL PROTECTED] * gnu/java/rmi/server/RMIClassLoaderImpl.java, java/beans/beancontext/BeanContextServicesSupport.java, java/lang/management/ThreadInfo.java: Removed unused private constructors. Hi Dalibor, Those ThreadInfo constructors aren't used in Classpath, but they are there for VMs to use to create instances of ThreadInfo without creating and then deconstructing a CompositeInfo object. Can you please put them back? I won't get around to do it until tonight, so feel free to revert my bad change, and add some documentation to the constructors to indicate why they are there, and who's using them. cheers, dalibor topic
[cp-patches] FYI: reverted patch to threadinfo from 21st
Hi all,
as requested I've reverted the patch to threadinfo.
Andrew, could you add some documentation about the role of the class to
the VM interface document, and add some documentation in the
documentation blocks of the constructors?
cheers,
dalibor topic
2007-09-24 Dalibor Topic [EMAIL PROTECTED]
* java/lang/management/ThreadInfo.java: Reverted patch from
2007-09-21, as it breaks JikesRVM.
Index: java/lang/management/ThreadInfo.java
===
RCS file: /sources/classpath/classpath/java/lang/management/ThreadInfo.java,v
retrieving revision 1.10
retrieving revision 1.9
diff -u -r1.10 -r1.9
--- java/lang/management/ThreadInfo.java 21 Sep 2007 19:39:19 - 1.10
+++ java/lang/management/ThreadInfo.java 25 Dec 2006 23:58:52 - 1.9
@@ -192,6 +192,134 @@
/**
* Constructs a new [EMAIL PROTECTED] ThreadInfo} corresponding
+ * to the thread specified.
+ *
+ * @param thread the thread on which the new instance
+ * will be based.
+ * @param blockedCount the number of times the thread
+ * has been blocked.
+ * @param blockedTime the accumulated number of milliseconds
+ *the specified thread has been blocked
+ *(only used with contention monitoring enabled)
+ * @param lock the monitor lock the thread is waiting for
+ * (only used if blocked)
+ * @param lockOwner the thread which owns the monitor lock, or
+ * codenull/code if it doesn't have an owner
+ * (only used if blocked)
+ * @param waitedCount the number of times the thread has been in a
+ *waiting state.
+ * @param waitedTime the accumulated number of milliseconds the
+ * specified thread has been waiting
+ * (only used with contention monitoring enabled)
+ * @param isInNative true if the thread is in a native method.
+ * @param isSuspended true if the thread is suspended.
+ * @param trace the stack trace of the thread to a pre-determined
+ * depth (see VMThreadMXBeanImpl)
+ */
+ private ThreadInfo(Thread thread, long blockedCount, long blockedTime,
+ Object lock, Thread lockOwner, long waitedCount,
+ long waitedTime, boolean isInNative, boolean isSuspended,
+ StackTraceElement[] trace)
+ {
+this(thread, blockedCount, blockedTime, lock, lockOwner, waitedCount,
+ waitedTime, isInNative, isSuspended, trace, new MonitorInfo[]{},
+ new LockInfo[]{});
+ }
+
+ /**
+ * Constructs a new [EMAIL PROTECTED] ThreadInfo} corresponding
+ * to the thread specified.
+ *
+ * @param thread the thread on which the new instance
+ * will be based.
+ * @param blockedCount the number of times the thread
+ * has been blocked.
+ * @param blockedTime the accumulated number of milliseconds
+ *the specified thread has been blocked
+ *(only used with contention monitoring enabled)
+ * @param lock the monitor lock the thread is waiting for
+ * (only used if blocked)
+ * @param lockOwner the thread which owns the monitor lock, or
+ * codenull/code if it doesn't have an owner
+ * (only used if blocked)
+ * @param waitedCount the number of times the thread has been in a
+ *waiting state.
+ * @param waitedTime the accumulated number of milliseconds the
+ * specified thread has been waiting
+ * (only used with contention monitoring enabled)
+ * @param isInNative true if the thread is in a native method.
+ * @param isSuspended true if the thread is suspended.
+ * @param trace the stack trace of the thread to a pre-determined
+ * depth (see VMThreadMXBeanImpl)
+ * @param lockedMonitors an array of [EMAIL PROTECTED] MonitorInfo} objects
+ * representing locks held on object monitors
+ * by the thread.
+ * @param lockedSynchronizers an array of [EMAIL PROTECTED] LockInfo} objects
+ *representing locks held on ownable
+ *synchronizers by the thread.
+ * @since 1.6
+ */
+ private ThreadInfo(Thread thread, long blockedCount, long blockedTime,
+ Object lock, Thread lockOwner, long waitedCount,
+ long waitedTime, boolean isInNative, boolean isSuspended,
+ StackTraceElement[] trace, MonitorInfo[] lockedMonitors,
+ LockInfo[] lockedSynchronizers)
+ {
+this(thread.getId(), thread.getName(), thread.getState(), blockedCount, blockedTime,
+ lock == null ? null : lock.getClass().getName() + @ +
+ Integer.toHexString(System.identityHashCode(lock)),
+ lockOwner == null ? -1 : lockOwner.getId(),
+ lockOwner == null ? null : lockOwner.getName
Re: Classpath 0.96
Andrew John Hughes wrote: On Wednesday 19 September 2007 13:07:01 Dalibor Topic wrote: Dâniel Fraga wrote: On Tue, 18 Sep 2007 15:27:15 +0100 I mean, I know I can use gcjwebplugin, but it doesn't work for all cases, all applets etc. Now that Java was GPLed, how much time will it take so classpath will merge code from Sun so we can have a gcjwebplugin that works in all cases? Currently, there is no one actively working on merging code from OpenJDK into GNU Classpath, so it will take an infinite amount of time. :) Alternatively, check out IcedTea. Mainly because I don't think all the legalities of doing such a thing have been sorted out. In particular, Sun's code is GPLv2 only and the FSF would like to move to GPLv3 at some point. The classpath exception on Sun's code would make that less of a problem for code in OpenJDK that would make sense to merge into Classpath. i.e. the class library code, as that code is licensed for the most part under GPLv2+classpath exception, so mixing and matching that code with GPLv2+classpath exception or GPLv3+classpath exception should be, per the exception, OK. If someone desperately wanted (i.e. volunteered) to make it happen, I guess we could bug the FSF mjw about a branch to do the work, or move that work to some other place, like icedtea, and resync from there (icepath ftw!). It's not really a pressing issue any more, in my opinion, as cacao ikvm have started to switch over to openjdk/icedtea libraries, and I'd expect other VMs to follow, as their resources permit. It'd be easier if an icedtea/classpath integration branch existed, but it seems possible to pull off that big merge without it, judging by Jeroen's and Christian's work. Meanwhile, there is a bug tracker full of regular maintenance work for those of us that can't just switch their VMs to icedtea's class libraries just yet, so I expect that we'll see more than a handful of releases of classpath until the big merge/switch happens. cheers, dalibor topic
[commit-cp] classpath ChangeLog java/lang/management/Thread...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/24 18:15:25 Modified files: . : ChangeLog java/lang/management: ThreadInfo.java Log message: 2007-09-24 Dalibor Topic [EMAIL PROTECTED] * java/lang/management/ThreadInfo.java: Reverted patch from 2007-09-21, as it breaks JikesRVM. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9395r2=1.9396 http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/management/ThreadInfo.java?cvsroot=classpathr1=1.10r2=1.11
[cp-patches] FYI: added link to wiki to home page
Hi all, I've applied the patch from Paul Jenner to add the link to the wiki to the homepage WML file. Could whoever takes care of that make it appear on the classpath.org site? Patch: http://developer.classpath.org/pipermail/classpath/2007-April/002016.html ChangeLog: 2007-09-22 Paul Jenner [EMAIL PROTECTED] * doc/www.gnu.org/include/layout.wml: Added link to Wiki. cheers, dalibor topic
[commit-cp] classpath ChangeLog doc/www.gnu.org/include/lay...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/22 15:50:20 Modified files: . : ChangeLog doc/www.gnu.org/include: layout.wml Log message: 2007-09-22 Paul Jenner [EMAIL PROTECTED] * doc/www.gnu.org/include/layout.wml: Added link to Wiki. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9393r2=1.9394 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/www.gnu.org/include/layout.wml?cvsroot=classpathr1=1.10r2=1.11
[cp-patches] FYI: removed unused labels
Hi all,
the attached patch removes unused labels.
cheers,
dalibor topic
2007-09-21 Dalibor Topic [EMAIL PROTECTED]
* gnu/CORBA/CDR/AbstractCdrInput.java,
gnu/CORBA/CDR/Vio.java,
gnu/CORBA/DynAn/gnuDynUnion.java,
gnu/CORBA/GIOP/MessageHeader.java,
gnu/CORBA/IorDelegate.java,
gnu/java/security/key/dss/FIPS186.java,
gnu/javax/crypto/key/dh/RFC2631.java,
gnu/javax/swing/text/html/parser/support/Parser.java,
gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java,
gnu/xml/aelfred2/XmlParser.java,
java/awt/im/InputContext.java:
Removed unused labels.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/javax/crypto/key/dh/RFC2631.java
===
RCS file: /sources/classpath/classpath/gnu/javax/crypto/key/dh/RFC2631.java,v
retrieving revision 1.4
diff -u -r1.4 RFC2631.java
--- gnu/javax/crypto/key/dh/RFC2631.java1 Jul 2006 10:00:26 -
1.4
+++ gnu/javax/crypto/key/dh/RFC2631.java20 Sep 2007 18:31:24 -
@@ -136,7 +136,7 @@
}
// 8. Let counter = 0
counter = 0;
-step9: while (true)
+while (true)
{
// 9. Set R = seed + 2*m' + (L' * counter)
R = SEED
Index: gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java
===
RCS file:
/sources/classpath/classpath/gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java,v
retrieving revision 1.2
diff -u -r1.2 ReaderTokenizer.java
--- gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java 2 Jul
2005 20:32:15 - 1.2
+++ gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java 20 Sep
2007 18:31:26 -
@@ -247,8 +247,7 @@
{
if (numberOfTokens = 0)
return;
-
-reading:
+
for (int i = 0; i numberOfTokens; i++)
readToken();
}
Index: gnu/CORBA/CDR/AbstractCdrInput.java
===
RCS file: /sources/classpath/classpath/gnu/CORBA/CDR/AbstractCdrInput.java,v
retrieving revision 1.2
diff -u -r1.2 AbstractCdrInput.java
--- gnu/CORBA/CDR/AbstractCdrInput.java 28 Oct 2005 14:05:20 - 1.2
+++ gnu/CORBA/CDR/AbstractCdrInput.java 20 Sep 2007 18:31:22 -
@@ -654,7 +654,7 @@
byte[] r = new byte[l];
int n = 0;
-reading: while (n r.length)
+while (n r.length)
{
n += read(r, n, r.length - n);
}
Index: gnu/CORBA/CDR/Vio.java
===
RCS file: /sources/classpath/classpath/gnu/CORBA/CDR/Vio.java,v
retrieving revision 1.9
diff -u -r1.9 Vio.java
--- gnu/CORBA/CDR/Vio.java 5 Sep 2006 13:57:46 - 1.9
+++ gnu/CORBA/CDR/Vio.java 20 Sep 2007 18:31:24 -
@@ -637,7 +637,7 @@
r = new byte[chunk_size + 256];
n = 0;
-reading: while (n chunk_size)
+while (n chunk_size)
n += input.read(r, n, chunk_size - n);
output.write(r, 0, n);
}
Index: gnu/java/security/key/dss/FIPS186.java
===
RCS file: /sources/classpath/classpath/gnu/java/security/key/dss/FIPS186.java,v
retrieving revision 1.5
diff -u -r1.5 FIPS186.java
--- gnu/java/security/key/dss/FIPS186.java 20 Jun 2006 11:24:43 -
1.5
+++ gnu/java/security/key/dss/FIPS186.java 20 Sep 2007 18:31:24 -
@@ -173,7 +173,7 @@
// 6. Let counter = 0 and offset = 2.
counter = 0;
offset = 2;
-step7: while (true)
+while (true)
{
OFFSET = BigInteger.valueOf(offset 0xL);
SEED_PLUS_OFFSET = SEED.add(OFFSET);
Index: gnu/CORBA/IorDelegate.java
===
RCS file: /sources/classpath/classpath/gnu/CORBA/IorDelegate.java,v
retrieving revision 1.4
diff -u -r1.4 IorDelegate.java
--- gnu/CORBA/IorDelegate.java 18 Sep 2007 21:52:26 - 1.4
+++ gnu/CORBA/IorDelegate.java 20 Sep 2007 18:31:21 -
@@ -173,7 +173,7 @@
throws ApplicationException, RemarshalException
{
StreamBasedRequest request = (StreamBasedRequest) output;
-Forwardings: while (true)
+while (true)
{
try
{
Index: gnu/javax/swing/text/html/parser/support/Parser.java
===
RCS file:
/sources/classpath/classpath/gnu/javax/swing/text/html/parser/support/Parser.java,v
retrieving revision 1.17
diff -u -r1.17 Parser.java
--- gnu/javax/swing/text/html/parser/support/Parser.java19 Dec 2006
01:14:25 - 1.17
+++ gnu/javax/swing/text/html/parser/support/Parser.java20 Sep 2007
18:31:25 -
@@ -523,8 +523,7 @@
restOfTag
[cp-patches] FYI: removed unused private constructors
Hi all,
the attached patch removes a bunch of unused private constructors.
cheers,
dalibor topic
2007-09-21 Dalibor Topic [EMAIL PROTECTED]
* gnu/java/rmi/server/RMIClassLoaderImpl.java,
java/beans/beancontext/BeanContextServicesSupport.java,
java/lang/management/ThreadInfo.java:
Removed unused private constructors.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/rmi/server/RMIClassLoaderImpl.java
===
RCS file:
/sources/classpath/classpath/gnu/java/rmi/server/RMIClassLoaderImpl.java,v
retrieving revision 1.2
diff -u -r1.2 RMIClassLoaderImpl.java
--- gnu/java/rmi/server/RMIClassLoaderImpl.java 17 Aug 2006 07:43:55 -
1.2
+++ gnu/java/rmi/server/RMIClassLoaderImpl.java 21 Sep 2007 19:32:22 -
@@ -64,12 +64,6 @@
this.annotation = annotation;
}
-private MyClassLoader (URL[] urls, ClassLoader parent)
-{
- super (urls, parent);
- this.annotation = urlToAnnotation (urls);
-}
-
public static String urlToAnnotation (URL[] urls)
{
if (urls.length == 0)
Index: java/beans/beancontext/BeanContextServicesSupport.java
===
RCS file:
/sources/classpath/classpath/java/beans/beancontext/BeanContextServicesSupport.java,v
retrieving revision 1.14
diff -u -r1.14 BeanContextServicesSupport.java
--- java/beans/beancontext/BeanContextServicesSupport.java 18 Sep 2007
21:52:34 - 1.14
+++ java/beans/beancontext/BeanContextServicesSupport.java 21 Sep 2007
19:32:22 -
@@ -86,11 +86,6 @@
private BeanContextServiceProvider provider;
-private BCSSProxyServiceProvider(BeanContextServiceProvider p)
-{
- provider = p;
-}
-
public Iterator getCurrentServiceSelectors (BeanContextServices bcs,
Class serviceClass)
{
Index: java/lang/management/ThreadInfo.java
===
RCS file: /sources/classpath/classpath/java/lang/management/ThreadInfo.java,v
retrieving revision 1.9
diff -u -r1.9 ThreadInfo.java
--- java/lang/management/ThreadInfo.java25 Dec 2006 23:58:52 -
1.9
+++ java/lang/management/ThreadInfo.java21 Sep 2007 19:32:23 -
@@ -192,134 +192,6 @@
/**
* Constructs a new [EMAIL PROTECTED] ThreadInfo} corresponding
- * to the thread specified.
- *
- * @param thread the thread on which the new instance
- * will be based.
- * @param blockedCount the number of times the thread
- * has been blocked.
- * @param blockedTime the accumulated number of milliseconds
- *the specified thread has been blocked
- *(only used with contention monitoring enabled)
- * @param lock the monitor lock the thread is waiting for
- * (only used if blocked)
- * @param lockOwner the thread which owns the monitor lock, or
- * codenull/code if it doesn't have an owner
- * (only used if blocked)
- * @param waitedCount the number of times the thread has been in a
- *waiting state.
- * @param waitedTime the accumulated number of milliseconds the
- * specified thread has been waiting
- * (only used with contention monitoring enabled)
- * @param isInNative true if the thread is in a native method.
- * @param isSuspended true if the thread is suspended.
- * @param trace the stack trace of the thread to a pre-determined
- * depth (see VMThreadMXBeanImpl)
- */
- private ThreadInfo(Thread thread, long blockedCount, long blockedTime,
-Object lock, Thread lockOwner, long waitedCount,
-long waitedTime, boolean isInNative, boolean isSuspended,
-StackTraceElement[] trace)
- {
-this(thread, blockedCount, blockedTime, lock, lockOwner, waitedCount,
-waitedTime, isInNative, isSuspended, trace, new MonitorInfo[]{},
-new LockInfo[]{});
- }
-
- /**
- * Constructs a new [EMAIL PROTECTED] ThreadInfo} corresponding
- * to the thread specified.
- *
- * @param thread the thread on which the new instance
- * will be based.
- * @param blockedCount the number of times the thread
- * has been blocked.
- * @param blockedTime the accumulated number of milliseconds
- *the specified thread has been blocked
- *(only used with contention monitoring enabled)
- * @param lock the monitor lock the thread is waiting for
- * (only used if blocked)
- * @param lockOwner the thread which owns the monitor lock, or
- * codenull/code if it doesn't have an owner
- * (only used if blocked)
- * @param waitedCount
[commit-cp] classpath ChangeLog gnu/CORBA/IorDelegate.java ...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/21 18:05:22 Modified files: . : ChangeLog gnu/CORBA : IorDelegate.java gnu/CORBA/CDR : AbstractCdrInput.java Vio.java gnu/CORBA/DynAn: gnuDynUnion.java gnu/CORBA/GIOP : MessageHeader.java gnu/java/security/key/dss: FIPS186.java gnu/javax/crypto/key/dh: RFC2631.java gnu/javax/swing/text/html/parser/support: Parser.java gnu/javax/swing/text/html/parser/support/low: ReaderTokenizer.java gnu/xml/aelfred2: XmlParser.java java/awt/im: InputContext.java Log message: 2007-09-21 Dalibor Topic [EMAIL PROTECTED] * gnu/CORBA/CDR/AbstractCdrInput.java, gnu/CORBA/CDR/Vio.java, gnu/CORBA/DynAn/gnuDynUnion.java, gnu/CORBA/GIOP/MessageHeader.java, gnu/CORBA/IorDelegate.java, gnu/java/security/key/dss/FIPS186.java, gnu/javax/crypto/key/dh/RFC2631.java, gnu/javax/swing/text/html/parser/support/Parser.java, gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java, gnu/xml/aelfred2/XmlParser.java, java/awt/im/InputContext.java: Removed unused labels. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9391r2=1.9392 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/CORBA/IorDelegate.java?cvsroot=classpathr1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/CORBA/CDR/AbstractCdrInput.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/CORBA/CDR/Vio.java?cvsroot=classpathr1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/CORBA/DynAn/gnuDynUnion.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/CORBA/GIOP/MessageHeader.java?cvsroot=classpathr1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/key/dss/FIPS186.java?cvsroot=classpathr1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/crypto/key/dh/RFC2631.java?cvsroot=classpathr1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/swing/text/html/parser/support/Parser.java?cvsroot=classpathr1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/aelfred2/XmlParser.java?cvsroot=classpathr1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/classpath/java/awt/im/InputContext.java?cvsroot=classpathr1=1.11r2=1.12
[commit-cp] classpath ChangeLog gnu/java/rmi/server/RMIClas...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/21 19:39:19 Modified files: . : ChangeLog gnu/java/rmi/server: RMIClassLoaderImpl.java java/beans/beancontext: BeanContextServicesSupport.java java/lang/management: ThreadInfo.java Log message: 2007-09-21 Dalibor Topic [EMAIL PROTECTED] * gnu/java/rmi/server/RMIClassLoaderImpl.java, java/beans/beancontext/BeanContextServicesSupport.java, java/lang/management/ThreadInfo.java: Removed unused private constructors. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9392r2=1.9393 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/rmi/server/RMIClassLoaderImpl.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/java/beans/beancontext/BeanContextServicesSupport.java?cvsroot=classpathr1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/management/ThreadInfo.java?cvsroot=classpathr1=1.9r2=1.10
[cp-patches] FYI: small warning fix for fdlibm
Hi all, the attached patch fixes a missing declaration warning in Kaffe's copy of classpath. cheers, dalibor topic 2007-09-19 Dalibor Topic [EMAIL PROTECTED] * native/fdlibm/dtoa.c: Include stdlib.h to have a declaration for free. Index: libraries/javalib/external/classpath/native/fdlibm/dtoa.c === RCS file: /cvs/kaffe/kaffe/libraries/javalib/external/classpath/native/fdlibm/dtoa.c,v retrieving revision 1.2 diff -u -r1.2 dtoa.c --- libraries/javalib/external/classpath/native/fdlibm/dtoa.c 16 Jul 2006 04:06:51 - 1.2 +++ libraries/javalib/external/classpath/native/fdlibm/dtoa.c 19 Sep 2007 13:24:00 - @@ -28,6 +28,7 @@ #include mprec.h #include string.h +#include stdlib.h static int _DEFUN (quorem,
[cp-patches] FYI: libtool warning fix
Hi all, the attached patch fixes a libtool warning. cheers, dalibor topic 2007-09-19 Dalibor Topic [EMAIL PROTECTED] * native/jni/native-lib/Makefile.am (AM_LDFLAGS) Use CLASSPATH_CONVENIENCE flags, as it is a convenience library. Index: libraries/javalib/external/classpath/native/jni/native-lib/Makefile.am === RCS file: /cvs/kaffe/kaffe/libraries/javalib/external/classpath/native/jni/native-lib/Makefile.am,v retrieving revision 1.1 diff -u -r1.1 Makefile.am --- libraries/javalib/external/classpath/native/jni/native-lib/Makefile.am 3 Jan 2007 23:02:28 - 1.1 +++ libraries/javalib/external/classpath/native/jni/native-lib/Makefile.am 19 Sep 2007 14:06:34 - @@ -7,6 +7,6 @@ cpproc.h \ cpproc.c -AM_LDFLAGS = @CLASSPATH_MODULE@ +AM_LDFLAGS = @CLASSPATH_CONVENIENCE@ AM_CPPFLAGS = @CLASSPATH_INCLUDES@ AM_CFLAGS = @WARNING_CFLAGS@ @STRICT_WARNING_CFLAGS@ @ERROR_CFLAGS@ Index: libraries/javalib/external/classpath/native/jni/native-lib/Makefile.in === RCS file: /cvs/kaffe/kaffe/libraries/javalib/external/classpath/native/jni/native-lib/Makefile.in,v retrieving revision 1.5 diff -u -r1.5 Makefile.in --- libraries/javalib/external/classpath/native/jni/native-lib/Makefile.in 7 Aug 2007 10:55:01 - 1.5 +++ libraries/javalib/external/classpath/native/jni/native-lib/Makefile.in 19 Sep 2007 14:06:34 - @@ -261,7 +261,7 @@ cpproc.h \ cpproc.c -AM_LDFLAGS = @CLASSPATH_MODULE@ +AM_LDFLAGS = @CLASSPATH_CONVENIENCE@ AM_CPPFLAGS = @CLASSPATH_INCLUDES@ AM_CFLAGS = @WARNING_CFLAGS@ @STRICT_WARNING_CFLAGS@ @ERROR_CFLAGS@ all: all-am
Re: Classpath / Icedtea Qtopia
kus Kusche Klaus wrote: Hello! From: Roman Kennke [mailto:[EMAIL PROTECTED] Not out of the box. The Qt peers are somewhat unmaintained at the moment. I did some splitting out in the GTK peers lately, so that they compile without X. I guess, something similar could be done for the Qt peers. Unmaintained doesn't sound very promising. It's an invitation to maintain it in disguise. :) Well, I managed to compile it (in fact, the piece of code mentioned in my first mail was dead code: not called from anywhere...). If you'd like to start contributing patches to classpath, Mark can set you up with everything. Having someone who needs them maintain the Qt peers would be great. I'm behind a firewall which blocks CVS access. Will there be a release with that code any time soon? There is no firm date set for 0.96 yet. Are there any daily snapshots available via http or ftp? Yes. Take a look at http://builder.classpath.org/dist/ . cheers, dalibor topic
Re: Classpath 0.96
Dâniel Fraga wrote: On Tue, 18 Sep 2007 15:27:15 +0100 I mean, I know I can use gcjwebplugin, but it doesn't work for all cases, all applets etc. Now that Java was GPLed, how much time will it take so classpath will merge code from Sun so we can have a gcjwebplugin that works in all cases? Currently, there is no one actively working on merging code from OpenJDK into GNU Classpath, so it will take an infinite amount of time. :) Alternatively, check out IcedTea. Ps: I'm interested in classpath because it's the only option I have for a 64 bit plugin... since Sun refuses to release a 64 bit plugin :( I saw the GPL Java announcement, but I don't understand how the code is being distributed...If at least Sun would release all the source code so we can compile the plugin ourselves, it would be much better. It's not a matter of refusing to release code, the plugin simply hasn't been a priority for them yet, afaict. At FOSDEM, someone said that the plugin code for IE alone is about the size of the hotspot code, so it's probably a lot of work. I'd expect it to be a bit lower in the priority queue than fixing encumbrancies (necessary for pure openjdk to move into fedora, debian, etc.) creating a certifiable OpenJDK 6 branch (necessary to certify the resulting binaries as Java(TM)), never mind all the other things going on in parallel (mercurial migration, build system changes, opening up the interpreter code to aid porting efforts, consumer JRE, JCK process, ...). cheers, dalibor topic
Re: Classpath / Icedtea Qtopia
Dalibor Topic wrote: Are there any daily snapshots available via http or ftp? Yes. Take a look at http://builder.classpath.org/dist/ . I've added this to the wiki at http://developer.classpath.org/mediation/ClasspathFirstSteps#head-9b1d9d73255384bbf12c9639829a748fb82a9490 cheers, dalibor topic
[commit-cp] classpath ChangeLog native/jni/native-lib/Makef...
CVSROOT:/sources/classpath Module name:classpath Changes by: Dalibor Topic robilad 07/09/19 14:36:40 Modified files: . : ChangeLog native/jni/native-lib: Makefile.am Log message: 2007-09-19 Dalibor Topic [EMAIL PROTECTED] * native/jni/native-lib/Makefile.am (AM_LDFLAGS) Use CLASSPATH_CONVENIENCE flags, as it is a convenience library. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9386r2=1.9387 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/Makefile.am?cvsroot=classpathr1=1.2r2=1.3
[cp-patches] FYI: fixed build under Eclipse
Hi all, I checked in the attached patch to fix the build under Eclipse. It reverts some changes that seem to have slipped through when Roman made his last commit. cheers, dalibor topic 2007-09-18 Dalibor Topic [EMAIL PROTECTED] * .classpath: Reverted escher-specific changes that break the build under Eclipse. ### Eclipse Workspace Patch 1.0 #P classpath Index: .classpath === RCS file: /sources/classpath/classpath/.classpath,v retrieving revision 1.19 diff -u -r1.19 .classpath --- .classpath 13 Sep 2007 22:31:04 - 1.19 +++ .classpath 18 Sep 2007 20:12:37 - @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? classpath - classpathentry excluding=.externalToolBuilders/|.settings/|ChangeLog*|Makefile*|autom4te.cache/|compat/|config*|doc/|examples/|external/|external/relaxngDatatype/|include/|install/|lib/|m4/|native/|resource/|scripts/|test/|testsuite/|tools/|tools/external/asm/|vm/reference/ kind=src path=/ + classpathentry excluding=.externalToolBuilders/|.settings/|ChangeLog*|Makefile*|autom4te.cache/|compat/|config*|doc/|examples/|external/|external/relaxngDatatype/|gnu/java/awt/peer/x/|include/|install/|lib/|m4/|native/|resource/|scripts/|test/|testsuite/|tools/|tools/external/asm/|vm/reference/ kind=src path=/ classpathentry excluding=.cvsignore|Makefile|Makefile.am|Makefile.in|README.txt kind=src path=external/relaxngDatatype/ classpathentry kind=src path=external/jsr166/ classpathentry excluding=.cvsignore|Makefile|Makefile.am|Makefile.in|README|external/asm/ kind=src path=tools/ @@ -10,6 +10,5 @@ classpathentry excluding=.cvsignore|Makefile|Makefile.am|Makefile.in|README kind=src path=external/w3c_dom/ classpathentry excluding=.cvsignore|Makefile|Makefile.am|Makefile.in|Makefile.jawt|Makefile.jawt.in|README kind=src path=examples/ classpathentry kind=src path=tools/external/asm/ - classpathentry kind=lib path=/escher/build/ classpathentry kind=output path=install/share/classpath/ /classpath
[cp-patches] FYI: Removed unused imports from examples
Hi all, the attached patch removed a bunch of unused imports from examples. cheers, dalibor topic 2007-09-18 Dalibor Topic [EMAIL PROTECTED] * examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToPassHelper.java, examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToReturnHelper.java, examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/TreeNodeHelper.java, examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/WeThrowThisExceptionHelper.java, examples/gnu/classpath/examples/awt/AnimationApplet.java: Removed unused imports. ### Eclipse Workspace Patch 1.0 #P classpath Index: examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToPassHelper.java === RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToPassHelper.java,v retrieving revision 1.2 diff -u -r1.2 StructureToPassHelper.java --- examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToPassHelper.java 10 Jul 2006 08:24:46 - 1.2 +++ examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToPassHelper.java 18 Sep 2007 20:43:36 - @@ -40,7 +40,6 @@ import gnu.CORBA.OrbRestricted; -import org.omg.CORBA.ORB; import org.omg.CORBA.StructMember; import org.omg.CORBA.TypeCode; import org.omg.CORBA.portable.InputStream; Index: examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/TreeNodeHelper.java === RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/TreeNodeHelper.java,v retrieving revision 1.2 diff -u -r1.2 TreeNodeHelper.java --- examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/TreeNodeHelper.java 10 Jul 2006 08:24:46 - 1.2 +++ examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/TreeNodeHelper.java 18 Sep 2007 20:43:36 - @@ -42,7 +42,6 @@ import gnu.CORBA.OrbRestricted; import org.omg.CORBA.Any; -import org.omg.CORBA.ORB; import org.omg.CORBA.StructMember; import org.omg.CORBA.TypeCode; import org.omg.CORBA.portable.InputStream; Index: examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/WeThrowThisExceptionHelper.java === RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/WeThrowThisExceptionHelper.java,v retrieving revision 1.2 diff -u -r1.2 WeThrowThisExceptionHelper.java --- examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/WeThrowThisExceptionHelper.java 10 Jul 2006 08:24:46 - 1.2 +++ examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/WeThrowThisExceptionHelper.java 18 Sep 2007 20:43:36 - @@ -41,7 +41,6 @@ import gnu.CORBA.OrbRestricted; import org.omg.CORBA.Any; -import org.omg.CORBA.ORB; import org.omg.CORBA.StructMember; import org.omg.CORBA.TCKind; import org.omg.CORBA.TypeCode; Index: examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToReturnHelper.java === RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToReturnHelper.java,v retrieving revision 1.2 diff -u -r1.2 StructureToReturnHelper.java --- examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToReturnHelper.java 10 Jul 2006 08:24:46 - 1.2 +++ examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication/StructureToReturnHelper.java 18 Sep 2007 20:43:36 - @@ -39,7 +39,6 @@ import gnu.CORBA.OrbRestricted; -import org.omg.CORBA.ORB; import org.omg.CORBA.StructMember; import org.omg.CORBA.TCKind; import org.omg.CORBA.TypeCode; Index: examples/gnu/classpath/examples/awt/AnimationApplet.java === RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/awt/AnimationApplet.java,v retrieving revision 1.1 diff -u -r1.1 AnimationApplet.java --- examples/gnu/classpath/examples/awt/AnimationApplet.java 16 Mar 2006 03:28:12 - 1.1 +++ examples/gnu/classpath/examples/awt/AnimationApplet.java 18 Sep 2007 20:43:36 - @@ -21,7 +21,6 @@ package gnu.classpath.examples.awt; import java.awt.*; -import java.awt.event.*; import java.applet.*;
