Short Story: My house was broken into MacBook Pro among stolen items. Bought a new MacBook restored from TimeMachine drive including Eclipse folder. System files could not be restored because hardware was slightly different. I did a system update and updated to 10.6.5 and Java 1.6.0_22, all the latest. I run Eclipse Helios for Java development for college assignments.
The problem I am having is that when I run Eclipse and start coding when I get to a method of any type when eclipse usually throws up an auto-complete type box underneath the current line the program hangs for a few seconds while it loads / moves through the list depending on how fast I am typing. Example:
JTextField txt = new JTextField();
txt.get....
I could type the second line out pretty quickly as I know what I am looking for but the program will hang (multicolor swirly mac icon will replace pointer). Eclipse process will spike to 100% and I will not be able to do anything until the auto-complete box finishes whatever it could possibly be doing and the suggestion moves down to "getText()" or whatever the list beginning with "get" contains.
Things I have done to correct include, re-downloading and installing eclipse into another location, creating a new workplace in that eclipse install, re-creating the projects and code files by hand (i.e. not importing anything). The problem still persist.
I am not seasoned enough in Java to abandon the helpful suggestion box, especially when I am learning new things.
Anyone else experience this problem or know a possible solution I have not tried?
This happens with me with Android development, and I have a clue as to why - documentation! If I uninstalled the documentation, meaning the completion list wouldn't show me any API documentation, the completion list was back up to normal speed. Installed it back, the completion list is slow again. This wasn't a problem in Galileo, just Helio.
I'm trying to find the best JVM settings to use with eclipse to see if I can improve things.
Related
I've attached two images to quickly display what I'm talking about.
It seems to effect my environment in incredibly annoying ways, such as no auto-complete for things like variables (every time I want to utilize a variable or parameter I have to literally type is every single time).
I tried restarting VSC, as well as uninstalling and reinstalling plugins. I also did a chkdsk for errors and corrected them but that seemed to have no correlation to the issues I've been having.
Interestingly enough I've also been having some other issues with my computer, such as my mail app not working anymore (it throws an error code), and not being able to connect to other microsoft products. Not sure if it's related but it seems to have began around the same time.
Reinstall the Java extension or update to a pre-release version.
Press CTRL + SHIFT + P, and type Java: Clean Java Language Server Workspace. to clean up the workspace and restart vscode.
I'm coming from NetBeans and evaluating others and more flexible IDEs supporting more languages (i.e. Python) than just php and related.
I kept an eye on Eclipse that seems to be the best choice; at the time I was not able to find an easy solution to keep the original project on my machine and automatically send / syncronize the files on the remove server via sftp.
All solutions seems to be outdated or stupid (like mounting a smb partition or manually send the file via an ftp client!
I'm not going to believe that an IDE like Eclipse doesn't have a smart solution of what I consider a basic feature of an IDE, so I think I missed something... On Eclipse forums I've seen the same question asked lots of time but without any answer!
Some suggestions about is strongly apreciated otherwise I think the only solution is stick on one IDE each language I use that seem to be incredible on 2018.
I'm developing on MacOS and the most interesting solution (kDevelop) fails on building with MacPorts.
Thank you very much.
RSE is a very poor solution, as you noted it's a one-shot sync and is useless if you want to develop locally and only deploy occasionally. For many years I used the Aptana Studio suite of plugins which included excellent upload/sync tools for individual files or whole projects, let you diff everything against a remote file structure over SFTP when you wanted and exclude whatever you wanted.
Unfortunately, Aptana is no longer supported and causes some major problems in Eclipse Neon and later. Specifically, its editors are completely broken, and they override the native Eclipse editors, opening new windows that are blank with no title. However, it is still by far the best solution for casual SFTP deployment...there is literally nothing else even close. With some work it is possible to install Aptana and get use of its publishing tools while preventing it from destroying the rest of your workspace.
Install Aptana from the marketplace.
Go to Window > Preferences > Install/Update, then click "Uninstall or update".
Uninstall everything to do with Aptana except for Aptana Studio 3 Core and the Aptana SecureFTP Library inside that.
This gets rid of most, but not all of Aptana's editors, and the worst one is the HTML editor which creates a second HTML content type in Eclipse that cannot be removed and causes all kinds of chaos. But there is a workaround.
Exit Eclipse. Go into the eclipse/plugins/ directory and remove all plugins beginning with com.aptana.editor.* EXCEPT FOR THE FOLLOWING which seem to be required:
com.aptana.editor.common.override_1.0.0.1351531287.jar
com.aptana.editor.common_3.0.3.1400201987.jar
com.aptana.editor.diff_3.0.0.1365788962.jar
com.aptana.editor.dtd_3.0.0.1354746625.jar
com.aptana.editor.epl_3.0.0.1398883419.jar
com.aptana.editor.erb_3.0.3.1380237252.jar
com.aptana.editor.findbar_3.0.0.jar
com.aptana.editor.idl_3.0.0.1365788962.jar
com.aptana.editor.text_3.0.0.1339173764.jar
Go back into Eclipse. Right-clicking a project folder should now expose a 'Publish' option that lets you run Aptana's deployment wizard and sync to a remote filesystem over SFTP.
Hope this helps...took me hours of trial and error, but finally everything works. For the record I am using Neon, not Oxygen, so I can't say definitively whether it will work in later versions.
I'm working with GuideWire - it's an out of box online insurance implementation. It's java based and has its own IDE. Firstly DCEVM worked perfectly, increasing my productivity dramatically. But couple days ago, it has stopped working, supplying me with
"Classes hasn't been reloaded as coderedefenition is disabled".
I've already tried everything and asked everybody for help, but nobody has faced this problem.
More than likely this is because the version of java you have started the app server with is now different and doesn't have the DCEVM applied to it.
You need to double click and run the applicable dcevm.jar and then it will throw up a UI for you to view and select the appropriate JDK's to apply the Dynamic Code Evolution VM changes onto.
Full video showing how to do that is here https://www.youtube.com/watch?v=eLFxCRaVh-g
Sorry in advance. This is a really vague question because I have no idea whatsoever what is going on. I have a Java Swing GUI desktop app that I wrote in NetBeans. While inside of NetBeans, the app works fine and passes all of the tests that I have thrown at it. I've been developing this app over the past several months, deploying it at various phases of its development.
Yesterday, I finished adding and testing some new functionality. I built the application and put it on another computer. I then went to run the program (outside of NetBeans) straight from the jar file. While in the new areas (JDialog boxes), the program crashes. Since I am not in an IDE, I have no feedback to see what is wrong.
The only thing that I can think of (and this is lame) is that I added some switch statements that switch on strings, which I know to new to 1.7. I was previously developing in 1.6. Otherwise, I can think of no reason that the program should work flawlessly inside the IDE, but crash outside of it.
Can anyone offer any suggestions for how I should approach this? I'm at a complete loss.
Thanks very much.
The next debugging step for you is reducing the size of your program until it doesn't crash, then seeing what change you made worked. That should either make the answer obvious or give you a good question to post on SO.
Your idea that it might have to do with switch statements tells you to try:
removing them
removing and compiling on JDK 6 and see if it works
Those are reasonable ways to reduce your program size to see if you can make it run.
I would start from collecting a crash dump data.
If you run the UI on windows you could use DrWatson
If you run the UI in Linux , By default the heap dump is created in a file called java_pidpid.hprof in the working directory of the VM. unless you specify the path yourself by adding this -XX:HeapDumpPath= option to your UI java options.
I'm new to Java (come from C++/.NET background) and am experiencing very strange error. I am developing w/ Eclipse IDE on Windows XP on my local desktop. It seems that for some reason, an older (and of course buggier) instance of my application stays running for some very odd reason which I cannot understand.
Even when I close eclipse, this old version of my application is running in the background. So unless I reboot, when I try to test new version of the code, this 'old, rogue instance' is fighting for the resources that are used (files on a share) with the newer (hopfully less buggy) version of the code.
Has anyone experienced this? Does the JVM cache old versions of your Java application for some reason? What am I missing here? When I reboot my machine, the instance finally dies...
I was ripping my hair out trying to figure out why the new version of my code still had the same old bug until I realized this was happening... shrug
Thanks for any help!
Do you by chance either run your program multiple times, or have forgotten to close one instance of it prior to re-running it from Eclipse?
One thing, that is not very obvious when using Eclipse, is that it allows to run any number of instances of Java programs simultaneously. When you have the Console view active, you have the option to terminate the latest launch.
To switch the console to a different launch (if there are multiple running) you can select from a list, by pressing the "Display Selected Console" icon, which is the monitor icon to the top-right in the Console view.
You can also remove any and all terminated launch console outputs from the Console view, by pressing "Remove All Terminated Launches", if every launch have been terminated it should now display "No consoles to display at this time", otherwise the next-newest running launch will be brought to the top.
If this isn't the problem, and indeed Eclipse have lost track of a launch (which is quite rare, but can happen - especially if you spawn sub processes yourself), you can safely terminate any run-amock java.exe process from the Task Manager, as Eclipse runs wrapped in a Windows executable on the Windows platform.
Java applications run under "java.exe", so you can look for that in the task list. Sadly, if several Java applications are running at the same time, it's hard to tell which is which.
I'm not terribly familiar with Eclipse, but it seems like Eclipse should tell your old version to terminate when you close Eclipse. The JVM doesn't cache past versions.
Hope this helps.
I had a problem like this as well. I would try to run the program after making changes, and it would run the older version of it, and still report errors and stop on lines that I had even commented out. I tried micdah's solution, but there were no java.exe processes in Task Manager. I solved the problem by killing the Eclipse process from the Task Manager, which closed the program without saving Eclipse Workspace settings. When I relaunched, everything I had saved in the .java files launched normally.
Could be a bug in Eclipse. Could be some code in your application that's spawning a new process. Impossible to tell from over here.
If you haven't already, check out the jps tool, which is included with the regular JDK. It might make it easier to diagnose the problem.