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
