Steve Loughran wrote:
1. I dont like all the extra typing you need everywhere; it makes
things more verbose. What is wrong with polymorphic type inference?
I'd like to know the story on type inference for Java too, though it is
probably more a question for the Types mailing list
(http://lists.s
Chavdar Botev wrote:
Peter Reilly wrote:
The original code may be slightly incorrect (my understanding
of java generics is not high).
Ha-ha. I think the original code cannot be slightly incorrect. It is
either correct or incorrect. ;) It certainly possible that my
understanding of Java generics
TWIMC,
I know I am a bit into the gray cross-posting area but here is the
thread I started on the Java Forums:
http://forum.java.sun.com/thread.jspa?threadID=778203.
Chavdar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addi
Ha-ha. I think the original code cannot be slightly incorrect. It is
either correct or incorrect. ;) It certainly possible that my
understanding of Java generics is wrong. I come from a C++ templates
background and although syntactically similar, Java generics and C++
templates seem to be very d
Chavdar Botev wrote:
Peter Reilly wrote:
The original code may be slightly incorrect (my understanding
of java generics is not high).
Ha-ha. I think the original code cannot be slightly incorrect. It is
either correct or incorrect. ;) It certainly possible that my
understanding of Java generics
Peter Reilly wrote:
The original code may be slightly incorrect (my understanding
of java generics is not high).
Ha-ha. I think the original code cannot be slightly incorrect. It is
either correct or incorrect. ;) It certainly possible that my
understanding of Java generics is wrong. I come from
And, regarding generics...as for value - wow...how many heterogenous
collections did we ever really use in pre 1.5 code? Most of my
collections always contained homogeneous data. So, having generics now
certainly improves readability (yes I know, under the covers it does the
casts for me)...
Sorry let me clarify... The comment was "The original code may be
slightly incorrect (my understanding
of java generics is not high)." And the response was "Me too. I don't
like STL!" I do realize STL is built using generics.The Standard
Template Library defines templates...but STL in and
Scot P. Floess wrote:
What do generics have to do with STL?
You're joking, right? Have you used the STL much?
Generics are very very handy :)
Maybe. I live in a world where the majority of my code has to work on
pre-Java 5, and for code where I can use Java 5 features, generics don't
seem
What do generics have to do with STL? Generics are very very handy :)
James Abley wrote:
Peter Reilly wrote:
The original code may be slightly incorrect (my understanding
of java generics is not high).
Me too. I don't like STL!
James
Peter:
Point well taken. The problem here, I think, is that the inner class
has access to everything defined in the outer class (this includes the
declaration of the generic). Of course, javac comes in and does some
creative compiling to make that possible. Personally, I strive very
hard t
Peter Reilly wrote:
The original code may be slightly incorrect (my understanding
of java generics is not high).
Me too. I don't like STL!
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EM
The original code may be slightly incorrect (my understanding
of java generics is not high).
Test1.java is defined as:
public class Test1 {
public class Inner1 {
protected T v;
public Inner1(T v) {this.v = v;}
public T getV() {return this.v;}
Actually, I think the real problem isn't generics but an inner class
that using a generic specified by the outer class. I bet this problem
goes away if all the classes were defined as outer classes.
Steve Loughran wrote:
Scot P. Floess wrote:
Steve:
My apologies...my mouth is now stretched
Scot P. Floess wrote:
Steve:
My apologies...my mouth is now stretched from the placement of my foot
in my mouth ;) When I tried this, I didn't specify -classpath to
command line javac. I see now by doing so it does, in fact, break as
mentioned.
Yeah, I agree (now) that it is a bug :)
Or
Steve:
My apologies...my mouth is now stretched from the placement of my foot
in my mouth ;) When I tried this, I didn't specify -classpath to
command line javac. I see now by doing so it does, in fact, break as
mentioned.
Yeah, I agree (now) that it is a bug :)
Scot
Steve Loughran wrote
Scot P. Floess wrote:
How is this a java generics bug? I specifically was able to compile
just Test3.java using command line javac... So its not javac nor is it
a generics problem.
we can replicate it on the command line, just by adding the .class file
to the classpath. That's why its a co
How is this a java generics bug? I specifically was able to compile
just Test3.java using command line javac... So its not javac nor is it
a generics problem.
It is probably needed for incremental builds in which all source files
are not in the source tree you specify, such as when you have
On 10/18/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
Peter Reilly wrote:
> On 10/17/06, Chavdar Botev <[EMAIL PROTECTED]> wrote:
>> Peter,
>>
>> I repeated the steps you described and I can confirm that with the
>> -classpath argument the compilation fails and without it the
>> compilation succ
Steve Loughran wrote:
> Peter Reilly wrote:
>> On 10/17/06, Chavdar Botev <[EMAIL PROTECTED]> wrote:
>>> Peter,
>>>
>>> I repeated the steps you described and I can confirm that with the
>>> -classpath argument the compilation fails and without it the
>>> compilation succeeds. I also tried running
Peter Reilly wrote:
On 10/17/06, Chavdar Botev <[EMAIL PROTECTED]> wrote:
Peter,
I repeated the steps you described and I can confirm that with the
-classpath argument the compilation fails and without it the
compilation succeeds. I also tried running javac on "src/test/*.java"
instead of "src/
Matt Benson wrote:
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
[SNIP]
I have just checked the revision history,
since the initial checkin (6 years, 9 months),
has always added
the destination path to the classpath for the javac
command.
It does not seem to be necessary? but I do not know
if
w
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> I have just checked the revision history,
> since the initial checkin (6 years, 9 months),
> has always added
> the destination path to the classpath for the javac
> command.
>
> It does not seem to be necessary? but I do not know
> if
> we
On 10/17/06, Chavdar Botev <[EMAIL PROTECTED]> wrote:
Peter,
I repeated the steps you described and I can confirm that with the
-classpath argument the compilation fails and without it the
compilation succeeds. I also tried running javac on "src/test/*.java"
instead of "src/test/Test3.java". In
Peter,
I repeated the steps you described and I can confirm that with the
-classpath argument the compilation fails and without it the
compilation succeeds. I also tried running javac on "src/test/*.java"
instead of "src/test/Test3.java". In this case, the compilation
succeeds with or without -cl
I have opened a bug report at
http://issues.apache.org/bugzilla/show_bug.cgi?id=40776.
Thanks,
Chavdar
On 10/17/06, Peter Reilly <[EMAIL PROTECTED]> wrote:
On 10/17/06, Scot P. Floess <[EMAIL PROTECTED]> wrote:
> Failed for me using Fedora Core 5, sun JDK 1.5_08
>
> I don't think its javac as I
On 10/17/06, Scot P. Floess <[EMAIL PROTECTED]> wrote:
Failed for me using Fedora Core 5, sun JDK 1.5_08
I don't think its javac as I was able to do this:
touch src/test/Test3.java
javac -d bin -sourcepath src -classpath bin src/test/Test3.java
That worked me as well, however I modifed the bu
Failed for me using Fedora Core 5, sun JDK 1.5_08
I don't think its javac as I was able to do this:
touch src/test/Test3.java
javac -d bin -sourcepath src -classpath bin src/test/Test3.java
Javac seems to find everything correctly...but the javac task in ant is
having difficulties. One thing
Fails for me:
Ubuntu Dapper, Ant 1.6.5, Sun JDK 1.5.0_07
bash:$ ant -v
bash:$ touch test/Test3.java
bash:$ ant -v
[javac] /work/ant-test/ant-generics/test/Test3.java
[javac] /work/ant-test/ant-generics/test/Test3.java:8: incompatible
types
[javac] found : test.Base
Also no problems on WinXP, Ant 1.6.5 and Java 1.5.0_06-b05.
>setant 165
Apache Ant version 1.6.5 compiled on June 2 2005
>setjava 15
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
>del test\*.class
Works for me with Ant 1.6.5 and 1.7beta2 and the given java sources (with and
without the commented line).
Jan
>-Ursprüngliche Nachricht-
>Von: Peter Reilly [mailto:[EMAIL PROTECTED]
>Gesendet: Dienstag, 17. Oktober 2006 11:39
>An: Ant Users List
>Betreff: Re: a problem
31 matches
Mail list logo
