Re: Clarification and apologies (was Re: Re: GCJ ------ file type not supported by system)
GCJ needs to use IcedTea. Unfortunately the difference between most Java developers who want to compile Java to a native executable and a GCC hacker is vast. Brian On Fri, Sep 5, 2014 at 7:22 AM, Andrew Haley a...@redhat.com wrote: On 09/05/2014 12:07 PM, Guillermo Rodriguez Garcia wrote: After reading in a previous post that Classpath was not being actively developed anymore, I said that it would be a pity to let the project die, and suggested that perhaps it was time to look for an adopter ( http://developer.classpath.org/pipermail/classpath/2014-August/003270.html ) That was perhaps my fault; I said it was not being actively developed, when I should have said it was not much being actively developed. That's a subtle distinction, but one that matters to some people. Andrew.
Fwd: How HTTPS Everywhere affects classpath.org
I believe the included classpath.org hosts are just pointed at FSF servers, so this should not impact anyone but I thought I'd pass it along. -- Forwarded message -- From: HTTPS Everywhere Project https-everywhere-notificat...@eff.org Date: Wed, Jul 24, 2013 at 7:36 PM Subject: How HTTPS Everywhere affects classpath.org To: cbjon...@gmail.com, webmas...@classpath.org Hi, You're receiving this note because classpath.org is part of our HTTPS Everywhere browser extension, and an upcoming change to the way Firefox handles HTTPS pages may cause your site to display or function incorrectly. We want to make sure that the nearly 3 million HTTPS Everywhere users have the best possible experience while browsing, so we're asking you to please take a minute and test how your site behaves in Firefox 23. You can find out more about our software at https://www.eff.org/https-everywhere To see the rules affecting your site, you can visit the HTTPS Everywhere Atlas at https://www.eff.org/https-everywhere/atlas/domains/classpath.org.html The Atlas shows both rules in the development and stable versions of our extension. Rules in the stable version are used by millions of users, while development rules are used by tens of thousands of users. Development rules are now being tested but will be migrated to the stable version in the future. **An upcoming change (described below) in how the Firefox browser renders HTTPS content makes it especially important that you check that your site is prepared for HTTPS access. We urge you review the rules affecting your site and also to test it using HTTPS Everywhere with the upcoming version of Firefox.** *NEW FIREFOX CONTENT SECURITY POLICY*: In the upcoming Firefox 23 browser release, due out the week of August 6, Firefox will stop loading certain active content such as scripts and stylesheets from insecure http:// URLs if they've been included from a secure https:// site. If the HTTPS Everywhere rules send users to the secure version of your site but the secure version includes some content loaded over an insecure connetion, the rendering of your site may become broken for Firefox users with HTTPS Everywhere installed after they upgrade to Firefox 23. You can check this by downloading a preview release of Firefox 23, installing HTTPS Everywhere, and visiting your site. We urge all web site operators to protect their users by making sure that all site content is always loaded over a secure connection. A preview version of Firefox 23 is available now at https://www.mozilla.org/en-US/firefox/beta/ and the HTTPS Everywhere extension is at https://www.eff.org/https-everywhere HTTPS Everywhere rules instruct browsers to access certain specified resources securely -- over HTTPS -- even if the user typed or followed a non-HTTPS link or even if the resources were included in a page via a non-HTTPS URL. For example, it might automatically rewrite http://www.classpath.org/ to https://www.classpath.org/ or make some similar change. The goal of this rewriting is to protect as much as possible of every web site against sniffing and tampering by ensuring that as many site resources as possible are loaded over a secure HTTPS connection. When web sites are accessed insecurely, users are vulnerable to attacks by other users on their networks. HTTPS Everywhere aims to activate sites' existing HTTPS protection more consistently to make sure users are as well-protected from these attacks as possible -- including attacks like sidejacking and SSL stripping. http://www.firesheep.org/ http://www.thoughtcrime.org/sslstrip As a result, we think there's an emerging consensus to make all web sites secure, not just financial sites and login pages. Providing a secure connection helps protect users' login credentials, but also helps protect their privacy and security even when accessing public resources, for example by preventing network operators from injecting malware downloads. The goal of HTTPS Everywhere is to make the web more secure and help users express their preference to use the secure version of every site automatically, even on sites where this is not the default. We don't want to break sites or harm users' experience. So, we encourage webmasters to test the effect of HTTPS Everywhere on their sites and fix any problems that result -- ideally, by making sure that all resources that make up a site are available over HTTPS, using a current, valid certificate. Although we only include rules that we've been told and believe work properly, we can't always anticipate whether a rule adversely affects a site, especially if the site's URL structure, use of CDNs, or level of HTTPS support changes over time. We are always happy to receive bug reports, updates, and fixes to HTTPS Everywhere rules. We will also make rules inactive by default if a site operator asks us to. Although we are working for a web where all sites are secure, we are not trying to use this
Fwd: Permission to translate your page at http://icedtea.classpath.org/
Not sure where to send this... Begin forwarded message: *From:* Anja Skrba an...@webhostinggeeks.com *Date:* April 10, 2013, 4:32:42 PM EDT *To:* c...@gnu.org *Subject:* *Permission to translate your page at http://icedtea.classpath.org/* *Reply-To:* Anja Skrba an...@webhostinggeeks.com Dear Sir, I am writing to inquire regarding your web page about IcedTea project where I have found a lot of useful information. My name is Anja and I'm currently studying at the Faculty of Computer Science in Belgrade. Here is the URL of your article: http://icedtea.classpath.org/wiki/Main_Page I would like to share it with the people from Former Yugoslav Republics: Serbia, Montenegro, Croatia, Slovenia, Macedonia, Bosnia and Herzegovina. I would be grateful if you could allow me to translate your writing into Serbo-Croatian language, that is used in all Former Yugoslav Republics and to post it on my website. Hopefully, it will help our people to gather some additional knowledge about computing. I hope to hear from you soon. Regards, Anja Skrba an...@webhostinggeeks.com http://science.webhostinggeeks.com/ Tel: +381 62 300604
Re: [cp-patches] [RFC/PATCH] Check for gettext m4 macros in autogen.sh
I'm sorry I'm not a good one to review this. They changed the auto* tools quite a bit since I used to mess with them. Is autogen.sh something auto* creates, just wondering if it is okay to modify... On Tue, Mar 12, 2013 at 2:47 PM, Pekka Enberg penb...@kernel.org wrote: If gettext-devel package is not installed on Fedora, autogen.sh fails as follows: [penberg@tux classpath]$ sh autogen.sh configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:22: AM_ICONV_LINK is expanded from... m4/iconv.m4:77: AM_ICONV is expanded from... Make the script more user fiendly by explicitly checking for the presence of gettext.m4 in the system. Cc: Andrew John Hughes gnu_and...@member.fsf.org Cc: Brian Jones cbjon...@gmail.com Signed-off-by: Pekka Enberg penb...@kernel.org --- ChangeLog |5 + autogen.sh |7 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 289a979..e26f627 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2013-03-12 Pekka Enberg penb...@kernel.org + + * autogen.sh: + Check that gettext.m4 is installed. + 2013-03-09 Pekka Enberg penb...@kernel.org * .gitignore: Exclude autogen-generated files. diff --git a/autogen.sh b/autogen.sh index adb8f0c..df0095f 100755 --- a/autogen.sh +++ b/autogen.sh @@ -34,6 +34,13 @@ if $have_libtool ; then : ; else DIE=1 fi +if [ ! -e $(aclocal --print-ac-dir)/gettext.m4 ] ; then + echo + echo You must have gettext package and, if applicable to your + echo system, gettext-devel package installed to compile $PROJECT. + DIE=1 +fi + if test $DIE -eq 1; then exit 1 fi -- 1.7.7.6
Re: Building GNU Classpath on Fedora 17
On Mar 11, 2013, at 9:57 AM, Pekka Enberg penb...@kernel.org wrote: Hello, On Mon, Mar 11, 2013 at 3:20 PM, Andrew Hughes gnu.and...@redhat.com wrote: I wasn't aware we did. What version of libtool does F17 have? I build with 2.4.2 at present. Oh dear. I was missing gettext-devel package again! How can we add some magic to autogen.sh to be more friendly to the user? I keep hitting the same problem every time I try to build GNU Classpath on a fresh installation... :-/ Add a configure check for whatever the dependency is...
Re: [cp-patches] GNU Classpath
On Oct 20, 2012, at 5:04 AM, Chris Burdess d...@bluezoo.org wrote: Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this. We did maintain the ChangeLog using commits originally and a script to suck them out and generate a file, but at some point we went to keeping a file instead, because it did not require a script. I suggest those merging changes into trunk/master have the ultimate responsibility regarding ensuring the ChangeLog is up to date and since it cannot be auto merged perhaps do not make changes to it except when merging to the release and trunk/master branches. As an aside I always found it easier to maintain my own ChangeLog entries in a separate file and only when committing upstream to add them to the project's file. Brian
Re: [cp-patches] [RFC PATCH] Bump up Java source and target version to 1.6
On Oct 15, 2012, at 2:37 AM, Pekka Enberg penb...@kernel.org wrote: On Sat, 13 Oct 2012, Ivan Maidanski wrote: If you could show the community that upgrading to 1.7 brings some benefit (e.g., like above) then it is ok to upgrade to 1.7 directly (thus eliminating Classpath VM implementors efforts to verify with 1.6). Java 1.7 has some nice language changes: http://docs.oracle.com/javase/7/docs/technotes/guides/language/enhancements.html#javase7 and more importantly, invokedynamic, that's heavily used by upcoming JRuby 1.7. IIRC, Scala 2.10 will no longer run on Java 1.5 either. Pekka Although jruby needs invokedynamic to perform better I don't think this means the class library needs to change source version unless an actual API change would be unrecognized otherwise? You do however need a vm that supports invokedynamic and uses GNU Classpath. Does one exist?
Re: [cp-patches] Assertions and System Assertions in GNU Classpath
On the administrative side, AFAICS you haven't contributed before. Do you have a copyright assignment with the FSF? The change appears to be minor enough to not require the paperwork to me. Mostly comments, very little code. But hey, if you're gonna be contributing better to get that started sooner than later. Brian
domain transfer
I'm transferring classpath.org to another registrar. This process should happen in the next few days. Anyway, the name servers for the domain are not supposed to change during this transfer process so this should be transparent to everyone involved, but in case something happens I wanted to at least let folks know it was going on. Happy hacking, Brian
Re: [cp-patches] [PATCH] Fix raw type references in AnnotationInvocationHandler
On Wed, Oct 12, 2011 at 3:16 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: On 12:07 Wed 12 Oct , Ian Rogers wrote: On 12 October 2011 03:52, Mark Wielaard m...@klomp.org wrote: On Wed, 2011-10-12 at 10:29 +0300, Pekka Enberg wrote: On Wed, Oct 12, 2011 at 1:28 AM, Dr Andrew John Hughes ahug...@redhat.com wrote: If we're going to change that, it should happen after the next release and with plenty of discussion / heads up for VMs. Right. I guess I could send patches for JamVM, CACAO, and Jato as well. Are there other VMs we care about? JikesRVM and GCJ of course! Although they only use part of the VM interface at this time. There is a somewhat full list at: https://www.gnu.org/software/classpath/stories.html#jvm Some of those are somewhat in hibernation though. Heay, and JATO is missing... If we're going to do this, it needs to wait until after the next release. When is that? Brian
Re: Future blog
Hi all, long time, no commit. It is unclear from my vantage point what the purpose of Classpath should be. Most of the VMs I'm familiar with who were essentially customers in the past are moving to support openjdk's class library it seems Thank goodness for JamVM and all the rest over the years. Brian On Dec 7, 2010, at 6:53 PM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 23:06 Tue 07 Dec , Mark Wielaard wrote: Hi all, Hi Mark, I'll apologise in advance if some of what I've written below sounds harsh, but I'm not that happy with the state of Free Java generally right now. For those who didn't see Pekka's blog on planet.classpath.org you can find it here: http://penberg.posterous.com/whats-the-future-of-gnu-classpath He makes some very good points. I agree with all of them. I agree on the general overtone. Indeed, I already blogged about it: http://blog.fuseyism.com/index.php/2010/11/03/the-homogenisation-of-the-java-platform/ There are several inaccuracies in the points themselves. I'm not too surprised, given that Pekka is still new to the project, but I am surprised that you'd agree wholeheartedly with such little hesitation. Mauve has not been abandoned (as you acknowledge below). You merely need to look at the logs to see that tests have been added e.g. http://sources.redhat.com/cgi-bin/cvsweb.cgi/mauve/gnu/testlet/java/security/Policy/setPolicy.java?cvsroot=mauve I posted to the Mauve mailing list about this last week. It is in the same state as GNU Classpath, in that there are very few contributors, but it has not been abandoned. 1.6 work has already been done on GNU Classpath, though that is now some time back; it's all there in the mailing list archives though. There is no 1.7 API to implement yet, so that's a pointless statement. I also tend to still believe in the general Classpath spirit that we implement primarily to match the requirements of applications, not specific applications. We have no hope of ever TCKing the thing anyway, and to my knowledge it's never been used with a JDK that's not Oracle-based so I have no trust in its reliability. Now the cool thing would be if I said lets do them all right now!. But instead I am going on vacation and be offline for about two weeks. Sorry about that. But I didn't want to not respond at all. As soon as I am back I would like us to at least start moving to mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. It would make more sense if there were lots of contributors but there aren't. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. One of Pekka's motivations is also flawed: 'how much problems it causes for developers that don't have commit rights to the centralized repository!' Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. The discussion earlier today: http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html shows exactly why we do need patch review and discussion. This is just because other projects around free java (hi openjdk) are also using mercurial and it seems convenient to use something similar, but other suggestions appreciated. Hopefully we can do something similar for Mauve (it isn't abandoned, more in the same state as GNU Classpath). And somehow integrate/extend it with Malva and the jtreg testsuite from OpenJDK. (They probably should stay separate projects, but at least the autobuilder should run them. The autobuilder is in a really bad shape, but there is a new host already that can pick up the load.) jtreg would have to be a project to begin with. It doesn't seem to be one at present, and I'd barely call OpenJDK one either. Why else are we all working on IcedTea? The discussion on the patches mailinglist does show a real problem though. We have very little active hackers, and so aren't doing very well helping new hackers like Pekka and Ivan to get their work integrated. I agree this is a problem. But whining about it won't help. Getting involved would. I'm doing my best but I can't do everything. There are only so many hours in the day. I'd prefer to spend more of those hours on GNU Classpath rather than the intense boredom of IcedTea/OpenJDK work, but unfortunately that's not how the cards are stacked. Opinions? Suggestions? Flames? Thanks, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and
Re: Future blog
On Wed, Dec 8, 2010 at 6:49 AM, Andrew Haley a...@redhat.com wrote: On 12/08/2010 11:44 AM, Brian Jones wrote: I've only recently gone from svn to git and honestly git is freaking awesome sauce. I'm pretty sure what you are missing is how much nicer having local branches can be for local development. The cvs way would be multiple checkouts, and a lot of manual diffing and merging. If Classpath were on svn at least then you could use git svn as a contributor with ease. But yea, git and github are pretty sweet. You seem to be assuming the rest of us don't use such systems. We do, every day. Please don't top-post. Oh okay, as long as you'll admit any dvcs is better than cvs for contributors, I suppose I can post in this way. Brian
Re: Where's the love?
Dalibor Topic wrote: On Fri, Mar 10, 2006 at 12:20:02AM -0800, Per Bothner wrote: Dalibor Topic wrote: The only way GNU Classpath would be acceptable for Apache Harmony, afaict from our dicussions in the past year, would be if the FSF contributed it to the ASF, and had the ASF manage the project, under the Apache license. Anything else is non-option for ASF, for a variety of reasons. Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I hope I'm wrong, but nothing I've heard suggests otherwise. I am sorry if I gave that impression, since that's not the way I experienced it. My impression was that the ASF simply has certain ways to do things, and does not want to change those, since their way basically works fine for them, and they don't think GNU Classpath is worth changing their ways of doing things, as apparently, that's all very tedious and so on. I wouldn't want to imply malice, where buerocratic inertia is a sufficient explanation. This is all really sad. Guess the only thing to do is ignore Harmony and and rub it in that they had to get donations to get anywhere. Ha! ;) Brian
Re: Where's the love?
Okay, there is a solution that is rather expedient to fixing the classpath/classlib licensing problems. The FSF has within it's power the ability to relicense the software under new terms and conditions or could in fact dual license the software under both the current license and a suitable Apache friendly license. All that is required is to win the argument with Richard Stallman or Bradley Kuhn. And that would have to start with getting most of the committers on board with the idea and the project maintainer. This is how we did the license change from LGPL to GPL+exception. Gcj (gcc) needed us to switch from LGPL to the exception bits because it is what they were already using to make certain use cases, such as delivery of a software controlled toothbrush, work, without requiring the redistribution of object files suitable for re-linking the application on your toothbrush. I don't really see the FSF backing down from the point of view that the users of free software should have the right to modify and release the software and Apache is unlikely to change either, as they have benefited enormously (in terms of brand at least) from letting anyone embed their software without having to divulge the source code to users. Given that you can already ship products with closed binary-only java class libraries from many sources adding one more isn't going to change that world or hurt a user. But, we can benefit enormously from combining our energies with Harmony to deliver a free J2SE 5 faster than anyone thinks is possible. So, given these things and my love for this project, I would really like the FSF to allow the developers to provide Classpath under an Apache compatible license in addition to the current licensing scheme, at least until the FSF and the Apache Foundation resolve their own license incompatibilities. We have no guarantees they will ever work things out and waiting a year to find that out is waiting a year too long. Thanks for letting me share, Brian (former maintainer)
Where's the love?
Etienne Gagnon wrote: Hi Dalibor, You just managed to ... Thanks guys for making my inbox more interesting. I'd go read the harmony mailing lists but I'm pretty sure something over there would tick me off. I'm not following Harmony too closely (so let me talk out my ... a moment) but let me see if I understand it so far. Harmony is: 1) Writing their own class libraries (based on email about japi comparisons) 2) Writing their own JVM (which I think is based in some part on one of the current JVMs, but ok, sure, everyone seems to write one eventually) 3) Writing their own test suite (because Mauve doesn't use junit and has a different license, but I think that's going to be fixed) Where's the harmony? Please tell me Classpath isn't going to be left standing at the altar while Harmony elopes? Brian
Re: Next release
Stuart Ballard wrote: On 2/27/06, Brian Jones [EMAIL PROTECTED] wrote: Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 release should be 1.4.0 (or 1.40 if you were going to be consistent, but I digress). Anyway my $0.02. 0.90 has problems if there turn out to be more than 9 more releases before 1.(4.)0 is reached. Hard to say whether that's likely or not, but I think it would be better if our decision of when to hit 1.x was based purely on technical grounds and not affected by limits on the version-number space. On the other hand, well spotted (I think?) that 0.9.x might be considered a lower version that 0.21 by packaging tools. dpkg --compare-versions appears to think so, if I'm understanding how to use it right. This may be moot though as the debian classpath package already has an epoch on it; I don't know how rpm handles this kind of issue. I think the actual precedent is to go 0.9xx... as needed until you _can_ declare the 1.0. So it's more of a mindset thing to bump the number and get folks really working towards that 1 goal. You do not need to feel limited to only 9 releases. There can in fact remain an infinite number of releases between 0.90 and 1.x. :) I just can't figure out a good way to declare something as pre-1.4.0 without confusing folks more, as in 1.3.x won't work as it is also false. So just keeping the same style as now and moving forward to 0.90 makes good sense to me. But what version numbers will you use post 1.4.0 for development releases? Would you go with 1.5.0- or similar for HEAD and 1.4.0- for the 1.4 release branch? That actually doesn't quite work, the 1.5 release branch would also end up 1.5.0- so something else will have to differentiate a dev release. You can of course internally continue with your same scheme and simply tag your production releases as corresponding to a particular java release and leave it at that. Doesn't look like anyone wants to do that though. Oh yes, if the packaging tools can't tell 1.4.0 is newer than 0.90 then perhaps you'd want to bring about the package version change hell sooner rather than later. Brian
Re: Next release
Michael Koch wrote: On Mon, Feb 27, 2006 at 08:36:37PM +, Chris Burdess wrote: Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. I agree with the above but my preference would be for 1.4.x. We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features. Full ACK. This really makes sense. Cheers, Michael Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 release should be 1.4.0 (or 1.40 if you were going to be consistent, but I digress). Anyway my $0.02. Brian
Re: New native layer
Dalibor Topic wrote: On Mon, 2006-01-30 at 12:20 -0500, Brian Jones wrote: It would be nice, I believe, to re-use libraries that have handled most of the porting and wrapping for you such as APR (http://apr.apache.org/), or NPR (http://www.mozilla.org/projects/nspr/) to platforms GNU Classpath might care to support. You might also find glib useful, http://developer.gnome.org/arch/gtk/glib.html. I believe that's the reason why neither APR nor NSPR (nor other similar projects) have seen wide spread acceptance, even though they have been around for many years now: they don't really pay off enough for people to rewrite their existing code bases to them. Okay, but I brought it up since the work Guilhem Lavaux is doing sounds an awful lot like a rewrite. Although technically I think you can just run the macro processor by hand to get the current real source code for say Linux and autoconfiscate it from there. Or you could go back a couple of years and look in native/ for the original autoconf/posix version of the libraries and move forward from there. See also what the OpenBSD developers did as one of the first things, once they 'forked' Apache web server 1.3.x after the Apache license change: rip out APR and replace its use by plain old posix functions, since those were more maintainable for them. Yea, I think the point for me would be to keep Classpath's java hackers out of the business of writing native code, and especially out of the business of porting native code for such common idioms as generic file operations, network operations, etc. Anyway, that was my $0.02, Brian
Re: classpath+mauve
Michael Koch wrote: On Fri, Oct 14, 2005 at 03:56:28PM +0200, Norman Hendrich wrote: Hello David and Audrius, first of all, thanks for your answers to my mauve-setup question(s). I tried the MakeTestClassList program, which seems to work fine. However, after spending another few hours trying to get the whole testsuite running, my worst fears are confirmed... To summarize: * writing new testcases is easy * running individual testcases is easy (from the shell or eclipse) * running parts of the testsuite via an index file works. * BUT there is no easy way to run the whole testsuite. A developer first has to create a custom list of exclusion testcases, before running the remaining fraction of the testsuite... Not true. I just use the batch_run utility to run them all. I know that Mark uses this too. Cheers, Michael Yes, due to the nature of how a JVM can fail... especially with respect to hanging and doing nothing, you have to wrap execution of each test case in a fashion that will kill the JVM if it does not exit in a reasonable period of time. I think this batch_run utility does that. I used to have a nice little set of scripts that did something similar and created pretty graphs. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: rmic contribution
On Wed, 2005-06-22 at 10:48, Tom Tromey wrote: Archit == Archit Shah [EMAIL PROTECTED] writes: Archit A patch to replace the old RMIC implementation with the new ASM-based Archit one attached. The patch file modifies configure.ac and Makefile.am to Archit deal with asm.jar. The 2 java files go in Archit cp-tools/src/gnu/classpath/tools/rmi/rmic. The Compile*.java files in Archit that directory should be deleted. asm.jar (version 1.5.x) is required Archit and can be downloaded here: Archit http://download.forge.objectweb.org/asm/asm-1.5.3.jar. I'm not sure Archit where that requirement should be listed (NEWS, README or INSTALL), so Archit the patch doesn't mention it. The newest version of ASM, 2.0, was Archit released three weeks ago and will not work as there were API Archit changes. Updating to use ASM 2.0 instead of 1.5.3 would require Archit minimal effort. Nobody has reviewed this yet, and I put it off a long time too -- sorry about that. The code itself looks good to me. It could use a few comments; when writing code like generateSkel() that builds up a method using some IR, I like to have comments showing what the generated code looks like (in java-ish pseudo code). This usually makes it a bit simpler to follow what is going on. As for ASM, I think it is fine for us to use it. We don't really have a good model for how to handle upstream code that we use but don't want to export. My first inclination is to say we should handle it like SAX, meaning it would go in external/asm, external/README would explain what it is (and where we got it and how and when it can be updated), and finally it would be built from source. Using it should be fine. It would be great to get everything (dealing with bytecode) using it but I'm not hacking right now. I believe the cp-tools configure stuff is setup to allow you specify where to find necessary jars. I don't have a debian or whatever free java system setup to know where one should look for jar files by default... but nothing has to be perfect to start out. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.14 released
On Fri, 2005-03-18 at 01:56, Chris Pickett wrote: C. Brian Jones wrote: I still wear my Japhar Hungry Programmer t-shirt sometimes. Speaking of which, we'll need a t-shirt for the 1.0 release. Anyone want to design one? Is there a gcc 4.0 t-shirt? I assume you mean Classpath 1.0 ... something along these lines? (attached) Thanks Chris, that's the idea. I may have to try doing something myself. I think Droplet, our mascot, should be included. :) Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: a faster rmic
On Tue, 2005-02-15 at 15:25, Archit Shah wrote: Thanks for the reply. I have a few questions below. C. Brian Jones wrote: If there is concern about the dependency on asm, I am open to suggestions for an alternate bytecode generating facility. I understand there is a gnu.bytecode in kawa [3]. I'm perfectly happy to switch from asm to something else if it will ease adoption of my code. Yes, that's available as well. Per is open to improving (accepting patches for) gnu.bytecode as needed. I'm not sure I understand. Are you saying it is ok for me to use asm? Are you saying it is preferable for me to switch to gnu.bytecode? There are no issues with using asm. I like asm as well and the license is acceptable. I haven't added the code to cp-tools yet, but I've been writing junit tests for javap. You might consider doing the same for rmic. Unit testing rmic is a bit problematic. I've been running end to end tests that with a client that download stubs and invokes remote methods. This is not trivially junit-able because it requires at least 2 separate processes with separate classpaths. I'don't really have a good idea for more lightweight testing of rmic. Any ideas on this front are appreciated. End-to-end rmi testing would be more difficult but not impossible. For things like j2ee other unit testing frameworks were developed to make it easier. I don't know if there is anything for generic rmi testing. PS Any reason you've replied off-list? Must have made a mistake and used reply instead of reply all. -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: gjdoc-0.7.1-pre1
On Sat, 2005-02-05 at 14:48, Mark Wielaard wrote: The current GNU Classpath documentation has been regenerated with this version and can be found at: http://developer.classpath.org/doc/ (Note that by configuring --with-gjdoc you can do the same on your local version of the GNU Classpath sources when gjdoc is installed.) Would you mind regenerating with -protected? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Bug#290377: classpath-common: why don't you provide a jar archive ?
On Mon, 2005-01-17 at 07:05, Michael Koch wrote: Am Montag, 17. Januar 2005 07:45 schrieb jewel: Welcome back, John. Do all classpath VMs have native code to load jar files? Does it make sense to distribute a jar instead? The ones the don't have the code to load jars can install classes instead of glibj.zip. A JAR is basically a ZIP. There is no advantage when we call it glibj.jar. This will probably get only more problems as people might try to add it to their classpathes because its a JAR. At some point someone who distributes a binary of glibj might want to use a jar file format to sign the jar and verify the integrity of the classes within it. I don't think this buys you much more than a regular md5sum of the zip file, but that the runtime can perform the verification in a standard way. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Which standard do you follow?
So I'm poking around http://java.debian.net/ wiki and I have to say I still don't understand what it is the upstream source provider should do with reference to scripts and libraries and jars that would be acceptable for everyone. It still seems like I have to pick a scheme, with reference just to finding a VM, that will only work on one distribution or packaging scheme for java libraries and applications. Anyone else thinking about this? With Debian our JNI libraries should be somewhere else, the .jar file (or .zip file I guess) should be versioned correctly and if we ever do install scripts for common tools or something then those have special requirements. I probably should ask the cojapas list but I thought I'd start here. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
All, If you have tried to send me email in the past week it is probably lost. It appears I was bitten by a default mailbox size limit in postfix of 50 MB that I didn't know about before. This should be corrected now. Looks like I missed 20 or 30 emails on the classpath list but the archives have them. Happy Hacking, Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Mauve test question
On Tue, 2004-12-28 at 17:56, Thomas Zander wrote: Since various Mauve users have said they wanted something like this anyway; I went ahead and coded the jvm-parsing stuff already. I read all source files, parse the minimum/maximum JVM 'Tags' from that file and store it. Then I have a new class called 'Filter' which will ask you what which version you want to check. If you choose JDK1.0 it will create a file with only 1.0 tests, if you choose 1.3 it will create a file with 1.0, 1,1, 1.2 and 1.3 tests. That output file can then be piped into the SimpleTestHarness. This brings the running of mauve back to one 'java -jar' and then just following instructions. (that 'java' is just an example; it should work on any JVM) here is the jar file: http://members.home.nl/zander/alltests.jar (1mb) This surely does not solve the whole problem; but I felt it would be usefull to point out my progress this far. Is this at all problematic if your JVM doesn't support whatever classes are needed for this additional test framework wrapper? Obviously you'd be failing some tests anyway so I don't know if it matters... everyone okay with something like this in java or prefer it written in something like perl? -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Removing primlib files from libclasspath?
On Wed, 2004-12-01 at 09:59, Dalibor Topic wrote: Hi everyone, after merging in libclasspath into Kaffe, primlib's missing LINK_* functions broke static builds for riscos. I tried to figure out what primlib does briefly, and gave up rather quickly as the files in native/jni/classpath/primlib.[ch] seem to be rather void of explanatory comments, unfortunately. Grepping a bit around, it seems that it is unused in GNU Classpath, except for a single test, so I'd like to propose removing the primlib files from the sources along with the test. The files have seen just cosmetic and warning cleanup patches since their introduction. CC:ing Brian as he introduced them into GNU Classpath. Haha, funny it was actually John Keiser who introduced them. I show up because they were moved by me from their original location. I'm guessing this library was never used as John originally intended. Looks like some primitive type wrapper library. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Build and install without compiling java files?
On Thu, 2004-11-25 at 14:52, Michael Koch wrote: Am Donnerstag, 25. November 2004 19:35 schrieb Archie Cobbs: Michael Koch wrote: Assuming that this glibj.zip has the default Configuration.java and that is acceptable to the builder, why not provide a way to configure the build so you can just install glibj.zip as shipped? I think shipping a glibj.zip is not good. This should be removed from source tarball. Just curious.. why do you say that? I think there is no real need for it. It just bloats the source tarball. All sources are included inside to tarball to build it. Actually there is a pretty good reason to have the built classes distributed. The fact is that results vary according to which free and broken compiler you use to compile Classpath. None of them really pass Jacks that I know of. New 1.5 features aren't supported anywhere in a production ready and easily available compiler (as in is already part of a popular distribution), and we thankfully don't include those in the main branch yet. And actually including the glibj.zip is a very popular thing, at least from actual users. For the rest of us who would rather change or fix things it matters very little. Again this can probably be solved by someone with a lot of initiative making something available to easily integrate into jpackage environments or the like to handle the actual distribution requirements vs. the developer requirements to only ship source and no binaries. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
On Mon, 2004-11-15 at 05:44, Dr. Torsten Rupp wrote: Dear Mark, (and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.) When I remember right, the agreement was not to remove the macros completely, but instead make them into alias-names for target specific implementations of some OS-function. I believe Mark is correct here, we agreed to turn the macros into real functions for debugging purposes. And we'll probably use autoconf feature testing for portability. Getting to the alias-names of some OS-function is a first step and then convert them into real functions. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: ANNOUNCE: japitools 0.9.5 released
On Thu, 2004-11-11 at 14:17, Stuart Ballard wrote: * A new bytecode reading implementation from Jeroen Frijters to replace Jode. This vastly reduces the amount of code because it only reads and understands the bits of metadata we actually need, where Jode was part of a larger system that needed more information. This code also fixes a Miranda Methods bug in the Jode implementation. I'm somewhat interested in this for use in javah/javap, to replace gnu.bytecode which again does way more than is necessary. Is it suitable Jeroen and would you be willing to put it in Classpath tools or let me do it? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: japi note
On Tue, 2004-11-02 at 15:06, Stuart Ballard wrote: C. Brian Jones wrote: Stuart, I've taken the serialization tests I once gave you to add to japitools and added those to a module in Mauve called 'serialization'. A new Mauve module seems like a good home for the japitools project to me, but it's up to you... and Tom too. So would you suggest I take serialize and serialcompat out of japitools along with the references on the webpage? Yes, you can point people at the Mauve module if they are wondering where it went. Perhaps with the work on Mauve's framework it will be easy to run this as part of the regular Mauve test set in the near future. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
On Fri, 2004-10-08 at 06:39, Mark Wielaard wrote: The JCP also doesn't require the (final) specifications to be provided under a click-wrap. As these JSR's show it it perfectly fine to publish the specification, reference implementation and test compatability kit in the public domain. (Unfortunately, as you point out most JSRs don't do this at the moment. Please tell specification leads about the option to do everything in the open.) Getting specs open doesn't appear to be too hard but I've had trouble in the past getting TCKs open because there is some feeling that in order to assure compatibility that one prevent inspection of TCK source. The theory is this makes it more difficult to fake the TCK results which prove or disprove compatibility. The practice I've seen is to let people self-certify. All of these experiences were from my involvement in OSS/J. I don't buy these arguments. People could fake the results with a binary TCK as well. People doing implementations have no motive to not pass the TCK as customers (or users) would then find their code which worked with the RI suddenly doesn't work on xyz despite claims of compatibility. Despite this, business types just don't get it sometimes and in some cases the geeks aren't running the show behind the JSR. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: japi note
On Thu, 2004-09-30 at 11:56, Stuart Ballard wrote: Michael Koch wrote: Its possible again afaik. Another option would be to make it its own CVS module in classpath or cp-tools. I won't object if this is the consensus of others, but my own preference is to keep japitools as a separate project. It isn't only useful for Classpath or classpath-using projects - it can be used to compare independent implementations of *any* API. For example, any of the standard extensions that Sun develops that aren't part of the core Java platform. The developers of various J2EE components might be interested too, for example. Since it does, indeed, seem like Savannah is accepting new registrations again, I've put in one for japitools. Stuart, I've taken the serialization tests I once gave you to add to japitools and added those to a module in Mauve called 'serialization'. A new Mauve module seems like a good home for the japitools project to me, but it's up to you... and Tom too. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: automated mauve reports
On Sun, 2004-07-18 at 12:32, Roman Kennke wrote: Am So, den 18.07.2004 schrieb Mark Wielaard um 16:36: Hi Roman, On Sun, 2004-07-18 at 00:23, Roman Kennke wrote: http://ontographics.com/classpath/report-index.html I still have to improve the script. When it is perfect, I will make a cron job out of it, which will fetch the current cvs of mauve and classpath and generate these reports on a nightly basis. Wow! Very useful! Would it be hard to adapt your script so it reports the number of passes/fails for each level? e.g something like: dir PASSFAIL awt 603 123 beans78 8 io 120 67 Yes, that should be no problem. I will modifiy the script, so that it generates the HTML on the fly, which enables additional options, like filtering FAIL/PASS and maybe some more. BTW. The original japhar had a mauve parsing script which is now also used by kaffe: http://www.kaffe.org/cgi-bin/viewcvs.cgi/*checkout*/kaffe/developers/mauve-html-gen.pl?rev=HEAD Why is this script not in action? /Roman You may find something useful from these scripts as well, see http://www.haphazard.org/~cbj/classpath/automauve-1.0.tar.gz. I like how what you've done is starting towards that consolidated japi/mauve view I mentioned a couple of weeks ago. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Question on autoconf
On Mon, 2004-07-19 at 21:19, Dan wrote: Hi, Im using GNU Classpath (0.09) with JamVM on an embedded linux board. I don't need the awt/swing classes (and a bunch of others) and thought I would remove them from the build to same on space. It's really simple, modify lib/standard.omit for the regex of your choice. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath API version
On Fri, 2004-07-09 at 10:24, Archie Cobbs wrote: Robert Schuster wrote: What I want to say is: IMHO since Classpath already stepped into the 1.4 land it would not a good idea to primary support previous JDK versions. Classpath had to rip classes, methods and signatures off to be compatible with 1.4 again. If Classpath would officially head for full 1.4 compatibility this would a much better. Java 1.5 is a nice 'natural' barrier for adding its features because it needs a different syntax and therefore tools ... Sounds good to me. I vote we say we strive for 1.4 compatibility but also say we don't promise everything in 1.4 is implemented yet. It would be nice if Mauve/japi/stck could essentially be used to indicate what's there and what works in a consolidated view, well actually better to indicate the holes really... but anyway. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: How to seperate the compilation of C source code and Java source code of CLASSPATH?
On Tue, 2004-07-06 at 06:04, Dalibor Topic wrote: Ming Chen wrote: Hi, I have some problem to compile the CLASSPATH in Debian Linux/ Xscale, it used up the memory (3G). Let me guess ... jikes? Known bug in jikes. Avoid using it to compile classpath on arm-linux. Use another compiler. What is _the_ best and single free software java compiler to get behind and use these days? Which one has the best jacks test suite score? Thanks, Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
[Fwd: How to participate to your project...]
---BeginMessage--- Hi, Your project draw my attention out. I would like to be part of it. I've checked some tasks you needed people to be working on, but it seemed they may be out of date (some should have been finished more than a year ago as it is written on the board). So I was wondering if could try myself on it. Here is a short overview of what I can do : I'm a french developper : - so I can translate docs or write some in english for you (it should be a good start to my mlnd so that I could better discover some parts of the project) - then I can write some java tests or pieces of packages I'll be waitin for informations Bye Hugo ___ Message sent via/by Savannah http://savannah.gnu.org/ ---End Message--- signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Question on java.lang.Thread and final static int constants
On Mon, 2004-05-10 at 12:46, Tom Tromey wrote: Steven == Steven Augart [EMAIL PROTECTED] writes: Steven So, for the purposes of GNU Classpath's AWT code Steven (--portable-native-sync), is it reasonable to assume that they are, Steven indeed, 1, 5, and 10, or should the implementation check the values at Steven run time and cache the results? Since the Java language spec Steven expicitly allows the java source-to-byte-code compiler to inline the Steven values of static final constants, presumably the values can never Steven change in the future Yeah, in theory the values can't change. In practice, Sun has broken this once or twice in the past, though honestly I doubt they would bother changing these particular values. I'd say in a case like this you can do whatever you like, provided the result is documented. There is precedent for native code to simply #define these constants to avoid expensive lookups so feel free to do the same here. Could probably add it to the cp-tools version of javap even if it isn't there. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
On Tue, 2004-05-11 at 20:41, Per Bothner wrote: Steven Augart wrote: Michael Koch wrote: What if someone wants to port GNU classpath to an Operating System with totally different semantics like Windows ? If someone does that kind of port, he'll have more problems than just than the size of a file descriptor. I think Michael was being ironic. I haven't checked the current Classpath, libcj (which shares most of its code with Classpath) certainly supports Windows. I think the cleanest solution is to allows FileChannelImpl to be subclassed, or to uses different classes that implement FileChannel. But the current code works fine for now. For JNI performance I don't see any reason not to not to have the Java code pass the native fd field to the native method - just realize that if/when Classpath gets ported to a system that uses 64 pointers we may have to redo things. One solution may be to use the Posix API. The Posix IO functions (open/read/write etc) are available on Windows. I don't know why they're not used - performance? I don't really know, Orp developers used the Posix stuff in Windows for implementing Classpath's JNI methods some time back. Then some folks in GCJ land decided they'd be better off using the native Windows API. The changes are pretty small to use Windows Posix API vs what we do today. Is the current JNI code compatible with a 64 bit system? Can you open a file larger than 4G or whatever it is and use the whole thing? Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: performance problems with classpath 0.09 on Jikes RVM
On Fri, 2004-05-07 at 14:21, David P Grove wrote: Here's some more data: dynamic count of JNI functions executed in 1 iteration of jack size 100 on classpath 0.08 and classpath 0.09 with Jikes RVM. Note the massive number of calls from FileChannelImpl.get_native_fd 2/3 of which are unnecessary. Unless I hear that someone else has already fixed it, I'll put a patch together in the next couple of days. Yes please do. I think it's part of the hacking guide, but fieldID and methodID lookups are supposed to be cached where possible. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: syntax error near unexpected token `PKG_CHECK_MODULES(GTK,
On Mon, 2004-04-19 at 06:26, Dalibor Topic wrote:
Dalibor Topic wrote:
Dalibor Topic wrote:
Howdy,
I ocassionally try out classpath's configury mechanism, and it always
breaks down on me, so I must be doing something really 'special' to it.
I've tried the autogen.sh script too, preparing to reach for the brown
paper bag ...
but nope, that still breaks in the same way.
Something tells me that the PKG_* stuff is in pkg.m4, but for some
reason it does not get picked up aut either autoreconf, nor autogen.sh
The reason is that they are not being told where to look for the
thrid-party m4 files. No idea if that's something particular to my setup
(am 1.8.3, ac 2.59, libtool 1.5.6), but an
${ACLOCAL} -I .
in autogen.sh fixes it, as far as I can tell.
Adding a AC_CONFIG_MACRO_DIR([.]) in configure.ac doesn't seem to work
though. I haven't tried moving the m4 files into their own subdirectory,
though.
cheers,
dalibor topic
For some reason, yet unknown, Michael put this macro in pkg.m4 instead
of adding it to acinclude.m4 which is where all our local macros go.
Why it would be there, and augogen.sh would not have the appropriate
arguments to pick it up, is beyond me. It isn't a standard file name, I
checked the 1.7.8 autoconf manual. It needs to be moved to
acinclude.m4.
As to the configure options you need, it's supposed to be just
--disable-jni for what you want. However, the link between this option
and the gtk-peer option may be broken, you may need to specify both.
Brian
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Support for installation of glibj.zip and separate class files
On Thu, 2004-04-08 at 16:36, Michael Koch wrote: Hi all, With my big NIO commit I accidently commited the first part (the parts in configure.ac) for this patch and so I decided to commit it fully. We now have two options for installing our classes --enable-glibj installs glibj.zip (enabled by default) --enable-class-install installs all classes as separate files as needed by jamvm and sablevm (disabled by default) Both options are indepedently from each other. You can even disable both options but this does not make really sense. I'm not really satisfied with the name --enable-class-install. If someone finds a better name please shout at me. Michael I thought this logic was already in lib/Makefile.am anyway without the extra config option? Maybe that was an old version I was thinking about. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Configuration class and --enable-native-sync
On Tue, 2004-04-06 at 17:56, Archie Cobbs wrote:
Steven Augart wrote:
How about including all the build options in the Configuration class?
public class Configuration {
public static final String BUILD_OPTIONS = {
--enable-jni, --enable-load-library, ...
};
...
}
Perhaps we could include even the build options that automatically had
their default values set? So, even if the user had not explicitly
stated --enable-jni, we would still include --enable-jni, since
it's the default?
I'm trying to guard against the defaults possibly changing. If we
were to, for example, one day make Classpath's default be
--enable-portable-native-sync, I'd still want Jikes RVM to correctly
read that the Classpath installation had that feature enabled.
Agreed.. in general more info is better. E.g., why not also throw in
the output of uname -a, the classpath version, etc.
I'm not sure if the intention is to be able to tell prior to runtime
what the options were or if it is only necessary during runtime. So it
would be easy enough to add something to the Configuration class, but I
thought folks wanted to not abuse it too much. Another option perhaps
even in addition to is to simply add these to standard classpath
specific system properties at startup for use via System.getProperty()?
--
Brian Jones [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: generated files in CVS?
On Mon, 2004-03-29 at 01:35, Michael Koch wrote: Am Sonntag, 28. März 2004 21:29 schrieb Etienne Gagnon: Mark Wielaard wrote: Unless running with --force the auto* tools shouldn't override these files so normally you won't see any diffs when following the HACKING instructions. But there is no particular reason. So please remove them. Make sure to update the HACKING file and send a message to the list how to regenerate these when you do. I have added a ./autogen.sh script that calls the auto* tools with the appropriate arguments, and updated the HACKING files accordingly. So, those of you that cvs up, simply type: ./autogen.sh after updating. I really wonder if this primitive script really works on some non-linux platforms. I will commit an improved version later. Why not just use autoreconf which is usually installed with the autotools. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
On Thu, 2004-03-25 at 13:53, Tom Tromey wrote: Etienne == Etienne Gagnon [EMAIL PROTECTED] writes: Etienne [talking of normal package tree: would anybody object to moving the Etienne whole tree to an src/ subdirectory, as it should be done in such Etienne a big project?] Personally I'd prefer no change, since moving stuff around is a pain with cvs, and since there doesn't seem to be a really big benefit from it. Assuming savannah moves to arch or subversion we should be able to move directories around easily at that point. CVS makes it a bit of a hassle as well as losing all historical data unless you get a CVS admin to do it on the server side. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Debugging acronyms
On Sun, 2004-03-14 at 07:12, Sascha Brawer wrote: (b): As a client-side API, any JDI implementation should run on all VMs. A free application that depends on JDI is JSwat, a GPL-ed graphical debugger. Right now, there are also other things missing from Classpath that would prevent JSwat from running on a free JVM, but with Swing coming, JDI will probably be the largest missing part. http://www.bluemarsh.com/java/jswat/ It may be easier to test/work with JMP, http://www.khelekore.org/jmp/, since it is written in C and uses GTK for a GUI interface. Of course at some point working with jswat would be sweet. Assuming gdb could work with some sort of plugin then that would make ddd work as well though I think you could write a 'jdb' type program to make that work as well if getting gdb to work is a complete pain. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.08 released
On Sat, 2004-03-13 at 13:28, Mark Wielaard wrote: Hi, Etienne, On Sat, 2004-03-13 at 18:08, Etienne Gagnon wrote: While importing Classpath into sablevm-classpath, using the classpath-0_08-release tag, I notice that you are resuscitating some files such as ./configure.in. Why isn't this file left into the Attic? Maybe it's just a tagging mistake. A good test, for a tag, is to do: cvs export -r tagname -d test classpath then compare: diff -r classpath test | sort | less So, maybe a thing to fix in 0.09? ;-) [It's considered bad practice (and it is painful in CVS) to change an existing tag. So, I recommend not changing the release-0_08-release tag.] Drat. Sorry about that. Yes, I made a mistake while tagging. I had tested everything, up to and including a complete make distcheck and a mauve and vte test run on another clean machine, but then went back to my development machine for the final cvs tag. And of course did it in the wrong working directory... I had hoped that I had done the re-tagging correctly, but forgot about the old files. I should have send a warning to the list. Thanks for the list of files erroneously tagged. I looked at the cvs documentation and it seems that you can remove tags from Attic files using rtag -a but I am a bit afraid that might mess up the tagging even more. I promise to do better for 0.09. For now please check a cvs checkout against the official classpath-0.08.tar.gz file. Or does someone know the magic command to make it all right in the repository? Thanks, I would probably go ahead with the rtag -a. I think just make sure in the future to use rtag to avoid tagging local working directory files. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Imported gnu.regexp and java.util.regex wrappers
On Sun, 2004-03-07 at 19:00, Mark Wielaard wrote: Hi all, I finally imported gnu.regexp and added java.util.regex wrappers for it. At the moment our gnu.regexp is the same as the original gnu.regexp version, except for a few files and added copyright notices. Maybe I should have mentioned it earlier (list is slow), but Dalibor Topic submitted wrappers for gnu.regexp to the list a year or so ago you could have used since Kaffe has been doing this for a while. Maybe they have fixed the 'bugs' already. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Free Java, the sequel
On Fri, 2004-03-05 at 04:35, Jens Lehmann wrote: Chris Gray wrote: This is bizarre. IBM already has an open source version of Java (JikesVM), but perhaps Rod Smith is not aware of that. The question is, if IBM is allowed to open source their Java implementation. Their AIX/Linux/etc. JVM is Sun's source code ported to their operating systems. In some cases there is no port, the only change is that instead of using hotspot IBM uses instead their own JIT technology. The licensing must be fairly strict, otherwise they would have not purchased the other clean-room Java implementation that the JikesRVM initially used before using Classpath. I'm of the opinion that no one is making a great deal of money off of the work one puts forth on the core language and libraries. It's like spending money on creating a new C compiler when what you really want to do is build a wireless router. That is sort of how I became involved with Classpath actually. I wanted to use Java but at every turn I was greeted with bugs and problems I was not allowed to fix, and even if I did I couldn't give my friends those fixes so my applications would work on their systems. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: [Article] Sun Fires Back over Open Source Java Accusations
On Wed, 2004-02-18 at 05:12, Robert Lougher wrote: Hi, A quite interesting response. However, it's funny hearing Phipps slam IBM so much (considering their Linux technology center and support of Jikes). He used to be IBM's Java evangelist (based in Hursley, UK) before defecting to Sun. Favourite phrase was Tsunami... I was recently in a small room with this man. He makes some fair points in response to Eric who really should have come here first before firing off his open letter. Rather than the rise of free software alternatives for Java I think the thing which could push Java along the path of openoffice, netbeans, etc. would be a wildly successful C# conversion of older Java software resulting in significant declines in the Java rank and file. I think Classpath isn't really looking to be branded 100% Java as much as we'd like to know that some combination of Classpath and JVM can pass the TCK with flying colors, in fact that the GNU Java platform can pass all applicable TCKs and our own tests. There is still a system integration project left to be done, to pull together the compilers, the tools, the JVM, the standard libraries and extensions and to make them work together using similar naming and arguments for programs, etc. and make the whole thing installable in one go instead of pulling bits and pieces together from across the globe. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Serialization compatibility testing
All, I've been working a little lately on some tools I once added to japi for serialization compatibility testing. I'm pretty close to having something useful, just wondering if anyone is interested in using these for checking compatibility? Here's the list of the files that are the same when compared to Sun's JDK 1.4.1 for Kaffe 1.1.3. These .ser files are object serializations. I've omitted the things that are missing in Kaffe or exist in Kaffe but not the JDK. The list of classes the tool attempted to serialize is based on Java 1.4 documented serializable classes. I'm looking forward to adding a tool to attempt to read objects written by Sun's JDK, from version 1.1 through 1.4 into the appropriate object type. Eventually I'll be able to combine these building block type tools to comprehensively state serialization compatibility for a JVM to Sun's JDK. I'll also have fun checking Sun. :) I've thought about trying to add this to Mauve. Thoughts? New module? kaffe113/java/security/Permission.ser identical kaffe113/java/security/Provider.ser identical kaffe113/java/security/BasicPermission.ser identical kaffe113/java/security/PermissionCollection.ser identical kaffe113/java/security/IdentityScope.ser identical kaffe113/java/security/Signer.ser identical kaffe113/java/security/SecureRandomSpi.ser identical kaffe113/java/security/cert/CertPath.ser identical kaffe113/java/security/cert/X509Certificate.ser identical kaffe113/java/security/cert/CertPath$CertPathRep.ser identical kaffe113/java/security/cert/Certificate.ser identical kaffe113/java/security/cert/Certificate$CertificateRep.ser identical kaffe113/java/security/Identity.ser identical kaffe113/java/net/SocketAddress.ser identical kaffe113/java/util/TreeSet.ser identical kaffe113/java/util/LinkedList.ser identical kaffe113/java/util/Stack.ser identical kaffe113/java/util/TimeZone.ser identical kaffe113/java/util/Hashtable.ser identical kaffe113/java/util/TreeMap.ser identical kaffe113/java/util/BitSet.ser identical kaffe113/java/util/IdentityHashMap.ser identical kaffe113/java/util/Calendar.ser identical kaffe113/java/util/EventObject.ser identical kaffe113/java/util/Vector.ser identical kaffe113/java/text/DateFormat.ser identical kaffe113/java/text/Format.ser identical kaffe113/java/text/NumberFormat.ser identical kaffe113/java/awt/Insets.ser identical kaffe113/java/awt/dnd/MouseDragGestureRecognizer.ser identical kaffe113/java/awt/dnd/DragGestureRecognizer.ser identical kaffe113/java/awt/CheckboxGroup.ser identical kaffe113/java/awt/GraphicsConfigTemplate.ser identical kaffe113/java/awt/Dimension.ser identical kaffe113/java/awt/Rectangle.ser identical kaffe113/java/awt/GridLayout.ser identical kaffe113/java/awt/Point.ser identical kaffe113/java/awt/ComponentOrientation.ser identical kaffe113/java/awt/image/renderable/ParameterBlock.ser identical kaffe113/java/awt/color/ColorSpace.ser identical kaffe113/java/awt/Component.ser identical kaffe113/java/awt/MenuComponent.ser identical kaffe113/java/lang/Integer.ser identical kaffe113/java/lang/VirtualMachineError.ser identical kaffe113/java/lang/Byte.ser identical kaffe113/java/lang/Short.ser identical kaffe113/java/lang/Character.ser identical kaffe113/java/lang/Float.ser identical kaffe113/java/lang/Double.ser identical kaffe113/java/lang/String.ser identical kaffe113/java/lang/Number.ser identical kaffe113/java/lang/Long.ser identical kaffe113/java/lang/StringBuffer.ser identical kaffe113/java/beans/PropertyChangeSupport.ser identical kaffe113/java/beans/PropertyChangeEvent.ser identical kaffe113/java/beans/beancontext/BeanContextEvent.ser identical kaffe113/java/beans/beancontext/BeanContextServicesSupport$BCSSServiceProvider.ser identical kaffe113/java/beans/beancontext/BeanContextSupport$BCSChild.ser identical kaffe113/java/beans/beancontext/BeanContextServicesSupport$BCSSChild.ser identical kaffe113/java/beans/VetoableChangeSupport.ser identical kaffe113/java/rmi/server/RemoteStub.ser identical kaffe113/java/rmi/server/RemoteObject.ser identical kaffe113/java/rmi/server/RemoteServer.ser identical kaffe113/java/rmi/activation/Activatable.ser identical kaffe113/java/rmi/activation/ActivationGroup.ser identical kaffe113/java/io/ObjectStreamException.ser identical kaffe113/javax/rmi/CORBA/ClassDesc.ser identical kaffe113/javax/rmi/CORBA/Stub.ser identical kaffe113/javax/naming/ldap/LdapReferralException.ser identical kaffe113/javax/naming/StringRefAddr.ser identical kaffe113/javax/naming/NamingSecurityException.ser identical kaffe113/javax/naming/NameClassPair.ser identical kaffe113/javax/naming/RefAddr.ser identical kaffe113/javax/naming/ReferralException.ser identical Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability
On Fri, 2004-01-09 at 03:45, Sascha Brawer wrote: Tom Tromey [EMAIL PROTECTED] wrote on Thu, 8 Jan 2004 17:48:59 -0700: [standard pluggable JIT interface] This would indeed be quite nice, IMHO. Language choice for API. The obvious choices being: C lowest common denominator C++ next-to-lowest common denominator :-) provides some abstraction benefit, maybe Java using our own tools... Going off on a tangent, are there other interfaces where reuse may be possible such as JVMPI, JPDA, and the wire protocols for those... if the hooks into the free JVMs are somewhat standard? Essentially Sun wrapped the native interfaces like JVMPI with Java in JPDA which made the tasks of writing profilers or debuggers somewhat easier. So these Java wrappers should be the same if written to the C interfaces that pre-existed JPDA but then all the JVMs need to support those interfaces. To what extent should Classpath provide parts of the debugging/profiling solution? Thanks, Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: The status of Classpath (in brief)
On Sun, 2004-01-04 at 18:15, David Holmes wrote: Mark, My only comment is that a stated goal of at least as complete as 1.1 is no longer adequate. The Java platform is a moving target and 1.5 is on the horizon. I recognise that there are too many packages to make a blanket statement of support - otherwise we'll be at 1.6 or 1.7 before Classpath 1.0 can get out the door. Perhaps it is time to look at breaking Classpath down into package subsets and aim for 1.2 compatibility for the core packages (lang, util, ???) and define other packages independently of the core eg nio must obviously aim for 1.4 compatability. I suspect that the above doesn't actually require many code updates as I think much of the core is already around 1.4 (maybe enough that 1.3 could be the stated level for the core?). I think changing the 1.0 goals at this point would delay the release of 1.0 and any subsequent releases containing the 1.2, 1.3, or 1.4 compatibility you mention. With the exception of Swing and Java 2D it seems as though those releases would follow quickly on the heels of 1.0. -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Serialization #5
Guilhem Lavaux [EMAIL PROTECTED] writes: Dalibor Topic wrote: Salut Guilhem, @@ -442,18 +443,46 @@ String field_name = this.realInputStream.readUTF (); dumpElementln (field_name); String class_name; - + +// There're many cases you can't get java.lang.Class from +// typename if your context class loader can't load it, +// then use typename to construct the field +// GL = No. You lose the capability to access the class loader. +// Type resolution must be done here. If it is an object we +// create the class just here if it is something else we delegate +// to TypeSignature. Just rewrite the comment, don't discuss it in another. ;) Ok. :-) Fixed in the next commit. Cheers, Guilhem. Guilhem are you going to be or have committed these to Classpath CVS? Thanks, Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: New homepage
Mark Wielaard [EMAIL PROTECTED] writes: Hi, On Thu, 2003-11-27 at 16:57, Mark Wielaard wrote: [UPDATE: It appears I broke it :( I am trying to figure out what I did wrong. Help wanted...] Somehow this fixed itself. Strange. I have been banging my head against a wall for an hour and apparently some cron job then kicked in and auto-fixed the symlinks or something... Anyway. Please check out Patrik his work: http://www.gnu.org/software/classpath/ Some of the links are broken that shouldn't be. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests, Documentation
Tom Tromey [EMAIL PROTECTED] writes: Mark Would someone be willing to try to set that up? Mark Could someone host the auto-generated documentation for now? Last time I ran javadoc on classpath, I got tons and tons of errors. Do we still get that? I could set things up to post the pages to gcc.gnu.org nightly, just like we do for the classpath comparison. This could be expedited if somebody sent a simple script to generate the pages. Is gjdoc ready for this sort of work? Here's and old script, I think it needs some work. Brian -- Brian Jones [EMAIL PROTECTED] classpath-gjdoc Description: Binary data ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] small fix for ServerSocket close
Michael Koch [EMAIL PROTECTED] writes: I think it would be really nice i you could commit this to libgcj too. This class is totally merged. Just out of my curiosity, how does that whole process work? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: reformatting: hacked jalopy available
Tom Tromey [EMAIL PROTECTED] writes: * I didn't add a GUI for the new options I added; I just set up their defaults to be what we'd like. This is easy enough to change later if needed. Ok, I think we should make the GNU option do what we like if someone does hack on the config piece. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
Patrik Reali [EMAIL PROTECTED] writes: Hi! Has anybody already tried to import classpath under Eclipse? I tried to create a project and import the files, but then Eclipse is far too intelligent: * gnu/java/lang classes are imported into package java.lang * vm/reference/java/lang classes are imported into package vm.java.lang Probably I'm just doing something wrong (I'm using Eclipse 3.0M4) Never tried it. Most IDEs do not expect people to try to work on core java, especially not a different core java. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: CVS configure.in is broken
Patrik Reali [EMAIL PROTECTED] writes: The problem with --disable-gtk-peer is that it works for the compilation, but GTK must be installed anyway, otherwise aclocal fails. In practice, I would have to install GTK-2 just to be able to configure the package _not_ to use GTK-2. To avoid this, I used to remove the GTK, GLIB, and LIBART stuff in the configure.in file (from line 121 to line 148) before aclocal and eventually configured classpath with --disable-gtk.peer. It's a hack , but it works for me. Right, as a rule we don't check in generated files. To avoid this problem we'd have to check in the generated aclocal.m4. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: installing classpath
Michael Koch [EMAIL PROTECTED] writes: afaik only specifiers like 'gcj' or 'jikes' are allowed, not executables with complete path. I may be wrong but last I tried it it didnt worked with full path. You should be able to --with-gcj=/usr/foo/gcc/bin/gcj and similar for jikes. If it doesn't work it is a bug. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard [EMAIL PROTECTED] writes: Incidentally, the link for the jgss package is also misleading, as the RFC doesn't appear to contain any implementation of the package in question (I scanned all the way to the end, the only source code was examples of usage) and even if it did, the license on the RFC is not free (it does not allow modification of the RFC itself, although certain kinds of derived works are permitted). Both of the links are apparently misleading. Each points to standards group or specification. The RFC contains better javadoc than we'll ever have concerning each interface, class, and method since you indicate that text is non-free. Chapter 6 should allow someone to pretty easily create the 3 interfaces and 5 classes, some of which are abstract. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Bryce McKinlay [EMAIL PROTECTED] writes: As far as I know, the OMG doesn't make any software - just specifications. Since I'm allowed, the javartf Source.zip is now online at http://www.haphazard.org/~cbj/classpath/javartf/Source.zip. Even so, the license makes it impractical for the project. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard [EMAIL PROTECTED] writes: Mark Wielaard wrote: I think you are right. It is not a good idea to provide links to software of which we cannot (currently) guarantee that it is Free Software. Could you provide a patch (source is in CVS module classpath under docs/www.gnu.org). Sure, I'll try to do this in the next couple of days. Incidentally, the link for the jgss package is also misleading, as the RFC doesn't appear to contain any implementation of the package in question (I scanned all the way to the end, the only source code was examples of usage) and even if it did, the license on the RFC is not free (it does not allow modification of the RFC itself, although certain kinds of derived works are permitted). (Note that I'm not suggesting that that would prohibit linking to the RFC in general, as the RFC is not software - just that if software source code *were* included in the RFC, that software would not be free). Should my patch remove that link as well? This sort of religious zealotry is not helpful. People wishing to implement free versions should know where to go for the standard, the RFC, etc. If it is not possible to link in this context then the FSF web server is useless and I'll have to consider moving http://www.classpath.org/ elsewhere. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard [EMAIL PROTECTED] writes: There is a link to http://www.omg.org/ on Classpath's homepage, referencing it as a provider for free core packages for the org.omg packages. I have a few questions about this: 1) I can't actually find any downloadable implementation of the org.omg packages in the omg site. It might be helpful to provide a more direct link to exactly where the code can be found. They are on the ftp site, probably not obvious. b) If they are free but aren't GPL-compatible, shouldn't there be a prominent warning because (if I understand the issues correctly) that would make anything that's simultaneously a derived work of Classpath and the org.omg packages completely unredistributable? Basically they will never be free to modify because the entire point of the OMG standard is these interfaces DO NOT CHANGE or change only as the standard evolves at the whim of the standards body. The GPL doesn't allow compatibility with licenses that do not permit modification. All of that said, I pursued getting the OMG responsible people to change the license and I think they saw why we needed this and at least in some sense were sympathetic but the overriding concern is that of interoperability and hence there was no change. It doesn't mean that going back to them now couldn't change the appropriate minds just that I didn't get very far except that it was on the agenda for one of the quarterly meetings as far as I know and I never got another response. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
Guilhem Lavaux [EMAIL PROTECTED] writes: If there is anything I can personally do to make sure the contributions from kaffe developers make their way back into Classpath, I'd appreciate hearing about it. I guess we should just talk to each other more often ;) Other than more people with more time to spend on reviewing and commiting patches, I don't know. I find it a tad difficult to evaluate some patches without test cases. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Question] j2ee, classpath, kaffe.
jsona laio [EMAIL PROTECTED] writes: Hi, Is there anyone/institute who ever developed application following j2ee spec that runs on free software such as kaffe and classpath? Because lately I involve a project that is going to be developed through free software. So I'm trying to evaluate such solution would be possible or not. (Though I know there're other solutions other than java; yet, first, I'm not familiar with other language; second, middleware is my consideration this moment.) I appreciate any suggestions, Sincerely. I don't know if there are any success stories with running JBoss yet. Definitely would be very cool. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Fwd: Alan Moore assigns past and future changes
---BeginMessage--- cc - maintainer name: Alan Moore email: [EMAIL PROTECTED] Which files have you changed so far, and which new files have you written so far? changed: RE.java, REException.java, new: MessagesBundle.properties ---End Message--- -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: RFC: Spin Java petition
Arnaud Vandyck [EMAIL PROTECTED] writes: Hi, I've just read an article on Newsforge: http://newsforge.com/newsforge/03/10/02/1240243.shtml?tid=3 And in a comment, I saw this reference: http://www.petitiononline.com/spinjava/petition.html I copy the text below. I did not sign the petition right now because I'd like to have your comments before doing it (or not!) ;) Sun has a lot of reorganization to do in order to stop bleeding cash each quarter. I don't really care about this petition because what would really useful is for Sun to 'let go' of Java by releasing the core development kit/runtime under a free software license as defined by the FSF; hopefully something gcj could use. They could actually just release under SCSL and BSD for example, continue to drive the platform from industry perspective via JCP and perhaps lighten up the resources devoted to the core platform. But don't hold your breath, the IP is probably considered too valuable. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
Mark Wielaard [EMAIL PROTECTED] writes: If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Please leave the stub methods in java.awt.peer.*/gnu.java.awt/peer.*, thanks. Feel free to make them do whatever you'd like. :) Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [patch] Re: HashMap putAll/putAllInternal bug
Stuart Ballard [EMAIL PROTECTED] writes: Dalibor Topic wrote: Not attached here ;) I already resent it but just in case that didn't make it through, I've re-attached it here. Could you give it spin on kaffe from CVS? It uses Classpath's collection classes. It applies cleanly to Kaffe CVS (of course) and passes all 144 make check tests; I also confirmed that it does have the desired behavior of allowing nrdo's first pass to run unmodified on Kaffe and generate correct results. If this gets accepted (and barring any problems in the second phase, which is mostly pretty simple JDBC) I can put nrdo on Savannah! Woo! Cool, don't want to hold you up on that too much. Wondering how Sun's impl makes a copy of the given Collection while avoiding copying an object being modified in another thread. Anyone know? I think the Iterators are supposed to throw exceptions when this occurs too. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Ingo Prtel [EMAIL PROTECTED] writes: Hi Sascha, Sascha Brawer wrote: Ingo Prtel [EMAIL PROTECTED] wrote on Tue, 23 Sep 2003 16:56:23 +0200: I would like to again propose a standard NYIException to be used in Classpath. [...] package gnu.org.classpath; Are you sure about this package name? This should be package gnu.classpath; public class NYIException extends UnsupportedOperationException I'd favor NotYetImplementedException. Class names tend to be very verbose in Java, and IMHO it would make sense to follow that style. Not sure we even need the extra exception type, just finding all the spots to throw the UnsupportedOperationException and doing that would probably be more than enough. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath - javax.sound implementation - which library?
Mark Wielaard [EMAIL PROTECTED] writes: If we want to distribute it as an integral part of GNU Classpath then making sure that all code is assigned to the FSF is the preferred way to go. But there are other ways we could package things. So the best course of action would seem to be to have Mark contact them about contributing their code to Classpath. I would fully support such a move. As soon as I have tried it out (might take a couple of days) I will contact them about how best to work together. It would be nice to get the javax.sound interfaces, etc. donated even if their system remained theirs to maintain and distribute. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
Tom Tromey [EMAIL PROTECTED] writes: Brian == Brian Jones [EMAIL PROTECTED] writes: Brian Bug: Printer Java: GNU brace style does not indent beyond braces Brian http://sourceforge.net/tracker/index.php?func=detailaid=716393group_id=45216atid=442212 I tried adding gnu-style indent to jalopy today. Unfortunately the result dies while trying to parse our javadoc. So, I'm giving up. I can send my hack if somebody wants it. The real GNU.xml style file is attached to the above PR. Go ahead and send my way, I'm starting to play with it too. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Sascha Brawer [EMAIL PROTECTED] writes:
Brian Jones [EMAIL PROTECTED] wrote on Tue, 23 Sep 2003 00:28:16 -0400:
A grep through the source confirms many complaints about Sun not
[...] providing a standard means of getting at the
available encodings.
They have added this with 1.4. See
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html
Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
looks like the nio versions could be used?
Brian
--
Brian Jones [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
Tom Tromey [EMAIL PROTECTED] writes: Actually, there are a few problems with it. Bug: Printer Java: GNU brace style does not indent beyond braces http://sourceforge.net/tracker/index.php?func=detailaid=716393group_id=45216atid=442212 I couldn't find any more. Of course we could just hack these features and have a classpath only fork of jalopy. Maybe. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
David Holmes [EMAIL PROTECTED] writes: Hi everyone, The EncodingManager expects the system property file.encoding to be set but I couldn't find any indication of who was responsible for setting this property, when and where. Is this something that would just be set from the command-line? Or should it be determined by native code somewhere in the VM startup process? A grep through the source confirms many complaints about Sun not documenting this or providing a standard means of getting at the available encodings. ;) I think a JVM is supposed to provide this if they want. If you do nothing it should still work, but you can override the default if you want including using file.encoding.pkg to prepend to the default of gnu.java.io for where we attempt to find encoders/decoders. gnu/java/io/EncodingManager uses System.getProperty(file.encoding, 8859_1); java/net/URLEncoder.java uses System.getProperty(file.encoding, 8859_1); java/util/logging/XMLFormatter.java uses System.getProperty(file.encoding) and later defaults to UTF-8 if null, which seems to be an error either here or in the documentation in java/io/InputStreamReader.java. More confusingly we provide DecoderUTF8 and EncoderUTF8 which implies the EncodingManager would load on UTF8 rather than UTF-8. There is a hacking guide reference in Chapter 11. I can't connect to gnu.org currently so I can't link it. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath java/awt/AWTEvent.java minor documentation patch.
Do we need paperwork to commit all of Ricky's documentation patches? Thanks, Brian Ricky Clarkson [EMAIL PROTECTED] writes: Hi, I was browsing AWTEvent.java, and came across a couple of tiny grammatical errors. Please see the attached files 'diff', which is the output of diff original AWTEvent.java my AWTEvent.java, and 'diff_minus_u', which is the output of diff -u original AWTEvent.java my AWTEvent.java. Regards, Ricky. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
Tom Tromey [EMAIL PROTECTED] writes: I was just looking at the jalopy lists for any sign of life, and I found out that jalopy is going proprietary. So unless someone starts a free fork, I'm afraid we're left once again without a plausible way of getting an auto-formatter. Perhaps Etienne will write his now :-) Link to the bad news: https://sourceforge.net/mailarchive/forum.php?thread_id=2526002forum_id=8775 Looking at CVS now. I don't care much about most of the editor plugins. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
Etienne Gagnon [EMAIL PROTECTED] writes: Hi Tom Brian, Jalopy seems to fill the needs, on the technical side. We could take the latest Free snapshot available before it becomes proprietary to indent the code. The only worry I have is that it is not obvious to me if all the licenses of the various parts of jalopy are compatible. Have a look at: http://jalopy.sourceforge.net/dependencies.html The page incorrectly lists getopt and aelfred as GPL, instead getopt is released under the LGPL and aelfred under a license similar to BSD. This is a link to a late May message about the commercial release. August was a planned FCS but it's likely late. Nothing has been updated in available CVS since last November it appears to me. http://sourceforge.net/mailarchive/forum.php?thread_id=2463425forum_id=8775 Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath CVS not buildable
graydon hoare [EMAIL PROTECTED] writes: Michael Koch [EMAIL PROTECTED] writes: Am Donnerstag, 18. September 2003 10:54 schrieb Michael Koch: Hi Graydon, I saw that you commited gnu/java/awt/peer/gtk/GdkGraphics2D.java and other files into classpath. Unortunately this file has references to a class called GdkFont. But I can find no file defining the class GdkFont. Can you please fix this ? To be more exact I present here the jikes compiler output as there are more errors then the described above: goodness! I'm sorry. I didn't realize files were built as soon as they were added to classpath; I didn't touch the Makefile but it seems to do wildcarding. those files are incomplete, I just added them so others could see my work and play with it if curious. I've backed them out now. sorry. It uses 'find' to build the class list. You can add files you don't want in the build by modifying lib/standard.omit. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: HTML-Rendering engine written in Java?
Clemens Eisserer [EMAIL PROTECTED] writes: Hi there! Does anybody know a useable html-rendering engine completly written using Java and 100% free Software (e.g. GPL, LGPL)... I want to port such a library from AWT/SWING to SWT. All libraries I found were proprietary, so they arent useful at all for me :-( There might be something useful in the Jazilla project archive at mozilla.org. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: extended peers
Sascha Brawer [EMAIL PROTECTED] writes:
package java.awt;
import java.awt.Toolkit;
import gnu.java.awt.ClasspathToolkit;
public abstract class GraphicsEnvironment
{
private static GraphicsEnvironment localGraphicsEnvironment;
public static synchronized getLocalGraphicsEnvironment()
{
if (localGraphicsEnvironment == null)
{
ClasspathToolkit ctk;
ctk = (ClasspathToolkit) Toolkit.getDefaultToolkit();
localGraphicsEnvironment = ctk.getLocalGraphicsEnvironment();
}
return localGraphicsEnvironment;
}
}
I think you can store the reference as a Toolkit only. What parts of
our code would rely upon having a ClasspathToolkit with the additional
Font related stuff?
Brian
--
Brian Jones [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: --enable-portable-native-sync
John Leuner [EMAIL PROTECTED] writes: Did this perhaps break during the change from using GTK 1 to GTK 2? Perhaps the required function vector has changed? That is correct, it broke then and the person working on this over in GCJ land was going to rework/rewrite the threading stuff anyway so no one has looked into it other than we want to make this option the default eventually. --enable-portable-native-sync to run AWT code. This worked in classpath 0.05 but fails in classpath 0.06 with the following error message: GThread-ERROR **: The supplied thread function vector is invalid. aborting... Abort -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
Sascha Brawer [EMAIL PROTECTED] writes: Hi all, if the signature of a JDK method declares to throw some RuntimeException, should the Classpath do so, too? For example, java.awt.Toolkit.createButton declares to throw java.awt.HeadlessException in the JDK, but not in Classpath. HeadlessException extends java.lang.RuntimeException. It's not necessary to use a 'throws' clause with RuntimeException or subclasses. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: extended peers
Sascha Brawer [EMAIL PROTECTED] writes: java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment java.awt.printerjob = sun.print.PSPrinterJob sun.java2d.fontpath = I believe there used to be a system property which told the Sun JVM which peers to use, so for example if everything was implemented in this unpublished peer interface you could plug these into Sun's JVM. In that sense, the java.awt.peer classes act as the public facade to internal private peer implementations such as the GTK peers we have today. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Kaffe/GNU Classpath AWT support
James Simmons [EMAIL PROTECTED] writes: I have managed to get the GNU Classpath AWT build under kaffe. The only issue I ran into was kaffe uses profiles to define which classes to build. The problem is the Classpth AWT code requires code from java beans and java.accessibilty. So the profile default breaks. The profile allatonce works with some changes. So I have something working. I'm working in the native code but I was wondering if any work has been done for a xlib peer. It would save me some time if this is the case :-) I think Kaffe has an AWT that has some xlib peers already. GCJ contains some xlib peers for Classpath's AWT. Someone was recently working to get the Kaffe xlib peers and all the Kaffe AWT code working under GCJ. The variations on AWT and Java2d are starting to require a huge matrix. It would be nice to standardize a peer interface. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpathx-discuss] [gnujaxp] javax.xml.* conform to jaxp1.1
Arnaud Vandyck [EMAIL PROTECTED] writes: I've just finished some commits (less than 10) to make gnujaxp compliant with jaxp1.1 public API. We still need to fix the build system (see [1]) and that's all for the minor changes. The major improvment would be to have an transform implementation. Ahh, that's good. Should we import that for the release? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Preparing for 0.06 release (last test release - hopefully)
Mark Wielaard [EMAIL PROTECTED] writes: Hi, On Mon, 2003-08-18 at 00:30, Mark Wielaard wrote: I have put up a new test release: http://www.klomp.org/mark/classpath/classpath-0.06-test3.tar.gz (Note that I disabled the actual API generation since that just takes to much time. I will generate a new set tonight and put it up somewhere tomorrow morning.) API documentation is now up at: http://www.klomp.org/mark/classpath/doc/api/html/ Cannot compare it with the old version since that seems to be gone: http://www.gnu.org/software/classpath/docs/api/ Brian, do you know how to get it back up? I had access to the file space on gnudist.gnu.org:/var/www/software/classpath which is where the web pages come from. Anyway with the crack that is gone and I don't know how to get it back up. I certainly don't think it reasonable to make us check this generated stuff into cvs. Paul set this up for me before. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Preparing for 0.06 release
Mark Wielaard [EMAIL PROTECTED] writes: Hi, Small update. I am not going to make it with 0.06 today. OK And the GNUAXP import seems to not really work correctly when doing a make from a make dist tarbal. Weird, I'll have to take a look. java.lang.ArrayIndexOutOfBoundsException: -1 Hmm, Julian ([EMAIL PROTECTED]) could probably answer if he had time. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: bug fix for java.io.InputReaderStream.close andjava.util.zip.InflaterInputStream.close
David P Grove [EMAIL PROTECTED] writes: Appended is a patch to avoid a NullPointerException if close is called multiple times. This matches the logic that is already in java.io.BufferedReader. Could someone please apply it? Someone applied the java/io/InputStreamReader patch but did not use synchronize on the java/util/zip/InflaterInputStream patch. Not sure why. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu.java.awt.font
Sascha Brawer [EMAIL PROTECTED] writes: Hi all, I've put a new snapshot of a prospective gnu.java.awt.font package at the following address: http://www.dandelis.ch/development/fonts/#Implementation Sascha, Is this something we should get imported into Classpath since you're no longer working on improving it or are you thinking of writing it on top of OpenGL? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patches need applying ...
Stephen Crawley [EMAIL PROTECTED] writes: Could some kind soul please apply the BigDecimal.setScale patch I just submitted on behalf of Saket and Jerry? Mark did this back in mid-July. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath java/util/TimeZone.java java/util/Loc...
Tom Tromey [EMAIL PROTECTED] writes:
Ingo == Ingo Proetel [EMAIL PROTECTED] writes:
Hi.
Ingo java/util : TimeZone.java Locale.java
Please follow the existing coding standards. I looked at this briefly
and there were a couple formatting bugs. For instance, in Classpath
an opening brace `{' goes on its own line.
Any word on jalopy understanding our conventions?
Brian
--
Brian Jones [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Preparing for 0.06 release
Ito Kazumitsu [EMAIL PROTECTED] writes: Hi, In message Preparing for 0.06 release on 03/08/10, Mark Wielaard [EMAIL PROTECTED] writes: - There are still some open bugs: http://savannah.gnu.org/bugs/?group=classpath I submitted two new bug reports, which were originally submitted to this mailing list. Thanks Ito, I hadn't forgot about these. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Method.equals() question
()) + return false; +if (!this.getName().equals(that.getName())) + return false; +if (this.getReturnType() != that.getReturnType()) + return false; +if (!Arrays.equals(this.getParameterTypes(), that.getParameterTypes())) + return false; +return true; } /** ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Preparing for 0.06 release
Brian Jones [EMAIL PROTECTED] writes: - Import new external libraries - GNU-JAXP Done, but someone concerned that I'm not seeing 'configure' in the jaxp directory. No difference otherwise between initial import and this import. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Method.equals() question
Tom Tromey [EMAIL PROTECTED] writes:
Brian == Brian Jones [EMAIL PROTECTED] writes:
Brian These have not been applied yet, we should do so before Friday.
Brian Does this look okay to everyone?
Yes, except for one little nit:
- // Implementation note:
- // The following is a correct but possibly slow implementation.
- //
- // This class has a private field 'slot' that could be used by
- // the VM implementation to link a particular method to a Class.
- // In that case equals could be simply implemented as:
- //
- // if (o instanceof Method)
- // {
- //Method m = (Method)o;
- //return m.declaringClass == this.declaringClass
- //m.slot == this.slot;
- // }
- // return false;
This part of the comment is still correct and could be left in place.
(This is actually what libgcj does.)
Whether you want to leave it in place, I don't know. I see it is a
nice, but optional, hint to implementors.
Left it in place. Checking in now.
Brian
--
Brian Jones [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
