Dear Brian,
(and I thought
we agreed to get rid of these kind of macros and would use normal
functions as much as possible in the future.)
When I remember right, the agreement was not to remove the macros
completely, but instead make them into alias-names for target specific
implementations of
Am Dienstag, 16. November 2004 10:46 schrieb Torsten Rupp:
Dear Brian,
(and I thought
we agreed to get rid of these kind of macros and would use
normal functions as much as possible in the future.)
When I remember right, the agreement was not to remove the macros
completely, but instead
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
(hope you don't mind my replying to this on the list)
Jeroen Frijters wrote:
One thing that's missing is the fact that annotations can have default
values:
import java.lang.annotation.*;
public @interface MyAnnotation
{
String value() default foo;
Thread.State state() default
On Mon, 2004-11-15 at 19:26, Michael Koch wrote:
Am Montag, 15. November 2004 19:00 schrieb Tom Tromey:
Michael == Michael Koch [EMAIL PROTECTED] writes:
Actually, putting the new code on the trunk as well makes
merging harder, not easier. That's because when it is put on
the
Seeing as this was raised in the jre5 thread:
java.util.concurrent
java.util.concurrent.atomic
java.util.concurrent.locks
Note that the java.util.concurrent implementation, as defined and
implemented by the JSR-166 is freely available for download:
/*
* Written by Doug Lea with assistance
6 matches
Mail list logo
