Re: Mauve reports
Roman Kennke wrote: Also, the ability to see/track when a failure started occurring could be very useful. That way we could easily match up new failures with patches that caused them. Hmm, that's an interesting feature indeed. We would have to keep diffs between versions around and teach the script to parse and display them somehow. I must think about this a little. It should become a bit easier with the new test harness. When you treat 1 test = 1 failure, each pass/fail can be uniquely identified, and regressions can be distinguished easily from new test cases. Bryce
Re: Mauve reports
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 welcome suggestions for improvements of this frontend. Sweet! I think it may be more useful to only report the failures. Scrolling through the many thousands of PASSes isn't really very interesting :) Also, the ability to see/track when a failure started occurring could be very useful. That way we could easily match up new failures with patches that caused them. Bryce
Re: libgcj merging and VMStackWalker
Andrew Haley wrote: Tom Tromey writes: > This week I spent some time looking at the libgcj/Classpath merge > situation. After removing all the simple merges that hadn't yet been > handled for some reason, I looked at VMStackWalker a little. > > I think this merge could be done fairly simply. In fact I think it > just requires adding a 'Class' argument to > VMStackWalker.getCallingClass and VMStackWalker.getCallingClassLoader. > This argument would name the immediate caller, and these methods > would be changed to return the class just above the argument class in > the stack trace. I think this is a bug. In the API spec, when the caller is wanted it is the immediate caller -- the calling method, not the calling class. We shouldn't be walking backwards until we see a different class. GetCallingClass(Class) is intended for situations where you really want the caller of an external API into the class, but due to overloaded methods or inlining may have an indeterminate number of frames between the external method and the site at which GetCallingClass() is called. java.lang.reflect and ResourceBundle are two examples where it is useful - we never want ResourceBundle.class or Field.class, for example, to be returned there. So, I don't think GetCallingClass(Class) is a bug - in fact it is important, because implementing the same functionality becomes more complicated and error-prone without it. You do of course need to be careful with where it is used, but that is also going to be the case with any alternative. In the case of gcc.gnu.org/PR27352, I think the problem is simply that Class.getClassLoader() is used internally within Class itself - we should be using getClassLoaderInternal(). I'm testing a patch. Bryce
Re: Summary of Mauve Results
Andrew John Hughes wrote: Collections === LinkedHashMap entrySet failures AcuniaHashMap test. (May be due to ConcurrentModificationException changes) These failures were due to the tests assuming the old behaviour of iterator.hasNext() checking for concurrent modification. I have now fixed the tests in mauve CVS. Bryce
Re: partial stub
Tom Tromey wrote: Bryce> Could JAPI scan for FIXME's as well? These could be flagged as Bryce> partial/known buggy method implementations. Nope, japi scans .class files. Hence the (clever :-) hack of a 'throws' clause. I'm not overly concerned about our ability to find FIXME comments -- grep or eclipse do this adequately. Also most of these comments indicate something a lot less drastic than an unimplemented method. True enough. Presumably, the Classpath coding style or Hacker guide will be updated to mention using the UnimplementedMethodException for stubs. I think it should also mention that FIXME comments should be used to flag things that are known to be incomplete or buggy. Often, I see XXX or other markers used instead. This makes it more difficult to find them with grep and such. Bryce
Re: partial stub
Tom Tromey wrote: In going through the stubs, I found java.awt.Image.getScaledInstance(). This method is interesting because it works for most cases, but not the SCALE_SMOOTH case. I'm not sure what to do here. I'm inclined to mark it as a stub. But maybe it isn't that different from any other 'FIXME'... comments? Could JAPI scan for FIXME's as well? These could be flagged as partial/known buggy method implementations. Bryce
Re: Mauve wishlist
David Gilbert wrote: 1) constant number of tests, regardless of exceptions being thrown or Mauve does have a design flaw where it can be tricky to automatically assign a unique identifier to each check(), and this makes it hard to compare two Mauve runs (say a test of the latest Classpath CVS vs the last release, or the Classpath vs JDK 1.5 - both of which would be interesting). Right. We all understand the problem - its just the solution is what we need to agree on :) I think the absolute number is meaningless however you count the tests, so I don't see this as an advantage. Yes, numbers alone are meaningless, but with the current design, all the results are meaningless without a lot of context. The real issue is having a simple way to uniquely identify each test case for the purpose of identifying regressions. This becomes fundamentally much easier when 1 test() method corresponds to one test case. It is not reasonable to expect test case developers ensure that all tests "run linearly". Exceptions can potentially be thrown at any time, so to ensure linearity, every check() call would need wrapped with a try/catch. You'll lose the ability to distinguish between an existing failure where (say) 1 out of 72 checks fail, and after some clever patch 43 out of 72 checks fail, but the new system reports both as 1 test failure. This is a valid concern. However, we will still track exactly which check() calls fail so that in the event of a test failure, a full diagnostic can be provided. In addition, we can still count the total number of check() calls executed, for statistical purposes. If the reduced test-case granularity does prove to be problematic in some cases - say some test() where a small number of checks fail for cases that are "hard to fix" problems and thus should be "xfailed" (to use gcc/dejagnu lingo), then that test case should probably be split. Alternatively, to avoid splitting things across multiple test classes, we could add JUnit-style support for multiple test() methods in a single test class. Bryce
Re: ResourceBundle optimisation
[EMAIL PROTECTED] wrote: While you are at it... I remember a discussion ( somewhere, somewhen long ago) about a probable bug with ResourceBundles, that they stay in memory (because of caching) and that they should be dropped from cache somehow. Maybe its a good idea to use one of the WeakReference-things to drop it when no longer needed. Yes, I think this a valid problem with the current implementation. Currently getBundle() keeps hard references to all the ClassLoaders that it is called from, meaning that none of those ClassLoaders (and hence the Classes and Resources that they load) can ever be garbage collected. This is solvable, however, by spitting the bundleCache into a two-level hashtable - the first being a WeakHashMap with the ClassLoaders as the keys. This way, when a ClassLoader becomes otherwise unreachable, it will be eligible for collection along with all the bundles it loaded. Another idea: invent a System.property to control cache-behaviour. With a useful default, users can tune as they like: cache, no cache, cache forever, cache with expiration... In general, I dislike adding additional, non-standard system properties. They create new code paths that will rarely get exercised, meaning additional testing & maintenance work. Meanwhile, users rarely bother to set them to anything other than the default. In a few cases, it might be worthwhile to add one, but I suspect not here. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: ResourceBundle optimisation
Thanks for the explanation, Nicolas. You are correct, the current caching strategy does not work when the same base resource is loaded repeatedly for many different locale arguments. I'm looking at a solution that will fix this but continue to avoid the string concatenations and allocations in the common case. getBundle() has a significant effect on the performance of things like java.util.Calendar, so I'd like it to continue to be as fast as possible. Bryce Nicolas Geoffray wrote: No, because in tryBundle, a new string is created with basename + locale. It is that new string that is put in the cache, not just the basename. For example, say you're looking for a resource "MyResource" with locale en_US. If it is found, then the result is cached with a key created from MyResource_en_US, not MyResource. Never the less, I'd be interested to know where the 2 minute speedup came from, and if there is anything we can do to improve ResourceBundle without breaking its semantics. Does Tomcat request the same bundle baseName for many different locales? It is when it loads struts. It is looking for a resource ApplicationProperties with all the locales classpath has. With the current implementation of ResourceBundle, looking for all resources takes a real long time. Here's an example : 1) You're in getBundle looking for resource ApplicationProperties with locale AA_aa 2) It's not in the cache, so you go into tryBundle 3) In tryBundle, you don't find ApplicationProperties_AA_aa 4) In tryBundle you find ApplicationProperties_AA so you return it 5) In getBundle you cache ApplicationProperties_AA_aa with the result (ApplicationProperties_AA is not cached) 6) In the next getBundle, you're looking for ApplicationProperties with locale AA... The patch improves the researches by caching ApplicationProperties_AA. Even better, in tryBundle when a result is found for a resource, we could cache all intermediary resources we were looking for. For example if we were looking for ApplicationProperties_AA_aa, and finally found a result for ApplicationProperties (with no locale), we could cache ApplicationProperties, ApplicationProperties_AA_aa, and ApplicationProperties_AA with that same result. I haven't done this greater optimisation, as i'm not sure of the correctness of the patch regarding "the most specialized bundle" in tryBundle. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: ResourceBundle optimisation
Thomas Zander wrote: I'm pretty sure its not an API design to disallow this. So its implementation specific and your argument that Sun does not do it is indeed a pretty strong one. I'm not sure I agree with it, but its a good argument nontheless. ... My original point still stands; loading "foo.properties" while "foo_nl_NL.properties" was requested will effectively make it impossible to find foo_nl* if its placed in the classpath later. Which is definitely not what I expect. Tomcat and other servers implement re-loading of existing classes by loading them into a new ClassLoader. This way, old instances of the classes will be garbage collected when their ClassLoader becomes unreachable. Resources work in the same way: ResourceBundles are cached per-ClassLoader, so modified bundles will be reloaded if getBundle() is called from a class loaded by a new ClassLoader. I have not confirmed that this is the behaviour you get from Sun's implementation, but I suspect it is. I also think it provides a good balance between caching performance and the flexibility to reload things in a long-running server. getBundle() is called a lot, so it should be very fast in the common case - ideally avoiding allocations or making system calls. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: ResourceBundle optimisation
Thomas Zander wrote: Won't that break things when new (more specialised) resource bundles are added to the classpath at a later time? Then again, we probably also don't store URL of already loaded RBs to check if the file was updated so we can reload. I don't think its valid to make changes to the resource bundles at runtime. We can't really cache things at all if this were allowed. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: ResourceBundle optimisation
Nicolas Geoffray wrote: My mistake, i gave you a patch against classpath-0.13. Here's a patch against the latest cvs. Nicolas Geoffray wrote: Hi everyone, I've been doing benchmarks beween my vm and another one launching Tomcat and noticed that the startup spent a long time trying to find Resouces with getBundle. The thing is, ResourceBundle uses a cache for the resources it founds, but i think it's not perfectly used. When getBundle is entered, it first tries to find the resource in the cache. If it's not found, it calls tryBundle. Then tryBundle tries to load ressources with different locales, but never searches in the cache, allthough it could. I made a patch for it and gained 2 minutes during startup of tomcat (using an ibook 500Mhz). It's attached. Hi Nicolas, I don't think this patch is correct. If an application requests the same bundle baseName, but with a different locale, the locale argument will be ignored and the first bundle placed in the cache will be returned. Never the less, I'd be interested to know where the 2 minute speedup came from, and if there is anything we can do to improve ResourceBundle without breaking its semantics. Does Tomcat request the same bundle baseName for many different locales? Regards Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Patch] java.util.logging.LogManager
Sven de Marothy wrote: On Fri, 2005-04-22 at 15:27 -0400, Bryce McKinlay wrote: Sven, Firstly, please don't ever put formatting and code changes in the same patch! This is bad because it makes it difficult to distinguish code changes from changes that are purely reformatting. Actually, I'm taking back my previous apology, since I looked back and discovered that I did indeed seperate the patches. (although not the commits). http://lists.gnu.org/archive/html/classpath-patches/2005-02/msg00084.html Ahh, ok. I think that doing separate commits is important as well, as for someone browsing through the CVS history it will be difficult to see code changes amongst the noise of the formatting changes. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Patch] java.util.logging.LogManager
Michael Koch wrote: Hi list, I just commited the attached patch to merge it from GNU classpath to HEAD to. It mainly reformates the LogManager.java file and fixes an issue with logger keys. Michael 2005-04-22 Sven de Marothy <[EMAIL PROTECTED]> * java/util/logging/LogManager.java: Reformatted. (readConfiguration): If a logger for a key is not found, create one. Sven, Firstly, please don't ever put formatting and code changes in the same patch! This is bad because it makes it difficult to distinguish code changes from changes that are purely reformatting. Secondly, some of the formatting changes you made go against out established style. We break lines at 80-columns unless there is no way to cleanly do so. Also, 2-char indenting should be used for all methods, including "static" blocks. Bryce @@ -132,20 +129,19 @@ * behave differently from the reference implementation in * this case. */ - private final PropertyChangeSupport pcs -= new PropertyChangeSupport(/* source bean */ LogManager.class); + private final PropertyChangeSupport pcs = new PropertyChangeSupport( /* source bean */ + LogManager.class); ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Unstructured locking bug
Etienne Gagnon wrote:
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
So, the current AWT code clearly does something that the JNI spec does
not allow for.
OK. It might be possible to fix this by moving the synchronization to
the Java level. eg in EventQueue.getNextEvent():
synchronized (queueLock)
{
...
callGtkThreadsEnter();
}
tk.iterateNativeQueue();
synchronized (queueLock)
{
callGtkThreadsLeave();
...
}
However, implementing this approach is not quite as simple because
iterateNativeQueue() is called more than once and also called within
nested flow control. A redesign of getNextEvent() is probably needed -
converting some of the if and while constructs into local state
variables which determine whether or not iterateNativeQueue() should be
called.
Bryce
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Unstructured locking bug
Etienne Gagnon wrote: Recent gtk peer code seems to have introduced a subtle bug, only visible on VM's that verify that structured locking is properly done. I have put a description of the bug in the bug tracker at: http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=12301 There seems to be an easy fix: 1- *Remove* the MonitorExit() ... MonitorEnter() calls [yes, they're in that order!] 2- Document somewhere (in the awt/gtk documentation) the hierarchy of locks: one must release the GDK lock before acquiring the EventQueue lock, iterateNativeQueue() needs to behave like wait(), because we need to allow threads to post events to the Java event queue while the EventDispatchThread is blocked in the GTK main loop. gtk_main_iteration could potentially block forever if there is no human/external event input, so other threads wishing to post events to the queue will block. For example: if the lock is not released, a thread drawing animations based on a timer wouldn't work correctly unless there is constant GTK event input because the "animation thread" would be blocked on postEvent(). I agree this approach is flakey, though - it isn't going to work if the queue lock is held at (depth > 1), and currently that is possible because it is a user-visible lock. Certainly, bytecode isn't allowed to do this kind of thing, but I'm not sure if the structured locking rules in the VM spec are meant to apply to native code. For example, wait() would be impossible to implement if this were the case, wouldn't it? Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Progress on a Classpath mauve suite?
Roman Kennke wrote: Am Montag, den 07.03.2005, 21:49 -0600 schrieb Archie Cobbs: 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. 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? Ideally, yes. But in practice, it isn't practical to pass all the tests ;-). What mauve does need is an easier way to highlight regressions. Currently the way people check for regressions is to do before & after mauve runs and diff the output to look for new FAILs, which is obviously pretty tedious. It would be nice if mauve could do this automatically by feeding it a file containing a list of known FAILs for a given VM, so that it would only let you know about failures that were previously expected to pass (and successes that were expected to fail!). This is complicated a little by mauve's design - there isn't a way to uniquely identify each "test" (ie each check() call), and sometimes some check()'s wont be run if a previous one failed, so fixing one bug can sometimes cause more FAILs. This means that it may not be clear if a new FAIL is actually a regression or a check that just wasn't run before. We could make the tests more course-grained from the point of view of the expected-failure machinery - ie track success/failure at the Testlet level, but that has the disadvantage of potentially not showing new regressions within a given a testlet that was already failing. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Patch: FYI: Re: fix to LinkedHashMap.java
Thanks for spotting this. We actually have a mauve test case for this but it wasn't enabled due to a tags typo! I'm checking in the following patch. Bryce 2005-02-18 Bryce McKinlay <[EMAIL PROTECTED]> * java/util/LinkedHashMap (addEntry): Call remove() with key argument, not the HashEntry. Reported by Jean-Marie White. --- java/util/LinkedHashMap.java6 Nov 2002 14:03:43 - 1.6 +++ java/util/LinkedHashMap.java19 Feb 2005 03:13:42 - @@ -412,7 +412,7 @@ e.next = buckets[idx]; buckets[idx] = e; if (callRemove && removeEldestEntry(root)) - remove(root); + remove(root.key); } /** Eric Blake wrote: Sorry I haven't cleaned my inbox in a while, you mailed an account I no longer actively track, since I no longer have time to actively develop on classpath. Please send bug reports to the project mailing list, and not an individual developer, if you want faster response. According to Jean-Marie White on 11/18/2004 5:44 PM: Hi Eric, just a quick note to let you know that I fixed a bug in LinkedHashMap.java. In method void addEntry(Object key, Object value, int idx, boolean callRemove), the remove call should read: remove(root.key) and not remove(root) (You always remove a map entry by key, not by the entry itself) This may or may not have been fixed, but thought would let you know anyway. Thanks for your implementing the class in the first place!!! jm ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
David Daney wrote: My understanding is that you want to integrate the libgcj and classpath bug databases with but still maintain the current situation with the actual code where there are separate code bases. How would a bug be marked that is fixed in libgcj and not fixed in classpath? In general, that shouldn't happen. libgcj developers should be in the habit of committing such fixes simultaniously to classpath. In the rare case where for some technical reason a fix can't be committed to the classpath repository, this could be handled with something like the reported-against/known-to-work/known-to-fail fields in GCC. It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. I don't think so. The vast majority of the code is merged. The vast majority of class library bugs are applicable to both libgcj and classpath. There may be a few issues to overcome, but it will be much more convenient to have a single combined bug database. For one thing, if someone does file a bug against libgcj that is really a generic classpath bug, it should be very easy to "move" the bug upstream just by re-categorizing it. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: cleaning up the gnu.classpath.Configuration.java.in file
Dalibor Topic wrote: d) It attracts overly generic constants Configuration.DEBUG is used a handful of times, in pretty unreleted classes to do the same job that's done in other classes using a private constant with the same name. It's pretty confusing, as the decription of the option that generates LIBDEBUG (which is assigned to Configuration.DEBUG) asks to be defined to 1 if one wants "native library runtime debugging code enabled", which java code is not. So I'd like to replace the few uses of Configuration.DEBUG with private DEBUG constants, like in the large majority of code in the library. I agree completely. Note that as it was originally conceived, Configuration.DEBUG meant to compile debugging code in to the library. Because it was a final constant, potentially large/expensive debugging code could be completely removed from optimized builds. The idea was that additional, more specific, runtime flags would be used in addition to DEBUG, so that if you built a library with DEBUG you would then also set a system property or something that would enable debugging for the specific feature you're interested in. But, in hindsight, debuggers are good enough, classpath is relatively bug free :), and the situations where this has been useful are pretty rare. I have no problem with seeing it go. I also agree that we will be better off moving the other flags to a Classpath.properties file, or, depending on the flag, a System property set by the VM or Classpath itself during initialization. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: org. omg. CORBA implementation
Jeff Bailey wrote: The tentative plan at this point is to use Orbit, since that's the Official GNU ORB(tm). My gut feeling is that using a non-Java ORB wouldn't be the best technology decision for classpath. It doesn't make much sense to add Java bindings to a non-Java ORB when there are so many ORBs written natively for Java, and writing/testing/debugging JNI bindings may not be all that much easier than writing a Java ORB from scratch. On technology grounds, OpenORB[1] or JacORB[2] would seem to be better choices. Licensing is the real issue, but we shouldn't write off the possibilty of using these until the parties in question have been contacted. I suspect that just having the org.omg interfaces, and not a full ORB implementation, will be sufficient for many/most users. Questions regarding the licensing of these classes have prevented/delayed this from happening in the past. Bryce [1] http://openorb.sourceforge.net/ [2] http://www.jacorb.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Mauve results...
Hey David, Very nice. What did you use to format the results? Regards Bryce David Gilbert wrote: I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest CVS version of Classpath) and posted the results here for anyone that is interested: http://www.object-refinery.com/classpath/mauve-report/latest/ The above reports exclude about 10 test files that won't run for me yet - I'll look into those when I get a chance. Regards, Dave Gilbert. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: DST related Calendar regression
Noa Resare wrote: tis 2004-11-02 klockan 10:36 -0500 skrev Bryce McKinlay: Hi Noa, Thanks for looking into this. I agree that there is a bug here, as demonstrated by your mauve test, but I'm not sure that this is the correct fix. It should not be possible to set DST_OFFSET explicitly because DST_OFFSET changes at different times of the year depending on whether the Calendar is in DST or not according to the rules of it's TimeZone. ie: for a given timezone and date value, there is only one valid value for the DST_OFFSET field and it doesn't make sense to set a different one explicitly. Although the spec doesn't define what happens if you do this, I think the simplest (implementation-wise) and most logical approach is to ignore user attempts to set DST_OFFSET, which also appears to be what Sun's implementation does (recent ones, at least). Consider the following test case for an example: I think that treating DST_OFFSET and ZONE_OFFSET as read only is reasonable, and marginally better than the current solution, but please don't silently ignore any attempts to set DST_OFFSET. If we choose not to use the provided value as expected by for example SimpleDateFormat the only reasonable thing to do IMO is to throw an exception. Well, if I were designing the spec, I'd agree - throwing an IllegalArgumentException would definitely be the best thing to do here. Unfortunately, the "other" implementation doesn't do this, and in cases like this where the spec is vague, IMO it is usually better to follow (and document!) their behaviour when in doubt. It seems fairly unlikely that any existing code (aside from SimpleDateFormat) actually depends on the existing behaviour, so I don't think its a big deal to change it. We should, however, clarify our spec to explicitly state that attempts to set these fields are ignored. I'll probably write a patch that does this as you suggest tonight. Stay tuned :) Great! Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: DST related Calendar regression
Noa Resare wrote:
On 04-10-08 [EMAIL PROTECTED] checked in changes to java.util.Calendar
that effectively made an explicitly set DST_OFFSET value to a function
of the set TimeZone for the Calendar object if an other field (such as
YEAR) is set in the calendar after DST_OFFSET is set.
I think this is wrong, as someone who sets DST_OFFSET explicitly and not
via .setTimeZone() presumably knows what she is doing and expects the
provided DST_OFFSET to be used.
Hi Noa,
Thanks for looking into this. I agree that there is a bug here, as
demonstrated by your mauve test, but I'm not sure that this is the
correct fix. It should not be possible to set DST_OFFSET explicitly
because DST_OFFSET changes at different times of the year depending on
whether the Calendar is in DST or not according to the rules of it's
TimeZone. ie: for a given timezone and date value, there is only one
valid value for the DST_OFFSET field and it doesn't make sense to set a
different one explicitly.
Although the spec doesn't define what happens if you do this, I think
the simplest (implementation-wise) and most logical approach is to
ignore user attempts to set DST_OFFSET, which also appears to be what
Sun's implementation does (recent ones, at least). Consider the
following test case for an example:
import java.util.*;
public class TestDST
{
public static void main(String[] args)
{
Calendar c =
Calendar.getInstance(TimeZone.getTimeZone("America/Toronto"));
c.set(2004, Calendar.NOVEMBER, 1); // Not in DST period
c.set(Calendar.DST_OFFSET, -1);
System.out.println (c.get(Calendar.DST_OFFSET));
c.set(2004, Calendar.OCTOBER, 1); // In DST period
c.set(Calendar.DST_OFFSET, 0);
System.out.println (c.get(Calendar.DST_OFFSET));
}
}
With Sun's JDK 1.5, this gives the following output:
$ java TestDST
0
360
So, I think the real bug here is in SimpleDateFormat - it should only
use setTimeZone() and not try to set DST_OFFSET or ZONE_OFFSET
explicitly. We should clarify our Javadoc to specify that attempts to
set these fields explicitly are ignored.
Regards
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] GregorianCalendar mess
Jeroen Frijters wrote: Perhaps a separate pass to normalize the fields is needed, which can be called by both calculateDay() and computeTime()? The nasty thing about this class is that all of its state is protected, so subclasses could (theoretically) depend on all sorts of nasty implementation details. I don't know if we should care about such a theoretical scenario, but it bothers me never the less. Yeah, subclasses that (ab)use the protected state are asking for trouble. I think its much more important to get it right in terms of the public interfaces than worry about what subclasses might do. That doesn't work. The docs explicitly say that set doesn't do anything other than setting that particular field and the result of roll over depends on the contents of the other fields. For example, the follow code should print two identical dates: GregorianCalendar cal = new GregorianCalendar(); cal.set(Calendar.MONTH, Calendar.FEBRUARY); cal.set(Calendar.DAY_OF_MONTH, 31); cal.set(Calendar.MONTH, Calendar.MARCH); System.out.println(cal.getTime()); cal.set(Calendar.MONTH, Calendar.MARCH); cal.set(Calendar.DAY_OF_MONTH, 31); cal.set(Calendar.MONTH, Calendar.MARCH); System.out.println(cal.getTime()); On the other hand, consider something like: cal.set(Calendar.MONTH, Calendar.FEBRUARY); cal.set(Calendar.DAY_OF_MONTH, 31); System.out.println(cal.get(Calendar.DAY_OF_MONTH)); This will print "2" (in a leap year), indicating that the fields are being rolled/recalculated upon any get() call. I still think the right thing to do is to have a separate recalculation/normalization pass, including processing any roll-overs that might be required due to out-of-range values in a lenient instance. I think that proper rolling behaviour (currently we are pretty buggy here) could be implemented relatively easily using recursion. For example, if someone has set MINUTES to an out of range value, recalculate() updates the minute field, then since it rolls over to the hours field, call recalculate(Calendar.HOUR_OF_DAY, ...) with the recalculated hours value, which will may turn call recalculate(Calendar.DAY_OF_YEAR,..), and so on. Note that this recalculate() method would be different from the current calculateFields(), because it recalculates the fields solely based on the values of other fields, not from the milliseconds time value. This recalculation should be done, if necessary, at the start of any of the get() calls. This should fix numerous bugs with the current implementation, and would simplify other methods such as calculateTime() as they will no longer have to deal with out-of-range values. An interesting observation from mucking around with test cases: at least in JDK 1.5, isSet() always returns true. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: remove print statements from Security
Mark Wielaard wrote: If you remove this could you add a little note to VM Integration Guide doc/vmintegration.texinfo about the importance of setting up the system property gnu.classpath.home.url and how it is used by Security, LogManager and InitialContext to find default configuration files. Is there a reason to use a non-standard system property here? whats wrong with java.home? Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Locale ResourceBundles
David Holmes wrote: In contrast, the bootstrap classloader, which is used to load the "system classes" (those logically in the 'bootstrap classpath'), such a Object, Class, Calendar etc, may be null. If you do Calendar.class.getClassloader you are asking for the bootstrap loader not the "system loader". So which classloader do you actually want? Good question. As you point out, getSystemClassLoader() will give the application classloader, so if we use the result of getSystemClassLoader(), then resources could be loaded from the application classpath instead of just the bootstrap classpath (ie glibj.jar). Which one we want depends on whether users/applications should be able to add their own locale data independently of Classpath's. I'm not sure whether that would be a useful feature, but I'm going on the assumption that its not really a _bad_ thing. Any opinions? But, getSystemClassLoader is a privileged call and requires an AccessController.doPrivileged() to call safely in a secure environment. It requires a security manager check involving the calling classloader - which is the same overhead that you were trying to avoid by using the getBundle form that takes a classloader - at least when a security manager is installed. Yes, but the getSystemClassLoader() call only needs to be made once. After that, the ClassLoader can be stored in a private field and reused for subsequent getBundle() calls. Rather than having to add an AccessController.doPrivilaged() to every getBundle() call in every class that uses Locale data, I wondered if we can use a "LocaleHelper" class to cache the system classloader and simplify locale bundle lookups from the classes that need access to them. My question is - could the LocaleHelper class be a security problem? I'm confused as to who as is asking for what here and which code you are trying to optimise - my apologies if my lack of understanding has made me miss the point. I would expect caching to be performed at each level. If the calendar requires locale information and the locale requires a resource bundle, then I would expect Calendar to cache the locale, and locale to cache the resource bundle, and resource bundle to actually cache the resources. The missing link here is the Locale->ResourceBundle association. The Locale class is just an identifier, it doesn't have any API to actually load/examine the Locale information. This is left up to the classes that actually need the locale data to implement. Calendar could certainly maintain its own cache of Locale->bundle mappings, thus bypassing the classloader stuff, but I think that a) having too many levels of caching becomes counter-productive - ResourceBundle already has a perfectly good cache, and b) the problem is not just in Calendar: every class that wants to load Locale data would need its own cache. Any necessary security checks when acquiring the initial values would be performed as defined/required, but should only happen once per calender/locale combination. Short-circuiting the security checks would seem to me to be presuming what security checks needs to be made, and while it might seem harmless, to me it seems the wrong thing to do I don't think we're short-circuiting any security checks here. All we're doing is passing a ClassLoader explicitly to getBundle() instead of forcing it to look on the stack to determine which classloader to use. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Locale ResourceBundles
Over the weekend I looked a bit at ResourceBundle usage in Calendar etc
again.
The problem:
Various classes, such as Calendar, need to load Locale information from
ResourceBundles. The ResourceBundle.getBundle() calls are frequent
enough, eg every time a Calendar instance is created, and sometimes
every time certain calls are made, that the calling-classloader check
performed by getBundle can be a significant performance issue. To avoid
this check, we use the 3-argument form of getBundle(), which includes an
explicit ClassLoader argument.
However, getting the classloader argument for getBundle() can be a
problem. Currently we use the system classloader as returned by
getSystemClassLoader() (using something like
Calendar.class.getClassLoader() unfortunately doesn't work because that
may return "null" for the system classloader, and null is not a valid
argument for getBundle() ). But, getSystemClassLoader is a privileged
call and requires an AccessController.doPrivileged() to call safely in a
secure environment.
Rather than having to add an AccessController.doPrivilaged() to every
getBundle() call in every class that uses Locale data, I wondered if we
can use a "LocaleHelper" class to cache the system classloader and
simplify locale bundle lookups from the classes that need access to them.
My question is - could the LocaleHelper class be a security problem? As
far as I can tell it isn't - the worst that can happen is that untrusted
code could load a ResourceBundle using the system classloader, but since
getBundle() itself is not a privileged call, and getBundle() is not
called with elevated privileges anyway, I don't see any problems there.
The code could do the same thing by calling getBundle() directly. Have I
missed anything?
Bryce
/* LocaleHelper.java
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. */
package gnu.java.locale;
import java.security.AccessController;
import java.security.PrivilegedAction;
import gnu.java.security.action.GetSystemClassLoaderAction;
/**
* This class provides a convienient interface to access Locale information.
*/
public class LocaleHelper
{
/** The system classloader is used to load Locale resource bundles. Passing
* this to ResourceBundle.getBundle() explicitly avoids a potentially
* expensive calling-classloader check. */
private static ClassLoader systemClassLoader;
static
{
PrivilegedAction action = new GetSystemClassLoaderAction();
systemClassLoader = (ClassLoader) AccessController.doPrivileged(action);
}
/** Retrieve LocaleInformation ResourceBundle for the given locale. */
public static ResourceBundle getLocaleInformation(Locale locale)
{
return ResourceBundle.getBundle("gnu.java.locale.LocaleInformation",
locale, systemClassLoader);
}
/** Retrieve Calendar ResourceBundle for the given locale. */
public static ResourceBundle getCalendar(Locale locale)
{
return ResourceBundle.getBundle("gnu.java.locale.Calendar",
locale, systemClassLoader);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: java.util.Date mess
Jeroen Frijters wrote:
Hi,
I have some code that depends on unspecified behavior of java.util.Date.
In the Sun JDK if you pass out of range parameters to the Date
constructors that take year, month, date, etc. it will automatically
convert to a valid date (for example, new Date(104, 8, 41) is Oct 11,
2004.)
I have a rather lame patch that addresses this (see below), would anyone
object to this?
Hi Jeroen,
Unfortunately I don't think this patch is the correct fix.
GregorianCalendar should already "roll over" overflowed date values,
regardless of whether these are set by the constructor or by the add()
method - check the test case below for an example - so I believe the way
the Date() constructors are calling GregorianCalendar are correct.
import java.util.*;
public class Cal6
{
public static void main (String[] args)
{
Calendar cal = new GregorianCalendar(2004, 1, 45);
System.out.println (cal.get(Calendar.DAY_OF_MONTH));
}
}
I think the real problem lies in the interaction between
GregorianCalendar and TimeZone - we need to make sure the DAY_OF_MONTH
and other values in a lenient calendar instance get normalized before
querying the TimeZone.
Interestingly, I did some tests with overriding
SimpleTimeZone.getOffset() and it seems that Sun's implementation of
GregorianCalendar never actually calls this method. Perhaps they have
some private internal interface between Calendar and TimeZone.
Regards
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: TimeZone
Jeroen Frijters wrote: Hi, I'm not sure, but I think with the recent time zone changes there was a bug introduced. Does the patch below make sense? Hmm... have an example/test case? Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: About locale data ... (again)
Guilhem Lavaux wrote: As we always need a good locale database for GNU Classpath, I was thinking of a way to get it. The ICU locale converter is only partially satisfying as it does not have any collation rules generator (at least). I've seen that www.openi18n.org[1][2] has begun a new standard file format to interchange locale data. It is purely written in XML form and looks well documented. On IBM[3], we can find the locale database waiting to be converted. As it is written in XML it should be fairly simple to write a parser in Java for these data. Once it is parsed, we can (I hope) all the same generate the Java classes/properties corresponding to our internal representation. I may start soon (one/two weeks) to build the parser. Is there someone against it ? No, I think this is an excellent idea. Its something I've wanted for a long time too. One issue to consider is whether the compiled locale data should be represented by properties files or java source files. Currently libgcj's locale date uses java files, but this has been a bit inefficient in terms of space used in the compiled .so. However, this overhead should be reduced with the BC-ABI, so if .class files are preferred for other VMs then I wouldn't be opposed to continue doing it this way. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: http.agent patch
[moving this to the gcj and classpath lists] Mark Wielaard wrote: On Mon, 2004-07-12 at 00:01, Bryce McKinlay wrote: I believe the following patch addresses both concerns and makes sure that even when the Connection class is loaded/initialized from a class with not enough permissions it can still get at the necessary system properties. I wonder if we really need to use AccessController.doPrivilaged() in a static initializer. Won't the class initialization code, which calls the static initializer, already be privilaged? Yes you need that. The idea behind the whole security model is that a programmer needs to explicitly say whether or not they need/want only their own ProtectionDomain to be used with any access checks. This makes sure that under "normal" circumstances only security sensitive code can execute that the developer and the user set security manager allow to execute. It reliefs the developer to think about all the ways the code can potentially be called from an insecure environment. If you insert a doPrivileged() call you assert that you have thought about all ways this code can potentially be used from an insecure environment. Yeah. Have a look at http://java.sun.com/j2se/1.4.2/docs/guide/security/doprivileged.html, particularly the bit about "GetPropertyAction". The syntax they suggest here addresses some of my concerns about PrivilagedActions. Namely, having a non-anonymous PrivilagedAction implementations to do common actions like System.getProperty() avoids the ugly anonymous class syntax I've seen elsewhere. My other concern has been efficiency. Thinking about this more, the amount of calls that need to be privilaged is probably not as extensive as I first thought. Provided we follow some simple guidelines to ensure we are not making privilaged calls where we don't need to - for example, ensuring that all getProperty() calls are done only from static initializers, I think the overhead should be managable. Moving forward, what we need is a list of all the calls that need to be privilaged - presumably this means calls that can throw SecurityException, and a list of all the places where they are called within the core classes. Does anyone have a tool that can do this? Hmm, maybe we can make an eclipse plugin to do it. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Mark Wielaard wrote: Does anybody know what version of gcj we need to avoid this complaint? We should update the configure script appropriately. The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually includes a couple of patches for the compiler... One of which looks like it was for the above issue. Darn. So you might actually need the 3.4 FSF release. If someone wants to identify the patch in question, and post a bug report to gcc.gnu.org/bugzilla, we can probably get that patch into the 3.3.5 release. This will make sure that other distributions still using gcc 3.3 pick up the fix. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: license question
Ben Hinkle wrote: I'd like to port the Collections implementation in Classpath to another language called D that is very similar to Java and I'm trying to figure out the Classpath license. My question is simple: what license would such a port fall under? It looks like Classpath uses the GPL (not LGPL) with the "special exception" which states that if one links statically *or dynamically* to the classpath library that the sum is governed by the GPL. But then there is the statement that "independent modules" aren't governed by the GPL. So I interpret that to mean "independent modules" are ones that aren't linked statically or dynamically with Classpath. No. "An independent module is a module which is not derived from or based on this library." For example, if you took Classpath collections code and made modifications to it, the modified code is subject to the terms of the GPL+exception, and is not an independent module. If you have some application code that USES classpath via the public java.* APIs, this IS an independent module. If you link it with classpath, it is not subject to the terms of the GPL+exception. You can think of the classpath license as being similar to the LGPL, but with less restrictions on the manner in which code that uses the library may be linked. I'm not even sure what those are. I'm guessing that using the classpath jar and class files are not considered dynamic linking? IMO, class files == dynamic linking. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Dalibor Topic wrote: Bryce McKinlay wrote: Again, these exceptions should be documented as part of our API documentation. They are exceptions that should _never_ happen. No call from the application should cause them to be thrown, thus they are not part of the API. If they are ever thrown, then there is a bug in classpath. Nevertheless, applications should have the ability to try and continue in the face of classpath bugs if they need fault tolerance. Can't we just use assertions for things that should never happen? In this case I think its better not to, because assertions may be disabled in production builds. In this case we're just rethrowing exceptions that occured within classpath, and although these exceptions arn't supposed to happen, we _do_ want to know about them if they do. On the other hand, I think assertions are the best bet in cases where the check itself makes the code more expensive, and you want to add some extra sanity tests to debug builds. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay wrote: 7) Document using @throws and use the throws keyword as per Sun's API. If you document too much, this makes it difficult to adjust if Sun ever updates things, because users might rely on Classpath's old behaviour. Again, these exceptions should be documented as part of our API documentation. Oops - this should have read "these exceptions should NOT be documented ..." Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Chris Pickett wrote: 5) Otherwise, if you need to throw an exception, and it is not strictly VM-related, and the user might have a hope of recovering, throw a subclass of RuntimeException, as per item (2). 6) Otherwise, throw something like UnrecoverableGNUClasspathError (needs deciding). Use this if the application must always die. I'm not sure that its worth making up new exception classes. It seems to me that serious internal VM/low-level runtime errors that are unlikely to be recoverable should throw InternalError, where as other errors should throw RuntimeException (or some subclass thereof). I agree that the type of exception should be specialized as much as possible, however there are many circumstances that simply do not fit into any of the available subclasses. In these situations I think RuntimeException is the best choice, so a blanket ban on throwing RuntimeException doesn't seem reasonable. 7) Document using @throws and use the throws keyword as per Sun's API. If you document too much, this makes it difficult to adjust if Sun ever updates things, because users might rely on Classpath's old behaviour. Again, these exceptions should be documented as part of our API documentation. They are exceptions that should _never_ happen. No call from the application should cause them to be thrown, thus they are not part of the API. If they are ever thrown, then there is a bug in classpath. Nevertheless, applications should have the ability to try and continue in the face of classpath bugs if they need fault tolerance. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: How to seperate the compilation of C source code and Java source code of CLASSPATH?
C. Brian Jones wrote: What is _the_ best and single free software java compiler to get behind and use these days? Which one has the best jacks test suite score? Just guessing here: for jacks testsuite scores I think my money would still be on jikes, however ecj might be close. You can get an ecj that builds out of the box with gcj as part of RHUG. ecj is very fast: it can build libgcj (over 2100 .java source files) from scratch in under 7 seconds on my P4 system. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote:
If a library call failed because of an internal bug that results in a
RuntimeException being thrown, how is that different from a library call
that fails because of an internal bug that causes, for example,
NullPointerException (which extends RuntimeException) to be thrown?
Many event loops have the form
for(;;) {
try { ... } catch(Exception) { /* recover */ }
}
If you throw a RuntimeException, then the application continues.
If you throw an Error, then the application stops.
That is the main difference between the two. I have never seen it
advocated that event loops catch Errors, ignore them and continue.
I understand this. But why shouldn't an application be allowed to
continue after a failed library call? My earlier point stands: What is
the difference between a buggy method that throws a NullPointerException
and a buggy method that throws a RuntimeException? None, IMO.
Its up to the application author to determine how robust their
application must be - as class library developers we should not try to
force the application to shut down just because we wrote a buggy
implementation of something. If Errors are not caught, then
InternalError should be used for problems that are so bad that the
application could not possibly continue.
The AssertionError case is different, because assertions are typically
disabled in production systems.
Regards
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
C. Brian Jones wrote: On Tue, 2004-07-06 at 12:22, David Daney wrote: If don't like the idiom new InternalError().initCause(), then add a constructor to InternalError (and perhaps Error also) so that you can pass the cause as a constructor parameter. As pointed out, Classpath does not add to the published, public, API of the core classes intentionally for compatibility. I too think RuntimeException would be incorrect in these situations, clearly an error should be thrown instead that indicates the dire situation the runtime is now in and the need to fix a potential library bug. The use of initCause() would seem appropriate if a cause exists. While applications can recover from many forms (maybe all) RuntimeExceptions, it is probably impossible to recover from InternalErrors. If a library call failed because of an internal bug that results in a RuntimeException being thrown, how is that different from a library call that fails because of an internal bug that causes, for example, NullPointerException (which extends RuntimeException) to be thrown? IMO, InternalError should be reserved for virtual machine and low-level runtime errors, as suggested by the spec - not generic class library bugs as is the case here. InernalError also suggests to me a more serious bug than what could be occuring in these situations - ie that something is seriously screwed up with the internal state of the runtime, whereas a RuntimeException just means that the call failed due to a bug in a peice of library code, which is what would be happening here if these exceptions ever got thrown. Its something of a moot point whether an application should be able to recover from these or not - they are errors that can/should never happen. Even so, it is certainly possible to imagine applications where continuing after a failed library call is preferrable to not being able to continue at all. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote: Does it say somewhere that we cannot add public methods while maintaining compatibility with Sun's implementation? Yes, this is one of the "license terms" of the Java specification. Although we do not (can not) meet the other conditions of this license, the goal of the classpath project is to provide a class library that is compatible with the Java specification. Adding new public APIs to the core classes would mean that classpath is no longer compatible. It doesn't seem like a good idea to use an unsuitable exception type just because its API has a slightly more elegant constructor. I do not believe that RuntimeException is unsuitable. It seems a better match than InternalError. Regards Bryce [1] http://java.sun.com/j2se/1.4.2/docs/relnotes/license.html ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote: We can't add constructors to InternalError, as that would violate the spec. Which spec. would that be? I am unfamiliar with it. David Daney. The Java 2(TM) Platform API specification[1] [1] http://java.sun.com/j2se/1.4.2/docs/api/ Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote: I wonder if we should standardize on using RuntimeException in these cases. A quick grep through the source code shows that we use both InternalError and RuntimeException for these "shouldn't/can't happen" catch blocks in various cases. I think RuntimeException would be a better choice, since it has a proper "cause" constructor for re-throwing exceptions. I don't like this idea. RuntimeException is meant to be the base class for Exceptions that can reasonable be expected to be thrown from error free library code when called by buggy application code. InternalError as its name suggests is meant to be thrown in situations that could only be caused by a bug internal to the runtime. If don't like the idiom new InternalError().initCause(), then add a constructor to InternalError (and perhaps Error also) so that you can pass the cause as a constructor parameter. We can't add constructors to InternalError, as that would violate the spec. InternalError extends VirtualMachineError, and is documented in the spec that it is "Thrown to indicate some unexpected internal error has occurred in the Java Virtual Machine.". Its questionable whether generic library code such as this can be considered part of the virtual machine. In any case, the lack of a "cause" constructor for InternalError pretty much rules it out for using in these situations - it clearly wasn't intended for chaining/rethrowing internal exception. RuntimeException subclasses are certainly exceptions that are expected to be thrown due to bugs in application code incorrectly calling the library, but there are also many cases where they could be thrown due to bugs in the runtime code. NullPointerException, for example, is a RuntimeException subclass. I'm sure I've seen that thrown once or twice due to bugs in Classpath ;-) Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Ranjit Mathew wrote:
Mohan Embar wrote:
Just out of curiosity, why is the result of new InternalError()
being explicitly cast to an InternalError?
Look closely - it's the return value (a Throwable) from
initCause() that is being cast into an InternalError:
+// Can't happen.
+throw (InternalError) new InternalError("Unconvertible file: "
+ + this).initCause(use);
I wonder if we should standardize on using RuntimeException in these
cases. A quick grep through the source code shows that we use both
InternalError and RuntimeException for these "shouldn't/can't happen"
catch blocks in various cases. I think RuntimeException would be a
better choice, since it has a proper "cause" constructor for re-throwing
exceptions.
Its also probably not worth bothering with string constants in the
"can't happen" cases. This case could be rewritten as:
--- File.java 6 Jul 2004 02:52:54 - 1.39
+++ File.java 6 Jul 2004 15:38:12 -
@@ -893,8 +893,7 @@
catch (URISyntaxException use)
{
// Can't happen.
-throw (InternalError) new InternalError("Unconvertible file: "
- + this).initCause(use);
+ throw new RuntimeException(use);
}
}
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: JDK 1.5 support?
Tom Tromey wrote: Andrew> The hardest thing would seem to be the generics (Java's Andrew> templates -- is it or me or does it seem strange that Java Andrew> 1.5/5.0 is basically bringing back in lots of C++ features, Andrew> mainly as a result of C# having them?). I think there's no question that Java is being strongly influenced by C#. For what its worth, C# currently doesn't have generics (or templates), and generics for Java were in development long before anyone had heard of C#, so this isn't a case of Java copying C# features. That isn't to say I don't think cherry-picking a few more features from C# wouldn't be a good idea, of course ;-) Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Javadocs
David Gilbert wrote: I'm familiarising myself with GNU Classpath at the moment, with the hope that I can contribute something in the future (copyright paperwork is in process). A quick question - are there any Javadocs online anywhere? I couldn't find any, but maybe I missed somewhere obvious? Anyway, I generated them from source (using javadoc) and would be happy to upload them somewhere if that would help. As far as I know, the classpath javadocs are not yet officially online anywhere. It would, however, be cool to have them on the web somewhere, and automatically generated from CVS classpath sources. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: FYI: More efficient ResourceBundle calls
Dalibor Topic wrote: I think the solution here is to pass the system class loader. This should always be correct for these bootstrap classes. It doesn't solve the performance issues for cases where a security manager is present, since a check will be performed by the getSystemClassLoader call - however its better than what we had before and certainly better than my incorrect patch ;-) Ah, the curse of getting microoptimizations right ;) I don't really consider this to be a micro-optimization. In libgcj it causes pretty severe performance problems. You could argue that this is because libgcj's calling-classloader check is too slow, and you'd be right, but I would imagine that in most VMs, stack-walking checks are relatively slow. Given that code like "new Date()" is very frequently executed in many apps, I think its important to make this as fast as we reasonably can. Of course, I will concede that correctness must take presidence over performance :) I think the patch is still wrong, in cases where one uses a Calendar class that's not loaded via the system class loader (like the bootstrap class loader, extension class loader, etc [1] :). Hmm - but can this ever happen? Is it possible to define a core class with a non-system class loader? In any case, it seems to me that it should always be correct to load Locale resources etc with the system class loader - or is there a situation I havn't considered? Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: FYI: More efficient ResourceBundle calls
Mark Wielaard wrote:
On Tue, 2004-06-15 at 16:56, Bryce McKinlay wrote:
I'm checking in this patch from libgcj. It changes various
ResourceBundle.getBundle() calls to use the 3-argument form which
includes a ClassLoader parameter. This call is more efficient because
it means getBundle() does not have to walk the stack to find the
calling classloader. This should speed up some Date/Calendar
operations which are currently quite slow due to repeated calling
classloader checks. Other VMs may implement the classloader check
faster than libgcj does currently, however it will presumably always
be faster to pass the classloader explicitly - so please use the
3-argument form when adding new getBundle() calls.
This looks a bit bogus to me.
-return ResourceBundle.getBundle(bundleName, locale);
+return ResourceBundle.getBundle(bundleName, locale,
+ Calendar.class.getClassLoader());
In every case you call getClassLoader() on a bootstrap class. So you
already know that it will be null. So you could have just passed in null
as loader. But ResourceBundle.getBundle() is documented to throw a
NullPointerException when any of its arguments is null. It seems we have
a bug because we don't throw a NullPointerException (we used to throw it
when we used HashTable, but we switched to HashMap which allows null
values), but the kaffe implementation does (IMHO correctly) throw a
NullPointerException.
OK, in libgcj, getClassLoader() never returns null, but the spec does
say that implementations may use null to represent the bootstrap
classloader. Since the classloader argument to getBundle() may not be
null, so we have a problem.
I think the solution here is to pass the system class loader. This
should always be correct for these bootstrap classes. It doesn't solve
the performance issues for cases where a security manager is present,
since a check will be performed by the getSystemClassLoader call -
however its better than what we had before and certainly better than my
incorrect patch ;-)
I'm checking in this.
Regards
Bryce
2004-06-15 Bryce McKinlay <[EMAIL PROTECTED]>
* java/util/Calendar.java: Use getSystemClassLoader as argument for
ResourceBundle.getBundle() calls.
* java/util/GregorianCalendar.java: Likewise.
* java/util/Currency.java: Likewise.
* java/text/BreakIterator.java: Likewise.
* java/text/Collator.java: Likewise.
* java/text/DateFormat.java: Likewise.
* java/text/DateFormatSymbols.java: Likewise.
* java/text/DecimalFormatSymbols.java: Likewise.
* java/text/NumberFormat.java: Likewise.
* java/awt/Window.java: Likewise.
Index: java/util/Calendar.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/Calendar.java,v
retrieving revision 1.20
diff -u -r1.20 Calendar.java
--- java/util/Calendar.java 14 Jun 2004 15:51:36 - 1.20
+++ java/util/Calendar.java 15 Jun 2004 22:37:11 -
@@ -377,7 +377,7 @@
private static ResourceBundle getBundle(Locale locale)
{
return ResourceBundle.getBundle(bundleName, locale,
- Calendar.class.getClassLoader());
+ ClassLoader.getSystemClassLoader());
}
/**
Index: java/util/GregorianCalendar.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/GregorianCalendar.java,v
retrieving revision 1.21
diff -u -r1.21 GregorianCalendar.java
--- java/util/GregorianCalendar.java 14 Jun 2004 15:51:36 - 1.21
+++ java/util/GregorianCalendar.java 15 Jun 2004 22:37:11 -
@@ -91,7 +91,7 @@
private static ResourceBundle getBundle(Locale locale)
{
return ResourceBundle.getBundle(bundleName, locale,
- GregorianCalendar.class.getClassLoader());
+ ClassLoader.getSystemClassLoader());
}
/**
Index: java/util/Currency.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/Currency.java,v
retrieving revision 1.3
diff -u -r1.3 Currency.java
--- java/util/Currency.java 14 Jun 2004 15:51:36 - 1.3
+++ java/util/Currency.java 15 Jun 2004 22:37:11 -
@@ -55,7 +55,7 @@
{
this.locale = loc;
this.res = ResourceBundle.getBundle ("gnu.java.locale.LocaleInformation",
- locale, Currency.class.getClassLoader());
+ locale, ClassLoader.getSystemClassLoader());
}
/**
Index: java/text/BreakIterator.java
===
RCS file: /cvs/gcc/gcc/libjava/java/text/BreakIterator.java,v
retrieving revision 1.8
diff -u -r1.8 BreakIterator.java
--- java/text/BreakIterator.java 14 Jun 2004 15:51:36 - 1.8
+++ java/text/BreakIterator.java 15 Jun 2004 22:37:11 -
@@ -136,7 +136,7 @@
{
ResourceBundle res
= ResourceBundle.getBundle("gnu.java.locale.LocaleInformation",
- loc, BreakIterator.class.getClassLoader());
+ loc, ClassLoader.getSystemClassLoader());
classN
Patch: FYI: More efficient ResourceBundle calls
Hi all.
I'm checking in this patch from libgcj. It changes various ResourceBundle.getBundle()
calls to use the 3-argument form which includes a ClassLoader parameter. This call is
more efficient because it means getBundle() does not have to walk the stack to find
the calling classloader. This should speed up some Date/Calendar operations which are
currently quite slow due to repeated calling classloader checks. Other VMs may
implement the classloader check faster than libgcj does currently, however it will
presumably always be faster to pass the classloader explicitly - so please use the
3-argument form when adding new getBundle() calls.
Tom Tromey suggested adding this to the classpath hackers guide.
Regards
Bryce
2004-05-28 Bryce McKinlay <[EMAIL PROTECTED]>
* java/util/Calendar.java: Change ResourceBundle.getBundle() calls
to pass ClassLoader argument.
* java/util/GregorianCalendar.java: Likewise.
* java/util/Currency.java: Likewise.
* java/text/BreakIterator.java: Likewise.
* java/text/Collator.java: Likewise.
* java/text/DateFormat.java: Likewise.
* java/text/DateFormatSymbols.java: Likewise.
* java/text/DecimalFormatSymbols.java: Likewise.
* java/text/NumberFormat.java: Likewise.
* java/awt/Window.java: Likewise.
Index: java/util/Calendar.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/Calendar.java,v
retrieving revision 1.19
diff -u -r1.19 Calendar.java
--- java/util/Calendar.java 7 May 2004 04:18:19 - 1.19
+++ java/util/Calendar.java 29 May 2004 00:01:30 -
@@ -376,7 +376,8 @@
*/
private static ResourceBundle getBundle(Locale locale)
{
-return ResourceBundle.getBundle(bundleName, locale);
+return ResourceBundle.getBundle(bundleName, locale,
+ Calendar.class.getClassLoader());
}
/**
Index: java/util/GregorianCalendar.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/GregorianCalendar.java,v
retrieving revision 1.19
diff -u -r1.19 GregorianCalendar.java
--- java/util/GregorianCalendar.java 30 Dec 2003 19:56:49 - 1.19
+++ java/util/GregorianCalendar.java 29 May 2004 00:01:30 -
@@ -89,7 +89,8 @@
*/
private static ResourceBundle getBundle(Locale locale)
{
-return ResourceBundle.getBundle(bundleName, locale);
+return ResourceBundle.getBundle(bundleName, locale,
+ GregorianCalendar.class.getClassLoader());
}
/**
Index: java/util/Currency.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/Currency.java,v
retrieving revision 1.2
diff -u -r1.2 Currency.java
--- java/util/Currency.java 23 Apr 2004 06:36:04 - 1.2
+++ java/util/Currency.java 29 May 2004 00:01:30 -
@@ -54,7 +54,8 @@
private Currency (Locale loc)
{
this.locale = loc;
-this.res = ResourceBundle.getBundle ("gnu.java.locale.LocaleInformation", locale);
+this.res = ResourceBundle.getBundle ("gnu.java.locale.LocaleInformation",
+ locale, Currency.class.getClassLoader());
}
/**
@@ -148,7 +149,9 @@
// First we need to implement fully LocaleInformation*.java
try
{
- ResourceBundle res = ResourceBundle.getBundle ("gnu.java.locale.LocaleInformation", locale);
+ ResourceBundle res =
+ ResourceBundle.getBundle ("gnu.java.locale.LocaleInformation",
+locale, Currency.class.getClassLoader());
if (res.equals(this.res))
return res.getString ("currencySymbol");
Index: java/text/BreakIterator.java
===
RCS file: /cvs/gcc/gcc/libjava/java/text/BreakIterator.java,v
retrieving revision 1.7
diff -u -r1.7 BreakIterator.java
--- java/text/BreakIterator.java 30 Apr 2003 13:22:45 - 1.7
+++ java/text/BreakIterator.java 29 May 2004 00:01:30 -
@@ -136,7 +136,7 @@
{
ResourceBundle res
= ResourceBundle.getBundle("gnu.java.locale.LocaleInformation",
- loc);
+ loc, BreakIterator.class.getClassLoader());
className = res.getString(type);
}
catch (MissingResourceException x)
Index: java/text/Collator.java
===
RCS file: /cvs/gcc/gcc/libjava/java/text/Collator.java,v
retrieving revision 1.13
diff -u -r1.13 Collator.java
--- java/text/Collator.java 5 May 2004 07:35:49 - 1.13
+++ java/text/Collator.java 29 May 2004 00:01:30 -
@@ -303,7 +303,7 @@
try
{
res = ResourceBundle.getBundle("gnu.java.locale.LocaleInformation",
- loc);
+ loc, Collator.class.getClassLoader());
pattern = res.getString("collation_rules");
}
catch (MissingResourceException x)
Index: java/text/DateFormat.java
===
RCS file: /cvs/gcc/gcc/libjava/java/text/DateFormat.java
Re: getenv()
Andrew Haley wrote: + return JvNewStringLatin1 (value); + } + Shouldn't this use JvNewStringUTF? We assume Utf-8 in most places for POSIX, and I could imagine problems if someone read a path variable containing non-Latin1 characters. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: AWT peers (Was: [PATCH] More List fixes)
S. Meslin-Weber wrote: Compatibility would be difficult given that there is no published spec, also the interface is no doubt quite complex. The benefits would be questionable - it would let us run our peers on Sun's JDK for debugging purposes, but I don't think that advantage is worth the effort that would be involved. I disagree, although undocumented by Sun, Sun's Peer interface is reasonably well structured and intuitive to implement (if somewhat painstaking to understand without docs). And as Dalibor just found, there *is* published documentation for AWT peers, see my footnotes [1.1] and [1.2]. As GNU Classpath already implements big chunks according to this spec there wouldn't be a great deal more 'effort' involved. Any effort required is to keep GNU-isms segregated as much as possible outside of the java* packages (yes, I know that's not feasible for java.awt.Font yet). OK, your arguments make sense. There certainly does seem to be more third-party peers out there than I had thought. But we still need a spec to write to. Note that [1.2] you mentioned doesn't look anything like being complete! As someone who has implemented their own AWT peers that work with the Sun JRE, you seem to be in a good position to write a specification (to the JRE 1.4.2 level) that we can use for our clean-room implementation. This could perhaps be in the form of java/awt/peer/*.java files with Javadoc comments. Once we have a sufficiently complete spec, we would be in a much better position to implement it faithfully. Would you be interested in doing this? Tom Tromey wrote: I disagree, although undocumented by Sun, Sun's Peer interface is reasonably well structured and intuitive to implement One problem we've run into has to do with List. With the Gtk peers, and the replace operation implemented as "remove + add", we get flickering. So Fernando's first solution -- entirely reasonable IMO -- was to add a new "replace" method to ListPeer. What would you suggest for a case like this? One idea is to somehow suppress Gtk redisplay while some java-side lock is held. We're pretty reluctant to do this, though. Well, this is basically how GUI toolkits generally work, and no extra lock should be needed. In the case of a "lightweight" java toolkit, what would happen is the updates to the internal state of the GUI are made but the actual drawing does not take place synchronously. Once control is returned to the event dispatch mechanism, any pending paint/refresh events are combined and the repainting takes place without any flicker. "heavyweight" peers may well work differently in the AWT, however, and currently I don't have enough knowledge of GTK to say whether we have sufficient control over GTK's internal refresh mechanism to do that. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.io.DataInputStream.readLine misbehaviour
On Nov 3, 2003, at 5:33 AM, Dalibor Topic wrote: For what it's worth, yes, there is code out there that expects threads to be able to read from readers/writers and not trip over their feet ;) AFAIK, the Java APIs explicitely mention when a method/class is not thread safe, so by default we should assume that APIs are to be thread safe. I mean, it's built in the laguage, why would you want to limit yourself to single threads when you're doing something as important as IO? Because, in general, IO from multiple threads makes no sense. If multiple threads are reading/writing the stream, the behavior is non-deterministic. Even if you synchronize correctly, the IO operations can occur in any order - there is no way to determine what data each thread will receive from the stream, or what the contents of the written stream will be. In order to do meaningful IO from multiple threads, synchronization needs to be done at the application level. We should assume that, unless otherwise stated by the spec, object instances do not have to be internally synchronized. Having said that, its clear that many of the streams classes must be synchronized by design (PrintStream for example), so I agree that in general synchronization is required for the streams classes. However this is not true for the Java APIs in general. Sun long ago realised their mistake in using synchronization too liberally throughout the older class libraries, and thats why mentions of synchronization have been removed from the spec for many classes - a hint that developers should not assume they are synchronized. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote: Bryce McKinlay wrote: Sorry, I think I misunderstood your message. I thought you were suggesting moving all the native methods (eg for IO classes) to separate VM* classes. I think that is in fact what Mark was suggesting and I think this is definitely a good idea. There are a lot of VMs that don't (want to) use JNI for their "native" methods. Having all native methods in the VM* classes makes this much easier. On the other hand, too much abstraction increases the complexity of the classes, making maintenance more difficult. Even putting efficiency issues aside, I agree with Andrew - we would not want to do this in libgcj. This assumption is not true for some VMs. My VM (IKVM) has no native methods and I'm pretty sure this is also true for JAOS and maybe others. I think its a mistake for classpath to try to be everything for everyone, even at the expense of elegance and efficiency. At some point, most implementations are going to have to modify it in some way in order to suit their special/custom needs. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
On Oct 27, 2003, at 2:01 PM, Mark Wielaard wrote:
On Mon, 2003-10-27 at 13:15, Bryce McKinlay wrote:
On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote:
I suggest to move the System.loadLibrary("javaio") calls completely
into the VMInterface classes. We want to have a system where (at
least
for lang, net, io and util) we have the "native" calls in the
VMInterface classes. We then provide a reference implementation that
implements this with JNI using our own libraries.
I don't think that is a good idea. IMO the VMInterface should define
the interface to a particular VM, not the entire native interface for
all classes. Things like java.net and java.io will typically have the
same native interface across different VMs.
Could you explain that a bit more? I don't understand why you think
having the loadLibrary() call in the same (VMInterface) class as the
native methods is not a good idea. Or do you mean that having
loadLibrary() calls at all is a bad idea because VMs should just link
against our default jni libraries (at least for lang/net/io/util)?
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
What I was suggesting in my previous message was consolidating the
javaio, javanet, javanio native libraries (and perhaps others) into a
single .so. In that case, we could just load this library once during
initialization, with just one System.loadLibrary() call.
The VMInterface classes define all methods that a particular VM might
want to/has to implement to get a complete working core libraries
implementation.
Right. I think there is a distinction, however, between what the VM
must implement to operate with classpath - ie core VM classes like
Class, Object, Throwable, Thread; and portable classes which happen to
have native methods, such as java.io.File and java.net.PlainSocketImpl.
The later are just normal classes with native methods, the
implementations of which are typically be portable across different
VMs. So, they a system/platform interface rather than the VM interface.
To put it another way, just because a method is native doesn't mean it
interfaces with the VM.
Regards,
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote:
Hi,
On Sat, 2003-10-25 at 19:43, Dalibor Topic wrote:
One of the things I keep stumbling over whenever I merge code from
Classpath into Kaffe is the different native library names. Would it
be
possible to separate those out into their own VMInterface class and
use
references instead?
I'd prefer something like
System.loadLibrary(VMNativeLibraries.IO);
to what we have now,
System.loadLibrary("javaio");
I suggest to move the System.loadLibrary("javaio") calls completely
into
the VMInterface classes. We want to have a system where (at least for
lang, net, io and util) we have the "native" calls in the VMInterface
classes. We then provide a reference implementation that implements
this
with JNI using our own libraries.
I don't think that is a good idea. IMO the VMInterface should define
the interface to a particular VM, not the entire native interface for
all classes. Things like java.net and java.io will typically have the
same native interface across different VMs.
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Modular InetAddress
On Oct 26, 2003, at 10:31 PM, Guilhem Lavaux wrote: here is a quick patch to be able to have a modular getHostByName and a getHostByAddr. To change implementation the user has just to provide a property gnu.java.net.dns containing the full class name of an implementation. Hi Guilhem, I'm not convinced that we need this. I know it is a feature of kaffe, but who is using it? What sort of system has sockets but no native ability to look up a DNS address? Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
On Oct 26, 2003, at 6:43 AM, Dalibor Topic wrote: One of the things I keep stumbling over whenever I merge code from Classpath into Kaffe is the different native library names. Would it be possible to separate those out into their own VMInterface class and use references instead? I'd prefer something like System.loadLibrary(VMNativeLibraries.IO); How about having less native libraries? Does it really make sense to have, for example, separate native libs for java.net, java.io, and java.nio? I think these ones at least should be merged into one library, which is loaded unconditionally at startup. After all, virtually all desktop java apps use some kind of I/O. This way we can get rid of the static initializer System.loadLibrary() calls all over the place, something that could be prone to bugs if someone forgets to include one somewhere. It would simplify the number of files needed to "deploy" classpath, make for less places that VM implementors need to customize, and probably improve performance as System.loadLibrary can be slowish. The AWT libs, however, should probably remain separate due to the existence of multiple toolkits and such. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
AccessibleObject redundant check
Anyone care to comment on this patch? Checking for whether we are
setting accessibility on a member of AccessibleObject seems redundant,
as code can only do that if it has already passed the SecurityManager
check required to call setAccessible() in the first place (the check
for java.lang.Class constructors, however, is specified by Sun's docs
so we should probably keep that one).
Regards
Bryce.
2003-10-25 Bryce McKinlay <[EMAIL PROTECTED]>
* java/lang/reflect/AccessibleObject.java (secureSetAccessible):
Don't check for AccessibleObject. Update javadocs.
Index: AccessibleObject.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/reflect/AccessibleObject.java,v
retrieving revision 1.7
diff -u -r1.7 AccessibleObject.java
--- AccessibleObject.java 22 Jan 2002 22:40:20 - 1.7
+++ AccessibleObject.java 25 Oct 2003 02:43:07 -
@@ -59,8 +59,7 @@
{
/**
* True if this object is marked accessible, which means the reflected
- * object bypasses normal security checks. NOTEDon't try messing
- * with this by reflection. You'll mess yourself up.
+ * object bypasses normal security checks.
*/
// default visibility for use by inherited classes
boolean flag = false;
@@ -88,19 +87,11 @@
* security check. If a security manager exists, it is checked for
* ReflectPermission("suppressAccessChecks").
*
- * If flag is true, and the initial security check succeeds,
- * this can still fail if a forbidden object is encountered, leaving the
- * array half-modified. At the moment, the forbidden members are:
- *
- * Any Constructor for java.lang.Class
- * Any AccessibleObject for java.lang.reflect.AccessibleObject
- * (this is not specified by Sun, but it closes a big security hole
- * where you can use reflection to bypass the security checks that
- * reflection is supposed to provide)
- *
- * (Sun has not specified others, but good candidates might include
- * ClassLoader, String, and such. However, the more checks we do, the
- * slower this method gets).
+ * It is forbidden to set the accessibility flag to true on any constructor
+ * for java.lang.Class. This will result in a SecurityException. If the
+ * SecurityException is thrown for any of the passed AccessibleObjects,
+ * the accessibility flag will be set on AccessibleObjects in the array prior
+ * to the one which resulted in the exception.
*
* @param array the array of accessible objects
* @param flag the desired state of accessibility, true to bypass security
@@ -121,19 +112,8 @@
* manager exists, it is checked for
* ReflectPermission("suppressAccessChecks").
*
- * If flag is true, and the initial security check succeeds,
- * this will still fail for a forbidden object. At the moment, the
- * forbidden members are:
- *
- * Any Constructor for java.lang.Class
- * Any AccessibleObject for java.lang.reflect.AccessibleObject
- * (this is not specified by Sun, but it closes a big security hole
- * where you can use reflection to bypass the security checks that
- * reflection is supposed to provide)
- *
- * (Sun has not specified others, but good candidates might include
- * ClassLoader, String, and such. However, the more checks we do, the
- * slower this method gets).
+ * It is forbidden to set the accessibility flag to true on any constructor for
+ * java.lang.Class. This will result in a SecurityException.
*
* @param flag the desired state of accessibility, true to bypass security
* @throws NullPointerException if array is null
@@ -171,9 +151,8 @@
private final void secureSetAccessible(boolean flag)
{
if (flag &&
-((this instanceof Constructor
- && ((Constructor) this).getDeclaringClass() == Class.class)
- || ((Member) this).getDeclaringClass() == AccessibleObject.class))
+(this instanceof Constructor
+ && ((Constructor) this).getDeclaringClass() == Class.class))
throw new SecurityException("Cannot make object accessible: " + this);
this.flag = flag;
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath and org.omg.*
On Oct 24, 2003, at 10:55 AM, Mark Wielaard wrote: Hi, On Thu, 2003-10-23 at 20:26, Stuart Ballard wrote: I think I see a fairly simple way that OMG could preserve the integrity of the CORBA standard while remaining Free Software. In much the same way as some Free licenses allow free modification but require that anyone making such modifications must change the name of the software, couldn't the OMG say something like: "You may modify this software, but if you distribute a modified version you must change the package name to something that does not begin with 'org.omg'." That would restrict certain functionality since package scoping is an important functionality of the java language. It has meaning to the language runtime. So this would not be something we could use to provide a free software implementation. Mark, How does the org.omg spec differ from the java.* spec which is also non-modifiable according to its license? Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
On Oct 23, 2003, at 3:17 AM, Stuart Ballard wrote: Andrew Haley wrote: Where is this software? I haven't found it yet, but see postings from Brian Jones on this list where he indicates it's in OMG's FTP area (which I still can't find linked from their site). I guess that you could argue that since the problematic software is almost impossible to find from the link, it isn't a link to non-free software, but it *claims* to be such a link, and it's certainly a *reference* to non-free software - after reading that part of Classpath's homepage, it's quite possible that someone would independently search for OMG's implementation of these packages under the impression that they were Free. As far as I know, the OMG doesn't make any software - just specifications. The public classes in org.omg are automatically generated from CORBA interface definition language (IDL) files by an IDL-to-Java compiler which is specific to each ORB implementation (although I think the actual IDL-to-java mapping is standardized these days, such that code compiled for one ORB will work on another, there would still be differences in the glue code generated for various ORBs). So, all there is to download on the omg site is likely 1) specification documents, and 2) the IDL files. The interfaces don't become software until you implement them - ie write an ORB implementation. IMO the link is not to non-free software: there is no software, so there is no problem. If you're trying to say we shouldn't link to or implement a non-free spec, well, Java is a non free spec in that sense isn't it? Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Oct 11, 2003, at 4:00 AM, Stuart Ballard wrote:
Bryce McKinlay wrote:
The collections classes, on the other hand, are actually quite well
specified in my opinion (having architected many of the current
collections implementations used in classpath). I don't believe that
anyone should need to write collections code that relies on
unspecified details. Besides, matching every single one of those
details would be close to impossible without copying Sun's source
code virtually line for line. I think its better to stop now, while
we have a very stable and bug-free set of collections classes, or we
will forever be chasing silly, unspecified details like this, and
potentially introducing real regressions and reducing performance in
the process.
I'm curious as to whether you can come up with an architecture for the
type of Map I need that includes an efficient and correct
implementation of size() - that is, an architecture such that the
prior implementation of putAll() would both work correctly and be not
significantly less efficient than calling hasNext().
My requirement is for a map which holds references to two other maps,
"front" and "back". The keySet() of my map is the union of
front.keySet() and back.keySet(). The value corresponding to a given
key is 'front.containsKey(key) ? front.get(key) : back.get(key)'. Both
front and back can be accessed directly through other code and may
change in any way without my map being notified. How can I implement
size() without a full iteration?
If you need this to be fast, perhaps the best way (to guarantee good
performance on any implementation) would be to define your own method:
HashMap asHashMap()
{
HashMap hash = new HashMap(estimatedSize);
hash.putAll(front);
hash.putAll(back);
return hash;
}
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Oct 10, 2003, at 12:40 AM, Sascha Brawer wrote: Bryce McKinlay <[EMAIL PROTECTED]> wrote on Fri, 10 Oct 2003 00:08:16 +1300: I wrote a quick test program to examine the behaviour of Sun's ArrayList - and it definitely calls and relies on size(). Would it make sense to have such test programs in the Mauve test suite? In this case: no. I'm reluctant to add such a test because it doesn't test whether we match the specification, but rather the behaviour of another vendors implementation. The internal implementation of addAll/putAll is clearly undefined, and properly written code should not rely on them being implemented one way or another - only that they do what the spec says. As an analogy, the Linux & glibc developers have never attempted to duplicate in precise detail the internal behaviour of functions from Solaris or any other OS - instead, they implemented the POSIX spec. Likewise, GCC doesn't precisely replicate other vendors compilers, it implements the ISO specifications for C and C++. If you rely on a behaviour of eg Microsoft's compiler that is undefined by the specs, such as evaluation orders or aliasing behaviour, thats too bad - your code is broken. Unfortunately in classpath we often have to make compromises and match the JDKs behaviour because many classes and packages are under-specified. In those cases we need to make an effort to fix Sun's mistake and specify the behaviour properly in our docs. The collections classes, on the other hand, are actually quite well specified in my opinion (having architected many of the current collections implementations used in classpath). I don't believe that anyone should need to write collections code that relies on unspecified details. Besides, matching every single one of those details would be close to impossible without copying Sun's source code virtually line for line. I think its better to stop now, while we have a very stable and bug-free set of collections classes, or we will forever be chasing silly, unspecified details like this, and potentially introducing real regressions and reducing performance in the process. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Oct 9, 2003, at 2:41 AM, Stuart Ballard wrote: Stuart Ballard wrote: Bah, forgot the attachment. Any decision on this? Kaffe's applied it for their 1.1.2 release (dalibor's comment was "Fight premature micro-optimizations!") but I'd still like to see the fix made to Classpath proper. There seems to be at least one developer opposed to the patch and at least a couple who are somewhat in favor. If there's any clear consensus, it's eluding me ;) So what happens next? I wrote a quick test program to examine the behaviour of Sun's ArrayList - and it definitely calls and relies on size(). So, in the case of the List classes our current implementation should probably remain. I'll concede that the Map changes don't really do any harm (apart from the minor efficiency loss) - so go ahead and check that in if you want. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Modular DNS resolution
On Sunday, Oct 5, 2003, at 23:25 Pacific/Auckland, Guilhem Lavaux wrote: I would like to introduce in classpath a concept which used to be in kaffe but was recently removed because of the merging with classes from classpath: DNS solver modularity. Previously it was possible to specify to kaffe (using -Ddns.resolve=class or something like this). That used to give an advantage: use a native method (using e.g. gethostbyname) or a Java method to resolve internet name. The java method is already implemented and we can get a lot of other useful insights to resolved name than we can get with gethostbyname. As the code to add if fairly simple (add an interface and a if branch at class initialization), I think it can be added painlessly. I think we want to stick with always using the OS's gethostbyname(). This ensures that the OS settings for name resolution get respected by Java - I suspect things like /etc/hosts, and other name resolution schemes like zeroconf/rendevous, etc may not get recognized by a Java resolver without additional Java-specific configuration. The "additional insights" would certainly be useful for applications that need to integrate tightly with DNS, however I don't think it would be useful or neccessary to put this inside InetAddress itself - no more information can be obtained given the existing InetAddress interface, right? Surely it would be better to put this code in its own class under gnu.* somewhere? Note that external resolvers can now easily create InetAddress objects using the JDK 1.4 getByAddress() methods, which are already implemented in classpath. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Tuesday, Sep 30, 2003, at 02:57 Pacific/Auckland, Stuart Ballard wrote: Furthermore, I'd argue that the very existence of a hasNext() method suggests that Sun didn't intend people to make this "optimization". If they expected that calling size() and maintaining your own counter would always be more efficient, why didn't they just leave hasNext() out and recommend coding that way? "while (list.hasNext())" is there because its a nicer style for many situations, it makes your code simpler and less error-prone compared to using a for loop based on size. However, its existence doesn't mean that size() shouldn't work! IMO you should implement size() correctly in your code, it is not specified how putAll() etc work and there is no guarantee that Sun won't change their implementation in a future release of the JRE! Note too that our current implementations leave the collections in an invalid state if next() causes a ConcurrentModificationException (or other RuntimeException) part way through, because they set the size variable in advance without waiting to ensure that all those elements could in fact be added. It would be possible to fix this problem without using hasNext(), and even if my patch isn't accepted I still think we should at least fix that. Yeah, those should probably be cleaned up. In general it should be assumed that everything is invalid if you get ConcurrentModificationException, but its good to be defensive. Of course, if there are real applications out there that rely on the way Sun implements it, then we may have to change to using hasNext(). But we should consider this carefully. If we must change it, then the addAll/putAll implementations should change throughout the collections classes for consistency - not just HashMap/Hashtable. As you noticed, in some cases this could make things significantly less efficient. I think it's perfectly possible to implement all our collections to give the correct behavior without making things less efficient in the case where size() is correct - at least, the only difference should be the cost of repeated calls to hasNext() versus a single call to size(), and the cost of hasNext() should *always* be small enough that that difference falls into the realm of micro-optimization. The optimization in using size comes simply from the reduction in method calls. Its true that some very smart JITs may be able to compile special copies of the method with the virtual calls to the iterator inlined where they see, for example, many putAll calls with iterator arguments of a certain class, but in general, if you add an extra method call into a loop, its going to make the code slower. But, you're quite right, we are talking about micro-optimization here. The example I gave was ArrayList: the optimization is to pre-allocate space for size() worth of elements using ensureCapacity(), and then copy elements directly into the backing array. It would be perfectly possible to implement it something like this, which optimizes for when size() is correct but is robust if it's not: I don't think is quite as simple as that. Consider the case of an addAll() with an index < size. The current implementation moves existing elements out of the way based on size(). If size() doesn't equal the actual number of elements returned, your going to have to make sure not to overrun existing elements and/or do fixups afterwards. Does Sun's implementation of addAll() really not call size()? However, having said all this, the argument for compatibility with Sun's implementation is somewhat compelling (even though only poorly written applications would suffer from this problem, IMO!) . I don't really object to this change, at least if we can come up with good solutions for things like the addAll() problem. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: Patch: java.text.SimpleDateFormat
On Sunday, Sep 28, 2003, at 11:04 Pacific/Auckland, Mark Wielaard wrote:
Hi,
On Sat, 2003-09-27 at 22:21, Bryce McKinlay wrote:
Can you give me a pointer to the failing mauve test?
Without the patch the following four mauve tests fail:
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: CDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EST (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: PDT (number 1)
Thanks Mark.
The real problem here is that setTimeZone() was being called on the
underlying calendar. This is not necessary since the ZONE_OFFSET field
has the same effect, without overwriting the timezone which the user
set and "sticking" across a calendar.clear() call. The cloning approach
only worked by chance, since it reset the calendar's timezone to GMT
which just happened to be what the test case expected.
I'm checking in this patch to libgcj & classpath.
Regards
Bryce.
2003-09-28 Bryce McKinlay <[EMAIL PROTECTED]>
* java/text/SimpleDateFormat (parse): Revert patch of 2003-09-25.
Don't call setTimeZone on the calendar.
Index: SimpleDateFormat.java
===
RCS file: /cvs/gcc/gcc/libjava/java/text/SimpleDateFormat.java,v
retrieving revision 1.20
diff -u -r1.20 SimpleDateFormat.java
--- SimpleDateFormat.java 25 Sep 2003 17:25:15 - 1.20
+++ SimpleDateFormat.java 28 Sep 2003 03:38:05 -
@@ -547,9 +547,8 @@
{
int fmt_index = 0;
int fmt_max = pattern.length();
-Calendar loc_calendar = (Calendar)calendar.clone();
-loc_calendar.clear();
+calendar.clear();
boolean saw_timezone = false;
int quote_start = -1;
boolean is2DigitYear = false;
@@ -697,8 +696,7 @@
found_zone = true;
saw_timezone = true;
TimeZone tz = TimeZone.getTimeZone (strings[0]);
- loc_calendar.setTimeZone (tz);
- loc_calendar.set (Calendar.ZONE_OFFSET, tz.getRawOffset ());
+ calendar.set (Calendar.ZONE_OFFSET, tz.getRawOffset ());
offset = 0;
if (k > 2 && tz instanceof SimpleTimeZone)
{
@@ -765,17 +763,17 @@
}
// Assign the value and move on.
- loc_calendar.set(calendar_field, value);
+ calendar.set(calendar_field, value);
}
if (is2DigitYear)
{
// Apply the 80-20 heuristic to dermine the full year based on
// defaultCenturyStart.
- int year = defaultCentury + loc_calendar.get(Calendar.YEAR);
- loc_calendar.set(Calendar.YEAR, year);
- if (loc_calendar.getTime().compareTo(defaultCenturyStart) < 0)
- loc_calendar.set(Calendar.YEAR, year + 100);
+ int year = defaultCentury + calendar.get(Calendar.YEAR);
+ calendar.set(Calendar.YEAR, year);
+ if (calendar.getTime().compareTo(defaultCenturyStart) < 0)
+ calendar.set(Calendar.YEAR, year + 100);
}
try
@@ -784,10 +782,10 @@
{
// Use the real rules to determine whether or not this
// particular time is in daylight savings.
- loc_calendar.clear (Calendar.DST_OFFSET);
- loc_calendar.clear (Calendar.ZONE_OFFSET);
+ calendar.clear (Calendar.DST_OFFSET);
+ calendar.clear (Calendar.ZONE_OFFSET);
}
-return loc_calendar.getTime();
+return calendar.getTime();
}
catch (IllegalArgumentException x)
{
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Friday, Sep 26, 2003, at 06:26 Pacific/Auckland, Stuart Ballard
wrote:
@@ -709,10 +708,10 @@
void putAllInternal(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-size = msize;
-while (msize-- > 0)
+size = 0;
+while (itr.hasNext())
{
+size++;
Map.Entry e = (Map.Entry) itr.next();
Object key = e.getKey();
int idx = hash(key);
Hi Stuart,
size() is used here because, obviously, it is generally more efficient
to call it once rather than calling hasNext() many times. I believe
that the current implementation is within spec according to the
collections documentation. If your collections are returning an
inaccurate size() then I'd argue they are not valid implementations of
Map.
Of course, if there are real applications out there that rely on the
way Sun implements it, then we may have to change to using hasNext().
But we should consider this carefully. If we must change it, then the
addAll/putAll implementations should change throughout the collections
classes for consistency - not just HashMap/Hashtable. As you noticed,
in some cases this could make things significantly less efficient.
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
StringBuffer.substring sharing
After I checked in Ralph Loader's fix for StringBuffer.substring the
other day, Ralph pointed out that my modification had changed the
meaning of the patch slightly:
On Monday, Sep 22, 2003, at 20:45 Pacific/Auckland, Ralph Loader wrote:
My interpretation of the original code was that it was meant to prevent
the possibility that a small substring of a large StringBuffer would
prevent the large array being gc'd.
The patch you checked in breaks this. Consider:
String Foo()
{
StringBuffer b = new StringBuffer();
... put a megabyte of stuff into b ...
String ignored = b.toString(); // sets b.shared
return b.substring (0, 1);
}
The 1 character String returned from Foo now has it's contents stored
in
a megabyte char[], and that array has no other references.
Passing ((len << 2) >= value.length) rather than StringBuffer.shared to
the String constructor prevented this.
Its hard to say what is optimal here, as you can also argue that if the
string is already shared then its reasonable to share even if the
substring is small. However, having to copy a small string
unnecessarily doesn't seem as bad as potentially wasting a lot of
memory in the scenario above. So, I'm checking in the following patch,
which reverts to the behaviour of Ralph's original patch.
2003-09-24 Bryce McKinlay <[EMAIL PROTECTED]>
* java/lang/StringBuffer.java (substring): Don't set `shared' on
small Strings, even if buffer is already shared.
Index: StringBuffer.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/StringBuffer.java,v
retrieving revision 1.16
diff -u -r1.16 StringBuffer.java
--- StringBuffer.java 22 Sep 2003 08:17:48 - 1.16
+++ StringBuffer.java 24 Sep 2003 06:02:00 -
@@ -564,11 +564,12 @@
throw new StringIndexOutOfBoundsException();
if (len == 0)
return "";
-// Share unless substring is smaller than 1/4 of the buffer.
-if ((len << 2) >= value.length)
- shared = true;
+// Don't copy unless substring is smaller than 1/4 of the buffer.
+boolean share_buffer = ((len << 2) >= value.length);
+if (share_buffer)
+ this.shared = true;
// Package constructor avoids an array copy.
-return new String(value, beginIndex, len, shared);
+return new String(value, beginIndex, len, share_buffer);
}
/**
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [patch] pr 12350, java.lang.StringBuffer.substring.
On Sunday, Sep 21, 2003, at 21:06 Pacific/Auckland, Ralph Loader wrote: java.lang.StringBuffer.substring is manipulating the shared flag on the StringBuffer object incorrectly, PR java/12350. The following patch fixes the bug and adds a test case. It passes the libjava/testsuite on i686-pc-linux-gnu. Thanks Ralph. I am checking in a slightly modified patch to both libgcj and classpath. Regards Bryce. 2003-09-21 Ralph Loader <[EMAIL PROTECTED]> PR java/12350: * java/lang/StringBuffer.java (substring): fix handling of shared flag. Index: java/lang/StringBuffer.java === RCS file: /cvs/gcc/gcc/libjava/java/lang/StringBuffer.java,v retrieving revision 1.15 diff -u -r1.15 StringBuffer.java --- java/lang/StringBuffer.java 24 Mar 2003 00:50:18 - 1.15 +++ java/lang/StringBuffer.java 22 Sep 2003 08:10:44 - @@ -564,8 +564,9 @@ throw new StringIndexOutOfBoundsException(); if (len == 0) return ""; -// Share the char[] unless 3/4 empty. -shared = (len << 2) >= value.length; +// Share unless substring is smaller than 1/4 of the buffer. +if ((len << 2) >= value.length) + shared = true; // Package constructor avoids an array copy. return new String(value, beginIndex, len, shared); } ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: question about serialization
On Monday, Aug 4, 2003, at 21:33 Pacific/Auckland, Chris Gray wrote: No. The security context of a given method invocation is the set of classes "on the stack" at the time of the invocation, and the resulting set of privileges is the intersection of the privileges of all those classes. So if com.acme.FooApp has permission to read all files, and com.ibm.KoolThing has read/write access to the user's directory only, when FooApp calls a method of KoolThing the latter just gets read access to the user's files. You're right - thanks for clearing that up. Looks like there is still quite a bit of work to do to implement the security model! The performance implications of all this are also rather concerning - walking up the stack is going to be fairly slow. But I presume that for normal applications where security is not required (ie System.getSecurityManager()), such checks are avoided? Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: question about serialization
On Monday, Aug 4, 2003, at 19:57 Pacific/Auckland, Chris Gray wrote: Sure. But to call AccessibleObject.setAccessible() you need ReflectPermission, which the user code that initiated serialisation does not necessarily have. So the java.io serialisation stuff needs to have this permission, and it seems to me that it needs to call AccessibleObject.setAccessible() from inside a PrivilegedAction. Isn't the security context of any given class is based on which ClassLoader that loaded the class, rather than what called it? Since ObjectOutputStream etc should always be loaded by the system classloader, it doesn't need a PrivilegedAction. ie: regardless of the code that calls it, the ObjectOutputStream class itself always has full privileges (assuming the default security policies). Note that the serialization classes have their own security checks to prevent them being used maliciously by untrusted code. Granting AllPermission to everything loaded by the system class loader is IMHO acceptable, *iff* by system class loader you mean the class loader which loads java.* classes from a trusted location. Not to be confused with the application class loader which loads from the -classpath, which is the one returned by ClassLoader.getSystemClassLoader() (aaargh). By default, the application/system class loader gets all permissions - why would you want to restrict access the access of applications? Regards, Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: question about serialization
On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove wrote: Hi Tom, We've had security manager checks in the reflection code in Jikes RVM for a while. Our current workaround for serialization is that classes loaded by the system classloader are always allowed access. This is probably too big of a hole, but it does work in practice. The key routine for us is in java.lang.reflect.JikesRVMSupport (appended below). If you come up with a finer-grained fix for libgcj, let me know -- I'm not that happy with what we are currently doing in Jikes RVM. AccessibleObject.setAccessible() is the correct way for serialization to get access to private reflection data. See: http://java.sun.com/j2se/1.4.2/docs/guide/reflection/reflection.html Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: BUG: java.net.SocketInputStream.read() is broken
Jeroen Frijters wrote: >Hi everyone, > >SocketInputStream.read() contains the following code: > > if (bytes_read != -1) >return((int)buf[0]); > >This is incorrect, as it promotes the signed byte to an int. The correct >code is: > > if (bytes_read != -1) >return(buf[0] & 0xff); > > Thanks. I have checked in the fix. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Problem with system properties
Compare the output of this test case using the current GCC/classpath
compared with GCC 3.1 or the JDK:
public class PropTest
{
public static void main(String[] args)
{
System.out.println (System.getProperties());
}
}
The problem (introduced into GCJ by a classpath merge) makes it
impossible to get a list of all the system properties which are defined,
because the "real" system properties are now just default properties for
the properties object that is returned by System.getProperties()
While looking for a fix, I wonder why system property initialization was
moved from System to Runtime. The comments mention something about VM
bootstrapping, but I don't understand why it makes a difference in this
case - System. calls loadLibrary which will cause Runtime to be
initialized anyway, so property initialization occurs at basically the
same time. It would make more sense to me to keep the properties init
code in System. Comments?
regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: debug output problem in ObjectInputStream
Per Bothner wrote:
> Having dumpElement[ln] as separate
> methods has the advantage that it could over overridden, but
> it seems like poinles generality. So if we want to keep the
> debugging printout, I suggest:
>
> if (Configuration.DEBUG && dump)
> for (int i=0, len=Array.getLength(array); i < len; i++)
> System.out.println(" ELEMENT[" + i + "]=" + Array.get(array, i));
>
> This makes it possible for a compiler to do the optimization to
> multiple print calls that my patch does.
I was originally hoping that the dumpElement() methods would get inlined
and the compiler would figure out that the code could be removed, but
you're right in that even if inlining worked properly the arguments
would still have to be evaluated unless it could also figure out that
the StringBuffer methods etc had no side-effects.
I agree that we should put the "if (Configuration.DEBUG ..." at the call
site to fix this. However, fixing this doesn't really help our extremely
crap serialization performance. eg the attached test runs more than 45X
slower with GCJ than JDK 1.4! Serialization needs some work...
regards
Bryce.
import java.util.*;
import java.io.*;
public class SerTest3
{
static void showUsage()
{
System.err.println("Usage: SerTest3 ");
System.exit(1);
}
public static void main(String[] args)
throws IOException, FileNotFoundException, ClassNotFoundException
{
if (args.length == 0)
showUsage();
HashMap hm = null;
long start = System.currentTimeMillis();
if (args[0].equals("write"))
{
hm = makeHugeHashMap();
System.out.println ("map created, writing it out...");
ObjectOutputStream out =
new ObjectOutputStream(new FileOutputStream("test.ser"));
out.writeObject(hm);
out.close();
}
else if (args[0].equals("read"))
{
ObjectInputStream in =
new ObjectInputStream(new FileInputStream("test.ser"));
hm = (HashMap) in.readObject();
}
else
showUsage();
System.out.println(hm.hashCode());
System.out.println(System.currentTimeMillis() - start + "ms elapsed.");
}
static HashMap makeHugeHashMap()
{
HashMap hm = new HashMap();
for (int i=0; i < 200; i++)
{
ArrayList al = new ArrayList();
for (int j=0; j < 1000; j++)
{
al.add (Integer.toString(i - j));
}
Integer integer = new Integer(i);
hm.put(integer, al);
}
return hm;
}
}
Re: Patch 184 (FileURLConnection formatting changes)
Nic Ferrier wrote: >Can I check in the FileURLConnection changes I submitted? They're >just formatting changes. > Certainly. You should always feel free to check in formatting-only changes which bring things into line with our coding standards. >I have another patch to FileURLConnection which adds some interesting >methods (ones that aren't exposed through the URLConnection class but >there we are). I'm using these new methods in Paperclips. > >I'd very much like to submit the patch to Classpath but I don't want >to do that until the FileURLConnection patch has been approved. > I'm not sure that its a good idea to add extra methods to things like the URL protocol drivers, even though in this case it is in the gnu namespace. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: StringBuffer question
Eric Blake wrote: >So back to my original question: Is the bounds check in the current >Classpath implementation of setLength necessary, or am I justified in >breaking the above snippet by removing the bounds check and throwing >IndexOutOfBoundsException instead? > Iit would be nice to do that, and it would not be incorrect according to the JDK 1.4 docs. However, in the JCL, setLength() and other StringBuffer methods are explicitly defined to throw the StringIndexOutOfBoundsException. Although I'm usually inclined to follow the Javadoc spec in preference to the JCL, given that there is some chance that changing it would break exisiting code, in this case I think it is safer to stick with the existing behaviour. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Method.equals()
Cierniak, Michal wrote: >Brian Jones writes: > >>Bryce McKinlay <[EMAIL PROTECTED]> writes: >> >>>I don't think it is neccessary to make it native. Method is already >>>part of the VM interface, so VMs can modify it or make it native as >>>they wish. I think the more conservative approach should be taken by >>>the default implementation. >>> >>It may be necessary to consider including an ORP vm directory >>or ask that the ORP team distribute these particular classes >>specific to ORP with ORP. >> > >But I thought that Bryce indicated in his message that he also liked the >patch submitted by Gansha. It sounds like this modification is useful for >both ORP and GCJ since they both have their own internal data structures to >represent a method. > Right. Gansha's implementation should be the one that goes in vm/reference. It may not be optimal for all VMs, but it is always correct and most accurately matches the JDK spec, and it is the implementation required for both ORP and GCJ. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Method.equals()
Mark Wielaard wrote: >I am going through the patches that the Orp developers submitted to >Classpath. The following patch to Method puzzles me: > >2001-12-17 Wu Gansha <[EMAIL PROTECTED]> > >* vm/reference/java/lang/reflect/Method.java: Reimplemented >equals(), refined toString(). > > >Why/When is this neccessary? The comment to equals says: > > Two Methods are semantically equivalent if they have the same declaring > class, name, and parameter list. This ignores different exception > clauses, but since you can't create a Method except through the VM, > this is just the == relation. > >So this comment is wrong for Orp, but when does this happen? > This comment is also wrong for GCJ, where a new Method object is always created by a getMethod call, since Method is really just a wrapper around an internal reflection data structure. Some VMs may use the Method class as their native/internal representation, and in that case using == would be an optimization. >Maybe we should just mark this method "native" in Classpath and >leave it to the VM implementor. > I don't think it is neccessary to make it native. Method is already part of the VM interface, so VMs can modify it or make it native as they wish. I think the more conservative approach should be taken by the default implementation. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Hashtable.size()/isEmpty()
Eric Blake wrote: >No - even accessing a simple field must be synchronized, for this >reason: > >Suppose thread A is in the middle of calling clear() when thread B calls >size(). Notice in clear() that the size is not changed until after all >entries have been set to null, meaning that B will read a larger size >than what is actually there. > So? Even if size() is synchronized there is nothing to stop another thread calling clear() after size()'s lock is released but before the first thread does anything with the value returned by size(). The only way to avoid issues like this is for the caller to put a big synchronized block around all its calls into the hashtable. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Hashtable.size()/isEmpty()
Etienne M. Gagnon wrote: > Artur Biesiadowski wrote: > >> First - removing as much synchronization as possible, while staying >> compatible is certainly a good thing. Synchronizing is _really_ costly - > > > Have you heard of "thin locks" and other VM level optimizations that > reduces "significantly" the cost of locks? Do not compute the cost of > locks based on their implementation in Sun's old JDK, or based on an > implementation that does not implement state-of-the-art techniques. Synchronization techniques have improved, however it will always be slow (relative to other operations) in a multithreaded/multiprocessing environment, because it cannot be done without some form of spinlocking or memory bus synchronization. The only way to truely make it fast for a multiprocessor would be to come up with some magic bus architechture which is as fast as the cpu cores! > Systems like "HotSpot/Jalapeno" are getting to the point where the are > able to identify things like "single threaded programs" and thus > eliminate all lock operations when possible. Yes. But remember that many of the applications that are hurt most by synchronization (AWT, Swing) are never single threaded. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Properties -- make it thread-safe?
Sascha Brawer wrote: >Sun's current JavaDoc (J2SE 1.4) does not mention whether >java.util.Properties is supposed to be usable from multiple threads >without additional synchronization. However, one might be able to infer >it from the fact that it is a subclass of java.util.Hashtable. > My approach is to assume that _nothing_ is synchronized unless the (current) specs explicitly say so, or it is obvious that it is not reasonable to implement something any other way. My reasoning is: 1. It is slow. In fact the overuse of synchronization is responsible for a great many of Java's performance problems. 2. A programmer has no reason to assume that something is synchronized if the specification does not say it is. 3. It could potentially cause deadlock issues if a progammer assumes something does not synchronize internally, but it does. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Hashtable.size()/isEmpty()
Etienne M. Gagnon wrote: >On Fri, Feb 15, 2002 at 11:19:15AM +0100, Sascha Brawer wrote: > >>Hello, >> >>the implementations of java.util.Hashtable.size() and >>java.util.Hashtable.isEmpty() merely access a single integer member >>field. Since accesses to integer variables are required to be atomic, I >>think these two methods don't need to be synchronized. Do people agree? >>(Yes, it's a micro-optimization). >> > >I do not agree. If I remeber correctly, this atomicity is only true >of "volatile" variables. Otherwise, you have no garantee that the >integer value visible to one thread is the same as the one visible to >another on a multiprocessor system. > You are correct that, without synchronization, the value for size could be seen differently by different CPUs at the same time. However, synchronizing is itself no guarantee of "thread safety" here. Even if it were synchronized the value could have been changed by another thread before getSize() returns, so it makes no difference either way. Hashtable and Vector (and the "synchronized" method modifier for that matter) are so bogus! regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Tom Tromey wrote: >>"Eric" == Eric Blake <[EMAIL PROTECTED]> writes: >> > >Eric> StrictMath is required to be implemented in pure Java > >How curious. >BTW, fdlibm is fine to use. We already use it in libgcj. > >Thanks for doing this. Now all we have to do is implement strictfp in >gcj :-) > Do you have any examples of how GCC is *not* strictfp compliant (at least on common platforms)? My understanding is that, by default, it tries to be strictly IEEE 754. On x86 it will store values to memory and make a function call to do FP arithmetic, unless -ffast-math is given which allows it to do inline math using (the 80-bit x87) FP registers. So, unless I misunderstand something and there is more to it, we should make -ffast-math the default for Java except where strictfp is encountered. regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: >OK to commit? If it weren't for this little section of StrictMath.java, >I would have committed without asking. But since it involves copyright >issues, I want to make sure. I don't think I tainted myself, since the >copyright notice of fdlibm (the source for my algorithms) does say it is >freely usable. > This is very cool! Thanks for doing this. Please consider it pre-approved for libgcj as well. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patch for com/sun/javadoc/Doclet
Applied. Thanks! Bryce. Julian Scheid wrote: > The validOptions() method is supposed to be static > as well, like all other methods in Doclet. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Draft release announcement (please comment)
Mark Wielaard wrote: > > 5). Who should use this software? > > This is a development release only. You should only install it if you are > interested in Classpath development or reporting bugs. We appreciate both. > You might also be interested if you enjoy installing random alpha > software. > I think this part sounds a bit too pessimistic. How about something like: 5). Who should use this software? Although it is already capable of supporting many Java applications, this is a development release. As such, there are still many unfinished components, and some problems are to be expected. You should install it if you are interested in Classpath development or reporting bugs. We appreciate both. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Stuart Ballard wrote: >I have no idea what a line of code that uses three : operators in a row >could possibly mean (in either language) and I can't find the source >code file to get context. But my guess is that the tokenizer is seeing >:: and thinking "ooh, class member operator" (or whatever that operator >is called in c++), and it doesn't occur to it that it might actually be >two separate ":" operators. > That would be my guess too, since (after reading the GCC manual) it turns out that ":::" is not a trigraph after all. >Anyone know what these three ":" operators are actually supposed to be >doing in this case? > It was an inline asm statement, which has no operands. In this case I'll bet its there as a write barrier to synchronize memory before releasing a lock. On x86, the hardware never reorders writes (ie another CPU cannot see a lock as released before any previous writes to memory were completed), but having an empty inline asm with the "memory" flag is a safeguard to ensure that GCC will not reschedule writes across the lock either. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Mark Wielaard wrote: >- There seems to be a gcc compiler bug that makes the following >patch >necessary: >--- orp-1.0.9/base_natives/common_olv2/mon_enter_exit.cpp >+++ orp/base_natives/common_olv2/mon_enter_exit.cpp >@@ -294,7 +294,7 @@ > #else >"nop;nop;nop" > #endif >- ::: "memory" >+ : : : "memory" >); > > #else > I think that is not a bug, but rather an obscure C++ misfeature called "trigraphs". regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: nio package and asynchronous io
Mark Wielaard wrote: do you have any plan on adding nio support and asynchronous io to the classpath project? if yes what is your agenda on this subject. >>>I have done a little bit of work for GCJ with this. >>> > >I have read the online 1.4 specs for java.nio and thought about how to >implement it but I have done no actual work. We will get it in time, but >nobody is actively working on it at the moment. > I've started to implement some of the Buffer and mapped I/O stuff in my GCJ tree too. Its relatively simple to implement for CNI, however I think we'll need to look at adding some special support for buffers in GCJ in order to get really good performance from zero-copy I/O. Thats because the idea is to write things like: while (buf.hasRemaining()) ... = buf.get(); in order to avoid copying data into an array during I/O, but unless they get inlined the call overhead is going to kill any performance gain obtained from not copying. Inlining the hasRemaining() and all its friends is easy because they are final, but the buf.get() is a bit harder because its a virtual method. However if we taught GCJ that the various methods in nio usually/always return a GCJMappedByteBuffer or whatever, it could inline the get() too and the whole things becomes no less efficient than a regular bounds-checked array acccess. Its just a shame they didn't include Buffer methods like: byte[] get(int length); // get bytes from the buffer as a shared byte array. I guess allowing that sort of thing would raise aliasing issues for the JITs, and you couldn't do it for a read-only buffer without changing the semantics of arrays. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Mark Wielaard wrote: >- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two > workaround for compiling with gcj in my local tree. It might be a good > idea to apply them. > I will try to fix any remaining issues preventing classpath being compiled with GCC 3.1. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Patch #103] formatting (indentation) changes for java/net/PlainSocketImp
I also like to stamp out the remaining comments like this: /*/ whenever reformatting. Can you do that as well? Do you have classpath CVS access or do you want me to commit it? regards Bryce. [EMAIL PROTECTED] wrote: >Patch #103 has been updated. > >Project: >Category: None >Status: Open >Summary: formatting (indentation) changes for java/net/PlainSocketImp > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: AWT licensing
On Sunday, January 13, 2002, at 08:53 PM, Paul Fisher wrote: > The Classpath AWT now falls under the GPL+exception, as does the > libgcj AWT. This is excellent (and long awaited!) news. Many thanks to those who went to the effort of getting this issue sorted. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JBOSS mods are now on https://savannah.gnu.org/patch/index.php
Washburn, Weldon wrote: >I just got approval to post the zip files. Diff the trees in patch ID 64 >and patch ID 65 to see each mod in each file. > I've made diffs and reposted separate patches for different packages that were changed. I also looked through the collections changes, and closed that patch since we have already fixed all of those bugs. In future it would be better if you could post actual patches rather than .zip files, since they are much easier to work with. The "-N" option for diff will ensure that newly-created files get included in the diff. Its unfortunate that some of the files you changed (eg java/io/ObjectInputStream) contain large blocks of reformatted code. This makes it very difficult to tell what the actual logic changes are, and reduces the chances that the patch will be integrated! Please keep formatting changes separate from code changes. >Gansha, >Will you supply the necessary change log to make it easier for the GNU >Classpath folks to integrate your work? > This would be very helpful. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: porting classpath to c# to get java <--> c#
Per Arneng wrote: >Since the java api is one of the greatest api's that evere seen the light. I >thought it would be cool to port classpath to c# to make it easier to port >software java <---> c# this would also reuse most of the efforts in >classpath in to the DotGnu project and the mono project. Are there any >porting projects of this kind? If there are i would like to participate. > >The reason is: c# language is very good but the .NET API is't allways that >good. and whats with the capital letter in method names. Console.WriteLine. >Its not very nice i really like the java coding conventions and if it was >possible to combine the strength of the c# language with the java API it >would be a winning combination. > What you really want to do is compile the classpath source code into the .NET bytecode such that it shares a common runtime object model with your c# code, not port the classpath source code to c#. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Serialver [was Re: [PATCH]]
Eric Blake wrote: >Therefore, the safest course of action is to explicitly have a >serialVersionUID for all Serializeable classes, rather than relying on >the implicit UID generated by the undocumented hash behavior. > After reading your explanation, I agree. >Note that the serialVersionUID field should be a private variable (Sun's serialver >neglects this fact, making it seem like package-private is acceptable), >so that it is not inherited by other subclasses in the same package. > Actually this shouldn't matter, since the serialization code looks up serialVersionUID using getDeclaredField(), which will not return fields declared in superclasses. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH]
Dalibor Topic wrote:
>--- classpath/java/io/Serializable.javaSat Nov 17 15:00:13 2001
>+++ patched/java/io/Serializable.java Sat Nov 17 16:04:01 2001
>@@ -40,6 +40,7 @@
> */
> public interface Serializable
> {
>+static final long serialVersionUID = 1196656838076753133L;
> } // interface Serializable
>
This is redundant. An explicit serialVersionUID is only required when a
classes implementation may be different from the JDK version (different
private fields, for example), or where a class has evolved over time and
needs to be backward-compatible with serialized instances from the older
versions.
You can write your own simple serialver utility to verify this:
import java.io.*;
public class SerialVer
{
public static void main(String[] args) throws ClassNotFoundException
{
String className = args[0];
Class cl = Class.forName(className);
ObjectStreamClass osc = ObjectStreamClass.lookup(cl);
System.out.println (osc.getSerialVersionUID());
}
}
$ serialver java.io.Serializable
java.io.Serializable:static final long serialVersionUID =
1196656838076753133L;
$ gij SerialVer java.io.Serializable
1196656838076753133
regards,
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Breaking VM integration interface
Brian Jones wrote: >Is the point to avoid having to initialize String or do subsequent >method calls in native code to convert the string to a char array? >The change can be made, but get this, I think a small library (JNI) >should be provided that implements the new method and calls the old or >something similar provided documentation-wise. > The new form is simpler and cleaner for VMs to implement, and a tiny bit more efficient. Obviously we should document the change in the release notes or whatever. VMs can provide both forms of the function during the transition. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: testing before a release
Tom Tromey wrote: >I've always assumed that since libgcc has used this license for years >(probably more than 10 years), that it is well understood and >acceptable (for its purpose). If it has problems, I think they should >be addressed through RMS and the gcc steering committee. If this >license is unworkable for libgcj then it is a hundred times worse for >libgcc -- libgcc is required by every gcc-compiled program. > Its unfair to lump classpath/libgcj and libgcc together here. The libgcc license has and does seem to work well - for libgcc. This is a small compiler support library that makes little sense outside the scope of supporting object files compiled gcc. But classpath and libgcj are much larger and broader in scope than libgcc or even libstdc++. The question is whether classpath/libgcj should be using the libgcc license or whether the classpath license should be clarified to prevent misinterpretation or misuse. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.ResourceBundle bug?
Brian Jones wrote: >Found 1 semantic error compiling "../../java/util/ResourceBundle.java": > > 118. return new Security(); > <-> >*** Error: An instance of "java/util/ResourceBundle.this" is not accessible here >because it would have to cross a static region in the intervening type >"java/util/ResourceBundle$1". >make[1]: *** [compile-classes] Error 1 >make[1]: Leaving directory `/home/cbj/cvs/classpath/build/lib' >make: *** [all-recursive] Error 1 > Doh, must be a bug in GCJ. I see you fixed it already... cheers Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
