From: Alexandre Oliva [EMAIL PROTECTED]
Date: 22 Apr 1999 11:09:10 -0300
On Apr 22, 1999, Andrew Haley [EMAIL PROTECTED] wrote:
As far as I can see, what is intended is something like this:
if (candidate.isProbablePrime (certainty))
return candidate;
else
Nic Ferrier writes:
As far as I can tell the Classpath/libgcj project is creating 3
things:
- a standard java source code base implementing the java libs
- native jni libs to implement the native parts of the libs
- native cni libs to implement the native parts of the libs for gcj
Hi everyone, I'm aph, gcj maintainer.
I've joined in order to merge bug fixes I make to libngcj into
Classpath. Here's my first.
Andrew.
2003-08-07 Andrew Haley [EMAIL PROTECTED]
* java/io/PrintStream.java (print(String)): Don't crash on a null
string.
Index
Andrew Haley writes:
2003-08-07 Andrew Haley [EMAIL PROTECTED]
* java/io/PrintStream.java (print(String)): Don't crash on a null
string.
This code has been superseded, so I won't commit it.
Andrew.
___
Classpath mailing list
Dalibor, what message are you replying to?
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Stephen Crawley writes:
[EMAIL PROTECTED] said:
Sun has a lot of lawyers, and they've been pretty aggressive than most
about staking their claims on the linguistic turf (so they can sell it
off).
That's a rather twisted interpretation of Sun's use of trademarks, IMO.
Another
Stephen Crawley writes:
[EMAIL PROTECTED] said:
Sun has a lot of lawyers, and they've been pretty aggressive than most
about staking their claims on the linguistic turf (so they can sell it
off).
That's a rather twisted interpretation of Sun's use of trademarks, IMO.
Another
the previous discussion and there Andrew Haley wrote:
UnsupportedOperationException is a good choice. Any subclass of
Error is not, because according to the spec Error indicates
serious problems that a reasonable application should not try to
catch.
IMNSHO, this is *exactly* why
Jeroen Frijters writes:
[I'm resending this, apologies if you get it twice]
Andrew Haley wrote:
My only argument was against subclassing Error, because the Java
specification strongly implies that the only reasonable thing to
do when receiving an Error is issue a disgnostic and die
Jeroen Frijters writes:
Andrew Haley wrote:
Andy Walter writes:
a surprising lot of emails have been sent about that
matter. It seems that we
all agree on that throwing *something* would be better
than what we have
currently. The attached class is a summary of what
Emile Snyder writes:
On Mon, 2003-09-29 at 09:25, Andrew Haley wrote:
Out of interest (and please forgive me if this has already been
discussed at length) why have dummy methods at all? Wouldn't it be
better to have a compile time failure for unimplemented methods?
If you go
Andy Walter writes:
Hi Andrew,
On Monday 29 September 2003 19:40, Andrew Haley wrote:
Throwing an appropriate message will help, of course, but one of
the advantages of gcj is that you can pre-link and you know you
won't get runtime linkage errors -- the linker has resolved
Mark Wielaard writes:
stub methods are a bad thing to have and should just be treated as
grave bugs.
Having those method because they allow people to compile against GNU
Classpath but not run against it really doesn't make much sense. Let
people fix either their code or help us
Ricky Clarkson writes:
If software that is non-free is software that is not part of the GNU
project,
False premise.
then Linux is non-free, and someone has somewhere defined free
as being GNU.
Incorrect conclusion. Please see The Free Software Definition,
Stuart Ballard writes:
Andrew Haley wrote:
FSF pages don't link to unfree software projects. It seems that OMG
is not be an unfree software project, because Implementations of the
OMG specifications - such as Object Request Brokers, IDL compilers,
and UML-based modeling tools
Patrik Reali writes:
Jeroen 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 this
Mark Wielaard writes:
Hopefully we won't do it at the expense of elegance 'and' efficiency,
but I agree that sometimes it won't be possible to achieve both. As our
Hacker Guide puts it (even though it leaves out elegance):
When you write code for Classpath, write with three
Sascha Brawer writes:
Andrew Haley [EMAIL PROTECTED] wrote on Thu, 6 Nov 2003 10:28:24 +:
[having the VMInterfaces classes clearly marked as 'special'
would make it easy for VMs and compilers to just inline all calls
to them]
It's not particularly difficult to do
David P Grove writes:
I don't think there is an easy solution to this as it is unlikely
that a single VMInterface will fit the needs of all VMs perfectly.
In some cases (java.lang.ref.* for example), I don't think that it
is reasonable for classpath to try to provide an implementation
Mark Wielaard writes:
The 4 people in brackets said they would try, but didn't know yet.
Thanks for organizing this.
I am now authorized to attend FOSDEM. I am more than 90% sure I will
be there.
Andrew.
___
Classpath mailing list
[EMAIL
Sascha Brawer writes:
Begin Forwarded Message
Subject: Re: Quadratic and cubic equations
Date Sent: Wednesday, January 7, 2004 3:17 PM
From: Sascha Brawer [EMAIL PROTECTED]
To: Brian Gough [EMAIL PROTECTED]
CC: Mark Wielaard [EMAIL PROTECTED], Michael
Tom Tromey writes:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Andrew It looks to me like this is a test of exact java strictfp
Andrew compliance. gcj fails, because it isn't strictfp compliant.
On top of that, to guarantee the same results everywhere we would need
Sascha Brawer writes:
TT == Tom Tromey [EMAIL PROTECTED] writes:
AH == Andrew Haley [EMAIL PROTECTED] writes:
AH It looks to me like this is a test of exact java strictfp
AH compliance. gcj fails, because it isn't strictfp compliant.
TT On top of that, to guarantee the same
JOnAS (http://jonas.objectweb.org/) is, as you may know, the Open
Source implementation by ObjectWeb of the J2EE(TM) specification.
We're having trouble with running it. The basic problem is (quoth
Simon Nieuviarts) because Carol is an improvement or a replacement of
RMI. As such, it needs to
David Holmes writes:
I'm somewhat baffled why Throwable's stacktrace management is implemented
like this:
private transient VMThrowable vmState;
private StackTraceElement[] stackTrace;
public Throwable fillInStackTrace() {
vmState =
Johan Peeters writes:
at FOSDEM, we discussed how I might help to improve free Java's
security. It seems to me that, for the edifice to be secure, the
native layer's security is absolutely essential. I scanned the native
directory with RATS (Rough Auditing Tool for Security -
Adam Young writes:
Hi, I'm the guys that joined recently and claimed he would implement
the javax.security.auth packages. As I've dug through the volumes of
info, the public Java docs, and the messages about what was or wasn't a
good way to approach coding I've come up with a plan.
Andrew Haley writes:
Johan Peeters writes:
The guarantee that the result is prime seems rather weak considering
that isProbablePrime() is called with argument 1. Assuming that the
likelihood that steps 1 to 6 comes up with a prime is about 1/2,
It isn't. Ron Rivest
Johan Peeters writes:
The guarantee that the result is prime seems rather weak considering
that isProbablePrime() is called with argument 1. Assuming that the
likelihood that steps 1 to 6 comes up with a prime is about 1/2,
It isn't. Ron Rivest conjectures [1] that the probablility of
Archie Cobbs writes:
I wrote an implementation of Runtime.exec() (including a new class
java.lang.VMProcess which extends java.lang.Process and native code)
for JC. This can be easily merged into Classpath if people want it.
It seems like a pretty glaring omission.
This uses the usual
David Holmes writes:
Thanks for the response Andrew.
Index: java/lang/ClassLoader.java
===
+ static private final native ClassLoader getClassLoader0(Class c);
Shouldn't this be a VMClassLoader method rather than
David Holmes writes:
Andrew,
I just realized that this code isn't in the Classpath version at all.
You would not expect it to be, would you? VMSecurityManager is part
of the VM-specific layer. It's a good deal more helpful than
static native ClassLoader currentClassLoader();
Andrew.
David Holmes writes:
I filed a documentation bug against this method because it implied that it
was only called by SecurityManager.getClassContext() when in fact it is also
calld by Class and ClassLoader directly. This makes it awkward for
VMSecurityManager.getClassContext() to know how
Jeroen Frijters writes:
Andrew Haley wrote:
David Holmes writes:
static native Class getClassFromContext(int pos);
This seems like a reasonable idea. In several cases we need to say
who is our caller? and some VM assistance is useful here.
I'd like to have a special
David Holmes writes:
Jeroen Frijters wrote:
Andrew Haley wrote:
David Holmes writes:
static native Class getClassFromContext(int pos);
This seems like a reasonable idea. In several cases we need to say
who is our caller? and some VM assistance is useful here
Jeroen Frijters writes:
Andrew Haley wrote:
David Holmes writes:
That was my initial thought but the generalization is
trivial and useful.
For example, given the XXX/VMxxx split having only
getCallerClass wouldn't allow XXX to defer to VMxxx and have
VMxxx find
Sascha Brawer writes:
4. The Mauve tests #5 and #8 fail both on JamVM and on gcj. (Thanks to
Michael Koch for testing on gcj, by the way). Basically, what happens is
something like the following:
Class c = myClassLoader.loadClass(name);
harness.check(c.getClassLoader() ==
Jeroen Frijters writes:
Etienne Gagnon wrote:
Mark Wielaard wrote:
I would like the vmdata field type then to be VMClass not Object.
I disagree, as it imposes a restriction on what vmData actually
is. The most obvious implementation of vmData is to be a byte[]
instance
Archie Cobbs writes:
Andrew Haley wrote:
I would like the vmdata field type then to be VMClass not Object.
I disagree, as it imposes a restriction on what vmData actually
is. The most obvious implementation of vmData is to be a byte[]
instance holding the byte
Archie Cobbs writes:
Dalibor Topic wrote:
I'd like to propose a couple new extensions to our Java coding
standard.
This comes from ZipEntry:
dostime = (cal.get(cal.YEAR) - 1980 0x7f) 25
Here, `cal' is a local variable and YEAR is a static field in
Mark Wielaard writes:
As Andrew says we could maybe just use long if we want to store an
address. Andrew also worked hard on getting SWT (Eclipse) 64 bit clean.
What I have seen from the (huge) patch this was mainly done by turning
addresses as stored by JNI from int to long. BTW, was
Michael Koch writes:
Uh, I don't understand what you mean, sorry. Why is a Java reference
the same size as a native pointer? Perhaps I misunderstood you.
AFAIK a java refernce is a pointer and this pointer can point
everywhere. Right ?
No, not at all. A java reference is
Michael Koch writes:
To be honest I think we should not have RawData in Classpath.
The trouble with RawData (as it is used in gcj) is that it breaks the
Java type system. Its bizarre semantics mean that you have something
that looks like an object reference but you can't use it as one.
Andrew Haley writes:
Michael Koch writes:
Uh, I don't understand what you mean, sorry. Why is a Java reference
the same size as a native pointer? Perhaps I misunderstood you.
AFAIK a java refernce is a pointer and this pointer can point
everywhere. Right
Etienne Gagnon writes:
IMO, the cleanest approach is really the use of a byte array.
Well, I tell you what: we could wrap the {byte[],long} in an opaque
type, call it a native pointer, and be done with it.
- Everyone who can use a long as a pointer (and, in practice, this is
everyone)
Jeroen Frijters writes:
Andrew Haley wrote:
Michael Koch writes:
To be honest I think we should not have RawData in Classpath.
The trouble with RawData (as it is used in gcj) is that it breaks the
Java type system. Its bizarre semantics mean that you have something
Michael Koch writes:
I think Andrew's solution might be viable. His solution is already
used in SWT. SWT runs with SUN JRE so it seems to be portable
enough for us.
Well, not exactly: I'm suggesting that we wrap all those longs in an
opaque type. But otherwise, yes.
Andrew.
Etienne Gagnon writes:
Andrew,
Andrew Haley wrote:
- Everyone who can use a long as a pointer (and, in practice, this is
everyone) will do so.
It's *NOT* the VM interface! There is a single JNI source code
source base, used by everyone.
It's easy to parameterize.
Andrew
Etienne Gagnon writes:
Andrew Haley wrote:
Well, not exactly: I'm suggesting that we wrap all those longs in an
opaque type. But otherwise, yes.
So, how do you do opaque types, in Java?
You write the code using a class that wraps your native pointer: a
class with a single member
Michael Koch writes:
Am Montag, 5. April 2004 20:06 schrieb Andrew Haley:
Etienne Gagnon writes:
Andrew Haley wrote:
Well, not exactly: I'm suggesting that we wrap all those longs
in an opaque type. But otherwise, yes.
So, how do you do opaque types, in Java
Michael Koch writes:
Am Montag, 5. April 2004 19:30 schrieb Andrew Haley:
Michael Koch writes:
I think Andrew's solution might be viable. His solution is
already used in SWT. SWT runs with SUN JRE so it seems to be
portable enough for us.
Well, not exactly: I'm
Etienne Gagnon writes:
Andrew Haley wrote:
Sure. Instead of putting a native pointer in a long or in a byte[],
you just declare a class with a single field that contains the
pointer. Everyone who needs a pointer makes a suitably named
subclass, so they'll know what they're pointing
Etienne Gagnon writes:
For one thing, you have not shown me *your* native part.
Second, see below.
Andrew Haley wrote:
JNIEXPORT void JNICALL
Java_somepackage_someNativeMethod
(JNIEnv *env, jobject this, jbyteArray nativePointer, ...)
{
void *ptr
Archie Cobbs writes:
Andrew Haley wrote:
Prove me wrong with a specific ISO C specification clause, if you
claim otherwise.
I spent a long time working on and supporting gcc, and this is the
rule I've had to refer people to more times than any other. It's
amazing how many
Etienne Gagnon writes:
Andrew Haley wrote:
malloc() returns a char*, not a jbyte*.
So, can you tell me the difference between a jbyte and a signed char?
Sigh. No it isn't, and this code will break with gcc.
OK, maybe I am tired and I don't see it. GCC -Wall does not complain
Etienne Gagnon writes:
I should have compiled with -pedantic, of course... I've included a few fixes
in the attachment.
malloc() returns a char*, not a jbyte*.
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic
Etienne Gagnon writes:
Etienne Gagnon wrote:
FYI: The JNI specification guarantees that jbyte is an 8-bit signed value.
Hmmm... Thinking about all this mess of non-specified C byte length...
Can JNI actually be implemented on a 16-bit per byte system?
Anybody has a reasonable
David Holmes writes:
Well if we're being pedantic and imprecise to boot ...
malloc() returns a char*, not a jbyte*.
malloc() returns void* not char*. It hasn't returned char* since pre ANSI C.
True, yes.
Hence the pointer returned by malloc can be legally converted to any real
every other type. In ISO C, character
types are in alias set zero.)
---
From: Richard Henderson [EMAIL PROTECTED]
To: Andrew Haley [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Byte types and aliasing
Date: Tue, 6 Apr
Etienne Gagnon writes:
Andrew Haley wrote:
Yes, but it's not a question of whether the type jbyte is the same
size as a character type, but whether it is treated in the same way as
a character by the compiler.
Hi Andrew. Please look carefully at my proposal (sent minutes ago
Jeroen Frijters writes:
Andrew Haley wrote:
jbyte must have a single platform-specific definition, as all
JVMs on that platform should be able to execute the same JNI
library code (no recompilation required).
I didn't know that. Is that requirement documented anywhere? I
Etienne Gagnon writes:
Andrew Haley wrote:
Maybe, but that's not the only thing. It's possible to define jbyte
so that it is an 8 bit signed value but not a character type, and JNI
does not forbid this. I suspect that all the platforms we use define
jbyte to be a character type
Who has this photo? Can we put it on the web?
Thanks,
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Jeroen Frijters writes:
Andrew Haley wrote:
Who has this photo? Can we put it on the web?
http://adorphuye.com/gallery/FOSDEM2004/IMGP0234?full=1
Cool, thanks!
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org
S. Meslin-Weber writes:
Hi Andrew!
On Wed, Apr 07, 2004 at 12:55:48PM +0100, Andrew Haley wrote:
Who has this photo? Can we put it on the web?
Thanks,
Andrew.
I have it up on my gallery at the moment - I believe Jim Pick also has a
version. Feel free to put it up
Etienne Gagnon writes:
On Wed, Apr 07, 2004 at 11:42:08AM +0100, Andrew Haley wrote:
Platform = Machine + OS. I don't have any reference, but I believe that
Etienne is right in saying that the same library should be usuable with
all JVMs on a specific platform.
But it's
Per Bothner writes:
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
Jeroen Frijters writes:
return env-NewObject(pclass, mid, p);
** Bzzzt *** Please try again...
Now that my proposal has been criticised to death on the smallest
nitpicks of pure ISO C portability, let me comment on the portability
of your code.
That wasn't my point in
Etienne Gagnon writes:
Now that my proposal has been criticised to death on the smallest
nitpicks of pure ISO C portability, let me comment on the portability
]of your code.
The ISO C standard says:
[#6] Any pointer type may be converted to an integer type;
Etienne Gagnon writes:
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient.
and later:
I'm not the one nitpicking about pure ISO C portability (I don't use
JNI, so I couldn't care less), ...
and later:
Archie Cobbs writes:
Note: by this logic byte[] is the most portable/generic way to hold
VM private data. It places no portability restrictions, only
(possibly) performance ones. However, I have yet to hear a
convincing argument that proves byte[] is slower than RawData (or
whatever)
expect it's rather big. I might try it
anyway.
Andrew.
From: Andrew Haley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Benchmarks
Date: Mon, 7 Jun 2004 19:20:28 +0100
What do people use for benchmarking their JVMs? I know about
CaffeineMark, but ere there any other good
Dalibor Topic writes:
Andrew Haley wrote:
What do people use for benchmarking their JVMs? I know about
CaffeineMark, but ere there any other good microbenchmarks that are
popular?
Hmm, microbenchmarks are hard, I think there are many left over, since
HotSpot like engines don't
Leston Buell writes:
Hi. I am very new to all of this, so please go easy on me.
OK.
I have not been successful in finding what i need to do to compile
my java programs to native code using Classpath. I am using
Mandrake 10 and have both gcj and the latest Classpath installed. I
can
Bryce McKinlay writes:
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
Andrew John Hughes writes:
Well, my suggestion would be that the branches are more for the benefit
of users rather than developers. Correct me if I'm wrong, but the
japitools comparisons suggest that 1.1 is just about supported. This
would seem to be a solid base to give to those who
Bryce McKinlay writes:
David Daney wrote:
It doesn't seem like a good idea to use an unsuitable exception type
just because its API has a slightly more elegant constructor.
I do not believe that RuntimeException is unsuitable. It seems a better
match than InternalError.
Yes, I
Ingo Prötel writes:
Roman Kennke wrote:
I have thought about how I would design this stuff in order to write
portable code:
1. first of all, try to stick to POSIX standard stuff ;)
2. Of course there are situations where this won't do. In this case I
would split out the
A modest proposal: could those people attaching files please give them
a content-type of text/plain rather than application/binary?
They'd still be transmitted faithfully, bus mailers could display them
inline.
Thanks,
Andrew.
___
Classpath mailing
Archie Cobbs writes:
Jeroen Frijters wrote:
True, but in reality I've never seen any evidence (or even suggestions)
that creating a class loader is safe on any VM (in fact, the Sun 1.4 VM
allows a custom class loader to redefine java.lang.Object and crash the
VM).
Trying to
Robert Schuster writes:
Hi
I've done the same comparison 6 weeks ago with Tom Tromey, and we
were at 75% back then.
5 % in 6 weeks. 20 % to go. You do the math. :)
I am excited too but on the other hand I worry about a lot bugs popping
up ...
Has anyone seen that
Sven de Marothy writes:
Andrew Haley writes:
Has anyone seen that one:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=10491
I recently discovered it while writing some test files for the
XMLDecoder I am working on. In an attempt to find the reason I
followed
to the C
Sven de Marothy writes:
On Thu, 2004-10-07 at 18:01, Per Bothner wrote:
That other issue is that system strtod may not be accurate.
Note that parseDouble is required to return the *closest*
double. This is a difficult requirement to meet, and cannot be done
by simple (i.e.
Tom Tromey writes:
Stuart Firstly it looks like Tom's gcj issues are solved so we have an
Stuart up-to-date classpath japi file[1].
I guess the build with gcj somehow got fixed.
Sadly, it got fixed bacsue Mark Wielaard changed the Classpath
source. Still, I've never seen the problem.
Andrew John Hughes writes:
On Sat, 2004-11-13 at 19:49, Tom Tromey wrote:
Bojan == Bojan Antonovic [EMAIL PROTECTED] writes:
Bojan Java 5.0 has some new language extensions. Many (?) of them, like
Bojan generics, are compiled in the way that the byte code binary is
Bojan
Jeroen Frijters writes:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5 bytecode in the
VM is trivial, but we don't have any 1.5 source compilers yet, do we?
Sorry, I thought it was clear. Tom said Here
Jeroen Frijters writes:
Andrew Haley wrote:
Jeroen Frijters writes:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5
bytecode in the VM is trivial, but we don't have any 1.5
source
Jeroen Frijters writes:
Andrew Haley wrote:
We're losing context because of heavy snipping.
The question of 1.5 bytecode came up in the context of gcj.
Oh, sorry, I missed that. I thought it was a general Classpath point.
The ldc class is a Good Thing in that context. Also
Jeroen Frijters writes:
Andrew Haley wrote:
In which case it'll fail because of unresolved classes. I don't see
how refusing to recognize the new format will help.
Just this Saturday I got a message from someone who tried to run a 1.5
class on IKVM and got a ClassNotFoundException
Robert Schuster writes:
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal to implement the 1.5
classes as much as possible (using 1.4 sources).
Robert Schuster writes:
Andrew Haley wrote:
Robert Schuster writes:
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal
Tom Tromey writes:
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes:
Andrew If this is the case, then is there a good reason for not
Andrew starting to include 1.5 changes, that will compile with
Andrew pre-1.5 compilers, into the HEAD branch?
Andrew * less problems with
Michael Koch writes:
Am Sonntag, 21. November 2004 18:17 schrieb Andrew John Hughes:
On Sun, 2004-11-21 at 14:50, Arnaud Vandyck wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Classpather's,
http://java.debian.net/index.php/MovingJavaToMain
I did try
Michael Koch writes:
Am Freitag, 26. November 2004 12:19 schrieb Sascha Brawer:
Michael Koch wrote:
What do you do if someone writes a package gnu.foobar and wants
to access it ? There are someI think it's OK iff that class is loaded by
the boot class loader on
the boot class
Grzegorz B. Prokopski writes:
On Thu, 2004-11-25 at 14:52, Michael Koch wrote:
Am Donnerstag, 25. November 2004 19:35 schrieb Archie Cobbs:
Michael Koch wrote:
Assuming that this glibj.zip has the default Configuration.java
and that is acceptable to the builder, why not provide a
I couldn't see a ChangeLog.
Jeroen, can you please use text/plain instead of
application/octet-stream? As it stands, mail readers won't display
your patch. You can still use base64 to protect the patch from being
scrambled.
Thanks,
Andrew.
___
Jeroen Frijters writes:
Andrew Haley wrote:
I couldn't see a ChangeLog.
I forgot to write it. Sorry.
'mkay.
Jeroen, can you please use text/plain instead of
application/octet-stream?
Is this better?
Much.
As it stands, mail readers won't display your patch.
Sorry
theUser BL writes:
Hi. For all people, who don't read monologue, here an interesting article
about Dynamic Java:
http://www.go-mono.com/monologue/
http://usefulinc.com/edd/blog/contents/2004/12/09-jvm/read
http://www.tbray.org/ongoing/When/200x/2004/12/08/DynamicJava
Rather than
Stuart Ballard writes:
Okay, this is a really dumb question, but I can't find the answer on
the website.
Does classpath even have anonymous CVS access available any more? I'm
trying to get a copy but the only instructions on the website these
days
Artur Biesiadowski writes:
Sascha Brawer wrote:
I was just re-reading the FAQ [1] -- what would speak against
pre-allocating thread-specific OutOfMemoryException objects when
creating a thread? (Probably more a VM-specific thing, but since it's
mentioned in the Classpath
1 - 100 of 501 matches
Mail list logo
