I'm at the mercy of being on a corporate laptop but since using Eclipse STS for spring development for the last few years both the previous and current version I have always had issues with code completion freezing for a few seconds or throwing an exception with missing content message. My question is, how can I get my sanity back being able to code quickly and not have to wait seconds at a time just to get a code completion suggestion in the java editor for spring STS. is this a known bug? this does not happen in other flavors of eclipse and it really makes the product less desirable to use, but i guess that is the reality of open source software I appreciate all the development effort put into this product just hope someone can help me resolve this code completion issue because it really slows me down. - Duncna
Related
I originally posted this question on GameDev stackexchange however I'll also ask the question here to try and get more outreach, especially since I wasn't sure my problem was specific to game development since it's a problem with a Java native call.
For the past months I've been working on creating my own game engine for personal use in LWJGL using pieces here and there, especially from developer ThinMatrix's rightfully credited code, to learn as much as I can while building it. Only recently there has been strange behavior happening when I launch the engine from IntelliJ for testing:
After about 6-10 individual times I click run, all subsequent runs suddenly take about 60 seconds for the window to appear.
Whenever I restart my PC this hanging resets and I have another 6-10 runs before it hangs everytime again.
I located the issue to glfwInit, more specifically at the call to the native method:
#NativeType("int")
public static boolean glfwInit() {
long __functionAddress = Functions.Init;
return invokeI(__functionAddress) != 0; // Right here
}
I also noticed that this issue only started when I attempted to implement text support in my engine using the STBTrueType library. It was perfectly fine before that. I tried removing the TrueType code but it didn't fix it.
Here's a list of things I've tried:
Clearing my temp folder in case a buggy or corrupted file was present.
Recompiling and rebuilding the entire LWJGL jars twice.
Building glfw.dll from the GLFW sources and replacing the glfw.dll in the native jars with the former.
Reinstalling Java and actually upgrading JDK versions (from 13.0.2 to 14.0.2)
Switching IDEs even if I suspected it wouldn't work.
Updating my NVIDIA drivers, and reinstalling them.
I'm quite confused as to what it could be, and I'd be more than happy to share code, thread dumps, or debug info if you deem it necessary. Here is the Github repository with the latest, "faulty" code (fault in quotes because I'm not too sure the code is the problem.)
Thank you very much for any guidance.
P.S: Please tell me if this is better asked in StackOverflow instead of here.
So I fixed the issue, it turns out it wasn't even related to anything to do with programming, or STBTrueType, or the library itself. The problem was as pointed out in this StackOverflow post, where this hanging behavior was due to a faulty driver or, in my case, my keyboard USB being plugged in the "wrong" USB port. I moved my computer at the same time I started working on text in my engine, hence why I wrongly linked the issue with the TrueType library. If you're having the same issue, look at the aforementioned post or if that doesn't work, look for a peripheral that might cause interference.
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 recently came across a bug with an unresolved issue in SDK 2.2 and, as its fixed in 2.5, decided to explore a switch.
Now I am new to GWT and I have no idea of the effects of doing such a switch, but figured it couldn't hurt to mess around locally. I went ahead and successfully updated to 2.5 locally to test and can run with no errors. However many of the text boxes have changed appearance and my navigation bar disappeared, etc...
Is this type of behavior normal after an update? If so I cant imagine why anyone would be in a hurry to do so, as spending enormous amounts of time to modify all pages is pretty unrealistic. Is there maybe some type of quick fix or an error i may have made to cause this?
If you want to put a lot of resources into a GWT project it is always a good idea to check regularly how the project is going on. On the release-note page you can check what's new and what has been deprecated. This way you can make an informed and rational decision whenever you want to update. This is very important since going from an old version (say 1.0) to a new one (i.e 2.5.1) might give some headaches to the programmers. Spendind half-an-hour checking what's going on every month will make your life easier.
GWT has an issue tracker where you can see the open issues and what has been resolved. Many issues have never been fixed, but I read the GWT team intend to solve the 100 most important issues for the next release. GWT is now open-source and you can contribute to its development whenever you know of to fix one of those issues.
Last but not least: many people say a lot of things, which are not always correct (including on Stack Overflow). Always dubble check before making important decisions.
Giving this advice is all I can do for you so far...
Yet, if you give me some info about that bug you expected to be fixed and the exact name of that "navigation bar" widget you might find out information on the sites above to check their status. But I can't search that for you if I don't know what the bug was and the name of the widget that is broken. Also, when you say "many of the textboxes" I understand it's not every textbox that's broken but some variant your are using in some particular places. More information would also be needed...
I'm really impressed with the startup time of IntelliJ which is really fast, however, every time I open it when it has started its always doing this indexing which causes everything to slow down, even if previously I have gracefully closed IntelliJ, the next start it will index again, why is that?
IntelliJ may not be the only application using your project working directory.
If you use version control like git, SVN, or hg, or other tools such as code generators that operate on the project, then they will likely not know about IntelliJ(with or without version control-ignored IntelliJ data), and will simply write their changes.
For that reason, the IDE reindexes completion and outline data to be consistent with the code,
What I mean is the following, illustrated via an example:
I start my Java application (which happens to be a simulator). The application runs for 1 hour and fails. I want to relaunch my application in debug mode, run it to minute 59, then start stepping through the code. At any point, I want to get back to the state that was present in minute 59 and re-start my debug.
Does Eclipse or some plugin have such support? If not, is there another open source application that can be used?
This can be accomplished by using a VM and simply saving state at the point of interest. But I'm wondering if there is a more native/faster Java solution.
The only possible solution to do this in Java that I know is this debugger from Chronon http://www.chrononsystems.com/ which integrates with Eclipse IDE.
The idea is that you record a debugging session which let you playback it. Although this is non-opensource and licensed software, it's still a cool product.
This could be done using a virtual maschine and taking a snapshot at the desired debugging state. You can then apply this snapshot over and over again, though this solution takes a considerably amount of time.