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 the
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 64-bit
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
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
Hi,
Jeroen Frijters jeroen at 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 maintain
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
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
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
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 is
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
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,
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 will make merging
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.
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 missing that
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.
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
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:
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
18 matches
Mail list logo
