Re: tiny bug gnu/classpath/Configuration.java.in
> "graydon" == graydon hoare <[EMAIL PROTECTED]> writes: graydon> ok to commit this? graydon> (gtk peers don't appear at all under classpath/kissme without setting graydon> this right) This is an obvious fix, so it can go in under that rule. Not that Classpath has patch review :-) I'm surprised to see this code in Classpath though. Last time it was in, Mark didn't like it, and I took it out, keeping it as a gcj-local change. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
tiny bug gnu/classpath/Configuration.java.in
ok to commit this? (gtk peers don't appear at all under classpath/kissme without setting this right) -graydon --- Configuration.java.in 2 Oct 2003 11:05:15 - 1.11 +++ Configuration.java.in 8 Nov 2003 02:37:06 - @@ -109,5 +109,5 @@ /** * Name of default AWT peer library. */ - String default_awt_peer_toolkit = "gnu.java.awt.peer.gtk.GTKToolkit"; + String default_awt_peer_toolkit = "gnu.java.awt.peer.gtk.GtkToolkit"; } ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
- Original Message - Tom Tromey writes: > David> I don't think there is an easy solution to this as it is unlikely > David> that a single VMInterface will fit the needs of all VMs perfectly. > David> In some cases (java.lang.ref.* for example), I don't think that it > David> is reasonable for classpath to try to provide an implementation > David> that will actually work unchanged on all VMs. > > Andrew> Exactly. Classpath should provide a reference implementation, > Andrew> we but shouldn't expect every core class to be used unchanged. > > I agree. I think it is reasonable to expect libgcj to diverge from > classpath in some places -- there are areas where libgcj's needs > aren't the same as the needs of other VMs. But at the same time, I'd > expect VMs that are unusual in other ways (e.g., IKVM or JikesRVM, > both "different" in one way or another) to also occasionally have > their own divergence. Or, to put it another way, let's distribute > some of the divergence; it can't all rest on libgcj. (Which I doubt > anyone is proposing anyway.) > I agree with you. My approach is rather pragmatic: first, classpath should allow to quickly develop a VM, by providing a clean design and as many features as possible in Java. Then, once the VM is running, everybody can choose the optimizations that match the problem that the VM is trying to address. In practice, as soon as one VM leaves the state of "pet project" or "proof of concept", optimizations are unavoidable. I'm not sure that compiler optimizations (in particular inlining and pointer escape analysis) can handle every problem (and as I remember, they ofter require static compilation and limit dynamic loading, a core java feature), thus some code modification may be required to optimize the API for the VM. Anyway, coming myself from the compiler world, you can imagine how painful it is for me to say that native methods should forward the call to the VM* classes (thus adding an indirection). This has for me the following advantages: * clear separation between the API and the VM * regrouping the native methods into a few classes (it is simpler to find out which methods must be implemented, and the number of stubs to create is much smaller, which is less code to manage) On the other hand, the VM* approach causes additional costs: * often requires to duplicate structures to keep track of one information. * additional indirection in each invocation As often the case, good design and optimizations don't mix well! In case of doubt, I always choose the good design (it fits every case) over the optimization (it usually fits only a specific use-case). But this is just my own opinion. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
I agree. One issue that comes up for Jikes RVM is that because we are licensed under the CPL we believe it is hard for us to provide modified versions of classpath in a way that is easy for our users to deal with. Because of this we have taken a tact of either (1) using a classpath class unchanged or (2) providing a complete replacement for the class. In most cases this is ok, but there are some cases where we want/need to make a very small change to a classpath class and things get awkward for us. In many cases, this can be done by adding a VMFoo class and a level of method calls. For us, this introduces no overhead because we inline them all away. It seems to me that the key question is can we construct this stuff in such a way that it causes no overhead for gcj as well (is there some stylized cross class inlining that you can do easily). If so, then there is a chance to really reduce the divergences by writing much of the sensitive code in this fashion, If not, then it is harder to balance the needs of the various VMs vs the obvious goodness of having as close to a single unified code base as possible. I personally really don't like having our own copies of entire classes because it is harder to track changes in classpath and benefit from bug fixes. So, there are places where Jikes RVM is living with very inefficient implementations of library functionality (almost everything having to do with stack inspection except java.lang.Throwable which we did reimplement) because in most cases the pain of diverging has been more important than the performance cost. --dave Tom Tromey <[EMAIL PROTECTED]> 11/07/2003 02:47 PM Please respond to tromey To: Andrew Haley <[EMAIL PROTECTED]> cc: David P Grove/Watson/[EMAIL PROTECTED], GNU Classpath <[EMAIL PROTECTED]> Subject: Re: VMInterface addition: Make native library names part ofVMInterface David> I don't think there is an easy solution to this as it is unlikely David> that a single VMInterface will fit the needs of all VMs perfectly. David> In some cases (java.lang.ref.* for example), I don't think that it David> is reasonable for classpath to try to provide an implementation David> that will actually work unchanged on all VMs. Andrew> Exactly. Classpath should provide a reference implementation, Andrew> we but shouldn't expect every core class to be used unchanged. I agree. I think it is reasonable to expect libgcj to diverge from classpath in some places -- there are areas where libgcj's needs aren't the same as the needs of other VMs. But at the same time, I'd expect VMs that are unusual in other ways (e.g., IKVM or JikesRVM, both "different" in one way or another) to also occasionally have their own divergence. Or, to put it another way, let's distribute some of the divergence; it can't all rest on libgcj. (Which I doubt anyone is proposing anyway.) Tom ___ 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: Patch: image loading fixes
> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
Tom> This patch fixes various problems related to image loading. It also
Tom> implements Component.imageUpdate, GtkToolkit.prepareImage and the
Tom> byte-array GtkToolkit.createImage method.
Looks good.
Tom> -// FIXME - gcj local: GdkPixbufDecoder doesn't work.
Tom> -// return new GtkImage (new GdkPixbufDecoder (filename), null);
Tom> -return null;
Tom> +return new GtkImage (new GdkPixbufDecoder (filename), null);
I don't remember why I commented out this code in libgcj, other than
what the comment says. I assume it is ok to enable now?
Tom> +boolean incrementalDraw = Boolean.getBoolean ("awt.image.incrementalDraw");
Tom> +Long redrawRate = Long.getLong ("awt.image.redrawrate");
Should these be computed once, at class init time?
Or do we want to recompute them each time this method is called?
Also, I forget where and how we're documenting properties we
recognize. I know this has come up before though. These two should
at least be mentioned in the javadoc for the method.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
David> I don't think there is an easy solution to this as it is unlikely David> that a single VMInterface will fit the needs of all VMs perfectly. David> In some cases (java.lang.ref.* for example), I don't think that it David> is reasonable for classpath to try to provide an implementation David> that will actually work unchanged on all VMs. Andrew> Exactly. Classpath should provide a reference implementation, Andrew> we but shouldn't expect every core class to be used unchanged. I agree. I think it is reasonable to expect libgcj to diverge from classpath in some places -- there are areas where libgcj's needs aren't the same as the needs of other VMs. But at the same time, I'd expect VMs that are unusual in other ways (e.g., IKVM or JikesRVM, both "different" in one way or another) to also occasionally have their own divergence. Or, to put it another way, let's distribute some of the divergence; it can't all rest on libgcj. (Which I doubt anyone is proposing anyway.) Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
> "Patrik" == Patrik Reali <[EMAIL PROTECTED]> writes: Patrik> Has anybody already tried to import classpath under Eclipse? FWIW, I wouldn't object to someone checking in an eclipse .project file (and other stuff) into classpath, provided it didn't rely on anything site-specific. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
> "David" == David P Grove <[EMAIL PROTECTED]> writes: David> One downside is that we haven't implemented JDWP in Jikes RVM David> yet, so you can't use the Eclipse debugger in this mode, but we David> all write bug free programs the first time, right ;-) This is a problem for gcj-eclipse, too. Does any free VM implement JDWP? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Ingo Prötel wrote: Hi Stuart, I have commited your patch: 2003-11-07 Stuart Ballard <[EMAIL PROTECTED]> * java/util/HashMap.java (putAll): Use Iterator hasNext() method. (putAllInternal): Likewise. * java/util/Hashtable.java (putAll): Use Iterator hasNext() method. (putAllInternal): Likewise. Thanks! Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
Julian Dolby knows more about this (maybe he will jump in), but when you run eclipse on Jikes RVM we've written a plugin such that the classpath libraries are not only used by eclipse, but are also used by the applications you develop in eclipse (and Jikes RVM is used to execute them). So, you can edit, build, compile, and run your Java code in Eclipse without needing any other JVM at all. One downside is that we haven't implemented JDWP in Jikes RVM yet, so you can't use the Eclipse debugger in this mode, but we all write bug free programs the first time, right ;-) We also have mainly been testing this on the 2.x versions of eclipse. I'm pretty sure we have a little work to do to get the current Eclipse milestone builds to work on Jikes RVM. --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
Has anybody already tried to import classpath under Eclipse? I tried to create a project and import the files, but then Eclipse is far too intelligent: * gnu/java/lang classes are imported into package java.lang * vm/reference/java/lang classes are imported into package vm.java.lang Probably I'm just doing something wrong (I'm using Eclipse 3.0M4) Never tried it. Most IDEs do not expect people to try to work on core java, especially not a "different" core java. Even so, there's nothing stopping you from configuring Eclipse to do so. The main areas you will need to configure are: - project properties -> Java Build Class Path -> Source Remove the autodetected source paths and add the project root as one. - Run -> Run As -> New Application (make sure you have your test app's main class open in the editor) gives you options to override the bootclasspath and other sundry items. I develop fbAWT under Eclipse 3.0M4 without problem. I use classpath's java.awt.Font* classes as they don't initialise native libs ;) Cheers, Stephane ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Hi Stuart,
I have commited your patch:
2003-11-07 Stuart Ballard <[EMAIL PROTECTED]>
* java/util/HashMap.java (putAll): Use Iterator hasNext() method.
(putAllInternal): Likewise.
* java/util/Hashtable.java (putAll): Use Iterator hasNext() method.
(putAllInternal): Likewise.
Ingo
Stuart Ballard wrote:
Stuart Ballard wrote:
Nobody spoke up, so could someone apply the patch (attached)?
Anybody? :)
Stuart.
Index: HashMap.java
===
RCS file: /cvsroot/classpath/classpath/java/util/HashMap.java,v
retrieving revision 1.24
diff -u -r1.24 HashMap.java
--- HashMap.java 1 Aug 2003 03:31:32 - 1.24
+++ HashMap.java 25 Sep 2003 18:16:52 -
@@ -381,8 +381,7 @@
public void putAll(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-while (msize-- > 0)
+while (itr.hasNext())
{
Map.Entry e = (Map.Entry) itr.next();
// Optimize in case the Entry is one of our own.
@@ -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);
Index: Hashtable.java
===
RCS file: /cvsroot/classpath/classpath/java/util/Hashtable.java,v
retrieving revision 1.28
diff -u -r1.28 Hashtable.java
--- Hashtable.java 7 May 2002 05:13:05 - 1.28
+++ Hashtable.java 25 Sep 2003 18:16:52 -
@@ -510,7 +510,7 @@
{
Iterator itr = m.entrySet().iterator();
-for (int msize = m.size(); msize > 0; msize--)
+while (itr.hasNext())
{
Map.Entry e = (Map.Entry) itr.next();
// Optimize in case the Entry is one of our own.
@@ -859,11 +859,11 @@
void putAllInternal(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-this.size = msize;
+size = 0;
-for (; msize > 0; msize--)
+while (itr.hasNext())
{
+size++;
Map.Entry e = (Map.Entry) itr.next();
Object key = e.getKey();
int idx = hash(key);
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
