This will implement the Method CommandSet
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_Method
It's fairly straight forward though the actual implementations for
LineTable and VariableTable will likely wait until we have a better hang
of how we deal with these in the
Implemented {,SHIFT-} PAGE {UP,DOWN} key action in BasicListUI. Also
had to make a small correction to JViewport's scrollRectToVisible that
PAGE DOWN revealed where we were off by 1 pixel.
Patch attached.
2005-07-28 Anthony Balkissoon <[EMAIL PROTECTED]>
* javax/swing/JViewport.java:
(scroll
These are many bugs I ran into when running several applications. There
are more I have found and will fix soon!
2005-07-28 Lillian Angel <[EMAIL PROTECTED]>
* java/awt/GridBagLayout.java
(distributeSizeAndWeight): added in check, because OutOfBounds
exception was being
Jeroen Frijters wrote:
Here's an alternative patch that rips out most of the complexity and
leaves everything to the VM. It took me about three minutes to implement
this new interface for IKVM, so I know I'm happy with it!
The only thing missing that the documentation should be improved a bit.
Hi,
On 7/28/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here's an alternative patch that rips out most of the complexity and
> leaves everything to the VM. It took me about three minutes to implement
> this new interface for IKVM, so I know I'm happy with it!
>
> The only thing miss
Hi,
Here's an alternative patch that rips out most of the complexity and
leaves everything to the VM. It took me about three minutes to implement
this new interface for IKVM, so I know I'm happy with it!
The only thing missing that the documentation should be improved a bit.
Rob and Archie, is t
Changed KeyEvent.isShiftDown() and KeyEvent.isControlDown() to
comparisons between KeyEvent.getModifiers() and InputEvent.SHIFT_MASK
and CTRL_MASK.
Also switched the order of shift and control handling in
MouseInputHandler.mousePressed to correspond to the JDK's behaviour.
Patch attached.
2005-0
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>> We have some similar tweaks in the libgcj ClassLoader.
>> And a while back I change our internals to register initiating
>> loaders by adding classes to the loadedClasses map.
>> So, I think this is a good idea.
Mark> So this change wil
> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:
Jeroen> This raises the question, how many VMs are actually using the
Jeroen> loadedClasses hashtable in ClassLoader?
Jeroen> We know these aren't: JCVM, JamVM, gcj, IKVM
Actually gcj does.
Tom
__
2005-07-27 Audrius Meskauskas <[EMAIL PROTECTED]>
* org/omg/DynamicAny/DynUnion.java,
org/omg/DynamicAny/DynUnionOperations.java,
org/omg/DynamicAny/NameDynAnyPair.java,
org/omg/DynamicAny/NameValuePair.java,
org/omg/DynamicAny/DynAny.java,
org/omg/DynamicAny/DynAnyOperations.java,
org/omg/Dyna
Robert Lougher wrote:
> Flame away,
I deleted everything I agree with.
Since I'm partly to blame for the current mess in Class.forName(), I'll
include a clean up of this in my next version of the patch.
Regards,
Jeroen
___
Classpath-patches mailing l
David Gilbert wrote:
> I hope when I mentioned that JamVM was broken, it didn't sound like a
> complaint, because that wasn't what I intended.
Not at all. I was just a bit surprised that it is possible to live on
the bleeding edge of development and still maintain the notion:
> how VMs work...as
Robert Lougher wrote:
In my opinion, the logic for deciding whether to load via the bootstrap
or via a classloader, whether to load an array or a "normal" class,
initialization, and the managing of the cache is best done in the runtime
for performance reasons.
Most of what Robert said above i
Mark Wielaard wrote:
> It looks like that is also what gcj and jamvm do already.
> That is why I am surprised that we really need the double callbacks
> everywhere. Does that make the interface really more flexible?
> In the case of Class.forName() you mean that when we need to delegate
> to Class
Mark Wielaard wrote:
Hi Jeroen,
On Thu, 2005-07-28 at 10:52 +0200, Jeroen Frijters wrote:
...I was a bit
surprised by the fact that two people complained that JamVM broke with
cvs head after my changes (I wasn't surprised that it broke, but I was
surprised that people actually ran into this
Mark Wielaard wrote:
But for a larger change like this it is probably good to get a sign-off
by Robert, Stephen, Archie or any other runtime implementor who you know
uses pristine Class/ClassLoader classes from GNU Classpath to make sure
they agree that they will keep on using them. Or hear from
Archie Cobbs wrote:
> For what it's worth, JCVM maintains its own intiated types and
> defined types tables internally, so this patch does not make life
> better (or worse). I would have to disable this code.
This raises the question, how many VMs are actually using the
loadedClasses hashtable in
Hi,
Jeroen Frijters sumatra.nl> writes:
>
> Mark Wielaard wrote:
> > On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote:
> > > While digging around the class loading issues, I discovered that we
> > > didn't record a class with the "initiating loader" [1]. This is
> > > necessary to maint
this is committed.
On Wed, 2005-07-27 at 15:38 -0400, Anthony Balkissoon wrote:
> JComponent's scrollRectToVisible method simply passes the call up to the
> Component's parent. Components that can handle the call should override
> scrollRectToVisible. This patch implements the method for JViewpo
Hi Tom,
On Wed, 2005-07-27 at 13:46 -0600, Tom Tromey wrote:
> We have some similar tweaks in the libgcj ClassLoader.
> And a while back I change our internals to register initiating
> loaders by adding classes to the loadedClasses map.
> So, I think this is a good idea.
So this change will make
Hi Jeroen,
On Thu, 2005-07-28 at 10:52 +0200, Jeroen Frijters wrote:
> I agree that the call to registerInitiatingLoader() in
> ClassLoader.defineClass() is a bit iffy. The reason I left it in there
> is to not break any VMs when I check in this patch. I was a bit
> surprised by the fact that two
Hi,
On Thu, 2005-07-28 at 09:55 +0200, Christian Thalinger wrote:
> Just a small typo. But it seems noone is testing with 64-bits ;-)
>
> 2005-7-28 Christian Thalinger <[EMAIL PROTECTED]>
>
> * native/jni/java-nio/java_nio_MappedByteBufferImpl.c
> (get_raw_values): Fixed typo for 6
I committed this patch:
2005-07-28 David Gilbert <[EMAIL PROTECTED]>
* java/text/AttributedStringIterator.java: reformatted.
Regards,
Dave Gilbert
Index: java/text/AttributedStringIterator.java
===
RCS file: /cvsroot/cla
Just a small typo. But it seems noone is testing with 64-bits ;-)
TWISTI
2005-7-28 Christian Thalinger <[EMAIL PROTECTED]>
* native/jni/java-nio/java_nio_MappedByteBufferImpl.c
(get_raw_values): Fixed typo for 64-bit case.
Index: native/jni/java-nio/java_nio_MappedByteBufferI
Mark Wielaard wrote:
> On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote:
> > While digging around the class loading issues, I discovered that we
> > didn't record a class with the "initiating loader" [1]. This is
> > necessary to maintain type safety in the face of buggy or malicious
> > cl
Hi,
On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote:
> While digging around the class loading issues, I discovered that we
> didn't record a class with the "initiating loader" [1]. This is
> necessary to maintain type safety in the face of buggy or malicious
> class loaders (or even when
Anthony Balkissoon wrote:
JComponent's scrollRectToVisible method simply passes the call up to the
Component's parent. Components that can handle the call should override
scrollRectToVisible. This patch implements the method for JViewport.
Patch is pending approval. Patch is attached.
Looks
27 matches
Mail list logo
