Re: Quality control and FOSS rant
And in case anyone is under any illusions, Sun's record of fixing bugs (and not re-breaking them) is poor. The number #1 voted bug* in their bug database has been unfixed for over 5 YEARS! -Archie * http://bugs.sun.com/view_bug.do?bug_id=4670071 -- Archie L. Cobbs
Re: jboss-4.0.4
Christian Thalinger wrote: On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? JCVM has class unloading, but I've never tried JBoss. If you want to try it, use the harmony version because it's more up to date: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm Cheers, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Harmony's Classpath adapter
Hey all, As some of you know I donated a version of JCVM to the Apache Harmony project under the Apache license called "JC Harmony Edition". BTW, SableVM has been donated too. However, Harmony has its own class library called "classlib" (why so is a different discussion for another thread). So my advice for "JCHEVM" was to start integration by creating a "Classpath adapter", which is a small "shim" layer of Java code that sits between "classlib" (above) and the JVM (below), roughly at the VMFoo layer. It takes any Classpath-compatible JVM and makes it work with "classlib". The goal is that any Classpath-compatible JVM can run with "classlib" instead of Classpath simply by putting the Classpath adapter on the bootclasspath and the classlib libraries on the library path. So why am I bringing this up here? Because although I don't like the fact that there are two whole class libraries out there that people are working on, there is one advantage in terms of testing and debugging: by being able to mix and match JVMs and class libraries, we can get a lot of testing leverage for detecting bugs and incompatibilities. I think this could be an interesting opportunity. So if any Classpath/JVM developers are interested in getting involved, you can SVN check out the evolving "Classpath adapter" via this URL: http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlibadapter Of course on the Harmony mailing list is lots more info, etc. Cheers, -Archie P.S. This email is purely informational (i.e., don't blame me if you think Harmony is stupid in the first place). __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: javah
Tom Tromey wrote: I recently rewrote 'gcjh' in java, including all the bits needed for 'javah'-like operation. I'd like to check it in. However, when I wrote it I used the ASM library. My preferred approach to this would be to check in the needed ASM sources (in tools/external), and build the library as part of the Classpath build. That way we wouldn't have any java-based external dependencies. On irc Mark suggested a --with-asm configure option. I could do that, instead, though it would make the eclipse-based build a bit weird. Any other ideas? I'm happy to send the code to anybody who wants it. It depends on the classpath getopt code. FWIW.. if a pure-C implementation is needed we could adapt the one in JCVM. Sometimes it's nice to not require a JVM to run javah. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve reports
Roman Kennke wrote: I'd like to get JCHEVM (the Harmony edition of JCVM) included.. is that possible? Let me know what I can do to help if so. This should be possible. Whenever me or Mark or somebody else finds time to fiddle with the build scripts we will include this. OTOH, it might be possible that Mark gives you access to the machine so you can set this up yourself? That'd be fine with me... just let me know what I need to do. Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve reports
David Gilbert wrote: Roman Kennke wrote: These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I'd like to get JCHEVM (the Harmony edition of JCVM) included.. is that possible? Let me know what I can do to help if so. Some details... - It's easy to download the latest source, but you'll need an SVN client - The SVN build requires the usual autofoo stuff (automake, autoconf, etc). There is a script included that runs everything (including ./configure). - Still targeted at Classpath 0.90, due to the fatal bug in Classpath 0.91 that makes startup fail with a NullPointerException. I have a patch for 0.91 though (it's currently checked in as an unapplied patch). Thanks, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Beanshell support for Mauve
Roman Kennke wrote: while having dinner I had a great idea: IMO it would be ubercool to have Mauve support Beanshell scripts as testcases. I came to this idea This sounds like a good idea. In any case, it can be done without any harm to the existing infrastructure, i.e., it could be prototyped as an optional add-on. Mauve could look for foo.class OR foo.bsh, and do the appropriate wrapper type operation in the latter case. We use BeanShell for lots of stuff at work and it's great. One glitch is: does BeanShell run on Classpath? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: running pscan, rats. flawfinder and splint on classpath
Dalibor Topic wrote: functions. Some of those are a little odd, for example it is not clear to me what to do if JNI function call ThrowNew fails. rats and Good question.. I think the only reasonable answer is "proceed with the knowledge that an exception was posted, but perhaps not the one you asked for (e.g., OutOfMemoryError or somesuch)". -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Ian Rogers wrote: Archie Cobbs wrote: IMHO using POSIX threads is the only "right" answer for a multi-platform JVM. You have no other choice except to leave it up to the specific platform to then implement POSIX threads efficiently. For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. I agree with you. I think it's always the case that Java threads are going to be better than POSIX threads though, as with some commodity processors, in particular I'm thinking of Cell, you no longer have a shared memory model. In such a situation you could use a distributed JVM, such as JESSICA2 - that's built on top of Kaffe :-). So whilst implementing a JVM assuming POSIX threads is a good idea to run on many platforms, there are legitimate reasons why you may want to be flexible and not assume a 1-to-1 mapping of Java threads to POSIX threads, and of course avoid native code. You're right.. there is a subtlety here I was glossing over. When referring to "threads" above, I guess I meant things that actually need to consume C runtime stack. For example, if you have code that invokes read(2), this code needs to have it's own C runtime stack and needs a "real" O/S-supplied thread to sleep with. Any time you invoke JNI native code, you'll also need a "real" thread and runtime stack. On the other hand, Java threads are entirely virtual and their stacks don't have to correspond 1:1 to C runtime stacks (although it surely is convenient to do it that way). I don't know which JVMs make this distinction. You would have to "lend" a real thread to a Java thread anytime it invokes native code. But you could re-use that thread once the thread returned to Java code; if the thread called back into Java code from within the native method, you could also return the real thread to the thread pool, but the chunk of C runtime stack that supported the native method call would have to be saved somewhere of course. You'd need a lot of longjmp() or setcontext() magic to do this. The upshot would be that you only use "real" threads when absolutely required, e.g., you're making a blocking system call, and Java threads would be very lightweight (corresponding merely to linked lists of Java stack frame structures, or whatever). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Clemens Eisserer wrote: For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. It seems you are some years behind actual development. The threading model you describe was used till linux-2.4, since 2.6 NPTL is used instead which outperforms almost everything else. Good to hear that :-) -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Andrew Haley wrote: > I think the long term view is to switch to POSIX threads. Having > used the Jikes RVM for an OS like project, relying on native > threads wouldn't have been desirable. In theory green thread > context switches should be possible in a few instructions whereas a > full context switch takes a few hundred. I guess its all down to > the situation the JVM is trying to optimise for. Indeed. I've been thinking about this, and it occurs to me that threads are used to solve two entirely problems, and which threading model is desirable depends on which problem you are trying to solve. IMHO using POSIX threads is the only "right" answer for a multi-platform JVM. You have no other choice except to leave it up to the specific platform to then implement POSIX threads efficiently. For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Datetypes for native target layer functions
Dr. Torsten Rupp wrote: I'm currently changing the target native layer to replace the macros by functions. For this suitable datatypes have to be used in the function prototypes (as requested in the dicussion). Currently it seems there is a mixture of native datatypes (e. g. int) and JNI datatypes (e. g. jint or jlong). First I thought it would be keep out JNI from the target native layer completely, because the layer should be independent from JNI (but used in JNI-functions). This seems to be impossible, because e. g. the datatype jlong which is at least on some systems not available as a scalar native type (e. g. long long). My question: what will be the accepted designed for datatypes? Do we - keep a mixture of native types and JNI types (and accept the additional code for conversion e. g. from int to jint and back)? - use only JNI types? - use only native type? My opinion.. use both native and JNI types. The specific siutation will dictate what to do. Uses casts as required. Etc. This probably sounds simplistic. Maybe a specific example would make the issue clearer.. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: RFC: VMClassLoader changes proposition
Olivier Jolly wrote: So basically, I'm asking about your thought on how to make the boot class loader (which is out of range of classpath) defines packages as it load classes. JCVM doesn't have any support for Packages, so any general-use code that gets added to Classpath and can save me work has my vote :-) -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Where's the love?
David Daney wrote: 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 I would support that idea. However, I don't think we require the FSF's permission. We are the authors of Classpath and therefore retain copyright privledges. IANAL, but I could swear that I signed over copyright to the FSF long ago. IANAL either .. but I think you "assigned copyright" to them, meaning you gave them the right to copyright. This has no effect on your own right to the copyright of your own work. Ie, you did "cp self fsf", not "mv self fsf". But since IANAL and TINLA [1], I should probably just shut up for now :-) -Archie [1] http://en.wikipedia.org/wiki/IANAL __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Where's the love?
Brian Jones wrote: 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 I would support that idea. However, I don't think we require the FSF's permission. We are the authors of Classpath and therefore retain copyright privledges. So we could collectively decide to release Classpath under any additional license we wanted to. I.e., we granted FSF copyright but not exclusive copyright. However, getting FSF to do it means not having to chase down every person who's ever contributed to Classpath and getting their permission. Not sure which would be harder: getting FSF's permission, or getting 100% of Classpath contributors' permission. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Real questions
Philippe Laporte wrote: Does this library have (ie is in a perfect state) all the security and signing stuff that classpath lacks right now? How about the security audit? I'm not sure exactly what it has, as I've been too busy to take a good look at it. It's all visible for inspection via the Apache SVN server if you want to have a look. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: RFC: Removing unused import
Arnaud Vandyck wrote: Filtering warnings in Classpath with Eclipse, I found there are 388 warnings about "The import XXX is never used". I can work on these warnings and I think I can commit the result without requesting for comment on each classes because it's a minimal impact patch. But before proceeding, I'd like to ask: 1- is it useful; It's useful.. but first verify that the tool is javadoc-aware. E.g., some imports may only be used in javadoc comments (in theory). -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Where's the love?
Brian Jones wrote:
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)
Here's a little bit more information re #2. I've donated an interpreter-only
version of JCVM to Harmony (called "JC Harmony Edition") under the Apache
license. Whether they'll end up using it or not, who knows.
IBM has donated a class library (called, unfortunately, "classlib").
There is an effort underway to "port" that class library to JCHEVM,
using the existing (Classapath-defined) Java/VM API. This effort has
seen some initial success. So in theory, if all goes well, any combination
of ("classlib" or Classpath) and (any VM that works with Classpath) will
run. This would be great if it can be achieved.
As for all the license stuff, I don't understand it all and don't care
strongly enough to follow the debate. I do think it's a real irony that
"free" software can't be packaged with other "free" software. I don't
in general like the idea of two "competing" class libraries nor two
"competing" test frameworks (the latter being especially stupid).
So #1 is not really true: they're not writing new stuff, they've just
accepted a pre-existing donation. They believe they can't just use
Classpath for license reasons (this part I don't fully understand).
Re #3 I've not been following it.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: JNI calls that don't return
Ian Rogers wrote: Thanks for the replies. I have worked further on this and the particular issue isn't with GC barriers but with M-to-N threading. In theory if 1 of the M threads becomes blocked in a JNI call then the other threads should be moved onto another of the N underlying native threads. Unfortunately, as it's possible to call back into the JVM, the JVM's yield code can schedule another thread on the same native thread before realising the 1st thread is blocked and now its possibly handling a I agree that this model though well intentioned is fundamenally broken. You simply can't implement correct M-N threading unless you have some way of being notified properly when a "lower layer" thread blocks. For example look at FreeBSD's KSE threading model, which is similar to "activations". If a system call blocks, the user thread manager is immediately notified by the kernel... http://www.freebsd.org/kse/ Without this kind of notification the only other alternative is to wrap every system call that could possibly block. That's not implemented in classpath (and besides the VM would also have to implement it). -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: dacapo xalan
Jeroen Frijters wrote: David Daney wrote: We cannot violate the JLS! A method that throws a checked exception without declaring it is a bug. Rubbish! There are several ways to throw checked exceptions: http://weblogs.java.net/blog/crazybob/archive/2004/09/dont_try_this_a.ht ml Besides, the JLS is only relevant to compilers, not runtimes. JVMs follow the JVM specification, which allows native methods to throw unchekced exceptions. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: JNI calls that don't return
Jeroen Frijters wrote: Some VMs require all Java threads to run upto a garbage collection barrier before garbage collection can be performed. If a Java thread never leaves JNI code then this will never happen and the VM deadlocks. Why not fix the VM? Real world applications are likely to have this issue as well, besides how is this any different from blocking on I/O inside a JNI method for a very long time? I agree.. any thread that's running JNI code is cannot possibly affect the state of the VM until if/when it either returns or invokes a JNI method. Therefore there's (in theory) no need to wait for it to return in order to do anything. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: HOWTO
Enrico Migliore wrote: I'm using Classpath with Archie Cobbs' JCHEVM virtual machine, and I'm writing another document that explains how to build JCHEVM on Cygwin. If you think it might be of interest, I'll post this second document too. The latter document (building JCHEVM on Cygwin) is better placed on the Apache Harmony web site. But it should definitely contain a pointer to the Classpath wiki entry describing how to build Classpath on Cygwin. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Next release
Mark Wielaard wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit "1.0". So the proposal is to keep using a "sequence version number". Either just drop the "0." and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Opinion requested, here granted :-) 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. Not a big deal really, but that's my $0.02 anyway... -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. Well then IMHO those people are the ones who are being "difficult" and putting politics over progress. Saying you won't contribute to a GPL project is more a political statement than the result of some reasonable decision-making process, because even if you do contribute to GPL software, you still own the copyright so you can also release your code under any other license you choose. Personally I don't love the GPL because it imposes more restrictions than a BSD style license (making, in my opinion, GPL software less free). But I respect others' religious beliefs. So if the GPL is not otherwise in the way, I have no problem working with it, etc. "Can't we all just get along?" :-) -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. This can make sense if the Harmony tests are Harmony-specific. Otherwise I don't see what the point is. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? There may be no real reason it should be GPL, but in any case it is... so.. what's the problem with that? I mean, from a practical standpoint. But you seem also to be asking the religious question "why GPL"? Like most religious questions that one has no objective "answer".. If you really want to hear an "answer" then you can read the "official" one in the GPL FAQ... -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) But let's talk practicalities.. here's a simple thing I don't understand. What exactly prevents Harmony from using Mauve as a test suite? Would Apache want to create it's own copy of Mauve and check that into SVN? That seems like a bad idea -- i.e, creating a "code fork". So then if Apache only wants to run Mauve tests, what impact does Mauve being GPL have? Why can Apache folks just download Mauve and run it, the same way Classpath hackers do? Mauve is its own self-contained project. As to the issue of converting Mauve to JUnit, that's surely a lot of work any way you slice it, and in any case that seems like an orthogonal issue. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Hashtable's and the tale of runtime
Tom Tromey wrote: At some point we changed libgcj's hash function to this: // This was chosen to yield relatively well distributed results on // both 32- and 64-bit architectures. Note 0x7fff is prime. return (jint) ((unsigned long) obj % 0x7fff); What if you're on a 32-bit machine and all the object addresses are less than 0x8000.. won't that give you the same result as just returning (jint)obj ? -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cgwin: UnsatisfiedLinkError problem
S. Meslin-Weber wrote: VM writers typically handle the delegated loadLibrary() call via their implementation of the VM* interface classes and in their own native code. As cygwin uses a decidedly odd naming convention for its dlls, I'd say those parts of jc would need to be investigated. IIRC, Cygwin calles its equivalent of libjavanio.so cygjavanio-0.dll. So... what's an #ifdef one can use on cygwin to detect cygwin? E.g. #ifdef WINDOWS or #ifdef CYGWIN or something? (This is hard for me to fix right now because I don't have cygwin set up anywhere). Presumably other VMs have the same issue (if they want to run on cygwin). Has anyone already solved this problem? Enrico: the relevant macro is _JC_LIBRARY_FMT in definitions.h. Perhaps you can play with some possibilities there. Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: New native layer
Per Bothner wrote: Casey Marshall wrote: We have the responsibility, as contributors to a GNU project, to maintain the project for the GNU system. GNU is sorta-POSIX, as are a lot of other interesting platforms, and targeting them earns us, as free software contributors -- not necessarily other groups or companies that want to use Classpath -- a lot. I see these "native portability layers" as being counter to that goal, and they especially don't make sense given that there's no other free implementations for platforms other than what we are targeting. An alternative take with similar conclusion: There is a standard "native portability layer". It is called Posix. There are multiple implementations of this layer available for MS-Windows. Other platforms we are likely to support (such as OS-X) already support Posix. I.e. there is no need for an extra portability layer. Exactly my sentiments (as a bystander in this thread so far) The parts of POSIX that Classpath uses are pretty much exactly those parts that Classpath needs. So why not just implement that subset of POSIX on your obscure platform? As a side-benefit, lots of other stuff might compile and work on your platform then too. Another thing that bugs me is that it's extra work to create a new 'layer' for each platform. Instead, the autoconf system is much more efficient: once you implement a test for whatever non-POSIX thing, that test can work for all platforms that need it, now and in the future. The "layer" idea is too big a level of granularity to be porting at. We should be porting more like at the function call and macro level. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: SecurityManager troubles
Gary Benson wrote:
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable? My reasoning was that the code
was added to possibly make more things work than do already, and that
anything that might make less things work was to be avoided.
The alternative to Throwable is to catch ClassNotFoundException, which
is the only subclass of Exception that Class.forName throws.
It's definitely not a big deal, but e.g. you should at least not
catch ThreadDeath. Moreover, if there is some obscure, unrelated VM
startup issue, you might get an Error thrown at any time.. if you
discard that here, it might make the obscure issue even more obscure.
This comes from someone who's created his fair share of obscure
VM startup issues :-)
You're right that ClassNotFoundException would be more appropriate
still than Exception. Then the code is clearest about what exactly
is intended.
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote:
Gary Benson wrote:
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did with the system properties (i.e. introduce a
gnu.classpath.SecurityProperties class).
The change to java.security.Security has made the majority of the
Mauve workarounds unnecessary: thanks! Now to see if I can get rid
of the last little bit...
The attached patch allows all Mauve workarounds to be removed.
Ok to commit?
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.6049
diff -u -r1.6049 ChangeLog
--- ChangeLog 13 Jan 2006 14:30:27 - 1.6049
+++ ChangeLog 13 Jan 2006 14:33:56 -
@@ -1,3 +1,8 @@
+2006-01-13 Gary Benson <[EMAIL PROTECTED]>
+
+ * java/lang/System.java (setSecurityManager): Ensure policy
+ files are loaded before a security manager is put in place.
+
2006-01-13 Mark Wielaard <[EMAIL PROTECTED]>
* configure.ac: Set version to 0.20.
Index: java/lang/System.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/System.java,v
retrieving revision 1.53
diff -u -r1.53 System.java
--- java/lang/System.java 13 Sep 2005 22:19:15 - 1.53
+++ java/lang/System.java 13 Jan 2006 14:33:56 -
@@ -178,6 +178,23 @@
if (SecurityManager.current != null)
SecurityManager.current.checkPermission
(new RuntimePermission("setSecurityManager"));
+
+// java.security.Security's class initialiser loads and parses the
+// policy files. If it hasn't been run already it will be run
+// during the first permission check. That initialisation will
+// fail if a very restrictive security manager is in force, so we
+// preload it here.
+if (SecurityManager.current == null)
+ {
+ try
+ {
+ Class.forName("java.security.Security");
+ }
+ catch (Throwable t)
+ {
+ }
+ }
+
SecurityManager.current = sm;
It might be more appropriate to only catch Exception, not Throwable.
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Mark Wielaard wrote: Maybe we can again special case that security check by doing a this.getClass().getClassLoader() == null? Hmmm, no, that doesn't work since getClassLoader() will trigger a security check. Nasty... That's what VMStackWalker.getClassLoader() is for... you could use it. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote: Isn't the boot class loader solely for java.lang? No.. under the Java2 delegation model, the boot class loader should be given the first chance to try and load *every* class. Typically it will only find classes in glibj.zip (or rt.jar, or whatever your VM equivalent of the core library is) because that's all it knows to look in. So then the child classloader(s) get to try. In any case I'm still not clear on this problem. Yesterday it looked to me like a result of delayed method resolution by kaffe. But that could be completely off. I haven't actually witnessed the problem so can't really say for sure without additional info. It would be nice however to get to the bottom of it before 0.20... -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: NIO (Non-block & Scatter/Gather)
Robert Schuster wrote: These macros look strange to me. What do our JNI experts say? +/* FIXME: This can't be right. Need converter macros */ +#define CONVERT_JINT_TO_INT(x) ((int)(x & 0x)) +#define CONVERT_INT_TO_JINT(x) ((int)(x & 0x)) + +/* FIXME: This can't be right. Need converter macros. */ +#define CONVERT_SSIZE_T_TO_JINT(x) ((jint)(x & 0x)) +#define CONVERT_JINT_TO_SSIZE_T(x) (x) I'm not a JNI expert, but these macros are not necessary. Just use C typecasts: (jint)foo, (int)foo, (size_t)foo, etc. (or, just leave them out .. because it's C they're implicit :-) The right thing will happen. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Guilhem Lavaux wrote: I must say that I don't understand this problem. Me neither... I do not think it is strictly linked to the VM. I have produced an "artificial" stack trace by tweaking kaffe's VM. Normally this stack trace is hidden by the VM and replaced by a NoClassDefFoundError. Here I removed the class preloading from my test. You can see there is a loop in CharsetProvider at least. Maybe it's VM related but it would be really weird. It doesn't happen with JCVM.. but see below.. This block is the loop: at testSM$MySM.checkPermission (testSM.java:17) at java.lang.SecurityManager.checkSecurityAccess (SecurityManager.java:1011) at java.security.Security.getProperty (Security.java:396) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) The last loadClass is already loading java/security/Permission and checkPermission needs to load java/security/Permission too. Maybe it is also a SystemProperties trouble ? OK, so this requires that the VM be lazily resolving classes, i.e., java.security.Permission, as referenced by testSM$MySM, is not resolved until checkPermission() is about to be invoked. JCVM resolves classes all at once, so it doesn't have this problem. Having said that, still not sure what the solution is. Seems likely that any class used as a security manager needs to be fully resolved before being used. Perhaps System.setSecurityManager(s) can always invoke Class.forName(s.getClass().getName, true, s.getClass().getClassLoader()). Right now I can't remember if class initialization implies (complete) class resolution. I think it does.. but if not then the above trick wouldn't necessarily work. Clearly it does NOT in kaffe, otherwise the above example couldn't happen. Hmm, maybe System.setSecurityManager() can do a "phony" invocation of s.checkPermission() to ensure that it's resolved... -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Archie Cobbs wrote: Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from "Balloc" in mprec.c. Sorry for the noise, that email got delayed several hours for some reason. As we now know strtod() has different behavior than desired... In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from "Balloc" in mprec.c. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Assertion failure
FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 << k) < 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Mark Wielaard wrote: Subversion support for savannah is planned in the future. And it might make sense to adopt it then since other projects that rely on GNU Classpath also use it and it makes merging easier. On the other hand That would be great. subversion is still a bit immature and not widely supported yet (for example on builder.classpath.org we needed to install the latest 1.3.0rc4 to get around some network timeout issues). CVS might be old and clumsy at times, it is much more mature and supported atm. That said, if savannah adds subversion support I would vote for us to switch. I think you're information is slightly dated :-) Subversion is quite matture. The 1.0 release, which itself was very stable, was released almost two years ago. Now they're up to version 1.2.3. For example, all of Apache is on a single Subversion server and they're up to revision #356264 (including imported CVS commits). We've used it at my real job for over a year with zero problems. As far as being "supported", not sure what you're referring to. Everything I've ever wanted to do with CVS I can do with SVN, plus a lot more. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Mark Wielaard wrote: - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot @cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath Hmm.. could this new infrastructure include possible a switchover from CVS to Subversion? (I'm so used to SVN now that CVS is gotten pretty gross to deal with). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Kerberos
Jeff Bailey wrote: Sorry, I chose my words poorly there. By 'native' I meant "Done in Java". Is there a better word that means that? =) "Pure Java"... ? -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Announcing JCVM release 1.4.7
JC is a Java virtual machine implementation that converts class files into C source files using the Soot Java bytecode analysis framework, compiles them with GCC, and loads them using a built-in ELF object file loader. JC utilizes the GNU Classpath class library and provides a fairly complete Java runtime including sophisticated optimizations to increase runtime performance. JC also includes a bytecode interpreter, and supports execution in either or mixed modes. http://jcvm.sourceforge.net/ Changes in version 1.4.7: - Fixed potential assertion failure in VMStackWalker.getClassContext(). - Upgrade to Classpath 0.19. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Stuart Ballard wrote: Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? Yes, I suppose so... > On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Yes.. all the other methods in there are too. VMStackWalker can only be used by classes loaded via the boot loader (see comment at the top). -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Jeroen Frijters wrote: The infinite loop is simple: Class.getClassLoader() invokes VMStackWalker.getCallingClassLoader() VMStackWalker.getCallingClassLoader() invokes Class.getClassLoader() It would be nice if VMStackWalker.getCallingClassLoader() could invoke VMClass.getClassLoader(), but access permissions prevent that. Any ideas? One idea is to move VMStackWalker into java.lang. We can't do that, it needs to be public. I guess that VMStackWalker should have a native method to get the class loader from a Class. Sounds good.. how about this? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: VMStackWalker.java === RCS file: /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java,v retrieving revision 1.5 diff -u -r1.5 VMStackWalker.java --- VMStackWalker.java 2 Jul 2005 20:33:08 - 1.5 +++ VMStackWalker.java 9 Nov 2005 17:44:29 - @@ -88,9 +88,9 @@ /** * Get the class loader associated with the Class returned by - * getCallingClass(), or null if no - * such class exists or it is the boot loader. This method is an optimization - * for the expression getClassContext()[1].getClassLoader() + * getCallingClass(), or null if no such class + * exists or it is the boot loader. This method is an optimization for the + * expression VMStackWalker.getClassLoader(getClassContext()[1]) * and should return the same result. * * @@ -102,7 +102,15 @@ Class[] ctx = getClassContext(); if (ctx.length < 3) return null; -return ctx[2].getClassLoader(); +return getClassLoader(ctx[2]); } + + /** + * Retrieve the class's ClassLoader, or null if loaded + * by the bootstrap loader. I.e., this should return the same thing + * as [EMAIL PROTECTED] java.lang.VMClass#getClassLoader}. This duplicate version + * is here to work around access permissions. + */ + public static native ClassLoader getClassLoader(Class cl); } ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Infinite loop
I'm adapting JCVM to work with a totally unmodified Classpath, but doing so seems to cause an infinite loop in Mauve test gnu.testlet.java.util.logging.Logger.getAnonymousLogger. The infinite loop is simple: Class.getClassLoader() invokes VMStackWalker.getCallingClassLoader() VMStackWalker.getCallingClassLoader() invokes Class.getClassLoader() It would be nice if VMStackWalker.getCallingClassLoader() could invoke VMClass.getClassLoader(), but access permissions prevent that. Any ideas? One idea is to move VMStackWalker into java.lang. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: configure failure
Christian Thalinger wrote: On Thu, Nov 03, 2005 at 08:50:40AM -0600, Archie Cobbs wrote: $ rpm -qa | grep freetype freetype-2.1.3-6 freetype-devel-2.1.3-6 $ rpm -ql freetype | grep '\.pc' $ I'm not educated on the wonders of pkg-config. Where do I find freetype2.pc and why isn't it on this system? Hmm, it seems that redhat 9 is too old. In an archive i found that gtk2 is: gtk2-2.2.1-4.i386.rpm Maybe you should try --disable-gtk-peer or upgrade your system :-) --disable-gtk-peer does workaround the problem. But FYI this same system was able to configure classpath-0.17 without that flag. Therefore something changed. I guess 0.17 didn't require freetype? Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
configure failure
Hi all, I'm trying to ./configure classpath-0.19 on Redhat9 and getting this: checking for freetype2... Package freetype2 was not found in the pkg-config search path. Perhaps you should add the directory containing `freetype2.pc' to the PKG_CONFIG_PATH environment variable No package 'freetype2' found configure: error: Library requirements (freetype2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. $ rpm -qa | grep freetype freetype-2.1.3-6 freetype-devel-2.1.3-6 $ rpm -ql freetype | grep '\.pc' $ I'm not educated on the wonders of pkg-config. Where do I find freetype2.pc and why isn't it on this system? Thanks, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updated FreeSwingTestApps
Mark Wielaard wrote: Another good one to test would be the Apache Batik SVG browser. http://xml.apache.org/batik/svgviewer.html This Swing app uses the graphics toolkit very heavily. Interesting application. I am currently unable to get past the (beautiful!) splash screen. The progress bar updates, but then I get some obscure error. Could you add this one to the webpage (probably under and add some comments about what to download where and how to startup plus anything you think is helpful for people wanting to this going? http://developer.classpath.org/mediation/FreeSwingTestApps I added it to the wiki. Download instructions, etc. are on the home page, no need to repeat. You can add more details on the "obscure error" if you want to. Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updated FreeSwingTestApps
Mark Wielaard wrote: In preparation for the next snapshot on Wednesday I went through the FreeSwingTestApps list. There are now 4 categories "Should Work", "Starts but doesn't really work", "Needs lots of Work" and "Untested". The first two categories are the most interesting since those are applications that (at least partially) work now. Another good one to test would be the Apache Batik SVG browser. http://xml.apache.org/batik/svgviewer.html This Swing app uses the graphics toolkit very heavily. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
David Gilbert wrote: Pointers to other Free-and-not-overly-complex Swing applications are welcome too. I'm happy to try running a few things and fixing some bugs (at least the easy ones). Haven't tried it with Classpath myself, but here's one that might be worth trying: http://pollo.sourceforge.net/ Pollo is a graphical XML editor. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Persuading the apaches
Martin Olsson wrote: Could someone clarify the difference between GPL+Exception and ASF? I'm interested both in the general differences but also specifically: - Why do you guys prefer GPL+Exception over ASLv2 ? Just to clarify: it's not necessarily "us guys" that prefer GPL+ex over Apache license. Rather (at least in my case) I need to be able to contribute to Classpath, and the only way to do that is to assign copyright assignment to FSF. The FSF owns the copyright and only they have the power to change it. So perhaps you should be asking "why does FSF prefer GPL+exception", which may have a more obvious answer. Personally, I'd happily agree to re-license Classpath under a BSD style license or something but that is probably highly unlikely, because I doubt *all* Classpath developers *and* the FSF would agree to that. Cheers, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Announcing JC virtual machine release 1.4.6
Announcing JC virtual machine release 1.4.6 This is a minor bug-fix release. It also updates to Classpath version 0.17. Changes in version 1.4.6: - Added new command line flags -Xrnd, -Xnoln, and -Xobj. - Fixed JNI method NewObjectArray(); was using the wrong class loader. - Fixed Soot bug that could change class initialization order. - Fixed bug in classes with a name component starting with underscore. - Fixed bug when invoking methods with 'float' parameters dynamically. - Fixed bug in Field.getFloat() when promoting byte -> float. - Throw IllegalArgumentException instead of IllegalAccessException when attempting to retrieve an invalid field via reflection. - Upgrade to Classpath 0.17. http://jcvm.sourceforge.net/ Cheers, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
I checked in the aforementioned assertion patch. 2005-07-25 Archie Cobbs <[EMAIL PROTECTED]> * native/jni/classpath/native_state.c: add assertion for object type -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Dalibor Topic wrote:
Doesn't GetObjectClass change the state of env? If that's the case, it
maybe shouldn't be an assert.
Not sure what you mean.. but there is a bug: we need to delete the
local native reference obtained by calling GetObjectClass.
Attached is a better patch.
Thanks,
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 24 Jul 2005 22:38:39 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include
+#include
#include
#include "native_state.h"
@@ -165,6 +166,18 @@
*head = new_node;
}
+#ifndef NDEBUG
+static void
+cp_gtk_check_compat (JNIEnv * env, jobject obj, struct state_table *table)
+{
+ jclass objclazz;
+
+ objclazz = (*env)->GetObjectClass(env, obj);
+ assert ((*env)->IsAssignableFrom(env, objclazz, table->clazz));
+ (*env)->DeleteLocalRef(env, objclazz);
+}
+#endif
+
void
cp_gtk_set_state_oid (JNIEnv * env, jobject lock, struct state_table *table,
jint obj_id, void *state)
@@ -214,6 +227,11 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
@@ -227,6 +245,11 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
@@ -239,6 +262,11 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk/GtkGenericPeer
Here is the relevant stack trace snippet:
#7 0x29f862d7 in
Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2
(env=0x107ed6a0, obj=0x29795698, peer=0x2979569c)
at gnu_java_awt_peer_gtk_GdkGraphics.c:154
Hmm, no response.. can anyone else confirm this problem??
It looks like this code is completely broken, because
it's trying to save a pointer in a field that doesn't
exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says:
NSA_SET_PTR (env, obj, g)
but "obj" is a gnu/java/awt/peer/gtk/GdkGraphics object, not
a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that
contains the "native_state" field.
Since nobody seems to be listening, I'm going to check in the
attached patch. This will cause all programs that use the GTK
peer to crash with an assertion failure. Sorry! The code
is broken but I don't know how to fix it. At least now we get
an assertion failure instead of random memory corruption.
You have been warned :-)
-Archie
__________
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 23 Jul 2005 19:30:28 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include
+#include
#include
#include "native_state.h"
@@ -214,6 +215,10 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+ assert ((*env)->IsAssignableFrom(env,
+(*env)->GetObjectClass(env, obj), table->clazz));
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
@@ -227,6 +232,10 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)->IsAssignableFrom(env,
+(*env)->GetObjectClass(env, obj), table->clazz));
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
@@ -239,6 +248,10 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)->IsAssignableFrom(env,
+(*env)->GetObjectClass(env, obj), table->clazz));
+
obj_id = (*env)->GetIntField (env, obj, table->hash);
if ((*env)->ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Implementation details of VMStackWalker
Ingo Prötel wrote: I would like to get the common case where private or protected methods are called before the actual stack check happens. This changes the current semantic but I feel that it would be more useful and less fragile to changes of classes that want to use VMStackWalker. If there is a real need for a method with the current semantic we could just add a method to the interface for the new semantic. None of the existing code in Classpath that uses VMStackWalker calls it through private or protected methods, so I'm not sure why you're saying that having private and protected methods is a "common case". Anyway, the reason it's done with the current "simple" semantics is to make these calls as efficient as possible. Although your semantics would make things more robust in the future, you have to balance that against a (probably small) loss of efficiency. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Implementation details of VMStackWalker
[EMAIL PROTECTED] wrote: The next thing I would like to have is a method to get the calling method name. This would be good for logging. You could create a Throwable() object and then get the StackFrame[]. That is what the logging API currently does. But that's terrribly inefficient. We could add a new method to VMStackWalker that returns the calling method name and in the reference implementation it will just do the Throwable thing. Then every VM can decide if they want do add a native method. Sounds reasonable. We take this same approach with getCallingClass() and getCallingClassLoader(), which can be implemented more efficiently in native code, but are also have the "fallback" Java implementation. For the security part: Is it enough to check if the class loader of context[0] is the boot classloader? Not sure what the question is here. In the VMStackWalker source it says only code loaded from the boot classloader may call the methods of this class. But how should we make sure? My question was if it is enough to check if the class in getClassContext()[0] (i.e. the class that actually invoked a method on VMstackWalker directly or through reflection) was loaded by the boot classloader. I didn't write that comment so I'm not sure how (if at all) it is enforced. Not sure what the real security problem is though, even if we did allow random code to call these methods. Maybe someone else can shed some light? -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: hasClassInitializer and exception
Nicolas Geoffray wrote: there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. How about this: add this line to ObjectStreamClass before calling VMObjectStreamClass.hasClassInitializer to force class initialization ahead of time: Class.forName(cl.getName(), true, cl.getClassLoader()); Then we'll know that any exception thrown in the JNI code is not an initializer exception. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String class: hack for ORP 1.0.9
David P Grove wrote: So, I'm having a hard time seeing how this "optimization" actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the method larger, and thus a slightly less attractive candidate for inlining), but if it actually buys you any measurable speedup on a "high performance" VM, then you should really take a hard look at your VM/JIT and find out why they didn't do a good job on the "unoptimized" version in the first place. clone() on an array is just a short hand for a new followed by an arraycopy, and the new followed by arraycopy idiom shows up all over the place so you need to do a good job on it. Not all VM's are high performance I guess :-) [I'm sure you know all this already but here goes..] E.g., on many VM's VMSystem.arraycopy() is a native method, and they can't optimize "into" that method. So all the normal type checking, array bounds checking, and array compatibility checking will be done by that native code in all cases, even though in this case we know it's not necessary. With array clone(), also typically a native method, none of that checking is ever needed. This is a good example of the advandages of a JVM written in Java (a coincidence? :-) There is no "optimization barrier" into "native" code like System.arraycopy(). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String.equals optimisation
Simon Kitching wrote: * Class.getName returns strings that have been interned. I don't think this is explicitly required by the java specs but is certainly true for Sun's JVM and seems likely to be done by any sensible JVM. You definitely make some good arguments, but this one is not neccesarily true. In fact, I'd argue a JVM that interns every class' name (even if only on demand) is potentially wasting a bunch of heap space. I'm assuming that the Class object would contain a reference to the interned string, so there is only one copy of the string, ie somewhere Not a valid assumtion.. in JC no String is associated with Class objects. VMClass.getName() is native and the returned String is created on demand, based on the UTF-8 name stored internally in memory. In fact, one could argue that storing class names in any other way than in their native UTF-8 form is a big waste of memory. E.g., for loaded classes... If the VM can find it's UTF-8 name and create a String dynamically: Then also storing the class name persistently as a String is a 200% increase in memory (a char[] array is twice as big as UTF-8) Else: The VM must store the class name as a String, which is a 100% increase in memory vs. storing it as UTF-8 The extra space used for interning is therefore just a single extra reference (as a reference to the string is contained in both the Class object and the String class internal pool). Yes that is a little space wasted, but not a bunch. Right, the wasted space is not much.. at first I was forgetting that intern'd strings are stored with weak keys and will get flushed out after they're no longer referenced (just like normal Strings)... replace "big waste of memory" with "waste of memory" :-) -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String class: hack for ORP 1.0.9
Simon Kitching wrote:
public char[] toCharArray()
{
// XXX ORP 1.0.9 crashes on (char[]) clone() during bootstrap, so we
// omit this optimization for now.
// if (count == value.length)
// return (char[]) value.clone();
char[] copy = new char[count];
VMSystem.arraycopy(value, offset, copy, 0, count);
return copy;
}
I just wondered if it was time to remove this hack...
Sounds good to me... and in any case, ORP should be doing it's
own disoptimization for VM-specific issues like this rather than
forcing it on all Classpath users.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: String.equals optimisation
Simon Kitching wrote:.
* Class.getName returns strings that have been interned. I don't
think this is explicitly required by the java specs but is
certainly true for Sun's JVM and seems likely to be done by
any sensible JVM.
You definitely make some good arguments, but this one is not
neccesarily true. In fact, I'd argue a JVM that interns every
class' name (even if only on demand) is potentially wasting
a bunch of heap space.
I.e., is there something special about class names which means
they should be treated differently from any other String randomly
created and used in a Java application? (rhetorical question)
Otherwise, why not intern all Strings? Etc.
In any case, to provide two concrete counter-examples:
$ cat > zz.java
public class zz {
public static void main(String[] args) {
zz z = new zz();
System.out.println(z.getClass().getName() == "zz");
}
}
$ javac zz.java
$ java zz
true
$ jc -Xint zz
false
$ jamvm zz
false
On the other hand, comparing reference equality is very low cost,
so it seems like adding "==" to equals() might make good sense.
Of course, the "real" answer lies in empirical testing (something
I can't claim to have done).
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: regression in logger?
David P Grove wrote: > This started showing up in regression tests of Jikes RVM with classpath > cvs head recently. I haven't dug deeply, so it could be a latent problem > in Jikes RVM that was exposed by a classpath change, rather than a real > classpath bug, but might still be worth mentioning. The failing program > is SPECjbb2000. > > --dave > > Exception in thread "main": java.lang.ArrayIndexOutOfBoundsException: > Array index out of range: 0 > at java.util.logging.Logger.getCallerStackFrame(Logger.java:1173) Looks like this can only happen if the VM doesn't return Throwable stack traces. Is this with 0.16? There were recent changes in the VMThrowable class (see NEWS) that might need to be followed in Jikes RVM. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fix for java/net/URLClassLoader
This patch (checked in) fixes two Mauve tests and removes some
obsolete code.
2005-07-09 Archie Cobbs <[EMAIL PROTECTED]>
* java/net/URLClassLoader.java: disallow directories as resources
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
--- java/net/URLClassLoader.java.orig 2005-07-09 15:07:42.0 -0500
+++ java/net/URLClassLoader.java2005-07-09 15:06:06.0 -0500
@@ -536,7 +536,7 @@
Resource getResource(String name)
{
File file = new File(dir, name);
- if (file.exists())
+ if (file.exists() && !file.isDirectory())
return new FileResource(this, name, file);
return null;
}
@@ -554,36 +554,11 @@
InputStream getInputStream() throws IOException
{
- // Delegate to the URL content handler mechanism to retrieve an
- // HTML representation of the directory listing if a directory
- if (file.isDirectory())
-{
- URL url = getURL();
- return url.openStream();
-}
- // Otherwise simply return a FileInputStream
return new FileInputStream(file);
}
public int getLength()
{
- // Delegate to the URL content handler mechanism to retrieve the
- // length of the HTML representation of the directory listing if
- // a directory, or -1 if an exception occurs opening the directory.
- if (file.isDirectory())
-{
- URL url = getURL();
- try
-{
- URLConnection connection = url.openConnection();
- return connection.getContentLength();
-}
- catch (IOException e)
-{
- return -1;
-}
-}
- // Otherwise simply return the file length
return (int) file.length();
}
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote: With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 Hmm, no response.. can anyone else confirm this problem?? It looks like this code is completely broken, because it's trying to save a pointer in a field that doesn't exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says: NSA_SET_PTR (env, obj, g) but "obj" is a gnu/java/awt/peer/gtk/GdkGraphics object, not a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that contains the "native_state" field. I'm not familiar with this code so I could be completely misunderstanding something. But it seems obviously wrong, and on VM's that don't check proper JNI usage will result in random memory corruption. I'd appreciate a quick confirmation from another set of eyes... Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JNI assertion failure
With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #4 0x282d6c1b in abort () from /lib/libc.so.5 #5 0x280ae91d in GetIntField (jenv=0x107ed6a0, obj=0x29795698, field=0x107527c8) at jni_native.c:82 #6 0x29f99d72 in set_state (env=0x107ed6a0, obj=0x29795698, table=0x10471440, state=0x109ea4c0) at native_state.c:217 #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 #8 0x280d4289 in _jc_dynamic_invoke (func=0x29f86214, jcni=0, nparams=3, ptypes=0x2979562c "\n\n\n\t", nwords=3, words=0x29795620, retval=0x107ed628) at arch/i386/arch_functions.c:336 #9 0x280aa802 in _jc_invoke_jni_a (env=0x107ed600, method=0x107f9d60, func=0x29f86214, obj=0x85e0308, params=0x29795754) at invoke.c:692 Could an AWT person take a look at the above trace and error? Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fix for configure test
2005-07-03 Archie Cobbs <[EMAIL PROTECTED]> * m4/acinclude.m4: fix broken expr(1) syntax -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: m4/acinclude.m4 === RCS file: /cvsroot/classpath/classpath/m4/acinclude.m4,v retrieving revision 1.4 diff -u -r1.4 acinclude.m4 --- m4/acinclude.m4 17 Jun 2005 19:32:13 - 1.4 +++ m4/acinclude.m4 3 Jul 2005 20:02:54 - @@ -147,7 +147,7 @@ JIKES_VERSION=`$JIKES --version | awk '/^Jikes Compiler/' | cut -d ' ' -f 5` JIKES_VERSION_MAJOR=`echo "$JIKES_VERSION" | cut -d '.' -f 1` JIKES_VERSION_MINOR=`echo "$JIKES_VERSION" | cut -d '.' -f 2` -if expr "$JIKES_VERSION_MAJOR" == 1 > /dev/null; then +if expr "$JIKES_VERSION_MAJOR" = 1 > /dev/null; then if expr "$JIKES_VERSION_MINOR" \< 19 > /dev/null; then JIKES="" fi ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Tom Tromey wrote: Archie> However, it doesn't seem appropriate for it to go into Classpath, Archie> or at least I'm not sure I understand how it would work exactly, Archie> since there is the obvious bootstrap problem with Java binding. I think if we have pieces of code that are usable by a number of VMs, Classpath would make a good clearinghouse for them, whether they are written in C or Java or whatever. Perhaps we can install a /usr/local/lib/classpath/libzipjar.so or whatever shared library. Then VM's can link to it (or dlopen() it) if they please... we'll also need a header file. I don't have time to do this right now (I'm slow when it comes to automake, etc.) but can help get the source files ready for import, etc. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Mark Wielaard wrote: Maybe we could actually provide the native glibj.zip file reading functionality completely in our vm reference code through zlib. That might not be such a bad idea since almost every runtime will need zlib to load the bootstrap classes and resources. The only trick is to make it flexible enough to be integrated into the various ways runtimes load classes. Archie, I believe you said you had such code for JCVM and that you would consider donating that to GNU Classpath for use with other runtimes. If you have and want to could you send that code to the (patches) list? Do other runtime implementers think they would adopt such shared bootstrap class loading code, or is that something that is too wired into the actual runtime to be easy to share in a generic way? The ZIP file reader in JC is welcome to anyone to use. It's fairly well self-contained in one file (zip.c) plus structure and macro definitions in structures.h and definitions.h. I believe SableVM is already using it. I'll happy re-license and/or donate to Classpath. However, it doesn't seem appropriate for it to go into Classpath, or at least I'm not sure I understand how it would work exactly, since there is the obvious bootstrap problem with Java binding. The relevant files for perusal... http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/zip.c http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/definitions.h http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/structures.h -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
API cleanup
I committed the API cleanup patch. * NEWS: document VM interface changes. * java/lang/ClassLoader.java: (vmdata): add * vm/reference/java/lang/VMClass.java: (getModifiers()): add new parameter ignoreInnerClassesAttrib * vm/reference/java/lang/VMClassLoader.java: (defineClass()): remove deprecated version (getPrimitiveClass(String)): remove (getPrimitiveClass(char)): make native (loadClass()): make native * vm/reference/java/lang/VMThread.java: (vmdata): add (countStackFrames()): make native * vm/reference/java/lang/VMThrowable.java: (vmdata): add (fillInStackTrace()): make native (getStackTrace()): make native * vm/reference/java/lang/reflect/Constructor.java: (parameterTypes, exceptionTypes): remove (getParameterTypes(), getExceptionTypes()): make native -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Michael Koch wrote:
I didn't know that function. Powerfull! So then, shouldn't the function
readConfiguration from LogManager make a call like
LogManager.class.getResourceAsStream("java/util/logging/logging.properties");
to have an InputStream instead of looking for system properties?
Use java.util.Properties.load(InputStream) with it.
I think people are missing Nicolas' point here. The class LogManager
is broken, because it is looking in the wrong place for the properties
file.
Does anyone know what the correct behavior is supposed to be?
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Nicolas Geoffray wrote: First question : how can i handle properties file stored in the glibj.zip. A simple example is the readConfiguration function in java/util/logging/LogManager class file. It first trys to get a "java.util.logging.config.file" property which should be a path in the filesystem. The thing is, it's in the glibj.zip file. There might be a hack somewhere in the FileInputStream to read from a zip file, but i'm not aware of it. That seems like a bug. Apparently LogManager expects the file to live in /usr/local/classpath/lib rather than glibj.zip.. Anyone more familiar with this class care to comment? -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
Tom Tromey wrote: Archie> You pretty much have to save something at construction time, Archie> because the stack sequence is going to change and be lost Archie> immediately afterward. ISTR that ORP had an optimization where it would avoid filling in the stack trace if it knew that the exception object was dead. I think a patch for this would not be reasonable, as long as it played well with other VMs and had a big explanatory comment. That's a neat idea.. I hadn't thought of that. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
Andrew Haley wrote: When the VMblah classes were first introduced, the justification was that they would isolate platform-specific code. Each VM would have its own versions of these classes. But expecting any VM to run Classpath without modifying the VMblah classes as was the original intention is IMO quite unreasonable. Why do you say that? The current API seems like a reasonable one to me. JC runs fine with just a few modifications (even fewer after this patch). > I'm only trying to make it at least theoretically possible for a VM > to use Classpath unmodified and still function properly. To what end? Here are a couple of reasons.. - It allows multiple VMs to share the same "stock" Classpath installation - Fewer Classpath "diffs" means an easier burden of merging Classpath changes into each VM's customized versions of the VMFoo classes. - It just plain looks dumb for the API to be inconsistent. For example, right now JC has to carry around 9 different customized Classpath files. Every time Classpath upgrades, I have to manually merge in the changes, etc. I'd like the number of these "custom" files and the size of the diffs to be as small as possible. To achieve this, I'm willing to adapt to the VM interface as Classpath defines it, to the extent I can. But when that interface is inherently broken, there's no way to do that. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
David Holmes wrote: Who wants a VM that's incapable of generating stack traces?? Probably noone, but I'd love to be able to NOT have the stacktrace always filled in automatically upon construction. You pretty much have to save something at construction time, because the stack sequence is going to change and be lost immediately afterward. In JC just the "raw" stack infomation is saved (namely PC values) and only later, if necessary, is that information decoded into a printable stack trace. I'm sure other VM's do similar things. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
Andrew Haley wrote: You don't explain why you want this. As I understand it, VMblah.java files are provided as templates for code that is target-specific. Why is that a bad thing? It's not a bad thing... however, doesn't it bother you that the API from a stock Classpath doens't even make sense, even if it's only supposed to be a "template"? As a template it's a pretty bad example because it couldn't possibly work. Doesn't really make me proud, for one. Why do you assume that VMThread.countStackFrames(), VMThrowable.fillInStackTrace(), and VMThrowable.getStackTrace() will be native? I'm not trying to assume anything. I'm only trying to make it at least theoretically possible for a VM to use Classpath unmodified and still function properly. Thanks, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
David Holmes wrote: Who wants a VM that's incapable of generating stack traces?? Probably noone, but I'd love to be able to NOT have the stacktrace always filled in automatically upon construction. OK.. though that seems like an orthogonal issue. VM implementors are welcome to change the API of course. Just to reiterate: I'm not trying to decide what the API should be. I'm just trying to pick one that isn't inherently inconsistent and broken a priori and doesn't *require* the VM implementor to change it. Summary of changes: - Add a "vmdata" field to ClassLoader, VMThread, and VMThrowable. Seems to me that every VM will require these (am I wrong?) Did you mean ClassLoader or VMClassLoader? ClassLoader. AFAICT, VMClassLoader is never instantiated, so there's no point in adding instance fields to it. While every VM may need VM specific data fields I don't see how adding these really helps because you can't know how the VM needs to use them. OK.. but does it really hurt either? At least with the new field added, a VM has a remote chance of being able to use this class unmodified. On the other hand, can you show me a VM that doesn't modify this class but properly supports user-defined class loaders? I can't imagine how, because the VM is required to keep internal state associated with all class loaders that define classes. - Constructor.getParameterTypes() and getExceptionTypes() become native methods, to align with Field.java and Method.java, and because nowhere is the code that sets these fields anyway. Shouldn't there be VMConstructor, VMField, and VMMethod classes that are deferred to rather than making these native? Or is the expectation that a VM will have to modify these classes regardless? (I don't think there is much VM independent code that can really go in these classes, so expecting the VM to modify Constructor et al directly is not unreasonable. That's a different question from the one I'm trying to address, which is simply to make the API self-consistent. However, it would be fine by me if someone wanted to move the native methods into VMFoo classes. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: API clean up patch
Jeroen Frijters wrote: Thanks. Looks good. The only change I would make is to make vmdata in ClassLoader package accessible instead of private. Good point.. I'll make that change. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Announcing JC virtual machine 1.4.5
Announcing JC virtual machine 1.4.5 Changes in version 1.4.5: - Fixed problem with function attributes declarations on GCC >= 3.4. - Eliminate "bootstrap" code generation; just interpret when needed. - Added --disable-pregenerated-sources flag to ./configure. - Increased default thread stack size from 64K -> 256K. - Upgrade to Classpath 0.15. - Misc other minor fixes. JC is a Java virtual machine implementation that converts class files into C source files using the Soot Java bytecode analysis framework, compiles them with GCC, and loads them using a built-in ELF object file loader. JC utilizes the GNU Classpath class library and provides a fairly complete Java runtime including sophisticated optimizations to increase runtime performance. JC also includes a bytecode interpreter, and supports execution in either or mixed modes. http://jcvm.sourceforge.net/ Cheers, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
API clean up patch
I'd like to throw this patch out for comments; it fixes some of the
inconsistencies in our VM interface. The basic problem is that the VM
interface as a "stock" Classpath defines it is almost guaranteed to
require changes before a VM can actually work properly.
As a small example, consider this "stock" implementation of
VMThrowable.fillInStackTrace():
static VMThrowable fillInStackTrace(Throwable t)
{
return null;
}
Who wants a VM that's incapable of generating stack traces??
Of course, many VM implementors will want to modify the "stock" Classpath
API, which is fine.. I'd just like to not *require* them to do so if
they'd prefer to use Classpath as-is.
Along with these changes are removal of some deprecated stuff that's
been marked "this will be removed in a future version of classpath"
for a long time, and some other minor cleanups.
Summary of changes:
- Add a "vmdata" field to ClassLoader, VMThread, and VMThrowable.
Seems to me that every VM will require these (am I wrong?)
- Constructor.getParameterTypes() and getExceptionTypes() become
native methods, to align with Field.java and Method.java, and
because nowhere is the code that sets these fields anyway.
- Made VMThread.countStackFrames(), VMThrowable.fillInStackTrace(),
and VMThrowable.getStackTrace() native.
- Fixed broken VMClass.getModifiers() API (for correct behavior a
VM is required to change this).
- Removed deprecated methods from VMClassLoader
Let me know what you think.
Yes this changes the API, but IMHO until the major version number of
Classpath is a non-zero number we shouldn't worry about that too much..
better to clean house now while we still can..
Thanks,
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: java/lang/ClassLoader.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/ClassLoader.java,v
retrieving revision 1.50
diff -u -r1.50 ClassLoader.java
--- java/lang/ClassLoader.java 10 May 2005 09:29:48 - 1.50
+++ java/lang/ClassLoader.java 17 May 2005 14:52:52 -
@@ -246,6 +246,11 @@
Map classAssertionStatus;
/**
+ * VM private data.
+ */
+ private transient Object vmdata;
+
+ /**
* Create a new ClassLoader with as parent the system classloader. There
* may be a security check for checkCreateClassLoader.
*
Index: vm/reference/java/lang/VMClass.java
===
RCS file: /cvsroot/classpath/classpath/vm/reference/java/lang/VMClass.java,v
retrieving revision 1.11
diff -u -r1.11 VMClass.java
--- vm/reference/java/lang/VMClass.java 18 Apr 2005 08:57:50 - 1.11
+++ vm/reference/java/lang/VMClass.java 17 May 2005 14:52:55 -
@@ -191,12 +191,7 @@
* @see Modifer
* @since 1.1
*/
- static int getModifiers(Class klass, boolean ignoreInnerClassesAttrib)
- {
-return getModifiers(klass);
- }
-
- private static native int getModifiers(Class klass);
+ static native int getModifiers(Class klass, boolean
ignoreInnerClassesAttrib);
/**
* If this is a nested or inner class, return the class that declared it.
Index: vm/reference/java/lang/VMClassLoader.java
===
RCS file:
/cvsroot/classpath/classpath/vm/reference/java/lang/VMClassLoader.java,v
retrieving revision 1.24
diff -u -r1.24 VMClassLoader.java
--- vm/reference/java/lang/VMClassLoader.java 19 Mar 2005 23:07:55 -
1.24
+++ vm/reference/java/lang/VMClassLoader.java 17 May 2005 14:52:55 -
@@ -66,30 +66,6 @@
/**
* Helper to define a class using a string of bytes. This assumes that
* the security checks have already been performed, if necessary.
- * This method will be removed in a future version of GNU
- * Classpath.
- *
- * @param name the name to give the class, or null if unknown
- * @param data the data representing the classfile, in classfile format
- * @param offset the offset into the data where the classfile starts
- * @param len the length of the classfile data in the array
- * @return the class that was defined
- * @throws ClassFormatError if data is not in proper classfile format
- * @deprecated Implement
- * [EMAIL PROTECTED] #defineClass(ClassLoader, String, byte[], int, int,
ProtectionDomain)}
- * instead.
- */
- static final native Class defineClass(ClassLoader cl, String name,
-byte[] data, int offset, int len)
-throws ClassFormatError;
-
- /**
- * Helper to define a class using a string of bytes. This assumes that
- * the security checks have already been performed, if necessary.
- *
- * For backward compatibility, this just ignores the protection
- * domain; that is the wro
Announcing JC virtual machine release 1.4.4
Announcing JC virtual machine release 1.4.4 This release adds support for different calling conventions in generated JCNI code, and with this support enables passing of function parameters in the %eax, %edx, and %ecx registers on the i386 architecture. It also fixes a bug in method interface dispatch for certain methods having float parameters. See the CHANGES file for details. Changes in version 1.4.4: - Allow optimized calling conventions in JCNI (generated) code; on i386, pass the first three parameters in registers. - Add missing access modifier flag `abstract' for array classes. - Fixed JNI bug resolving (don't recurse to superclass). - Fix bug invoking interface methods that have 'float' parameters. - Make installation succeed even if JDK not found. http://jcvm.sourceforge.net/ Cheers, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: can Mauve help me test a PersonalJava implementation?
Steven Schwarz wrote: Thanks for the suggestion to make jars -- that will definitely help make things more convenient, if I can get around something else. Here's the something else: If I compile with a JDK 1.4.2 or 1.5.0 I end up with class files with major.minor version 46.0. If I attempt to run them with a PersonalJava or JDK 1.1.8 VM, I run up against the limitation that those VMs are only empowered to accept classes whose versions are in the range 45.0 .. 45.65535, i.e. strictly before version 46.0. JDKs 1.2.2 and 1.3.1 will produce class files with versions before 46.0, but unfortunately, cannot compile Mauve, as I explained in my previous posting. So I guess my question about whether I can use Mauve in the environment I need to is made equivalent to whether I can find a compiler that will compile Mauve producing classes with version strictly before 46.0. Any suggestions for such a compiler? I've only ever used Sun (or blackdown) JDKs. Will Jikes help? Just compile with "-target 1.4" (or whatever). -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: merge Jessie as an external project
Thomas Zander wrote: From this thread I note that most developers are worried about distribution issues, not development issues. Which I find strange. A classpath user should not have to download the tarball and compile it himself, and a typical user will not do that anyway. He will just apt-get (or yum*) the package and dependencies come along. The need to put external libraries in your CVS, is frowned upon in just about all projects I have contributed on. Yes, to me it seems like development and packaging are two different things. Seems like these things everyone agrees on.. 1. Everyone agrees on the need for a "one stop shop" download to get a JDK equivalent (or more). 2. If Jessie's CVS moves into Classpath's CVS then that eliminates the forked code maintenance problem. 3. To the extent that Classpath itself contains components that someone (e.g. embedded system users) might not want, it would be nice if you could ./configure the build to optional exclude those components.. i.e., more build flexibility is a good thing. So e.g. we should have --enable-jessie and --disable-jessie, etc. (defaulting to --enable). As long as #3 is realized then I guess I'm satisfied.. though I still think it's a bad idea to have copies of code that originates elsewhere actually checked in to our repo. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: merge Jessie as an external project
Thomas Fitzsimmons wrote: Classpath should (IMHO) simply be an implementation of the core Java classes, nothing more. I agree fully and that's the point of this proposal. SSL support is part of the "core Java classes" and that's why integrating Jessie into Classpath is different than integrating, say Java-GNOME. Sun's SDK includes an SSL implementation. They happen to ship it as a jar that is separate from rt.jar but it is still included on the boot classpath. The important point is that a JPackage SDK RPM includes an SSL implementation, with no external dependencies. We could simulate this in Fedora but in our RPM we'd need to carry a local patch that did the import I'm proposing. It's much more efficient to maintain this import upstream. I would argue that in general, Classpath's policy should be to include anything that's in Sun's SDK by default. For things like image and protocol providers I think we should strive to include more than Sun by default. For example, as both a Classpath developer and end-user, I'd much rather have the ability to read and write any image format by default. I don't want to have to search around for external plugins to build and install. If you want the full monty, it's easy to put that together, but don't force it on every one. I consider the full monty to be all Free Software written in the Java programming language. For stuff above the SDK, definitely, split it into separate packages. But for the SDK, our implementation should be at least as convenient out-of-the-box as Sun's. What you're saying makes sense from the "packaging" point of view. I.e., I agree that it's nice to be able to download one thing and get the complete package. There should be a "JDK equivalent" in free software. However it doesn't make as much sense from the developer's point of view. Classpath developers (I assume) want to focus on Classpath, not on maintaining Makefiles and 3rd party code build integration. Not to mention that some users of Classpath don't want all the extra junk, e.g., people targeting embedded systems. I guess then what I'm arguing for is that maybe Classpath should be split into multiple projects: one to produce the "core core" Classpath code (i.e., the code that lives as source code in Classpath's CVS and originates there), and others to produce a "JRE equivalent" (which includes Classpath, Jessie, Xerces, etc) and perhaps a "JDK equivalent" (which inludes as well a java compiler, etc.). I'm looking at Classpath as the former type of thing whereas you are looking at it as the latter type of thing. As Classpath exists right now it seems a lot more like the former. Instead of trying to morph it into a JDK/JRE replacement, let's create a separate project to do that. I'm curious what other Classpath developers think... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: merge Jessie as an external project
Thomas Fitzsimmons wrote: I propose that we build Jessie directly into glibj.zip. Having Jessie present by default would be convenient both for GNU Classpath developers and also for packagers. For GNU Classpath developers who want to test apps that require SSL, it would mean one less dependency to fetch and setup on CLASSPATH. For packagers obviously it would mean one less package to maintain. More importantly though, it would eliminate a circular dependency. In Fedora Core 4, for example we want a Java SSL provider available by default. This means that ideally the libgcj package should depend on the Jessie package. But Jessie's build requires libgcj. We worked around this by having java-gcj-compat depend on both libgcj and Jessie, and packages requiring a Java SSL provider requiring java-gcj-compat. However in my opinion this complexity is unwarranted especially given that Jessie's SSL provider jar is only 350K. Not to be a contrarian, but in general I don't like the idea of glomming in more and more libraries together like this. I'll try to emit some coherent reasons why... First, you are looking for a workaround to a dependency problem which is not of Classpath's making. "Ideally the libgcj package should depend on the Jessie package" -- perhaps that's true for Fedora, but if so it's because of a Fedora policy decision. That policy should be encapsulated in the Fedora build, not the Classpath build. If Classpath wants to help users to have a good experience, we can point them at the relevant external 3rd party libraries to go fetch. Secondly, there are good solutions out there to the JAR interdependency problem, namely Jpackage. Jpackage can eliminate the habit of every Java project shipping every other Java project's JAR files in its lib/ subdirectory.. invariably you end up with a zillion copies of the same JAR (e.g., xerces and xalan) but different (often incompatible) versions. Thirdly, there's the inevitable maintenance problem with having a copy of somebody else's code lying around.. it always goes out of date, becomes incompatible, etc. E.g., if my boot loader is loading an old, broken version of Jessie, just putting the new one in my (application) classpath won't work.. I have to perform surgery on my boot loader classpath. This actually happened to me with Sun's JDK because Sun ships an old, broken version of Xerces in their rt.jar (!) Finally (and this is only obliquely related), Classpath does not depend on libgcj. It builds just fine using Jikes... so don't assume they always go together. For example, I never use gjc (preferring JC of course :-) Classpath should (IMHO) simply be an implementation of the core Java classes, nothing more. If you want the full monty, it's easy to put that together, but don't force it on every one. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: NIO charsets attacked by gang of rabid platypi
Sven de Marothy wrote: Also, I'd like to know which NIO charset provider is preferred, now that we have two in CVS. (pure java and iconv-based) They complement eachother pretty well, iconv being somewhat faster in the actual conversion, but with more overhead for invocation (=slower on short strings, faster on long ones). Not really an answer, but here are some thoughts... All other things being equal, IMHO pure Java is better than Java+native. Of course all other things are not equal, in particular the speed question, but Java vs. native speed is very JVM dependent, so that detracts from the usefulness of using speed as a generic criterion. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RPM spec file?
PA wrote: Seems like in the Linux world it's more of a random free-for-all, though maybe Debian works like FreeBSD too? Perhaps you might like Gentoo's Portage: http://www.gentoo.org/main/en/about.xml Thanks, that looks very cool. It's good to know I'm not alone in my frustration :-) -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RPM spec file?
Andy Walter wrote: On Saturday 19 March 2005 00:32, Archie Cobbs wrote: Who do I ask about building a Debian package for JC? Are you sure you want to manually create rpm and deb packages? Thanks for the link... looks interesting. Preferably someone *else* would build the packages :-) This is how e.g. FreeBSD works: as a port maintainer all you need to supply are the build instructions, not the actual binary package. Seems like in the Linux world it's more of a random free-for-all, though maybe Debian works like FreeBSD too? In any case it seems silly to require every package maintainer to have lying around an instance of every possible Linux distribution just so they can build that flavor of RPM. Guess I've never really understood how it's all supposed to work on Linux. E.g., why isn't there a central repository for RPM spec files? Etc. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RPM spec file
Tom Tromey wrote: Archie> Only problem I've encounterd is that it conflicts with libgcj Archie> on the file /usr/lib/security/classpath.security. Not sure Archie> what to do about that. I suspect we ought to change how these providers are found. There's been some work in this area for Fedora Core, I think atm Tom Fitzsimmons has us installing separate provider files and then merging them in %post. On some systems there seems to be libgjc.security as well. Maybe gcj could be configured to use that instead? I'm not an expert in these files though, so if someone else is already solving the problem I should probably be quiet :-) Archie> %define version_num 0.14 Archie> %define release_num 1 It would be nice if this somehow came from configure, so we don't have to touch two places at release time. Gnome used to check in .spec.in files and AC_OUTPUT them, but I don't know how that worked out. Certainly that can be done, at least for version_num. The release_num is really up to the packager I suppose. I've checked it into the scripts/ subdirectory: 2005-03-22 Archie Cobbs <[EMAIL PROTECTED]> * configure.ac: Generate scripts/classpath.spec. * scripts/classpath.spec.in: New file. Cheers, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JC virtual machine release 1.4.0
Announcing JC virtual machine release 1.4.0. This release adds a Java bytecode interpreter and updates to Classpath version 0.14. There have been a few bug fixes as well. See the CHANGES file for details. JC is a Java virtual machine implementation that converts class files into C source files using the Soot Java bytecode analysis framework, compiles them with GCC, and loads them using a built-in ELF object loader. JC uses GNU Classpath's class library and provides a fairly complete Java runtime including sophisticated optimizations to increase runtime performance. JC also includes a bytecode interpreter, and supports execution in either or mixed modes. http://jcvm.sourceforge.net/ Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RPM spec file
FYI,
Here's the RPM spec file I came up with... pretty simple.
Only problem I've encounterd is that it conflicts with libgcj on the file
/usr/lib/security/classpath.security. Not sure what to do about that.
-Archie
______
Archie Cobbs *CTO, Awarix* http://www.awarix.com
# $Id$
%define version_num 0.14
%define release_num 1
Summary: GNU Classpath Java class libraries
Name: classpath
Version: %{version_num}
Release: %{release_num}
Group: Development/Tools
Copyright: GPL+exception
URL: http://www.classpath.org/
BuildRoot: %{_tmppath}/%{name}-root
BuildRequires: jikes, zip
Packager: Archie Cobbs <[EMAIL PROTECTED]>
Source: ftp://ftp.gnu.org/pub/gnu/classpath/classpath-%{version_num}.tar.gz
%description
GNU Classpath, Essential Libraries for Java, is a GNU project to create
free core class libraries for use with virtual machines and compilers
for the Java programming language.
%prep
%setup -n classpath-%{version_num}
%build
pushd ${RPM_BUILD_DIR}/classpath-%{version_num}
# Determine if we can build the GTK stuff
GTKPEER='disable'
if pkg-config --exists 'gtk+-2.0 >= 2.4 gthread-2.0 >= 2.2 libart-2.0
gdk-pixbuf-2.0'; then
GTKPEER='enable'
fi
%configure --with-jikes --enable-jni --${GTKPEER}-gtk-peer
make
popd
%install
pushd ${RPM_BUILD_DIR}/classpath-%{version_num}
%{makeinstall}
popd
pushd ${RPM_BUILD_ROOT}/%{_infodir}
rm -f dir
for i in *; do
mv $i classpath-$i
done
popd
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%clean
rm -rf ${RPM_BUILD_ROOT}
%files
%defattr(-,root,root)
%doc AUTHORS COPYING LICENSE README THANKYOU
%{_libdir}/classpath
%dir %{_datadir}/classpath
%{_libdir}/security/classpath.security
%{_datadir}/classpath/glibj.zip
%doc %{_datadir}/classpath/api
%doc %{_datadir}/classpath/examples
%doc %{_infodir}/*
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: RPM spec file?
Mark Wielaard wrote: There is an old one by Brian Jones. http://www.haphazard.org/~cbj/classpath/classpath.spec Thanks.. I've got basically the same thing with updated info and less hard-coded stuff. I'll post it after testing it out a bit. I'm also planning to put Classpath RPM(s) up in the JC SourceForge project download area with the next JC release. My motivation is that a JC RPM needs to depend on "classpath", but there's no RPM for Classpath yet. I see "classpath-inetlib", "classpath-mail", etc. RPMs.. but none for Classpath. I don't know that much about packaging. For Debian packages I believe they want to do their debian control files themselves and don't like to have them in the upstream sources. I don't know what the conventions are for rmp packages. But it seems a good idea in general. There are a couple of packages that can then depend directly on a classpath package. (Sorry if this is straying off-topic...) Who do I ask about building a Debian package for JC? Thanks, -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.14 released
Tom Tromey wrote: A couple years ago I promised to print more of these, and then totally failed to. I've still got the graphics... maybe I should just find some on-line t-shirt printer and let people order them? fyi, CafePress.com is great for this kind of stuff.. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RPM spec file?
Does an RPM spec file for Classpath exist? Is there interest in creating one? I'd be happy to work on it. We can save it in scripts/ or somewhere. My motivation is that a JC RPM needs to depend on "classpath", but there's no RPM for Classpath yet. I see "classpath-inetlib", "classpath-mail", etc. RPMs.. but none for Classpath. -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: benchmarks (was Re: Progress on a Classpath mauve suite?)
Stephen Crawley wrote: I agree that academic credit is very important. Again, I belive that to be a part of proper academic conduct, rather than something that needs to be explicitely enforced in a software license. Hah.. so why do we need the GPL? Isn't sharing your modifications with the world a natural consequence of good software conduct? :-) :-) -AC __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Progress on a Classpath mauve suite?
Roman Kennke wrote: If we're going to make these HTML pages the "official" place for VM implementors to look for this information, that's OK. I'd just like us to decide and then do it, keep them updated, etc. This can perhaps be automated, etc. They actually are (or were) automated. Mauve has been run in a daily cron job and the rendering of the results has been dynamic (on-demand). A comparison of the failures/successes between the VMs should not be that difficult to add. Great! Looking forward to seeing your stuff back up on the web. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Progress on a Classpath mauve suite?
Roman Kennke wrote: Ah, now I'm understanding. I think maybe you mean the mauve HTML pages that I once put together? This basically tested different runtimes against the Mauve suite and formatted to Mauve output nicely into HTML for displaying in a browser, so it is easily visible which tests fails (red) and which don't (green). Is that what you mean? If yes, then I can tell you that the nessecary scripts are not online ATM due to lack of resources on my side, but probably soon will be available again on developer.c.o. At least I hope so... Something like that :-) Basically, here's my problem. When I run Mauve against my VM, there are some test failures. Some are caused by Classpath and some are caused by my VM. Right now I don't know which is which. But if I did then that information would be very valuable, because it would save me a lot of time in tracking down the problem. I'm sure all the other VM implementors face the same situation. Sometimes I'm working on my particular VM and want to fix its bugs. Other times I'm working on Classpath and want to fix its bugs. So it's nice to know which bugs are which. This information does exist, we just haven't compiled it and made it easily accessible. Your HTML pages are a nice step in that direction. They still don't completely tell us whether a test failure is because of Classpath itself or not, i.e., it could be that all the tested VM's exhibit the same problem, but presumably that's pretty rare, so not a big deal. If we're going to make these HTML pages the "official" place for VM implementors to look for this information, that's OK. I'd just like us to decide and then do it, keep them updated, etc. This can perhaps be automated, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Progress on a Classpath mauve suite?
Roman Kennke wrote: http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137 we talked about putting together somehow a list of Mauve tests that all Classpath-based VMs should expect to pass, along with another (complementary) list of those tests a Classpath-based VM should expect to fail. Sorry if I am completely naive here, but why should there be tests, that a Classpath-based VM should be expected to fail?? Isn't the whole point to (ideally) pass all tests? If there would be such a test, I would rather rewrite the harness.check(cond) into harness.check(!cond) so that the (expected) failure passes... Ideally there should be no expected failures. In reality there always are, simply because some feature is unimplemented or some bug has not been tracked down yet. Obviously, any expected failures are good starting points for anyone looking to improve Classpath... another benefit of having (or being able to easily generate) such a list. You wouldn't want to change the test, because the test is written to the spec, not Classpath's (or any VM)'s particualr implementation. I.e., Mauve itself is independent of Classpath or any particular VM. It is supposed to represent what "run anywhere" actually looks like. -Archie ______ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Progress on a Classpath mauve suite?
In this thread: http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137 we talked about putting together somehow a list of Mauve tests that all Classpath-based VMs should expect to pass, along with another (complementary) list of those tests a Classpath-based VM should expect to fail. Ideally, there would be separate list pairs for each release of classpath, perhaps stored in Classpath's CVS, and it would be fairly easy to keep the list updated as fixes to Classpath were put in. I suggested one approach but it was never agreed to. It doesn't seem like there's been any progress since. This would really be useful so I think we should still try to do it. I'm open to suggestions. The first step is to agree how exactly to do it. Even an imperfect solution is better than none at all. Thanks, -Archie __________ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CORBA
Meskauskas Audrius wrote: I know that Jeff and Brian have planned some work on CORBA Classpath implementation. However the amount of work is tremendous: 25 packages in java 1.4. It may be sufficient work for more developers. Maybe it would be possible to create a CORBA team, divide the tasks and discuss the shared problems. We need the shared classes first, and then we can just take a separate package each. Is it time to start thinking about splitting off some of these Classpath sub-projects into separate builds/packages? E.g., we could have: classpath-core classpath-corba classpath-foobar etc. Otherwise things may get to be too monolithic (i.e., inflexible). In particular I'm thinking of embedded system applications, which may only want/need a subset of the whole shebang. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
