Mark Wielaard wrote:
> The FOSDEM organization has granted us a developer room!
Nice! Just booked my hotel. Looking forward to seeing everyone again.
Regards,
Jeroen
Mark Wielaard wrote:
> On Sat, 2007-04-07 at 08:03 +0200, Jeroen Frijters wrote:
> > I'd really like to see the removal of the META-INF/services/*xml* go
> in.
>
> Yes, that seems like a good idea. libgcj also did I believe that and
> the fallbacks are in place. Besides
Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > I'll try to pick up any fixes made on the trunk, but if you feel some
> > patch is release critical please do CC me.
>
> I'd really like to see the removal of the META-INF/services/*xml* go
> in. The inclusion
Mark Wielaard wrote:
> A release branch has been created 'classpath-0_95-branch'
Shouldn't that have been 0.94?
> I'll try to pick up any fixes made on the trunk, but if you feel some
> patch is release critical please do CC me.
I'd really like to see the removal of the META-INF/services/*xml* g
Tom Tromey wrote:
> I think for proper operation we have to remove the various XML service
> files from META-INF; see the earlier thread. But in order for this to
> work we also have to fix SAX to properly fall back to the Classpath SAX
> parser.
Any update on this? I'm convinced that we must rem
Tom Tromey wrote:
> Today I found out that ^M characters were added to the end of all the
> lines of ChangeLog. I undid this and added a local variable section
> for the benefit of those using Emacs.
I'd just like to point out (as the only evil CR/LF using OS user) that it
wasn't me... ;-)
Rega
Christian Thalinger wrote:
> On Fri, 2007-03-23 at 13:38 +0100, Jeroen Frijters wrote:
> > I think my Socket patch from the 19th introduced this. I'm looking
> into it...
>
> Yes, I just verified.
The attached patch fixes things. Sorry for the trouble.
Regards,
Jeroen
I
Mark Wielaard wrote:
> On Fri, 2007-03-23 at 12:26 +0100, Christian Thalinger wrote:
> > I've found another regression with current head. jetty-5.1.11 does
> > not serve pages anymore (while it does for 6.1.1):
> >
> > $ telnet localhost 8080
> > Trying 127.0.0.1...
> > Connected to localhost.loca
Hoi Mark,
When is the next release due? The current release (0.93) has the incorrect
daylight savings rules for the US and I've already had one IKVM user run into
this. I'm probably going to release an IKVM update that is based on GNU
Classpath 0.93 + the cvs version of TimeZone, but it would b
Andrew Haley wrote:
> Jeroen Frijters writes:
>
> > However, the truth of the matter is that IMO our serialization code
> > is broken beyond repair, so I don't think it's worth it to try to
> > fix it the right way. We should just merge in the Sun serializatio
e that was introduced when I merged in
> the latest
> classpath code.
> The failures were apparently introduced with Jeroen's patch from
>
> 2006-08-11 Jeroen Frijters <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
> * java/io/ObjectInputStream.j
Roman Kennke wrote:
> I don't know if the FileInputStream should attempt to use a direct
> buffer. I guess it could be better in the case when a VM supports
> efficient access to it (see above). In other cases it should not be
> slower, so we should probably try to use direct buffers there (and in
Hi,
Subject says it all. Can someone who understands the Classpath build
infrastructure please have a look at this?
Thanks,
Jeroen
Mark Wielaard wrote:
> Interesting. Even though Enums should never be initialized "by hand"
> this is something a garbage collector should be aware of. Do garbage
> collectors already handle empty finalize() methods as if there was no
> finalizer?
Good ones do :-)
(I know that HotSpot does and IK
Ian Rogers wrote:
> I'm interested in adding these optimization to the Jikes RVM, but
> clearly the annotations need adding to Classpath. I was
> wondering what kind of response this would get?
I've been thinking about using annotations for similar things and one of
the things that I think makes
Andrew Haley wrote:
> Jeroen Frijters writes:
> > Tom Tromey wrote:
> > > >>>>> "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes:
> > >
> > > Roman> We are using the SystemProperties class throughout the
> > >
Tom Tromey wrote:
> > "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes:
>
> Roman> We are using the SystemProperties class throughout the
> Classpath code to
> Roman> access system properties and avoid the security checks in
> Roman> java.lang.System. However, I come to think that this
> i
Andrew John Hughes wrote:
> Hi everyone,
>
> Now that:
>
> a) gcj has branched for 4.2 and the gcj-eclipse branch is moving
> to trunk
> b) there is another Free 1.5 compiler in the form of Sun's javac
> c) most VMs have support for at least some of the 1.5 native stuff
>
> I'd like to suggest t
Andrew Haley wrote:
> I can't get even simple tests with generic signatures to work. Like
> this:
>
> public class test2
> {
> static class A extends ArrayList {};
>
> public static void main(String[] args)
> {
> A a = new A();
> Object x = a;
> ((Collection)x).add(new Byte((by
Andrew Haley wrote:
> I don't think that's a reasonable excuse for a bad interface.
It's not a bad interface, it's a bad implementation, that's a big
difference.
> If we had a better one, people could actually _use_ some of these
> "reference" methods without having to rewrite them.
That's compl
Andrew Haley wrote:
> How, exactly? I see horrors like
[...]
> public static ClassLoader getCallingClassLoader()
> {
> Class[] ctx = getClassContext();
> if (ctx.length < 3)
> return null;
> return getClassLoader(ctx[2]);
> }
>
> in several places.
Huh? The code you quot
Andrew Haley wrote:
> The current gnu.classpath.VMStackWalker interface is inefficient.
>
> Sun provide:
>
> sun.reflect.reflection.getCallerClass(int depth)
>
> and for the same function we would do
>
> VMStackWalker.getClassContext()[depth];
>
> You see the difference: Classpath's VMStac
Raif S. Naffah wrote:
> * the header file generated by the RI-1.5 emits a signature
> for the native method of an inner class that looks like so:
>
>JNIEXPORT void JNICALL Java_OC_IC_natInit
This looks like a bug in javah. [1] claims they fixed it.
> my questions are:
>
> 1. do VMs handle
Andrew Haley wrote:
> That depends on whether or not we think the spec or some
> implementation is buggy. It is often possible to tell -- some
> behaviours are just Obviously Wrong.
Even if something is "Obviously Wrong", it may not be a good idea to fix
it because it would be a breaking change.
David Gilbert wrote:
> The theory is easy: Mauve should test AN implementation against THE
> spec.
Pardon me for beating my favorite horse again, but this assumes that the
spec is somehow more valuable than code and/or that the spec doesn't
contain bugs. In the real world both are buggy and user
Mario Torre wrote:
> This patch makes the gconf backend the default.
>
> The configure part of the patch is the same as the one
> discussed early, but now the backend name is stored under
> META-INF and loaded at runtime using ServiceFactory.
>
> A new file is introduced in the META-INF director
Mario Torre wrote:
> Ops, this had to be System.get(...)
>
> Rereading the code, this (few lines later) makes more sense:
>
>String className =
> System.getProperty("java.util.prefs.PreferencesFactory",
> +
> Configuration.DEFAULT_PREFS_PEER);
OK. I see what you mean now.
> > I would expect
Mario Torre wrote:
> This patch makes gconf the default backend.
>
> The patch works adding a new configure option that let the user to
> specify a default implementation (like FileBased or GConfBased ones).
>
> If the user does not provides this option, than the preference backend
> is FileBased
Andrew John Hughes wrote:
> Based on your comments, it seems you agree with my original intuition
> of making this a native VM call (by default) in the majority of
> cases, but efficiency would seem to be fairly VM specific.
Sure, but Thread.getState() is unlikely to be used very often and shoul
Roman Kennke wrote:
> We could then merge some patches for java.util.logging, which
> would make use of this for more efficient logging. I think this
> would be useful for GNU Classpath. As it is now, we faced severe
> bottlenecks in applications that make use of the logging API.
Well then, by al
Roman Kennke wrote:
> Here (@Aicas) we faced a similar problem as described by Tom.
> We came up with another possible (but similar) solution, which
> doesn't 'muddle up' the VM interface (ok, depends on your meaning
> of 'muddle up', it adds a new method with -IMO - also clearly
> defined semanti
Roman Kennke wrote:
> I also don't think I misunderstood the purpose of the VMStackWalker VM
> interface. As far as I understand it, this interface is there in order
> to provide more efficient access to stack information than
> Thread.getStackTrace().
Tom's proposal was about VMStackWalker.getCal
Roman Kennke wrote:
> > If gcj cannot reliably walk the stack at the moment,
>
> I just want to add one comment here. The problem (at least as we found
> it @aicas) is not to reliably walk the stack, the problem is that the
> VMStackWalker interface is not well suited for 'walking' the
> stack.
Bryce McKinlay wrote:
> 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 GetCallingCla
ather not make this change this late in the release, I
understand and I'll base my IKVM release on a patched version.
Thanks,
Jeroen
2006-05-15 Jeroen Frijters <[EMAIL PROTECTED]>
* java/awt/Toolkit.java (getDefaultToolkit): Use Class.forName()
instead of directly c
Hi,
I still don't get it. Why can you walk up one frame from the context
class, but not two frames from the VMStackWalker class?
Regards,
Jeroen
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Tom Tromey
> Sent: Sunday, May 14, 2006 01:42
> To: G
Edwin Steiner wrote:
> I'm testing cacao with an "ecj -target 1.5"-compiled classpath in
> addition to the jikes-compiled classpath I normally use. With ecj I
> ran into a bootstrapping problem that made both cacao and jamvm fail:
>
> What makes the difference is that ecj uses StringBuilder instea
Andrew John Hughes wrote:
> Edwin Steiner <[EMAIL PROTECTED]> wrote:
[...]
> > A solution to this is to use VMSystem.arraycopy instead of
> > System.arraycopy. (StringBuffer already does that.)
[...]
> Yes, I know about this from when I was first bootstrapping
> the generics branch about 18 months
Andrew John Hughes wrote:
> So I see, although you didn't post a patch.
I did.
http://developer.classpath.org/pipermail/classpath-patches/2006-April/00
1837.html
> In general, can everyone please check against the generics
> branch in future if there is something that could possibly
> have been
Mark Wielaard wrote:
> And I might misunderstand the semantics of the @Internal access
> modifier. As I read your suggestion the VMClass.checkAccess()
> method is only invoked when the Constructor of the Class is not
> public.
It is invoked when either the constructor or the class is not public.
Mark Wielaard wrote:
> On Thu, 2006-03-30 at 13:09 +0200, Jeroen Frijters wrote:
> > I've added a new access modifier to IKVM. By applying the
> > @ikvm.lang.Internal annotation to a type or member, you can
> > mark it as internal to the library it resides in. Hopef
Hi,
I've added a new access modifier to IKVM. By applying the
@ikvm.lang.Internal annotation to a type or member, you can mark it as
internal to the library it resides in. Hopefully Java will provide
something similar with JSR 277, but I've decided not to wait on that.
To support this access leve
Hi,
I have not yet investigated, but it looks like the Mauve test
gnu.testlet.java.lang.String.split gets stuck in an infinite loop (it
runs fine on JDK 1.5). Could this be due to recent regexp changes?
Regards,
Jeroen
David Daney wrote:
> We cannot violate the JLS! A method that throws a checked exception
> without declaring it is a bug.
Rubbish! There are several ways to throw checked exceptions:
http://weblogs.java.net/blog/crazybob/archive/2004/09/dont_try_this_a.ht
ml
Regards,
Jeroen
Ian Rogers wrote:
> Some VMs require all Java threads to run upto a garbage collection
> barrier before garbage collection can be performed. If a Java
> thread never leaves JNI code then this will never happen and the
> VM deadlocks.
Why not fix the VM? Real world applications are likely to have
Mark Wielaard wrote:
> Does the dacapo xalan work for you with the following patch?
>
> diff -u -r1.36 ResourceBundle.java
> --- java/util/ResourceBundle.java 23 Oct 2005 17:04:46
> - 1.36
> +++ java/util/ResourceBundle.java 1 Mar 2006 10:59:59 -
> @@ -476,9 +476,7 @@
>
Jeroen Frijters wrote:
> Christian Thalinger wrote:
> > Yesterday I investigated the dacapo xalan problem. It's about
> > Class.newInstance.
>
> No, it's not. JikesRVM's Class.newInstance() is broken and ours is
> correct. Sun also lets exc
Christian Thalinger wrote:
> Yesterday I investigated the dacapo xalan problem. It's about
> Class.newInstance.
No, it's not. JikesRVM's Class.newInstance() is broken and ours is
correct. Sun also lets exceptions (even checked ones) escape from
Class.newInstace().
> The problem is around Resourc
simon place wrote:
> while browsing, trying to solve a problem, came across classpath, but
> when i tried it i found a bug in the bit i wanted to use,(
> URL class )
> which appeared easy to fix, wrote what i thought was a fix
> but now can't seem to find a nice way to run it.
>
> i am trying
Ito Kazumitsu wrote:
> I am playing with gnu.regexp these days and finding more and more
> to do before it becomes comparable with Sun's JDK.
>
> Although I will continue to make efforts on gnu.regexp,
> I am beginning to try another thing.
>
> I have found oniguruma, the regex library which is u
Wolfgang Baer wrote:
> I am a bit confused when to use the internal
> SystemProperties.getProperty()
> method over the normal System.getProperty() method.
When writing new code (or modifying existing code) you should almost
always use SystemProperties.getProperty(). Unless that would be a clear
s
Roman Kennke wrote:
> Am Donnerstag, den 26.01.2006, 14:28 +0100 schrieb Roman Kennke:
> > Hi Stuart,
> >
> > this is really interesting, thanks!
> >
> > I found something which might be a bug in Japi. The reverse
> Japi points
> > out the following:
> >
> > field
> >
> javax.swing.JTree.Acces
Gary Benson wrote:
> Archie Cobbs wrote:
> > Gary Benson wrote:
> > > + try
> > > + {
> > > + Class.forName("java.security.Security");
> > > + }
> > > + catch (Throwable t)
> > > + {
> > > + }
> >
> > It might be more appropriate to only catch Exception, not Throwable.
>
Dalibor Topic wrote:
> I believe the reflection code would profit from getting a nice
> VMInterfaceLift for the next release :)
Not to discourage anybody, but I've started on that several times
already and it is *really* hard to design an interface that suits
everyone's needs. Reflection is both h
Gary Benson wrote:
> Gary Benson wrote:
> > Jeroen Frijters wrote:
> > > I think I figured it out. With the attached test I could reproduce
> > > the problem on IKVM as well. The attach Classpath patch fixing
> > > things, although past 0.20 I think we should re
Archie Cobbs wrote:
> Mark Wielaard wrote:
> > Maybe we can again special case that security check by doing a
> > this.getClass().getClassLoader() == null?
> > Hmmm, no, that doesn't work since getClassLoader() will trigger a
> > security check. Nasty...
>
> That's what VMStackWalker.getClassLoade
David Lichteblau wrote:
> Quoting Archie Cobbs ([EMAIL PROTECTED]):
> > Gary Benson wrote:
> > >Isn't the boot class loader solely for java.lang?
> >
> > No.. under the Java2 delegation model, the boot class loader
> > should be given the first chance to try and load *every* class.
> >
> > Typica
I forgot to attach the patch.
Regards,
Jeroen
> -Original Message-
> From: Jeroen Frijters
> Sent: Friday, January 13, 2006 07:54
> To: 'Archie Cobbs'; Gary Benson
> Cc: Classpath List
> Subject: RE: SecurityManager troubles
>
> Archie Cobbs wrote:
Archie Cobbs wrote:
> Gary Benson wrote:
> > Isn't the boot class loader solely for java.lang?
>
> No.. under the Java2 delegation model, the boot class loader
> should be given the first chance to try and load *every* class.
>
> Typically it will only find classes in glibj.zip (or rt.jar,
> or w
Guilhem Lavaux wrote:
> Jeroen Frijters wrote:
> > Gary Benson wrote:
> >
> >>Guilhem Lavaux wrote:
> >>
> >>>3) One solution of the problem is to load some core classes. But it
> >>>will appear quite soon that some other classes may al
Gary Benson wrote:
> Guilhem Lavaux wrote:
> > 3) One solution of the problem is to load some core classes. But it
> > will appear quite soon that some other classes may also be loaded
> > for really wicked applications. It is a limitative solution and I
> > would not support it.
>
> Yes. Exactly
Guilhem Lavaux wrote:
> I have stumbled across a bug probably shared by all VMs using GNU
> Classpath. In Apache Ant a SecurityManager is installed to be able to
> execute java application without forking the VM. Thanks to the SM
> exiting a VM is forbidden and so ant is protected from the
> ap
Casey Marshall wrote:
> I'd prefer to keep ".in" files to a minimum. We could attain
> the same thing by using reflection for the parts that may or
> may not be available or are disabled at compile time.
I agree. At the moment it is possible to compile Classpath without using
any of the build inf
Gary Benson wrote:
> > That's not exactly true. The system class loader does enforce that
> > user code cannot access classes in protected packages. It's just
> > that we don't have the proper security configuration files in place
> > to define the protected packages yet.
>
> You make it sound lik
Andrew Haley wrote:
> Gary Benson writes:
> > Michael Koch wrote:
> > > On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote:
> > > > If your security policy denies read access to that
> system property
> > >
> > > The solution is to use
> gnu.classpath.SystemProperties.getProperty(.
Archie Cobbs wrote:
> I'm adapting JCVM to work with a totally unmodified Classpath, but
> doing so seems to cause an infinite loop in Mauve test
> gnu.testlet.java.util.logging.Logger.getAnonymousLogger.
>
> The infinite loop is simple:
>
>Class.getClassLoader() invokes
> VMStackWalker.getC
Mark Wielaard wrote:
> +FAIL: gnu.testlet.java.text.DecimalFormatSymbols.serial (number 1)
> +FAIL: gnu.testlet.java.text.DecimalFormatSymbols.serial:
> uncaught exception: java.lang.NullPointerException
This is also a regression. At the moment I have no clue on how to fix
this, according to cvs
Hoi Mark,
Mark Wielaard wrote:
> +FAIL: gnu.testlet.java.io.ObjectInputOutput.OutputTest:
> gnu.testlet.java.io.ObjectInputOutput.Test$NotSerial (number 1)
This is a real regression and I'm testing the patch below at the moment.
Regards,
Jeroen
Index: java/io/ObjectOutputStream.java
=
Audrius Meskauskas wrote:
> However if anybody knows the way to get the loader of the caller
> class (stack trace contains the name only - no use), it would be
> great to know it.
Please add the following method to gnu/classpath/VMStackWalker.java and
use that.
/**
* Returns the first user defin
Stuart Ballard wrote:
> On 10/5/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote:
> > Possibly. Maybe we can use annotations (in the -- hopefully near --
> > future) to mark code that differs from Sun for a valid reason?
>
> Perhaps I have too little faith in my fello
Stuart Ballard wrote:
> > [1] One example I can think of is the non-constant serialVersionUID
> > fields in some classes (that compute their serialVersionUID based on
> > some runtime setting or such)
>
> Why would we get japi failures here? As long as we do the same thing
> the JDK does, japi won
Mark Wielaard wrote:
> This looks like something the compiler should warn against
> "public/protected field/return with package/private type"
> (inner classes could be private).
>
> Tom are you taking notes for gcjx?
>
> I think japi should also warn against it not hide it, except when
> explicit
Stuart Ballard wrote:
> Tom pointed out a little problem with Japitools' serialVersionUID
> calculation.
It's Japi bug. Classpath gets it right.
I don't have time to look into it right now (alright, I admit, I'm too
lazy), but I'm pretty sure that we're (read: I am) using the wrong class
modifier
Andrew John Hughes wrote:
> On Thu, Jun 16, 2005 at 12:08:18PM +0200, Jeroen Frijters wrote:
> > I'd like to propose a fundamental change to the VM interface on the
> > generics branch. In particular, I'd like the VM interface
> > (and in this case I mean strictl
Stuart Ballard wrote:
> Out of interest, exactly what difference in behavior would you see in
> the compiler and/or reflection based on those two different
> declarations of MyList?
Only the obvious things really. With reflection you can use
Class.getGenericSuperclass() to get a Type that describe
Stuart Ballard wrote:
> I have another question about Java generics behavior and hopefully
> people here are expert enough on the subject to be able to answer
> it...
>
> Does Java draw any distinction at all between, say, java.util.List and
> java.util.List?
Depends on what you mean by "Java" .
Stuart Ballard wrote:
> I see where you're coming from but I disagree. As I said about jgss, I
> believe that any time there's a japi error it indicates a real problem
> that needs to be fixed; if not in Classpath then in japitools itself.
> I've always erred on the side of only flagging errors whe
Stuart Ballard wrote:
> Does the Classpath project have an explicit policy for these kinds of
> situations?
I don't know if there is a policy, but I agree with you that we
shouldn't try to "fix" problems like this. It doesn't really solve
anything and makes interoperability more difficult.
> [1]
Stuart Ballard wrote:
> Jeroen, can you think of any immediately obvious reason why
> ClassFile.java might be missing the fact that these things are
> deprecated, other than a compiler bug?
I think it's a compiler bug. Looking at my japi stats [1] for IKVM 0.18
(based on Classpath 0.17), we don't
Christian Schlichtherle wrote:
> > Unfortunately, we cannot add additional public constructors,
> > but I would suggest adding a system property to control the
> > encoding used by our zip implementation. By default we should
> > be compatible with the JDK, but this would allow applications
> >
Christian Schlichtherle wrote:
> the changes from int to long are required as to the ZIP file format
> specification available online from PKZIP Inc.
>
> The specification says that all integers are 4 byte unsigned integers.
> Java's int type is 4 byte signed, thus the type long is
> required to
Casey Marshall wrote:
> Bug classpath/22853 prompted this, btw.
>
> Kaffe and jamvm should (I posted patches for both of these);
> probably gcj (I posted a patch for this too, but it's been
> hit-or-miss on whether or not my GCJ patches are accepted); I
> think I remember reading that IKVM implem
Andrew Haley wrote:
> Of course, yes. But it's security issues that I'm concerned about
> here: what we want to know is the first caller of Foo.method() that is
> not Foo.
Not necessarily. Typically what's important is the supplier of the arguments to
the method. In the subclassing scenario, the
Ingo Prötel wrote:
> I really like the idea of having a stack walker so I would like to use
> it wherever possible. For example in java.util.logging.Logger. If a
> class calls 'logger.warning("some warning")' this call will
> be forwarded through a couple of calls until it will call
> 'Logger.log(
Andrew Haley wrote:
> Which is the Right Answer: the caller of baz *is* Frob.
It *may* be the right answer, but how can you be certain that the coder of
class Foo intended this? IMNSHO, code like this is completely unauditable
(remember, this isn't just a correctness issue, access to class loade
Andrew Haley wrote:
> However, as for overhead -- I don't believe it. I doubt that not
> having this parameter saves anything much on any VM.
That's just your lack of imagination ;-) I was concerned with two
aspects wrt performance:
1) Class literals are inefficient -- this is no longer an issue
Andrew Haley wrote:
> In gcj, we have a method called GetCallingClass(Class c). It searches
> firstly for a method declared in class c, then for a method not
> declared in c. We have found, after a certain amount of trouble, that
> this is the right way to do things; it means that an arbitrary nu
Ingo Prötel wrote:
> I just implemented VMStackWalker for our VM and have some questions.
>
> The reference implementation of 'getCallingClass()' and
> 'getCallingClassLoader()' just look at the third entry in the class
> context. Would it not be better to return the first class that is not
> assi
Sven de Marothy wrote:
> Ok, I've been looking into the issue of our AWT peer
> interface now that I've been running my peers on Classpath
> in earnest.
>
> The goal here is to try to bring our peer interface as close to Sun's
> as possible. And simplify things for potential peer-authors.
>
[...]
Mark Wielaard wrote:
> Thanks. I turned this into some mauve tests. See
> gnu/testlet/java/io/Serializable/BreakMe. It seems we already have the
> correct behavior since all these tests PASS. Or I implemented
> the tests wrong of course. Please check.
Thanks! The tests look correct to me and Brea
Mark Wielaard wrote:
> On Thu, 2005-07-21 at 11:59 -0500, Archie Cobbs wrote:
> > Nicolas Geoffray wrote:
> > > there is something that might be wrong in the implementation of
> > > VMObjectStreamClass.hasClassInitializer
> > > (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses
> > > Ge
Archie Cobbs wrote:
> Simon Kitching wrote:.
> > * Class.getName returns strings that have been interned. I don't
> > think this is explicitly required by the java specs but is
> > certainly true for Sun's JVM and seems likely to be done by
> > any sensible JVM.
>
> I.e., is there something
Meskauskas Audrius wrote:
> When the CORBA server POA is temporary deactivated (discarding mode),
> the client receives remote exception org.omg.CORBA.TRANSIENT.
> One of the fields in this exception is the integer "minor error code".
> My OMG document (March 2004) clearly states that the value
Mark Wielaard wrote:
> I don't think we need a branch or backporting fixlets to 0.16
> for small bug fixes. We are in rapid development mode for various
> parts of our library. If people want we can make a new 0.17 release
> at the end of this week (next weekend) that incorporates all new
> work d
Chris Burdess wrote:
> Jeroen Frijters wrote:
> > I just tried running Eclipse 3.0 and 3.1m5 and both crash
> when exiting,
> > due to a problem with persisting its settings:
> >
> > java.lang.NullPointerException
> > at gnu.xml.dom.DomNamedNodeMap.setNam
Hi Chris,
I just tried running Eclipse 3.0 and 3.1m5 and both crash when exiting,
due to a problem with persisting its settings:
java.lang.NullPointerException
at gnu.xml.dom.DomNamedNodeMap.setNamedItem
(DomNamedNodeMap.java:209)
at gnu.xml.dom.DomNamedNodeMap.setNamedItemNS
(Dom
Hi Mark,
Mark Wielaard wrote:
> On Sun, 2005-06-19 at 12:39 +0200, Jeroen Frijters wrote:
> > I just updated my anoncvs classpath tree and it appears to be out of
> > sync. Some Corba classes that Audrius checked in on Thursday are
> > missing. Can someone please look into th
Hi,
I just updated my anoncvs classpath tree and it appears to be out of
sync. Some Corba classes that Audrius checked in on Thursday are
missing. Can someone please look into this?
Regards,
Jeroen
___
Classpath mailing list
Classpath@gnu.org
http://l
Andrew John Hughes wrote:
> Keeping the VM interfaces in sync sounds like a good idea to me, but
> keep a couple of things in mind:
>
> 1) A lot of VM differences between the two will be due to new methods
> that just don't exist outside the generics branch e.g.
> cast(), isEnum().
> You mention
Hi,
I'd like to propose a fundamental change to the VM interface on the
generics branch. In particular, I'd like the VM interface (and in this
case I mean strictly the interface between the Foo and VMFoo classes) on
the generics branch to be compatible with the main branch. That way a VM
can use t
1 - 100 of 358 matches
Mail list logo
