So, I have something written in Java, and I want to extend it in Scala... The issue I'm running into is that Scala isn't seeing methods I need.
Here is how it's set up:
Player extends Mob, and Mob extends Entity.
I need to access a method in Player that isn't defined in Mob or Entity, but Scala doesn't think it exists even though Java does.
It can see methods defined by Mob and Entity just fine. Also, all the methods I'm talking about are non-static.
So, am I doing something wrong, or is this a limitation imposed by Scala?
Edit --
Here is the relevant code:
package test
import rsca.gs.model.Player
object Test {
def handle(p:Player): Unit = {
p.getActionSender().sendTeleBubble(0, 0, false);
}
}
Player class:
package rsca.gs.model;
// imports
public final class Player extends Mob {
// Implemented methods (not going to post them, as there are quite a few)
// Relevant code
private MiscPacketBuilder actionSender;
public MiscPacketBuilder getActionSender() {
return actionSender;
}
}
Error:
value getActionSender is not a member of rsca.gs.model.Player
I never encountered such problems, and you probably checked your configuration and everything else twice, so I would guess this is some Eclipse related build issue. You should try to build from the command line in order to see whether Scala or Eclipse is the problem.
Is it possible for you to run a test against the class just to see if you got the right one?
p.getClass.getMethods
... and if possible (may run into NPE) in order to find the source:
p.getClass.getProtectionDomain.getCodeSource.getLocation.getPath
When compiling the Scala class, do something like this:
scalac *.scala *.java
This way, Scala will look a the Java code to see what is available. If, however, the Java code is already compiled and provided as a jar file, just add it to the classpath used when compiling the Scala code.
Related
Learning Java. I have two files, each containing one java class. When I run the file with the main method, I get the following error:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class TapeDeck from class TapeDeckTestDrive (TapeDeck is in unnamed module of loader 'app'; TapeDeckTestDrive is in unnamed module of loader com.sun.tools.javac.launcher.Main$MemoryClassLoader #18bf3d14)
at TapeDeckTestDrive.main(TapeDeckTestDrive.java:3)
class TapeDeckTestDrive{
public static void main(String[] args){
TapeDeck t = new TapeDeck();
t.canRecord = true;
t.playTape();
if (t.canRecord == true) {
t.recordTape();
}
}
}
class TapeDeck {
boolean canRecord = false;
void playTape(){
System.out.println("tape playing");
}
void recordTape(){
System.out.println("tape recording");
}
}
Any help please?
Actual Issue
I got this exact same error* doing something very silly:
I tried to run the file as java {main-class}.java. That simple!
Instead, be sure to run it simply as java {main-class}.
*Specifically, the error format I had, like yours:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class {pack.other-class} from class {pack.main-class} ({pack.other-class} is in unnamed module of loader 'app'; {pack.main-class} is in unnamed module of loader com.sun.tools.javac.launcher.Main$MemoryClassLoader #29f69090)
at {pack.main-class}.{who-cares-where}
at {pack.main-class}.{who-cares-why}
. . .
Extra Advice
You can get a similarly annoying error on the same issue, namely inability to access packages in the same directory, if you only compile your {main-class}.
So instead of javac {directory}/{main-class}.java
Be sure to compile all of them at the same time, so there's no issue in cross-referencing: javac {directory}/*.java
OP Specific
This would just be a silly command-line mistake. If it's occurring in IntelliJ as well, as you say, this isn't your issue. However, I hope it's at least helpful to the others who come across your question with this error!
Make sure each class is in the same folder, since the error is saying TapeDeckTestDrive can not find TapeDeck. I would recommend starting out with an IDE like Eclipse since it will help you focus more on coding and less with folder problems.
I know your code is all good (in java 8 at least) since when I copied it in eclipse it works no problem, meaning it has to be a folder problem, a problem with the installed version of java, or the way you are running the code is not working for some reason. If both files are in the exact same folder then I would make sure your java version says 1.8 something in the system files (Program Files(x86) most likely in windows), if it does not say that version then it could be another problem with the code and syntax for that version.
Another thing that might help is to put public behind the "class" on the first line of each class and make the Boolean public. This might be a syntax requirement on other versions of java or something that is needed when running off command prompt.
Quick possible fix, try making the classes and methods "Public".
Under normal circumstances this shouldn't be necessary but you may be hitting a specific case where it might be (It's an edge case so I don't know if it's a problem or not off the top of my head):
Java is really uncomfortable with stuff being in the "Default" package--code from other packages can't access objects in the default package (Meaning no package statement). Although this shouldn't cause problems in your case, maybe your "package" level security settings are also not working in the default package.
If this is actually the problem, the two fixes would be to make the packages and methods public (as I said above) or move both classes into a package.
What worked for me was to add the key word 'public' in both methods (playTape and recordPlay) and variables (canRecord).
I have the following class signature:
public BlockstemRequester(RateLimiter throttler,
String url, List<String> payloadsToBeRequested, List<String> objRef) {
.
.
.
}
And I'm using that constructor at this following code:
threads.add(new BlockstemRequester(RateLimiter.create(1.0),
String.format("url...", apiKey),
chunks.get(index),
chunksObjRef.get(index)))
where:
RateLimiter is from import com.google.common.util.concurrent.RateLimiter
chunks is defined as val chunks:util.List[util.List[String]] = new util.Vector[util.List[String]]
chunksObjRef is defined as val chunksObjRef:util.List[util.List[String]] = new util.Vector[util.List[String]]
But, unfortunately I'm getting an error telling me that class constructor was not found or defined:
java.lang.NoSuchMethodError: BlockstemRequester.<init>(Lcom/google/common/util/concurrent/RateLimiter;Ljava/lang/String;Ljava/util/List;Ljava/util/List;)
Basically, I'm using this class defined in Scala at my java code project, and I did defined the scala class to use List from java to avoid any problem of incompatible types between the languages.
At runtime I'm getting this following types according to my debug process:
chunks is a Vector[Collections$SynchronizedRandomAccessList]
chunksObjRef is a Vector[Collections$SynchronizedRandomAccessList]
I appreciate any kind of help towards this problem. Thank you!
As per Java docs:
Thrown if an application tries to call a specified method of a class
(either static or instance), and that class no longer has a definition
of that method. Normally, this error is caught by the compiler; this
error can only occur at run time if the definition of a class has
incompatibly changed.
From you question it is not clear if you are getting this at compile time or run time but looks like you are having issue at run time. So, use a Java decompiler and check the .class of this class whether this method is present or not.
Most probable root cause of this issue is that library used at compile time have such a method but library used at runtime doesn't have it, and hence NoSuchMethodError.
Use decompiler and check .class file of the class.
Just solved the problem. So this was the scenario: I have a project X and using a library Y. So both X and Y have different definition of the class BlockstemRequester, both with different constructor signatures. I had to change that class name of my project and refactor my code. So, at runtime the constructor pointed out it was that one from my project X and not from that one defined in the library Y
I appreciate any advise if there is any way to approach this problem better than just renaming/refactoring my local classes
I think that the problem is with your 'typed' list.
If you change the signature to
public BlockstemRequester(RateLimiter throttler,
String url, List payloadsToBeRequested, List objRef)
Or
public BlockstemRequester(RateLimiter throttler,
String url, List<?> payloadsToBeRequested, List<?> objRef)
This will work.
Recently I have encountered some problem which seems a little strange to me.
In order to use some predefined class, I imported two .jar files say foo.jar and bar.jar(Both were written by others)
And my source code is like the following:
package jerry.deque
public class Deque {
.....
.....
Foo item = new Foo(); //Already defined in the foo.jar
.....
}
I added the external library exactly as what How to Import a Jar in Eclipse
did. But when I tried to use the class defined in foo.jar Eclipse shows me that "Foo can't be resolved to a type".
I spent a lot of time to fix this problem and finally succeeded after I removed
the clause: "package jerry.deque" at the beginning of my class file.
I think this is weird because just a few days ago when I was doing some Android development, I followed the same way to add a Twitter API library. And it works fine even when I declared "package jerry.search_twittes" at the beginning of my .java
file. I'm confused by this problem and couldn't figure out what's going wrong. Could someone help me to explain it in detail? Thanks very much.
Check that Foo is same package as Deque class. If they are not same
package, you need to import Foo class in Deque class.
For example,
package jerry.deque;
import packagename.foo; // packagename.foo
public class Deque {
.....
.....
Foo item = new Foo(); //Already defined in the foo.jar
.....
}
Added Explanation
I want you to check access modifier of Foo class carefully.
There are 2 access level for top level(class) access control . These
are public, or package-private (no explicit modifier).
Your Foo class is under default package(not specified package)and may be no explicit access modifier. Hope so! Then, all classes under default package can access to Foo class. That's why when you remove package jerry.deque clause, it works.
Similarly, I want you to check Android development java code in which it works fine even when you declared "package jerry.search_twittes". In that case, classes inside Twitter API library's access modifier is public.So you can access it from anywhere.
For more information you can read this.Is this information helpful???
Foo is in default package. Classes from default package cannot be imported directly.
So when you remove the package declaration in your code, you don't get the error.
You can look for reflection api or write a proxy in the default package for that class.
Im trying to use Scala and Java in one project. Im working with the Scla IDE for Eclipse. I have two packages in my Scala Project: one for my scala code and one for my java code.
Now lets say I create new JavaClass with one static member.
package javastuff;
public class MyJavaClass {
public static String MESSAGE = "Im Java";
}
After that Im trying to get access to this variale and somehow I cannot. Funny thing, because scala is able to see the Java class "MyJavaClass" just not able to see MESSAGE.
import javastuff.MyJavaClass
object Main {
def main(args: Array[String]) {
println(MyJavaClass.MESSAGE)
}
}
Value MESSAGE is not a member of object javastuff.MyJavaClass
If I use Project/Clean... 1-2x times eclipse is maybe starting realizing that the member MESSAGE is really there and everything is fine. Is this normal? Maybe Im doing something wrong, I know eclipse is really a bad IDE and I should maybe try IntelliJ, but somehow I like eclipse and I would like to use later some of my favorite plugins, thats why I would not change the IDE just because of this problem. Any ideas how to handle this problem better?
Scala doesn't have any static fields. Here is a blogpost about it
btw. public static without final is pretty bad design (no encapsulation => possible memory leaks)
I've come across an oddity of the JLS, or a JavaC bug (not sure which). Please read the following and provide an explanation, citing JLS passage or Sun Bug ID, as appropriate.
Suppose I have a contrived project with code in three "modules" -
API - defines the framework API - think Servlet API
Impl - defines the API implementation - think Tomcat Servlet container
App - the application I wrote
Here are the classes in each module:
API - MessagePrinter.java
package api;
public class MessagePrinter {
public void print(String message) {
System.out.println("MESSAGE: " + message);
}
}
API - MessageHolder.java (yes, it references an "impl" class - more on this later)
package api;
import impl.MessagePrinterInternal;
public class MessageHolder {
private final String message;
public MessageHolder(String message) {
this.message = message;
}
public void print(MessagePrinter printer) {
printer.print(message);
}
/**
* NOTE: Package-Private visibility.
*/
void print(MessagePrinterInternal printer) {
printer.print(message);
}
}
Impl - MessagePrinterInternal.java - This class depends on an API class. As the name suggests, it is intended for "internal" use elsewhere in my little framework.
package impl;
import api.MessagePrinter;
/**
* An "internal" class, not meant to be added to your
* application classpath. Think the Tomcat Servlet API implementation classes.
*/
public class MessagePrinterInternal extends MessagePrinter {
public void print(String message) {
System.out.println("INTERNAL: " + message);
}
}
Finally, the sole class in the App module...MyApp.java
import api.MessageHolder;
import api.MessagePrinter;
public class MyApp {
public static void main(String[] args) {
MessageHolder holder = new MessageHolder("Hope this compiles");
holder.print(new MessagePrinter());
}
}
So, now I attempt to compile my little application, MyApp.java. Suppose my API jars are exported via a jar, say api.jar, and being a good citizen I only referencd that jar in my classpath - not the Impl class shiped in impl.jar.
Now, obviously there is a flaw in my framework design in that the API classes shouldn't have any dependency on "internal" implementation classes. However, what came as a surprise is that MyApp.java didn't compile at all.
javac -cp api.jar src\MyApp.java
src\MyApp.java:11: cannot access impl.MessagePrinterInternal class file for impl.MessagePrinterInternal not found
holder.print(new MessagePrinter());
^
1 error
The problem is that the compiler is trying to resolve the version print() to use, due to method overloading. However, the compilation error is somewhat unexpected, as one of the methods is package-private, and therefore not visible to MyApp.
So, is this a javac bug, or some oddity of the JLS?
Compiler: Sun javac 1.6.0_14
There is is nothing wrong with JLS or javac. Of course this doesn't compile, because your class MessageHolder references MessagePrinterInternal which is not on the compile classpath if I understand your explanation right. You have to break this reference into the implementation, for example with an interface in your API.
EDIT 1: For clarification: This has nothing to do with the package-visible method as you seem to think. The problem is that the type MessagePrinterInternal is needed for compilation, but you don't have it on the classpath. You cannot expect javac to compile source code when it doesn't have access to referenced classes.
EDIT 2: I reread the code again and this is what seems to be happening: When MyApp is compiled, it tries to load class MessageHolder. Class MessageHolder references MessagePrinterInternal, so it tries to load that also and fails. I am not sure that is specified in the JLS, it might also depend on the JVM. In my experience with the Sun JVM, you need to have at least all statically referenced classes available when a class is loaded; that includes the types of fields, anything in the method signatures, extended classses and implemented interfaces. You could argue that this is counter-intuitive, but I would respond that in general there is very little you do with a class where such information is missing: you cannot instantiate objects, you cannot use the metadata (the Class object) etc. With that background knowledge, I would say the behavior you see is expected.
First off I would expect the things in the api package to be interfaces rather than classes (based on the name). Once you do this the problem will go away since you cannot have package access in interfaces.
The next thing is that, AFAIK, this is a Java oddity (in that it doesn't do what you would want). If you get rid of the public method and make the package on private you will get the same thing.
Changing everything in the api package to be interfaces will fix your problem and give you a cleaner separation in your code.
I guess you can always argue that javac can be a little bit smarter, but it has to stop somewhere. it's not human, human can always be smarter than a compiler, you can always find examples that make perfect sense for a human but dumbfound a compiler.
I don't know the exact spec on this matter, and I doubt javac authors made any mistake here. but who cares? why not put all dependencies in the classpath, even if some of them are superficial? doing that consistently makes our lives a lot easier.