Hi,
I wrote:
> I'm going to submit a Sun bug report against the InternalError
> javadoc. It will suggest that either they change the javadoc wording
> to match current practice, or they define a new xxxError exception to
> be thrown for library internal errors.
> I'm also going to submit a bug re
David Daney wrote:
Stephen Crawley writes:
I'm also going to submit a bug report about the JDK's widespread abuse
of RuntimeException. IMO, they should either throw InternalError (or
its replacement) or they should define some appropriate subtypes of
RuntimeException and throw those.
I agree. IM
Tom Tromey wrote:
"Guilhem" == Guilhem Lavaux <[EMAIL PROTECTED]> writes:
Hi Tom,
Guilhem> * first, it is not compilable in C++ mode. I've fixed that by
Guilhem> moving some ifdef block and adding a '}' to finish the
Guilhem> 'extern "C"' block.
Hmm, we should probably merge in
Stephen Crawley writes:
>I'm also going to submit a bug report about the JDK's widespread abuse
>of RuntimeException. IMO, they should either throw InternalError (or
>its replacement) or they should define some appropriate subtypes of
>RuntimeException and throw those.
I agree. IMHO RuntimeExcep
On Tue, 2004-07-06 at 19:46, Chris Pickett wrote:
>
> 3) RuntimeException's are what you should throw if there is a
> programming error, including if it's in the class libraries. By strong
> convention, Error's are reserved for the JVM only (Bloch gives two
> references). The JLS does not ma
For the record, grep tells me that Sun's JDK 1.4.2 class libraries
throws InternalError in 145 places. Notwithstanding the wording of the
InternalError javadoc, Sun uses it extensively for library errors. In a
couple of cases, the comments that indicated that the developer thought
that InternalE
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 e
> "Brian" == C Brian Jones <[EMAIL PROTECTED]> writes:
Brian> What is _the_ best and single free software java compiler to get behind
Brian> and use these days? Which one has the best jacks test suite score?
Either jikes or the eclipse compiler. I don't have results handy for
the latter.
T
> "Guilhem" == Guilhem Lavaux <[EMAIL PROTECTED]> writes:
Guilhem> * first, it is not compilable in C++ mode. I've fixed that by
Guilhem> moving some ifdef block and adding a '}' to finish the
Guilhem> 'extern "C"' block.
Hmm, we should probably merge in the libgcj version again, there ar
Bryce McKinlay wrote:
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, Cla
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?
Hi all,
A little update. We are almost, really ready. But I forgot how much time
generating the API doc takes. And I hadn't counted on the Americans
taking the Monday off. Silly, inconsiderate European...
Quickly talked to Steven Augart on irc and we got JikesRVM working much
better with classpat
Bryce McKinlay wrote:
> 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 param
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 t
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, pu
On Tue, 2004-07-06 at 06:04, Dalibor Topic wrote:
> Ming Chen wrote:
> > Hi,
> >
> > I have some problem to compile the CLASSPATH in Debian Linux/ Xscale, it
> > used up the memory (3G).
>
> Let me guess ... jikes? Known bug in jikes. Avoid using it to compile
> classpath on arm-linux. Use anothe
Am Di, den 06.07.2004 schrieb Roman Kennke um 22:19:
> > > Together with Michael I have put together an emacs configuration
> > > hook, which enables GNU style auto-completion in Emacs with JDEE.
>
> > I found a bug: It wants to indent the { } for method/constructor
> > bodies for 2 spaces too, b
> > Together with Michael I have put together an emacs configuration
> > hook, which enables GNU style auto-completion in Emacs with JDEE.
> I found a bug: It wants to indent the { } for method/constructor
> bodies for 2 spaces too, but these must he like for classes and
> interfaces have the sa
Amazing. I've only just got this.
Thanks for the clarification, but as Jeroen said, irrelevant to us as
VM implementors. To be robust, we have to handle invokeinterface on a
method that only exists in Object.
Rob.
On Tue, 06 Jul 2004 06:27:52 -0600, Eric Blake <[EMAIL PROTECTED]> wrote:
> Robe
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 class
Bryce McKinlay wrote:
> 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.
>>
>
>
> The Java 2(TM) Platform API specification[1]
>
> [1] http://java.sun.com/j2se/1.4.2/do
Hi,
Merging jni.h with kaffe, we have noticed two problems:
* first, it is not compilable in C++ mode. I've fixed that by moving
some ifdef block and adding a '}' to finish the 'extern "C"' block.
* second, I think the definition for JNI_CreateJavaVM is slightly wrong.
Instead of
JNIEXPORT jint
Bryce McKinlay wrote:
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/
It's worth reading
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
_
Bryce McKinlay wrote:
> 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
Bryce McKinlay wrote:
> 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
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
bet
Bryce McKinlay wrote:
> I wonder if we should standardize on using RuntimeException in these
> cases.
I'm not in favor of using RuntimeExceptions for these. RuntimeExceptions
are much more likely to be swallowed by user code and the semantics of
InternalError are much closer to what we want to ex
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.
+
Eric Blake wrote:
> The compiler must always allow you to invoke a
> public method from Object from a qualifying type of an
> interface (since in JLS 9, interfaces implicitly have all
> public methods from Object), but the compiler's responsibility
> according to JLS 13.1 is to flatten that to a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 6. Juli 2004 10:45 schrieb Roman Kennke:
> Hi list,
>
> Together with Michael I have put together an emacs configuration
> hook, which enables GNU style auto-completion in Emacs with JDEE.
>
> In order to make this work, you have to have J
Hi,
Apologies for my previous rather vacuous reply. Gmail doesn't seem to be
receiving classpath ATM(or very slowly), so I replied to Jeroen's email,
without realising there was rather more to it...
My observations follows what Eric has said. Using javac 1.3 and jikes I saw
a call to (say) to
On Tue, 6 Jul 2004 15:06:16 +0200, Jeroen Frijters <[EMAIL PROTECTED]> wrote:
> Eric Blake wrote:
> > Robert Lougher wrote:
> > > OK, I'm yelling :) Please don't use Mark's patch!
> > >
> > > It "fixes" it by stopping resolution finding the method on Object.
> > > However, it is legal to have an i
Jeroen Frijters wrote:
Eric Blake wrote:
I think you two are talking about two different things. I think Robert
means that it is legal to use invokeinterface on an Object method
through an interface type. So this is legal:
invokeinterface java/lang/Runnable/toString()Ljava/lang/String;
No, it is
Eric Blake wrote:
> Robert Lougher wrote:
> > OK, I'm yelling :) Please don't use Mark's patch!
> >
> > It "fixes" it by stopping resolution finding the method on Object.
> > However, it is legal to have an invokeinterface on an Object method
> > (as all interfaces subclass Object).
> >
> > Ins
Robert Lougher wrote:
OK, I'm yelling :) Please don't use Mark's patch!
It "fixes" it by stopping resolution finding the method on Object.
However, it is legal to have an invokeinterface on an Object method
(as all interfaces subclass Object).
Instead, please use the attached patch to the interp
Hi,
Yes, I found that problem with jikes on arm-linux. If I remember
(over a year ago now) it gobbled up the memory when compiling classes
that used doubles, etc. (java.lang.Double). I found if you copied
over the class files for these so it didn't try to compile them you
could get it to work.
Ming Chen wrote:
> Hi,
>
> I have some problem to compile the CLASSPATH in Debian Linux/ Xscale, it
> used up the memory (3G).
Let me guess ... jikes? Known bug in jikes. Avoid using it to compile
classpath on arm-linux. Use another compiler.
cheers,
dalibor topic
_
Mark Wielaard wrote:
Hi,
But maybe all this talk about compatibility will at least lead to the
Kaffe team finally getting access to the TCK on reasonable terms. And
after the release (waiting for some feedback from the Jikes RVM hackers)
we should try to explain the JCP pitfalls again now that the
Hi list,
Together with Michael I have put together an emacs configuration hook,
which enables GNU style auto-completion in Emacs with JDEE.
In order to make this work, you have to have JDEE installed:
http://jdee.sunsite.sk
XEmacs includes JDEE by default.
include the following snipped directl
Hi,
On Mon, 2004-07-05 at 23:36, David Holmes wrote:
> Sun wasn't "full of praise". OVM was mentioned by Greg Bollella as an
> example of an independent implementation of the RTSJ and how academia was
> looking at issues within the RTSJ. Nothing more, nothing less.
I wasn't there, but I read abou
41 matches
Mail list logo
