I know that similar questions have been asked (here, here, here), but none of the answers seem to apply to my case.
Consider the following set of interfaces:
public interface I1<X> {
void method(X arg);
}
public interface I2 {
void method(String arg);
}
public interface I3 extends I1<String>, I2 {
// empty
}
Now I want to call method(String) on an instance of I3, like so:
public class C implements I3 {
public void method(String arg) {
// does nothing
}
public static void main(String[] args) {
((I3) new C()).method("arg");
}
}
The OpenJDK (Java 7 or 8, doesn't matter) flags an incompatibility error here:
generics\C.java:10: error: reference to method is ambiguous
((I3) new C()).method("arg");
^
both method method(String) in I2 and method method(X) in I1 match
where X is a type-variable:
X extends Object declared in interface I1
Since X is instantiated to String in I3, I do not see where the problem comes from. Note that Eclipse considers this to be fine.
The answer to the question, "why?" is simple but probably not what you're looking for. It is, "Because Eclipse and Open JDK each have their own compilers and either a) one of them has a bug or b) the language specification (JLS) is ambiguous and they've interpreted it differently."
Figuring out which of a) or b) is the case is a tricky, tedious task. It means, as a starting point, reading the relevant sections of the JLS, trying to compile the same code with Oracle JDK's javac, and possibly diving into the bug tracking systems of Eclipse and OpenJDK.
Related
I have two classes, E and F.
In class F, I'm trying to call the method which I created in class E called printData(), but I'm unable to call it. There is an error which says 'printData cannot be resolved or is not a field'. What is the reason? See the screenshots below. I did import the package as well(import login.*;)
package login;
public class E {
public void printData {
System.out.println("Hello...");
}
}
Class E
package testing;
import login.*;
public class F {
public void main(String[] args) {
B b = new B();
b.printData
}
}
Class F
In case it is not clear from my comment, your mistake is that in your main method of class F, you are creating an object of class B, which clearly does not have a public method printData, as opposed to class E, which does.
As this is basically a typo, I am voting to close this question, as it is of very little use to other users. You should not be disheartened, if the question is closed. This is normal behaviour on this site, to try to restrict the size of the repository of questions and answers to ones, which would be of greater use to more people.
I have included your code within the body of the question (as you should have done). People here do not appreciate images, as they cannot be copied. This also makes it clearer than you have a syntax error in calling the method: you need b.printData();. Without the parentheses, the compiler takes printData to be a field, not a method, hence the nature of your error message.
I'm trying to extend a class (SWT.java) from a Java library (SWT) that only has static final members. An excerpt from the library class:
package org.eclipse.swt;
import org.eclipse.swt.internal.*;
public class SWT {
public static final int None = 0;
// ...
public static final int MouseDown = 3;
// ...
}
My Java wrapper class that worked fine in Java land:
public class SWT extends org.eclipse.swt.SWT {
public static final int FinalizeText = 201;
public static final int ParseText = 202;
}
Now if I try to use my new SWT class in Scala, I'll get errors like this:
Error:(198, 27) value MouseDown is not a member of object my.package.SWT
table.addListener(SWT.MouseDown, periodEditListener)
^
Ideally I would like a new SWT object with which I could access both original members (e.g. MouseDown) and members I define (e.g. FinalizeText).
It seems that Scala interprets everything useful about this class as an object, which is fine if we just want to use the original SWT definitions, but you can't easily extend objects in Scala.
It has occurred to me that implicits a la pimp my library might be the way to go, but even were I to get this to work, I think the solution would not be accessible from Java (still, I have not even gotten in to work in Scala).
How to best tackle the problem? Maybe the right answer is to just define a separate, unrelated object.
I don't think there is a good way to do what you want such that:
You can neatly tie all members to an identifier (i.e. refer to the field via SWT.X instead of X)
Have it work both in Scala and Java.
You don't have to manually forward fields.
This is a documented limitation of Scala -- see access java base class's static member in scala.
In addition, I don't think the implicit route works either, because you can't treat a Java class as a value: How to access a Java static method from Scala given a type alias for that class it resides in
Probably the best way to do what you want is to manually forward the static members you need in my.package.SWT:
public class SWT extends org.eclipse.swt.SWT {
public static final int FinalizeText = 201;
public static final int ParseText = 202;
public static int getMouseDown() {
return MouseDown;
}
}
If you only care about automatically forwarding members and not about the other requirements, you can use import:
import org.eclipse.swt.SWT._
table.addListener(MouseDown, periodEditListener)
I am accepting yuzeh's answer for thoroughness, general applicability, and helpfulness, but here is what I actually did, which is slightly different:
I was very tempted by yuzeh's last suggestion for the sake of uniformity, i.e.
import org.eclipse.swt.SWT._
import my.package.SWT._
Although as my first example snippet above inadvertently shows, SWT.None unfortunately is, so bringing it into the local namespace would conflict with Option's None.
I think for now I'll just import like:
import org.eclipse.swt.SWT
import my.package.{SWT => MySWT}
If nothing else, it is a bit more clear where the constants are coming from. There, I talked myself into believing this is better :).
Working on a GWT project (2.7.0), i have experienced a very odd client code behaviour.
The following code throws the error "SEVERE: (ReferenceError) : Ljava_io_Serializable_2_classLit_0_g$ is not definedcom.google.gwt.core.client.JavaScriptException: (ReferenceError) : Ljava_io_Serializable_2_classLit_0_g$ is not defined".
The error occurs, when calling Arrays.asList() with a parameter, that has an interface type.
Is this expected behaviour or a GWT bug?
// Working
Integer n1 = 1;
Arrays.asList(n1);
// Not working
Serializable n2 = 1;
Arrays.asList(n2);
GWT 2.7's Super Dev Mode (and from the _g$ in your class literal field, I think that is what you are using) has been observed having other issues like this, but when compiled the issues go away.
If this is indeed what you are seeing, the issue seems to be fixed in 2.8, not yet released: https://groups.google.com/d/topic/google-web-toolkit/RzsjqX2gGd4/discussion
This behavior is definitely not expected, but if you can confirm that this works correctly when compiled for production and in GWT 2.8, then we at least know the bug is fixed.
Well, the typical use of Arrays.asList would be
Object myObj = new Object();
List theList = Arrays.asList(new Object[] {myObj});
This works in GWT with any kind of interface/class/enum you throw at it.
EDIT : I've tested this with GWT 2.5.1 :
public class Foo implements EntryPoint {
public static interface MyInterface {
}
public static class MyObject implements MyInterface {
}
public void onModuleLoad() {
MyInterface myObject = new MyObject();
List<MyInterface> myList = Arrays.asList(myObject);
}
}
Isn't it possible that the problem lies somewhere else?
Is it possible to do Inter Type Declarations with AspectJ on Compiled Class Files at Load Time Weaving?
As an example: I compile some Groovy code and want to add fields or methods with IDT.
Update:
Oh my goodness, you do not need reflection to access members or execute methods. Eclipse shows errors in the editor, but you may just ignore them, the code compiles and runs fine anyway. So the aspect is really much more strightforward and simple:
public aspect LTWAspect {
public static String Application.staticField = "value of static field";
public String Application.normalField = "value of normal field";
public void Application.myMethod() {
System.out.println(normalField);
}
void around() : execution(void Application.main(..)) {
System.out.println("around before");
proceed();
System.out.println("around after");
System.out.println(Application.staticField);
new Application().myMethod();
}
}
Original answer:
Yes, but you have a hen-and-egg problem there, i.e. you cannot just reference the newly introduced fields from your LTW aspect code without reflection. (The last sentence is not true, see update above.) Plus, in order to make your LTW aspect compile, you need the classes to be woven on the project's build path so as to be able to reference them. Example:
Java project
public class Application {
public static void main(String[] args) {
System.out.println("main");
}
}
AspectJ project
import org.aspectj.lang.SoftException;
public aspect LTWAspect {
public static String Application.staticField = "value of static field";
public String Application.normalField = "value of normal field";
public void Application.myMethod() {
try {
System.out.println(Application.class.getDeclaredField("normalField").get(this));
} catch (Exception e) {
throw new SoftException(e);
}
}
void around() : execution(void Application.main(..)) {
System.out.println("around before");
proceed();
System.out.println("around after");
try {
System.out.println(Application.class.getDeclaredField("staticField").get(null));
Application.class.getDeclaredMethod("myMethod", null).invoke(new Application());
} catch (Exception e) {
throw new SoftException(e);
}
}
}
So, e.g. in Eclipse you need to put the Java project on the AspectJ project's build path under "Projects" because only then it can see Java class Application on which you want to declare members. After compilation you just start the Java project and do LTW on the aspect project (don't forget an aop-ajc.xml referencing LTWAspect).
In my example above I declare a static member, a non-static ("normal") member and a non-static method. My advice prints the static member and calls the non-static method, both via reflection. The non-static method then prints the non-static member, again via reflection. This is not nice, but it works and proves the ITD in combination with LTW is possible. There might be a more elegant way, but if so I am unaware of it. (Update: There is a more elegant way: Just ignore the errors marked by Eclipse IDE, see above.)
Program output
around before
main
around after
value of static field
value of normal field
I've seen this quite a few times while using Office Interop classes
this.CustomXMLParts.Add(MyResources.Data, new Office.CustomXMLSchemaCollection());
If I hover over the CustomXMLSchemaCollection class, it shows up as an interface. Then how come I can do a new on it ? What gives?
BTW this code compiles and works.
You are not creating an instance of the CustomXMLSchemaCollection interface but an instance of the CustomXMLSchemaCollectionClass coclass.
The definition for CustomXMLSchemaCollection interface is:
[Guid("000CDB02-0000-0000-C000-000000000046")]
[CoClass(typeof(CustomXMLSchemaCollectionClass))]
public interface CustomXMLSchemaCollection : _CustomXMLSchemaCollection
{
}
This means that the designated coclass that implements the interface is CustomXMLSchemaCollectionClass. My guess is that when the C# compiler sees the new for CustomXMLSchemaCollection interface it translates it to create a COM instance of the CustomXMLSchemaCollectionClass based on the attributes provided with the interface.
After writing this simple example:
namespace ConsoleApplication2
{
using System;
using Office = Microsoft.Office.Core;
class Program
{
static void Main(string[] args)
{
Office.CustomXMLSchemaCollection test = new Office.CustomXMLSchemaCollection();
}
}
}
I just ran ildasm and get the following MSIL:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 8 (0x8)
.maxstack 1
.locals init ([0] class [Interop.Microsoft.Office.Core]Microsoft.Office.Core.CustomXMLSchemaCollection test)
IL_0000: nop
IL_0001: newobj instance void [Interop.Microsoft.Office.Core]Microsoft.Office.Core.CustomXMLSchemaCollectionClass::.ctor()
IL_0006: stloc.0
IL_0007: ret
} // end of method Program::Main
As you can see the class that is constructed is CustomXMLSchemaCollectionClass to prove my initial assumption.