So this will be a long story so I thank you in advance for reading. Let me start by saying that I've been working with java for more than 15 years and I've been working on this specific project for over 5 years and I'm stumped.
I compile the project on 3 different computers. I was working on the project in eclipse juno on Computer A and everything was fine so I checked in the code. Then I checked out the code on Computer B and tried a javac clean build and got a bunch of errors, starting with "cyclic inheritance involving..." and then a bunch of errors such as "cannot find symbol" and there were many of these then it had a couple of these "no suitable method found for" until finally it just wigged out and never even gave me an error total.
So, I've never seen anything like this, and as I said the code was fine earlier in the day on a different computer, so I just fired up eclipse, told it to do a clean build, and everything was fine. Go back to the terminal and do a javac and it compiled fine. Whew, I said, it must have just been a glitch.
Then on Computer C, which does a nightly build, it gave the same errors as Computer B (note that Computer B is a mac and Computer C is rhel, but both were running jdk1.7u15). So now I realize it isn't a glitch, but what to do?
I go and look at the code and I'm certain there is no cyclic inheritance and what it says it can't find the symbol for is sitting right where it is supposed to be. I investigate a bit and find out that eclipse uses an internal compiler so this would explain the disparity between compilations, but it doesn't explain why they are giving wildly different results on the same code base.
Out of ideas, and hoping there is something weird with the update 15, I update Computer B to jdk1.7u51 but unfortunately it is giving the same errors.
I realize without seeing the compiler output (which is really not much more interesting than I described), or more importantly, not seeing the actual code there isn't much you can help with. But assuming I'm telling the truth, that there is no cyclic inheritance, there are no missing symbols, and eclipse compiles the code fine when javac rejects it, does anyone have a suggestion of what I could try now?
My next thought is to update eclipse, but assuming it still compiles fine there, what to do next?
Thanks again for reading!
Related
Basic background data: Windows 7, Netbeans 8.0.2, LWJGL 2.9.3, Slick Util.
The rest of the code is my own.
So, periodically, I was having what I thought was a bug, that caused my program to run within the IDE, but would fail when I used "Clean and Build" on the project.
Today, when it happened again, I decided to get to the bottom of it. So, taking a copy of the whole project folder, that was working and otherwise identical, and replacing 1 file at a time, and testing it, I was able to narrow it down to the /nbproject/project.properties file.
Every other file could be replaced and the problem persisted. Replace ONLY this file, and the problem went away. So then I loaded up both files and compared them side by side (using the Netbeans "Diff to..." feature) and narrowed it down to the following lines:
javac.classpath=\
${libs.LWJGL-2.9.3.classpath}:\
${libs.0-Slick_Util.classpath}:\
${libs.0-Loaders_v03.classpath}:\
${libs.0-Text2D_v03.classpath}:\
${libs.0-Foundation_v04.classpath}:\
${libs.0-Abstracts_v04.classpath}
Now this code, looks like it is telling the compiler the ORDER in which the libraries should be loaded (I may be wrong).
With that in mind, I decided to test it. I copied this block from the working file, to the non-working file, and it worked just fine. The working code btw is this:
javac.classpath=\
${libs.LWJGL-2.9.3.classpath}:\
${libs.0-Slick_Util.classpath}:\
${libs.0-Foundation_v04.classpath}:\
${libs.0-Abstracts_v04.classpath}:\
${libs.0-Loaders_v03.classpath}:\
${libs.0-Text2D_v03.classpath}
The only differences, you may notice, is the ORDER. Continuing my test, I went into the non-working project's Library properties page, and simply re-ordered the libraries to match the working list. PROBLEM WENT AWAY! If I simply moved the Foundation and Abstracts libraries down in the list, the PROBLEM CAME BACK!
I must have tried a dozen different order combinations, and got about 2/3 that failed, and 1/3 that worked. The ones that worked all involved Foundation and/or Abstracts to be near the top.
Why is this happening? How can I know what order my libraries need to be loaded to avoid the error?
The error btw is this:
F:\Dropbox\2-Documents\4-Java Programming\Library\0-LoadingScreen_v04-Copy\src\A_Library\Test_LoadingScreen.java:94: error: cannot find symbol
Lib_Foundation .setConfigLocation(configLocation);
symbol: method setConfigLocation(String)
location: class Lib_Foundation
Any information that can help me avoid this problem in the future will be appreciated.
It would appear that either “Loaders_v03” or “Text2D_v03” contains its own version of Foundation, including an incompatible Lib_Foundation class. A classpath is searched in order, so your current solution—reordering javac.classpath—will always work, assuming NetBeans doesn’t mess with it the next time you make any change to your project.
Whether that will break Loaders and Text2D depends upon how well Foundation adheres to object-oriented design: public classes and their public members are never supposed to be changed or removed in successive versions. (That is why 20-year-old code written for Java 1.1 will still compile in Java 8.)
I have no idea what a hot swap is and for the life of me cannot construct a google search that will find what it means in the context of my program. I was editing my class, the same way I do all the time, and when I went to run it I all of a sudden got a
Hot Swap failed: myClassName: schema not implemented
error.
Can anyone explain this to me in Layman's terms?
You are attempting to change your source code while the program (or IntelliJ's debugger) is still running. This is what the HotSwap feature does according to IntelliJ's KB.
Please make sure your program and/or debugger is stopped before re-launching the program and the issue should be resolved.
I was working this afternoon in my project without problems. Before come home I did a commit to my svn to continues it in home, but now when I try to run it shows a code error that hadn't shown before. The Following code it's supposed to initiate new scene using controllers and passing parameters. Error:
Someone knows what is happening? If you say "The code is wrong" it's not possible cause I was using the exactily same code in my work.
Detail, in the afternoon i was using Mac OS and now I'm using Windows. And IDE is Netbeans in booth places
My problem was not about code, actually the code is right.
The problem ocurred because my Netbeans was pointing to a old version of JavaFX. The way to fix it was to uninstall everything about java from my computer and after reinstall with the newer versions of JDK, JavaFx and Netbeans.
Cast your loaders to their appropriate types. For the first cast it to the Login Controller and for the second cast it to the MainViewController.
NetBeans only see's an abstract Object being returned, even though what is actually being returned is a little more specific. I'm not sure why this happened when you moved from one platform to the next (I assume you have the same version and everything), but some compliers will catch this as an error and others will not. Technically there is no error, just questionable results.
I have been working with the Play! Framework for a few weeks now, and am really enjoying it. Occasionally I have an issue come up which is frustrating me. It starts when I encounter a compile error. I refresh, and see the (excellent) Play! error message. Here's a simple example.
I go to the appropriate file, fix the error, and reload the page. Then I get this compiler error:
Strangely, it shows the updated source code, with the bug fix, but it is throwing the same compiler error from the previous message. If I restart the Play! server, then everything compiles and I can go on as expected, but of course one of the great things about Play! is being able to edit .java source files and see those changes right away in the browser.
Would really appreciate a tip from anyone who's bumped into this before, or has a clue what is causing it! Thanks so much! I am running OSX 10.6.
EDIT
I have also tried manually deleting the tmp/ directory, where the .class files are stored. This does not help, and I get the same behavior, where the edited source code appears, but the old compiler error is still dsiplayed.
My best stab at this is that your clock is screwed up. Do you use time synchronization? Keep a terminal open running:
while true; do sleep 1; date; done
and check whether there is a correlation with clock changes and this behaviour.
FWIW, I've never witnessed this (also on MacOS 10.6)
Is it possible to enter an infinite loop at compile time?
My program seems to enter an infinite loop when I attempt to compile it. I have a class with a class constructor that calls the method gameRun(). gameRun() calls itself at the end of its execution, but should have the appropriate checks to be able to break from it during run time... However when I attempt to compile the class, I actually seem to get an infinite loop then.
My understanding of compilation is that it does not actually execute the code... Which would mean it would be impossible to enter an infinite loop unless there is actually a serious bug in the compiler's source. Is this correct?
I am writing in Java, and am using BlueJ (a beginner's IDE which I am growing out of) as my IDE.
Thanks in advance.
.....................................
Thanks to you all for so many helpful responses. Just thought I'd post an update, as this seems to have perked some interest, and I am curious about it myself.
I have not done a whole lot with BlueJ or this error since I posted the original error, becuase I had taken the source files from the project, and was able to successfully compile and run them with eclipse. This suggests to me that it is a BlueJ (or related) problem. I have continued to work on this project with eclipse without any more problems of this nature. I will follow up with more detail on the problem when I am able to use the machine with the original project on it again. (Nothing should have been changed since)
.....................................
As an afterthought... Is there any way I can link this question to an account I have created and registered since this was posted? I can't find a way to do that, and it would make keeping track of this more convenient...
Some languages do allow the compiler to enter an infinite loop. Java isn't one of those languages. :-)
You're right, the compiler doesn't execute the code, and would only enter an infinite loop due to a bug. I'm confident that the javac compiler from Sun doesn't have such a bug.
I don't know what compiler BlueJ is using "under the covers", but I have seen a problem when Ant runs javac that makes it take a really long time to compile. Simply stated, there are some cases where Ant will direct the compiler to load every class under a given directory. If that directory contains hundreds of third-party libraries, it can take a while… or even run out of memory.
Does your compilation hang (loop) if you just use javac ?
I've never seen a compilation hang indefinitely whilst compiling Java and I'm wondering if BlueJ is having a problem instead.
It would be theoretically possible to do if, for example, to compile a file, the compiler first had to have finished compiling that file. (Ahhh... Recursion).
But I'd imagine checking for that kind of madness would be the first thing a real-world compiler would handle.
But I wouldn't think it would happen on a method/function, unless (postulating) the compiler was trying to resolve tail-recursion to an simpler implementation, and failing. But, again I can't imagine that would be an issue with a modern Java compiler, even if it exists at all. Certainly I'd imagine that the compiler would eventually give up and post an error rather than infinite looping.
It's far more likely to be the IDE than the compiler. At a guess, the IDE might be trying to trace a warning/error to its source in the code in order to highlight it and getting trapped. Does BlueJ have text-highlighting on compiler errors/warnings? You could try turning it off.
Although, as many others have already suggested, the first real test is to compile from the command line using
javac *.java
Or whatever files your code uses.
EDIT: Sorry I never got back to you. For future reference, to compile from the command line (I'm assuming Windows as your OS):
Open the command line by going to the start menu and select Run...
Type cmd into the Run dialogue, and click OK.
This should bring up a cmd.exe console.
From here, use the "cd" command to change directory to the directory containing your java files.
(cd "My Documents\Java\Monster Battle\core")
Once you're in the right directory, type "javac *.java". This will run the compiler without needing to deal with the IDE. It should pause while compiling, and when it's done, you get the command prompt back.
If you type "javac *.java -verbose" you get full output, in case you get your infinite loop.
If that works fine, it's an IDE bug. Send them a bug report. If it doesn't, congratulations! You've found something really interesting, that will probably tie up some poor Sun developer for a month.
If BlueJ does use its own compiler, you may have found a bug in it, or in BlueJ's build tools that surround it.
You might take a BinaryChop approach to this one: break your program into pieces, compile them individually, and see if the compiler-hanging behavior can be isolated to a small, specific testcase. At the end of the day, you'll either have an excellent bug report to show the BlueJ people, or you'll find that your program actually does compile (yet you'll be scratching your head).
AFAIK, Standard Java cannot be compiled infinitely.
Are you sure that the problem is at compilation rather than at some other feature that BlueJ provides? Many Eclipse-based IDEs perform multiple actions during a rebuild, and that compilation is just one of them. It is possible that something else does.
What exactly do you see? An unending Eclipse task?
Try to make the source code you are compiling as small as possible and still exhibit the behaviour you describe. The process of doing so, may help you identify what the problem is.