Roman Kennke wrote:
These results normally get updated continuously, so the frontend should
always report the latest results that have been built sucessfully.
In the future we will (hopefully) add more compiler/VM(/classlib)
combinations so that we can compare the results to others.
I welcome
Roman Kennke wrote:
Also, the ability to see/track when a failure started occurring could be
very useful. That way we could easily match up new failures with patches
that caused them.
Hmm, that's an interesting feature indeed. We would have to keep diffs
between versions around and teach
Andrew Haley wrote:
Tom Tromey writes:
This week I spent some time looking at the libgcj/Classpath merge
situation. After removing all the simple merges that hadn't yet been
handled for some reason, I looked at VMStackWalker a little.
I think this merge could be done fairly simply.
CVSROOT:/sources/classpath
Module name:classpath
Branch:
Changes by: Bryce McKinlay [EMAIL PROTECTED] 06/04/11 19:11:00
Modified files:
. : ChangeLog
java/io: DataOutputStream.java
Log message:
* java/io
been modified, in practice
it is arguably redundant for these methods to do the check as they will
typically be called in tandem with next(), etc, if their results are
actually used.
I'm checking this in to Classpath HEAD, and gcc-4_1-branch.
Bryce
2006-04-05 Bryce McKinlay [EMAIL
Tom Tromey wrote:
In going through the stubs, I found java.awt.Image.getScaledInstance().
This method is interesting because it works for most cases, but not
the SCALE_SMOOTH case.
I'm not sure what to do here. I'm inclined to mark it as a stub.
But maybe it isn't that different from any other
Tom Tromey wrote:
Bryce Could JAPI scan for FIXME's as well? These could be flagged as
Bryce partial/known buggy method implementations.
Nope, japi scans .class files. Hence the (clever :-) hack of a
'throws' clause.
I'm not overly concerned about our ability to find FIXME comments --
grep or
David Gilbert wrote:
1) constant number of tests, regardless of exceptions being thrown or
Mauve does have a design flaw where it can be tricky to automatically
assign a unique identifier to each check(), and this makes it hard to
compare two Mauve runs (say a test of the latest Classpath CVS
Keith Seitz wrote:
Any better?
Keith
ChangeLog
2005-08-10 Keith Seitz [EMAIL PROTECTED]
* vm/reference/gnu/classpath/jdwp/VMIdManager.java: New file
with example implementation of ID-management for JDWP back-end.
* gnu/classpath/jdwp/id/JdwpIdFactory.java: Removed.
Aaron Luchko wrote:
This is the ThreadReferenceCommandSet
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_ThreadReference
thanks, Aaron
ChangeLog
2005-08-09 Aaron Luchko [EMAIL PROTECTED]
* gnu/classpath/jdwp/processor/ThreadReferenceCommandSet.java:
Keith Seitz wrote:
I'll post a ChangeLog, but this is really more an RFC than an RFA
(request for comment/request for approval). But who knows, even a blind
man occasionally hits the target! ;-)
ChangeLog
2005-08-04 Keith Seitz [EMAIL PROTECTED]
*
Aaron Luchko wrote:
This is the StackFrame command set
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_StackFrame
I'm not entirely sure what our classpath level Frame object will look
like in the end. For this I just have class with a bunch of getters and
setters
Keith Seitz wrote:
On Tue, 2005-08-09 at 15:30 -0400, Bryce McKinlay wrote:
Keith, this looks reasonable to me, although see comments below. Note
that using an abstract class is a little different to how most of the
VM* classes are implemented in classpath. Typically, classpath provides
Aaron Luchko wrote:
+try
+ {
+if ((invokeOpts JdwpConstants.InvokeOptions.INVOKE_SINGLE_THREADED)
+!= 0)
+ {
+// We must suspend all running threads first
+suspendSuccess = vm.suspendAllThreadsExcept(Thread.currentThread().
+
Aaron Luchko wrote:
Ok this is a touch more complicated but not too bad, there's also a
couple possibly minor issues. This implements the VirtualMachine
CommandSet
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_VirtualMachine
The VERSION command is the first one
Thomas Zander wrote:
I'm pretty sure its not an API design to disallow this. So its
implementation specific and your argument that Sun does not do it is
indeed a pretty strong one. I'm not sure I agree with it, but its a good
argument nontheless.
...
My original point still stands;
Thanks for the explanation, Nicolas.
You are correct, the current caching strategy does not work when the
same base resource is loaded repeatedly for many different locale arguments.
I'm looking at a solution that will fix this but continue to avoid the
string concatenations and allocations
[EMAIL PROTECTED] wrote:
While you are at it...
I remember a discussion ( somewhere, somewhen long ago) about a probable
bug with ResourceBundles, that they stay in memory (because of caching)
and that they should be dropped from cache somehow.
Maybe its a good idea to use one of the
Aaron Luchko wrote:
2005-07-05 Aaron Luchko [EMAIL PROTECTED]
* gnu/classpath/jdwp/processor/ReferenceTypeCommandSet.java:New
file.
Aaron,
This is OK with the formatting fixes that we discussed.
Bryce
___
Classpath-patches mailing
it in!
Thanks
Bryce
Keith Seitz wrote:
[pardon top posting]
It's been over a week now, does anyone else have an opinion or does
everyone agree with Bryce's comments?
Keith
On Mon, 2005-06-27 at 17:51 -0700, Keith Seitz wrote:
On Mon, 2005-06-27 at 17:03 -0400, Bryce McKinlay wrote
Keith Seitz wrote:
There's also a couple places I use classes from java.lang.reflect
This is a bit of a problem as it's been pointed out if in the instance
of a command like
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_ReferenceType_GetValues
Using the Field
Keith Seitz wrote:
I've addressed these concerns in the following two patches. Patch #1
contains the original changes submitted. Patch #2 addresses the
JdwpPacket.toBytes issue.
?
Keith
ChangeLog #1
2005-06-30 Keith Seitz [EMAIL PROTECTED]
*
Aaron Luchko wrote:
Ok, after some discussions with Bryce and Keith I've arrived at an
improved version of the patch. The first couple changes involve using an
array instead of the hashtable and tossing the IOException up from
_processOnePacket and exiting in run() when we get it.
The final
Keith Seitz wrote:
I believe the attached patch addresses concerns over temporary
OutputStream allocations.
Yes, this looks better. At least by using reset() on the
ByteArrayOutputStream we are eliminating one level of allocation and
potential copying. Aaron managed to convince me that
Chris Burdess wrote:
Bryce McKinlay wrote:
Does anyone know why we use the custom LineInputStream class instead
of, say, BufferedReader here? At one point BufferedReader.readLine() was
buggy and could read too much and block before returning a line, but I
believe we have fixed that. Code re
Michael Koch wrote:
Does anyone know why we use the custom LineInputStream class instead of, say, BufferedReader here? At one point BufferedReader.readLine() was buggy and could read too
much and block before returning a line, but I believe we have fixed that. Code re-use would help to avoid bugs
Does anyone know why we use the custom LineInputStream class instead
of, say, BufferedReader here? At one point BufferedReader.readLine() was
buggy and could read too much and block before returning a line, but I
believe we have fixed that. Code re-use would help to avoid bugs like
this ;-)
Sven de Marothy wrote:
On Fri, 2005-04-22 at 15:27 -0400, Bryce McKinlay wrote:
Sven,
Firstly, please don't ever put formatting and code changes in the same
patch! This is bad because it makes it difficult to distinguish code
changes from changes that are purely reformatting.
Actually
Etienne Gagnon wrote:
Recent gtk peer code seems to have introduced a subtle bug, only visible
on VM's that verify that structured locking is properly done. I have
put a description of the bug in the bug tracker at:
http://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=12301
There seems
Etienne Gagnon wrote:
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
So, the current
Roman Kennke wrote:
Am Montag, den 07.03.2005, 21:49 -0600 schrieb Archie Cobbs:
In this thread:
http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137
we talked about putting together somehow a list of Mauve tests that
all Classpath-based VMs should expect to pass, along with
Thanks for spotting this. We actually have a mauve test case for this
but it wasn't enabled due to a tags typo! I'm checking in the following
patch.
Bryce
2005-02-18 Bryce McKinlay [EMAIL PROTECTED]
* java/util/LinkedHashMap (addEntry): Call remove() with key argument,
not the HashEntry
David Daney wrote:
My understanding is that you want to integrate the libgcj and
classpath bug databases with but still maintain the current situation
with the actual code where there are separate code bases.
How would a bug be marked that is fixed in libgcj and not fixed in
classpath?
In
Dalibor Topic wrote:
d) It attracts overly generic constants
Configuration.DEBUG is used a handful of times, in pretty unreleted
classes to do the same job that's done in other classes using a
private constant with the same name. It's pretty confusing, as the
decription of the option that
Jeff Bailey wrote:
The tentative plan at this point is to use Orbit, since that's the Official GNU
ORB(tm).
My gut feeling is that using a non-Java ORB wouldn't be the best
technology decision for classpath. It doesn't make much sense to add
Java bindings to a non-Java ORB when there are so
Hey David,
Very nice. What did you use to format the results?
Regards
Bryce
David Gilbert wrote:
I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest
CVS version of Classpath) and posted the results here for anyone that is
interested:
Noa Resare wrote:
tis 2004-11-02 klockan 10:36 -0500 skrev Bryce McKinlay:
Hi Noa,
Thanks for looking into this. I agree that there is a bug here, as
demonstrated by your mauve test, but I'm not sure that this is the
correct fix. It should not be possible to set DST_OFFSET explicitly
because
Noa Resare wrote:
On 04-10-08 [EMAIL PROTECTED] checked in changes to java.util.Calendar
that effectively made an explicitly set DST_OFFSET value to a function
of the set TimeZone for the Calendar object if an other field (such as
YEAR) is set in the calendar after DST_OFFSET is set.
I think this
Jeroen Frijters wrote:
Perhaps a separate pass to normalize the fields is needed,
which can be called by both calculateDay() and computeTime()?
The nasty thing about this class is that all of its state is protected,
so subclasses could (theoretically) depend on all sorts of nasty
David Holmes wrote:
In contrast, the bootstrap classloader, which is used to load the system
classes (those logically in the 'bootstrap classpath'), such a Object,
Class, Calendar etc, may be null. If you do Calendar.class.getClassloader
you are asking for the bootstrap loader not the system
Mark Wielaard wrote:
If you remove this could you add a little note to VM Integration Guide
doc/vmintegration.texinfo about the importance of setting up the system
property gnu.classpath.home.url and how it is used by Security,
LogManager and InitialContext to find default configuration files.
Over the weekend I looked a bit at ResourceBundle usage in Calendar etc
again.
The problem:
Various classes, such as Calendar, need to load Locale information from
ResourceBundles. The ResourceBundle.getBundle() calls are frequent
enough, eg every time a Calendar instance is created, and
Jeroen Frijters wrote:
Hi,
I have some code that depends on unspecified behavior of java.util.Date.
In the Sun JDK if you pass out of range parameters to the Date
constructors that take year, month, date, etc. it will automatically
convert to a valid date (for example, new Date(104, 8, 41) is Oct
Jeroen Frijters wrote:
Hi,
I'm not sure, but I think with the recent time zone changes there was a
bug introduced. Does the patch below make sense?
Hmm... have an example/test case?
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
Guilhem Lavaux wrote:
As we always need a good locale database for GNU Classpath, I was
thinking of a way to get it. The ICU locale converter is only
partially satisfying as it does not have any collation rules generator
(at least). I've seen that www.openi18n.org[1][2] has begun a new
[moving this to the gcj and classpath lists]
Mark Wielaard wrote:
On Mon, 2004-07-12 at 00:01, Bryce McKinlay wrote:
I believe the following patch addresses both
concerns and makes sure that even when the Connection class is
loaded/initialized from a class with not enough permissions it can
Mark Wielaard wrote:
Does anybody know what version of gcj we need to avoid this
complaint? We should update the configure script appropriately.
The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and
gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually
includes a
Ben Hinkle wrote:
I'd like to port the Collections implementation in Classpath to another
language called D that is very similar to Java and I'm trying to figure
out the Classpath license. My question is simple: what license would
such a port fall under?
It looks like Classpath uses the GPL (not
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
Dalibor Topic wrote:
I think the solution here is to pass the system class loader. This
should always be correct for these bootstrap classes. It doesn't
solve the performance issues for cases where a security manager is
present, since a check will be performed by the getSystemClassLoader
call
David Gilbert wrote:
I'm familiarising myself with GNU Classpath at the moment, with the hope
that I can contribute something in the future (copyright paperwork is in
process). A quick question - are there any Javadocs online anywhere? I
couldn't find any, but maybe I missed somewhere obvious?
S. Meslin-Weber wrote:
Compatibility would be difficult given that there is no published
spec,
also the interface is no doubt quite complex. The benefits would be
questionable - it would let us run our peers on Sun's JDK for
debugging
purposes, but I don't think that advantage is worth the
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
On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote:
Bryce McKinlay wrote:
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
I think that is in fact what Mark was suggesting and I think
On Oct 27, 2003, at 2:01 PM, Mark Wielaard wrote:
On Mon, 2003-10-27 at 13:15, Bryce McKinlay wrote:
On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote:
I suggest to move the System.loadLibrary(javaio) calls completely
into the VMInterface classes. We want to have a system where (at
least
for lang
On Oct 26, 2003, at 6:43 AM, Dalibor Topic wrote:
One of the things I keep stumbling over whenever I merge code from
Classpath into Kaffe is the different native library names. Would it
be possible to separate those out into their own VMInterface class and
use references instead?
I'd prefer
for java.lang.Class constructors, however, is specified by Sun's docs
so we should probably keep that one).
Regards
Bryce.
2003-10-25 Bryce McKinlay [EMAIL PROTECTED]
* java/lang/reflect/AccessibleObject.java (secureSetAccessible):
Don't check for AccessibleObject. Update javadocs.
Index
On Oct 23, 2003, at 3:17 AM, Stuart Ballard wrote:
Andrew Haley wrote:
Where is this software?
I haven't found it yet, but see postings from Brian Jones on this list
where he indicates it's in OMG's FTP area (which I still can't find
linked from their site). I guess that you could argue that
On Oct 24, 2003, at 10:55 AM, Mark Wielaard wrote:
Hi,
On Thu, 2003-10-23 at 20:26, Stuart Ballard wrote:
I think I see a fairly simple way that OMG could preserve the
integrity
of the CORBA standard while remaining Free Software. In much the same
way as some Free licenses allow free
On Oct 11, 2003, at 4:00 AM, Stuart Ballard wrote:
Bryce McKinlay wrote:
The collections classes, on the other hand, are actually quite well
specified in my opinion (having architected many of the current
collections implementations used in classpath). I don't believe that
anyone should need
On Oct 9, 2003, at 2:41 AM, Stuart Ballard wrote:
Stuart Ballard wrote:
Bah, forgot the attachment.
Any decision on this?
Kaffe's applied it for their 1.1.2 release (dalibor's comment was
Fight premature micro-optimizations!) but I'd still like to see the
fix made to Classpath proper.
There
On Oct 10, 2003, at 12:40 AM, Sascha Brawer wrote:
Bryce McKinlay [EMAIL PROTECTED] wrote on Fri, 10 Oct 2003
00:08:16
+1300:
I wrote a quick test program to examine the behaviour of Sun's
ArrayList - and it definitely calls and relies on size().
Would it make sense to have such test programs
On Sunday, Oct 5, 2003, at 23:25 Pacific/Auckland, Guilhem Lavaux wrote:
I would like to introduce in classpath a concept which used to be in
kaffe but was recently removed because of the merging with classes
from classpath: DNS solver modularity. Previously it was possible to
specify to kaffe
On Tuesday, Sep 30, 2003, at 02:57 Pacific/Auckland, Stuart Ballard
wrote:
Furthermore, I'd argue that the very existence of a hasNext() method
suggests that Sun didn't intend people to make this optimization. If
they expected that calling size() and maintaining your own counter
would always
On Sunday, Sep 28, 2003, at 11:04 Pacific/Auckland, Mark Wielaard wrote:
Hi,
On Sat, 2003-09-27 at 22:21, Bryce McKinlay wrote:
Can you give me a pointer to the failing mauve test?
Without the patch the following four mauve tests fail:
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: CDT
On Friday, Sep 26, 2003, at 06:26 Pacific/Auckland, Stuart Ballard
wrote:
@@ -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())
{
checking in the following patch,
which reverts to the behaviour of Ralph's original patch.
2003-09-24 Bryce McKinlay [EMAIL PROTECTED]
* java/lang/StringBuffer.java (substring): Don't set `shared' on
small Strings, even if buffer is already shared.
Index: StringBuffer.java
On Sunday, Sep 21, 2003, at 21:06 Pacific/Auckland, Ralph Loader wrote:
java.lang.StringBuffer.substring is manipulating the shared flag on the
StringBuffer object incorrectly, PR java/12350.
The following patch fixes the bug and adds a test case. It passes the
libjava/testsuite on
On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove wrote:
Hi Tom,
We've had security manager checks in the reflection code in Jikes RVM for a while. Our current workaround for serialization is that classes loaded by the system classloader are always allowed access.
On Monday, Aug 4, 2003, at 19:57 Pacific/Auckland, Chris Gray wrote:
Sure. But to call AccessibleObject.setAccessible() you need
ReflectPermission, which the user code that initiated serialisation
does not
necessarily have. So the java.io serialisation stuff needs to have
this
permission, and
On Monday, Aug 4, 2003, at 21:33 Pacific/Auckland, Chris Gray wrote:
No. The security context of a given method invocation is the set of
classes
on the stack at the time of the invocation, and the resulting set of
privileges is the intersection of the privileges of all those classes.
So if
Compare the output of this test case using the current GCC/classpath
compared with GCC 3.1 or the JDK:
public class PropTest
{
public static void main(String[] args)
{
System.out.println (System.getProperties());
}
}
The problem (introduced into GCJ by a classpath merge) makes it
Per Bothner wrote:
Having dumpElement[ln] as separate
methods has the advantage that it could over overridden, but
it seems like poinles generality. So if we want to keep the
debugging printout, I suggest:
if (Configuration.DEBUG dump)
for (int i=0, len=Array.getLength(array); i
Nic Ferrier wrote:
Can I check in the FileURLConnection changes I submitted? They're
just formatting changes.
Certainly. You should always feel free to check in formatting-only
changes which bring things into line with our coding standards.
I have another patch to FileURLConnection which
Eric Blake wrote:
So back to my original question: Is the bounds check in the current
Classpath implementation of setLength necessary, or am I justified in
breaking the above snippet by removing the bounds check and throwing
IndexOutOfBoundsException instead?
Iit would be nice to do that, and
Mark Wielaard wrote:
I am going through the patches that the Orp developers submitted to
Classpath. The following patch to Method puzzles me:
2001-12-17 Wu Gansha [EMAIL PROTECTED]
* vm/reference/java/lang/reflect/Method.java: Reimplemented
equals(), refined toString().
Why/When is
Cierniak, Michal wrote:
Brian Jones writes:
Bryce McKinlay [EMAIL PROTECTED] writes:
I don't think it is neccessary to make it native. Method is already
part of the VM interface, so VMs can modify it or make it native as
they wish. I think the more conservative approach should be taken
Etienne M. Gagnon wrote:
On Fri, Feb 15, 2002 at 11:19:15AM +0100, Sascha Brawer wrote:
Hello,
the implementations of java.util.Hashtable.size() and
java.util.Hashtable.isEmpty() merely access a single integer member
field. Since accesses to integer variables are required to be atomic, I
Sascha Brawer wrote:
Sun's current JavaDoc (J2SE 1.4) does not mention whether
java.util.Properties is supposed to be usable from multiple threads
without additional synchronization. However, one might be able to infer
it from the fact that it is a subclass of java.util.Hashtable.
My approach
Eric Blake wrote:
No - even accessing a simple field must be synchronized, for this
reason:
Suppose thread A is in the middle of calling clear() when thread B calls
size(). Notice in clear() that the size is not changed until after all
entries have been set to null, meaning that B will read a
Tom Tromey wrote:
Eric == Eric Blake [EMAIL PROTECTED] writes:
Eric StrictMath is required to be implemented in pure Java
How curious.
BTW, fdlibm is fine to use. We already use it in libgcj.
Thanks for doing this. Now all we have to do is implement strictfp in
gcj :-)
Do you have any
Applied.
Thanks!
Bryce.
Julian Scheid wrote:
The validOptions() method is supposed to be static
as well, like all other methods in Doclet.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Mark Wielaard wrote:
5). Who should use this software?
This is a development release only. You should only install it if you are
interested in Classpath development or reporting bugs. We appreciate both.
You might also be interested if you enjoy installing random alpha
software.
Mark Wielaard wrote:
- There seems to be a gcc compiler bug that makes the following
patch
necessary:
--- orp-1.0.9/base_natives/common_olv2/mon_enter_exit.cpp
+++ orp/base_natives/common_olv2/mon_enter_exit.cpp
@@ -294,7 +294,7 @@
#else
nop;nop;nop
Mark Wielaard wrote:
do you have any plan on adding nio support and asynchronous io to the
classpath project?
if yes what is your agenda on this subject.
I have done a little bit of work for GCJ with this.
I have read the online 1.4 specs for java.nio and thought about how to
implement it
Mark Wielaard wrote:
- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two
workaround for compiling with gcj in my local tree. It might be a good
idea to apply them.
I will try to fix any remaining issues preventing classpath being
compiled with GCC 3.1.
regards
I also like to stamp out the remaining comments like this:
/*/
whenever reformatting. Can you do that as well?
Do you have classpath CVS access or do you want me to commit it?
regards
Bryce.
[EMAIL PROTECTED] wrote:
Washburn, Weldon wrote:
I just got approval to post the zip files. Diff the trees in patch ID 64
and patch ID 65 to see each mod in each file.
I've made diffs and reposted separate patches for different packages
that were changed. I also looked through the collections changes, and
closed
Per Arneng wrote:
Since the java api is one of the greatest api's that evere seen the light. I
thought it would be cool to port classpath to c# to make it easier to port
software java --- c# this would also reuse most of the efforts in
classpath in to the DotGnu project and the mono project.
Eric Blake wrote:
Therefore, the safest course of action is to explicitly have a
serialVersionUID for all Serializeable classes, rather than relying on
the implicit UID generated by the undocumented hash behavior.
After reading your explanation, I agree.
Note that the serialVersionUID field
Dalibor Topic wrote:
--- classpath/java/io/Serializable.javaSat Nov 17 15:00:13 2001
+++ patched/java/io/Serializable.java Sat Nov 17 16:04:01 2001
@@ -40,6 +40,7 @@
*/
public interface Serializable
{
+static final long serialVersionUID = 1196656838076753133L;
} // interface
Tom Tromey wrote:
I've always assumed that since libgcc has used this license for years
(probably more than 10 years), that it is well understood and
acceptable (for its purpose). If it has problems, I think they should
be addressed through RMS and the gcc steering committee. If this
license
Brian Jones wrote:
Is the point to avoid having to initialize String or do subsequent
method calls in native code to convert the string to a char array?
The change can be made, but get this, I think a small library (JNI)
should be provided that implements the new method and calls the old or
Mark Wielaard wrote:
Permissions depend on the complete Class call chain. If any class in the
call chain does not have the required permission then the security check
will fail.
Thanks for the explanation. I agree that relying on ResourceBundle being
initialized before a Security Manager is
Brian Jones wrote:
Found 1 semantic error compiling ../../java/util/ResourceBundle.java:
118. return new Security();
-
*** Error: An instance of java/util/ResourceBundle.this is not accessible here
because it would have to cross a static region in the
Brian Jones wrote:
Out of curiosity, would it be possible to get gcj to use a class
library specified at runtime? Tried setting my CLASSPATH with 2.96
(sorry so old) and it didn't like it. Is there a strategy for
upgrading the class library in use without upgrading the compiler (gcj)?
Tom Tromey wrote:
Perhaps for certain methods this is necessary for VM security. In
this particular case I doubt it matters. Is there an exploit
available if you can find all the classes on the stack?
I think you can override SecurityManager and call it without any
restrictions anyway.
Mark Wielaard wrote:
Log message:
* lib/standard.omit: DataFlavor.java and AWTEvent.java should and must
be compiled by default
AWTEvent depends on Event.java, which for some reason doesn't exist in
Classpath. If you compile classpath with javac its okay because javac
finds
Mark Wielaard wrote:
Note to gcj hackers: To reproduce just run the following in the lib dir
from Classpath gcj --classpath=.. -C -d . @classes. You will get errors
like:
../java/lang/ClassNotFoundException.java:48: Class `java.lang.ClassNotFoundException'
already defined in
Eric Blake wrote:
Bryce McKinlay wrote:
I also looked at your implementations of removeAll/retainAll in Vector
-- nice. But don't you think its odd that there would be optimized
implementations in Vector but not ArrayList? I wonder if we should put
those in ArrayList as well. In the past I have
1 - 100 of 167 matches
Mail list logo
