Generic bug in Eclipse 3.1M4??

I gave Eclipse 3.1M4 a try and noticed a bug(?)/ feature(?) in a code like the following:
class Test implements Iterator<Integer> {
 public boolean hasNext() { return false; }
 public Integer next() { return null; }
 public void remove() {}
}the problem is that the next() method raises the following compiler warning:
"Type safety: The return type Integer of the method next() of type Test needs unchecked conversion to conform to the return type E of inherited method"
Code looks fine to me -- am I missing something? Ideas?
thanks,
Barak

"Type safety: The return type Integer of the method
next() of type Test needs unchecked conversion to
conform to the return type E of inherited method"That is a bug.

Similar Messages

Generic working in eclipse compiler but not through builds

The following code snippet works fine in my eclipse development environment (1.6.0_06), but the build system running 1.6.0_06 throws exception:
MyClass:343: incompatible types
found : java.util.List<C>
required: java.util.List
entries = createListFromSmartCopy(myAList, new B(), true);
Types:
A is an interface
B is an interface of A
C is an implementation of B
List<A> aList = new ArrayList<A>();
aList.add(new A());
List return = createListFromSmartCopy(aList, new C(), true);
 * Creates a copy of a list where the source list could be an ancestor
 * type of the returned list. It also uses a reference object to actually
 * construct the objects that populate the return list.
 * @param <T> - The ancestor type of the source list
 * @param <R> - The derived type of the destination list
 * @param <S> - The more derived type of the prototype object used to
 * construct the list of R's
 * @param sourceList - The source list
 * @param referenceObject - The object used to construct the return list
 * @param deepCopy - Deep copy serializable objects instead of just copying
 * the reference
 * @return a list of R's (as defined by the caller) of entries with the
 * object constructed as a copy of referenceObject with the properties of the
 * sourceList copyied in after construction
public static <T extends Serializable, R extends T, S extends R> List<R> createListFromSmartCopy(
 List<T> sourceList, S referenceObject, boolean deepCopy)
 List<R> retr = new ArrayList<R>();
 for(int i = 0; i < sourceList.size(); i++)
 retr.add(copyOf(referenceObject));
 copyInto(sourceList.get(i), retr.get(i), deepCopy);
 return retr;
 }Any thoughts on either:
1. How does this pass the compiler validation inside eclipse, even through 'R' has not been defined? I believe that the code is doing some sort of return type inference to return the exactly correct type of list as referred by the return result or else it is simply ignoring the invariant capture of R all together and silently dropping the error. The funny thing is that the code does work just fine in practice in my development system without an issue.
or
2. Why if the code is valid does the independent build system disallow this generic return type 'inference' to occur? Are there compiler flags I can use to withhold this special condition?

Thanks for the response, I wasn't trying to show a full example but just my implementation's snippet. I'll list one now:
package test;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
public class TestMe
 * This method performs a deep copy of an object by serializing and
 * deserialzing the object in question.
 * @param <T> - The type of data to copy
 * @param original - The original object to copy
 * @return The object who's state should be the same as the original. This
 * call uses serialization to guarantee this copy is fully separate from the
 * original, so all sub-object references are also deep copies of their
 * originals
 @SuppressWarnings("unchecked")
 public static <T extends Serializable> T clone(T original)
 T obj = null;
 try
 ByteArrayOutputStream bos = new ByteArrayOutputStream();
 ObjectOutputStream out = new ObjectOutputStream(bos);
 out.writeObject(original);
 out.flush();
 out.close();
 ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(
 bos.toByteArray()));
 obj = (T)in.readObject();
 catch(IOException e)
 e.printStackTrace();
 catch(ClassNotFoundException cnfe)
 cnfe.printStackTrace();
 return obj;
 * Copies the properties from one object to another. The destined object
 * in this method must be derived from the source object. This allows for a
 * faster and smoother transition.
 * @param <T> The type of source
 * @param <R> The type of destination
 * @param source - The source object
 * @param destination - The destination object
 * @param deepCopy - Copies the reference objects instead of just passing
 * back the reference pointer reference
 public static <T, R extends T> void copyInto(T source, R destination,
 boolean deepCopy)
 // Stubbed because it links into a ton of unnecessary methods
 * Copies the values of a list of an ancestor class into the values of
 * another list who's value is derived from the ancestor.
 * @param <T> - The ancestor type of the source list
 * @param <R> - The derived type of the destination list
 * @param sourceList - The source list
 * @param destinationList - The destination list
 * @param deepCopy - Deep copy serializable objects instead of just copying
 * the reference
 public static <T, R extends T> void copyIntoList(List<T> sourceList,
 List<R> destinationList, boolean deepCopy)
 if(sourceList.size() > destinationList.size())
 throw new IllegalArgumentException(
 "Cannot copy entire source set into destination list");
 for(int i = 0; i < sourceList.size(); i++)
 copyInto(sourceList.get(i), destinationList.get(i), deepCopy);
 * Creates a copy of a list where the source list could be an ancestor
 * type of the returned list. It also uses a reference object to actually
 * construct the objects that populate the return list.
 * @param <T> - The ancestor type of the source list
 * @param <R> - The derived type of the destination list
 * @param <S> - The more derived type of the prototype object used to
 * construct the list of R's
 * @param sourceList - The source list
 * @param referenceObject - The object used to construct the return list
 * @param deepCopy - Deep copy serializable objects instead of just copying
 * the reference
 * @return a list of R's (as defined by the caller) of entries with the
 * object constructed as a copy of referenceObject with the properties of the
 * sourceList copyied in after construction
 public static <T extends Serializable, R extends T, S extends R> List<R> createListFromSmartCopy(
 List<T> sourceList, S referenceObject, boolean deepCopy)
 List<R> retr = new ArrayList<R>();
 for(int i = 0; i < sourceList.size(); i++)
 retr.add(clone(referenceObject));
 copyInto(sourceList.get(i), retr.get(i), deepCopy);
 return retr;
 public static void main(String[] args)
 List<A> aList = new ArrayList<A>();
 aList.add(new AImpl());
 aList.add(new AImpl());
 List bList = createListFromSmartCopy(aList, new C(), true);
 for(B bItem : bList)
 System.out.println("My String = "
 + bItem.getString() + " and my number = " + bItem.getInt());
 public static interface A extends Serializable
 public void setString(String string);
 public String getString();
 public static class AImpl implements A
 private static final long serialVersionUID = 1L;
 @Override
 public void setString(String string)
 @Override
 public String getString()
 return null;
 public static interface B extends A
 public void setInt(int number);
 public String getInt();
 public static class C implements B
 private static final long serialVersionUID = 1L;
 public C()
 @Override
 public String getInt()
 return null;
 @Override
 public void setInt(int number)
 @Override
 public String getString()
 return null;
 @Override
 public void setString(String string)
}In my eclipse (20090920-1017), this compiles and runs just fine. I stripped out the functional pieces that weren't pertinent to the discussion.

Generics bug in Sun compiler?

The code show compiles using the oracle compiler, but when executed generate a NoSuchMethodError. Apparently, this doesn't occur when run under Eclipse, presumably compiled byJikes. Is this a known bug? (Compiled using 1.6.0_21)
public class Bug {
 public static void main(String[] args) {
 X x = new X();
 x.da();
 public static interface A {
 void foo();
 public static interface B {
 void bar();
 public static class FooBar implements A, B {
 @Override public void foo() {
 @Override public void bar() {
 public static class Z<T extends A & B, TT extends T> {
 final TT t;
 public Z(final TT t) {
 this.t = t;
 void da() {
 t.foo();
 t.bar();
 public static class X extends Z<FooBar, FooBar> {
 public X() {
 super(new FooBar());
}Exception in thread "main" java.lang.NoSuchMethodError: com.iontrading.anvil.tradelibrary.bus.Bug$A.bar()V
 at com.iontrading.anvil.tradelibrary.bus.Bug$Z.da(Bug.java:40)
 at com.iontrading.anvil.tradelibrary.bus.Bug.main(Bug.java:8)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)

rxcolvin wrote:
Apparently, this doesn't occur when run under Eclipse, presumably compiled byJikes.Minor correction: Eclipse doesn't use Jikes (and as far as I know never did). They do have their own compiler however (called simply the Eclipse Java Compiler). ECJ is written in Java, as opposed to Jikes, which is written in C++.
Edit: confirmed to be broken with javac from the Sun JDK (6u22) and the OpenJDK 1.6.0_20. Works when compiled with the Eclipse compiler (both with conformance 1.5 and 1.6) from an up-to-date Eclipse 3.6.1.
It wouldn't be the first time that ECJ gets something right that javac doesn't compile correctly.

Generics bug or just me being stupid?

Heya, does anyone know why this doesnt work?
 @SuppressWarnings("unchecked")
 private Map.Entry<String, Map<String, Serializable>> safeCast(Map.Entry<String, Serializable> entry)
 if ((entry.getValue() instanceof Map<?, ?>) == false)
 throw new ClassCastException();
 return (Map.Entry<String, Map<String, Serializable>>)entry;
 }Gives me:
MoniterMessage.java:45: inconvertible types
found : java.util.Map.Entry<java.lang.String,java.io.Serializable>
required: java.util.Map.Entry<java.lang.String,java.util.Map<java.lang.String,ja
va.io.Serializable>>
 return (Map.Entry<String, Map<String, Serializable>>)entry;It is a tree-like structure, a map can contain either Serializable objects or instances of Map. If the entry is an instance of map we want to add it to the folders list etc

@SuppressWarnings("unchecked")
private <T extends Map<String, Serializable>,
Serializable> Map.Entry<String, T>Here, you are creating a type parameter called Serializable. I guess you don't want to do that.
Generics should save you from casting, instanceof, etc. If you want the thing in your map to be both Serializable and Map, say so:
<V extends Map & Serializable, T extends Map<String, V>>(or something like that - I don't have the time to test it right now)

Generics bug with multiple interface inheritance?

Hi,
I've noticed what I believe to be a compiler bug (I am getting an error where I believe none should exist). Can someone please comment on the following use-case?
interface Interface1<SelfType extends Interface1<SelfType>>
interface Interface2
class Superclass implements A<Superclass>
class Dependant<Type extends Interface1<Type>>
 public static <Type extends Interface1<Type>> Dependant<Type> getInstance(Class<Type> c)
 return new Dependant<Type>();
class Subclass extends Superclass implements Interface2
Subclass()
 Dependant<Subclass> dependant = Dependant.getInstance(Subclass.class);
}The problem is that in the above code the compiler will complain that Dependant<Subclass> is illegal because "Subclass is not within its bounds" . The compiler requires that Subclass implement Interface1 and Interface2 directly and implementing Interface1 by extending Superclass doesn't seem to count. If you replace Subclass's definition by "class Subclass implements Interface1<Subclass>, Interface2" the problem goes away.
Is this a compiler bug?
Thank you,
Gili

Actually now I understand what you mean.... Ok, now I am going to modify the problem slightly and add Interface2 into the picture. The new code is:
interface Interface1<SelfType extends Interface1<SelfType>>
interface Interface2
class Superclass implements Interface1<Superclass>
class Dependant<Type extends Interface1<Type>>
 public static <Type extends Interface1<Type> & Interface2> Dependant<Type> getInstance(Class<Type> c)
 return new Dependant<Type>();
class Subclass extends Superclass implements Interface2
public Subclass()
 Dependant<Subclass> dependant = Dependant.getInstance(Subclass.class);
}Now, previously I could replace:
Dependant<Subclass> dependant = Dependant.getInstance(Subclass.class);
with
Dependant<Superclass> dependant = Dependant.getInstance(Superclass.class);
and it solved the problem, but now that Type must implement Interface2 I cannot.
The reason I added this requirement is that this is actually what is going on in my applicationI had made mistakely omited this detail from the original use-case.
Can you think up of a possible solution to this new use-case?
Thanks,
Gili

Bazzar bug in Eclipse/JVM/JDK?

Hi,
I am having this weird issue when debuging a STATIC block. Basically, I have a break point on a line of code inside the STATIC block, but when I press F6 to step over that line, it skips all the lines after that.
The thing is those lines were executed, it just not step to it for some bazzar reasons.
Does anyone here able to help me?
I am running Ubuntu 7.04, JDK6 and tomcat5.5. I had tried using jdk1.5 instead, but nothing seemed to help.
Thanks very much for your help.

in a nutshell, the eclipse debugger isn't very good at coping with static blocks
and the JDK doesn't enter into matters with eclipse, it only uses a JRE

Generic Method override compatibility

I tried to find references to the problem but couldn't. I face it all the time and I thought some else must have had the same problem already.
Oh well, here it goes.
With both 3.1M4 and 3.1M5a the following code compiles without any problems.
public interface MyIface {
 public <T> void foo(T p);
public class MyClass implements MyIface{
 public <T extends Integer> void foo(T p) {
 //does something
}However, javac 1.5 gives me:
MyClass.java:1: MyClass is not abstract and does not override abstract method <T>foo(T) in MyIface
public class MyClass implements MyIface{
^
1 error
I found many different variations to this problem, which I am not going to list here as I am trying to be concise. But for the eclipse compiler, <T extends Integer> is the same as <T> in terms of method signature. For the javac compiler these are different thingss.
Does anyone know if this is a Bug in eclipse or javac, or if this is a known decision, which is taking both tools in different directions?
Coconha

Coco, you have to understand how generics work in the compiler to understand this. Basically, erasure means that all the fancy generics stuff you write in your source code gets 'erased' when it gets compiled... So:public interface MyIface {
 public <T> void foo(T p);
}gets compiled and the resulting .class file, if you decompiled it, would actually look like this:public interface MyIface {
 public void foo(Object p); // NOTICE that "T" gets erased to plain old java.lang.Object
}See? The same thing happens with MyClass:public class MyClass implements MyIface {
 public <T extends Integer> void foo(T p) {
 //does something
}after it's compiled, actually looks like this inside the .class file:public class MyClass implements MyIface {
 public void foo(Integer p) { // NOTICE that "T extends Integer" gets erased to plain old Integer!
 //does something
}Do you see what the problem is now? MyClass has a method called foo(Integer) and MyIface has a method called foo(Object). Obviously now, you see, foo(Integer) shouldn't override foo(Object). The Eclipse compiler should actually complain that you haven't implemented foo(Object) in MyClass. Do you follow?
Let's look at your second example.public class Base {
public <S> void foo(S a) {
 System.out.println("Base: " + a);
public class Sub extends Base {
public <S extends Integer> void foo(S a) {
 super.foo(a); // should be an error here! super.foo(Integer) doesn't exist!
 System.out.println("Sub: " + a);
}Let's apply erasure manually and see why there is no error:public class Base {
public void foo(Object a) {
 System.out.println("Base: " + a);
public class Sub extends Base {
public void foo(Integer a) {
 super.foo(a); // calls foo(Object a)! you could also write "this.foo((Object)a)"
 System.out.println("Sub: " + a);
}Sub actually has two methods - foo(Integer a) which it defines explicitly - and foo(Object a) which it inherits from Base.

WorkSpace Studio as eclipse plugin

I found a problem when my workspace studio installation is starting, and i found that the error is related to some bug on eclipse 3.2.
The solution is easy. I have to replace or downgrade the version of the xulrunner library, but after doing that firefox does not start since it's built with the other version. I thought wlp 10.3 uses a newer version of eclipse but i think i'm wrong since the probelm persists.... so the question is ... is there any package of workspace studio as a plugin for an existing eclipse installation?
andi if so, where can I download it?

I have the same problem as mentioned above. If anybody knows
solution for it then please tell me.

Database bug issue after upgrade ( version 8.1.7.4)

Hi,
Currently our database version is 8.1.7.0.0
We have planned to upgrade our database to 10g Rel2 and for that we have already applied terminal patch set (i.e. 8.1.7.4).
But after applying terminal patch set we came through list of the GENERIC bug fixes included in the 817X Patch Sets. i.e.
ALERT: Oracle8i Release 3 (8.1.7) Support Status and Alerts
Note :- 120607.1
Actually in this note we are having confusion whether to apply the patch or not for the bug that is mentioned.
Some are those which affect Oracle 8.1.7.X releases are :
1)Trigger updates wrong after DROP functional index Note 259854.1
2)Changing the Database Character Set can corrupt LOBs Note 118242.1
3)Large export buffer can produce corrupt export file Note 223399.1
4)Export can generate a corrupt export file Note 199416.1
The first one has been applied successully, but having confusion with the remaining,
Question regarding points 2 & 3 above :
2)
As we are not going to alter our database character set (WE8ISO8859P1) at 8.1.7.4, so is it required to apply the patch ???
or will have to apply as we are going to upgrade it further to 10g Rel2(Here database character set might get change) for future upgradation ???
3)
Currently our database export is being done via conventional path
Now, the workaround mentioned in the patch is as follows :
(Patch is not available for Windows OS)
Workaround
~~~~~~~~~~
1. Prior to a Conventional path export, set the environment variable
ORA_OCI_NO_OPTIMIZED_FETCH to 1.
Windows:
set ORA_OCI_NO_OPTIMIZED_FETCH=1
OR:
2. Export the data in Direct path mode, by specifiying the additional
export parameter: DIRECT=Y
So the query is,
I am not getting any parameter like ORA_OCI_NO_OPTIMIZED_FETCH.
Is there any parameter like ORA_OCI_NO_OPTIMIZED_FETCH in oracle 8.1.7.4 ?
OR
Will have to change the export method to direct mode ? by doing so will there be any adverse effect ?
With Regards

You are repeating a question that you already made on your previous thread.
Re: Database upgradation to 9i rel2
Regards,
Francisco Munoz Alvarez
www.oraclenz.com

Can't install Flex Builder 2 plugin in Eclipse 3.3/Europa

[I hope Adobe reads these forums. I tried to submit this as a
customer service request, but the customer service request form
kept telling my I had to enter my First Name, Last Name, and Email
address, even though I _had_ entered them!]
I can't seem to install the Flex Builder 2 plugin in Eclipse
3.3/Europa. I had it installed fine in 3.2/Callisto. I uninstalled
it from there, installed Europa, then tried to install the plugin.
After I selected the Eclipse folder, I got the error:
"Please choose an existing Eclipse folder (3.1 or greater) to
be updated. This folder must contain eclipse.exe and the standard
folder named "configuration"."
All three conditions (3.1 or greater, eclipse.exe and
configuration) hold in my case, so I don't know what the real
problem is.

Actually it's quite simple. But you have to be warned. This
doesn't guarantee a bug free Eclipse setup and it isn't supported
by Adobe in any way. It is how-ever your only shot at getting
Eclipse with Flex Builder 2 AND php-development support, as Zend
has stopped deploying the php-development-requirement for Eclipse
3.2 (or at least I haven't found it in their archives.)
Flex Builder 2 simply checks for some files to see if the
directory you want to install to exist, so it recognizes the
directory as an Eclipse 3.1+ directory. Eclipse 3.3 however misses
the file startup.jar. If you simply copy startup.jar from an
Eclipse 3.2 directory into the 3.3 directory, Flex Builder 2 will
install in the 3.3 directory.
Again. This is not supported in any way by Adobe.
For more info, Google on: eclipse-3.3 Flex-builder-2
startup.jar
http://www.google.com/search?hl=en&q=eclipse-3.3+Flex-builder-2+startup.jar
Kind regards.
PS. I would still like to have an Adobe Representative answer
the simple question: Is Adobe or is Adobe not working on getting
Flex Builder 2 to work on Eclipse 3.3? A simple yes or no will
suffice.

Why the ScrollDemo sample can not be debugged in Eclipse?

Hi, All,
I am an newer of the Swing/JFC. When I debugged the ScrollDemo in Eclipse 3.0.2, it always reported an exception at setRowHeaderView(...). But it could run perfectly. So I am confused. Who can tell me whether it is a bug of Eclipse or a bug of the ScrollDemo sample?
Thanks,
Terry Nee

The debug window displays:
Thread [DestroyJavaVM] (Running)
Thread [AWT-Shutdown] (Running)
Thread [AWT-Windows] (Running)
Thread [AWT-EventQueue-0] (Suspended (exception ArrayIndexOutOfBoundsException))
 JViewport(Container).getComponent(int) line: not available
 JViewport.getView() line: not available [local variables unavailable]
 JViewport.getViewPosition() line: not available [local variables unavailable]
 MetalScrollPaneUI(BasicScrollPaneUI).updateColumnHeader(PropertyChangeEvent) line: not available
 BasicScrollPaneUI$Handler.scrollPanePropertyChange(PropertyChangeEvent) line: not available
 BasicScrollPaneUI$Handler.propertyChange(PropertyChangeEvent) line: not available
 PropertyChangeSupport.firePropertyChange(PropertyChangeEvent) line: not available
 PropertyChangeSupport.firePropertyChange(String, Object, Object) line: not available
 JScrollPane(Component).firePropertyChange(String, Object, Object) line: not available
 JScrollPane.setColumnHeader(JViewport) line: not available
 JScrollPane.setColumnHeaderView(Component) line: not available
 ScrollDemo.<init>() line: 55
 ScrollDemo.createAndShowGUI() line: 114
 ScrollDemo.access$0() line: 105
 ScrollDemo$1.run() line: 128
 InvocationEvent.dispatch() line: not available [local variables unavailable]
 EventQueue.dispatchEvent(AWTEvent) line: not available
 EventDispatchThread.pumpOneEventForHierarchy(int, Component) line: not available
 EventDispatchThread.pumpEventsForHierarchy(int, Conditional, Component) line: not available
 EventDispatchThread.pumpEvents(int, Conditional) line: not available
 EventDispatchThread.pumpEvents(Conditional) line: not available
 EventDispatchThread.run() line: not available [local variables unavailable]
Thread [Java2D Disposer] (Running)

I can't attach the JSF 1.2_04 sources to Eclipse project !

Hello,
I am using Eclipse 3.3.2. I am trying to build a ICEFaces project and I need the JSF sources for convinience.
I have them, I am trying to attach them with Project>Properties>JavaBuildPath>Sun JSF RI 1.2_04>jsf-api 1.2> Source Attachment> Edit>External file.
It's OK, but when I close the window and reopen it > there are no sources checked again.
I have downloaded them from here : https://javaserverfaces.dev.java.net/download.html
Please, help !

[This is indeed a bug in Eclipse|https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=attach+source]. As far the only workaround is to add a new JRE via Window > Preferences > Java > Installed JREs and adding the desired JAR's as external JAR's, saving it and opening it again (!!) and finally attach the sources to the added JAR's. Then in the project properties choose the new JRE (and keep the same JSF JAR's in the web-inf/lib!).
Yes it is cumbersome, but I suppose that this will be fixed in the next Eclipse release.

Javac bug database still being maintained?

After the Oracle acquisition, is the javac bug database still being maintained? I submitted a bug report on 04/20/2010 and received an e-mail response back confirming it was a new bug on 04/22/2010. The e-mail said it would be posted in the external database in "a day or two", but now 12 days later Bug ID [6946211|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6946211] is still not visible. I tried replying back to the e-mail but no response.
If anyone's interested, here is the sample code I submitted with the bug report.
public interface BaseType {
BaseType clone() throws CloneNotSupportedException;
public interface SubType<T extends BaseType & java.io.Closeable> extends BaseType {
}It should compile correctly but fails. It appears to be a generics bug.

I am rather certain that years ago (thus pre Oracle) it could take weeks before posted bugs showed up.
And presumably this was discussed in the Generics forum before posting it as a bug.

Bug FIX help

Hi, I'm new to this forum and to this field. I have a bug i need to fix ..and need some help on ideas. I'm using Eclipse for J2EE. the bug is: when navigating the screen with the tab Key ...it does not stop on a field it should, rather it skips and goes to the next field. I need some ideas guys or any help and hints to point me to the right direction. I started doing research on the mapping in eclipse to kind of generate some ideas but so far no luck. I''ll keep at it. Thanks

Eh, a bug in Eclipse or a bug in your program? If the former, what makes you think that we're responsible for Eclipse bugs? At least go to an Eclipse forum. If the latter: post code or at least describe your focus handling implementation.

Ant in eclipse

when i use ant in eclipse.
it says
[javac] BUILD FAILED: file:D:/JavaProject/ACS/testAnt.xml:18: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
but i set the classpath as follow:
CLASSPATH
.;d:\j2sdk1.4.1_01\lib\dt.jar;D:\j2sdk1.4.0_01\lib\tools.jar
JAVA_HOME
D:\j2sdk1.4.0_01
Path
......;D:\j2sdk1.4.0_01\bin;.;D:\j2sdk1.4.0_01\lib\dt.jar;D:\j2sdk1.4.0_01\lib\tools.jar
how to slove that?

Thanks for the solution E13, that fixed the same problem I was having. However, I'm thinking that this might be an Eclipse-specific bug, and not due to a shortcoming on M$ part (for once :)
The reason I say this, is that when I was trying to debug this problem, I noticed that Eclipse kept wanting to set its internal java.home to the location of the System JRE (which was J2SDK1.4.2 in my case - run 'ant -diagnostics'). So I'm assuming that when it looked under ${java.home}/bin, it didn't find the javac compiler and failed.
What's strange, is that no matter what I tried, I couldn't get Eclipse's Ant tool to point to a different java.home. My system JAVA_HOME is set correctly, but eclipse apparently clobbered it. I tried overwriting this value in the properties sheet to no avail. Even after applying your solution, the code compiles fine, but java.home is still pointing to the wrong directory.
Is eclipse querying the Registry for Ant's java.home?? I grepped all the xml resource and property files in my Eclipse install dir looking for where this value was assigned, but it isn't there. Is anyone else seeing this problem? I'll probabally open up a Bug on Eclipse since this doesn't appear to be correct behavior.

Generic bug in Eclipse 3.1M4??

Similar Messages

Maybe you are looking for