I recently upgraded to helios and now every time I step into a constructor for a class (e.g. Cat myCat = new Cat();), eclipse debugger shows the stack as
:
To get to the actual constructor code, I have to step out several times which is annoying. This is happening with every class and despite the stack I never see any error messages in the console. How do I fix this so it directly steps into the constructor for my class?
This only happens the first time the class is used, and even for classes that are in the same src file as the current one.
Eclipse has a step filter preference in the Java debugger preferences. Its default preference filters out java.lang.ClassLoader, however this wasn't working. This might have something to do with recently having installed and switched to using jre7. To solve my problem I added a filter to step through any code in the java.lang package.
I think the ClassNotFoundException is just happening as a part of class loading -- the problem is that you have a breakpoint set to trigger when those exceptions are thrown. My guess is that your version of Eclipse has this breakpoint on by default, whereas the old one didn't.
Check out this link, which reports a similar problem and provides the solution, which is just to disable that breakpoint.
(In the interest of teaching to fish and all that, the google search term was "eclipse debugger launcher$appclassloader".)
From the stack track reported in Eclipse, it seems a ClassNotFoundException was initialized and is being thrown, Did the application you wrote ran into any problems?
Have you set breakpoints in constructor of the class? you was not able to step into the constructor at all?
Were you using Class.forname() or import to introduce the class to JRE?
It seems that the for my students using lab machines running openjdk, the solution was to add a step filter in the same preferences mentioned in https://stackoverflow.com/a/10525351/1449799 but add jdk.*
Related
In IDEA IntelliJ I have the option to:
Update resources
Update classes and resources
Redeploy
Restart server
If I change some code of a Servlet then I always need to redeploy. Is there another way to "reload" faster to get changes affected?
Check out this IntelliJ WebHelp article: Reloading Classes
However there are limitations:
At the moment due to original limitations of Java SDK the HotSwapping
is possible ONLY if a method body is altered. In all other cases (like
changing method or class signature), the class reload is impossible
and the corresponding error message appears.
For more options you might want to check out what Engineer Dolly suggested in his comment to your question.
In my case there are two reason for doing that:
Sometimes people by mistake import classes which present in macbooks JDKs but absent in Linux. That causes build to fail on ci servers which are Linux based boxes. I doesn’t happen frequently, but when it does happened I'm thinking that there should be some smarter way to find out that earlier.
Unused imports trigger warning in IDE/code analysis. From time to time somebody need to spend time on cleaning up this stuff. Even if its just single right click in IDE you still need to commit your changes and make sure everything alright on build.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail locally if there are any.
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
UPDATE:
I followed yegor256 suggestion and incorporated Checkstyle task with initially small subset of Sun Code Conventions (unused imports is one of them) and made it break a build if violations found.
After one week of trial we've got zero unused imports in our codebase and surprisingly zero complaints about this rule (by the way, Checkstyle is really fast: analyzing ~100KLoc taking less than one second).
As for using IDE for such analysis: yes, it good choice, but having this kind of checks run as part of automated build is better.
What you're trying to do is called static code analysis. Checkstyle can help you. If you're using Maven, this plugin will do the automation for you: http://maven.apache.org/plugins/maven-checkstyle-plugin/
You can also take a look at qulice.com (I'm one of its developers), which integrates a few static analysis tools and pre-configures them (incl. Checkstyle, PMD, FindBugs).
If you are using eclipse IDE or IntelliJ IDEA, you can configure them to
1a. organize imports / remove unused imports on save or before commit (see cleanup preferences)
1b. switch the "unused imports" warning to an error (see error settings)
2a. configure a jre which does not include com.* stuff
2b. configure the warning of proprietary api usage from the jre to be an error
You might still want to check that on the build server, though. In this case the more complicated stuff like configuring CheckStyle would still be necessary.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail build locally if there are any.
I use IntelliJ to organise imports, this removes all the unused imports. You can do this with one hot key from the top of you code base to correct all the imports. (It also has over 700 other types of static checks and fixes)
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
I have IntelliJ check in code which formatted and with imports organised so the issue never arises in the first place. ;)
In Computer Science the name given to such a process of analyzing the code without executing is known as static code analysis.
Try using an IDE, I am using Eclipse, which marks all the Unused imports and Unused Variables or methods in with a Yellow color underline....
Aren't these unrelated questions? If you import classes only present in the local JDK, these imports are used (just unsatisfied). For either problem, I recommend solving it in the IDE so the problem will be detected when code is written, rather than prior to checkin (the earlier the detection, the easier the fix ...).
In eclipse, you could prevent unsatisfied imports with access rules, and automatically fix imports whenever a source file is saved by enabling the appropriate save action. If you check these settings into version control, you can easily share them with the team.
I see lot of comments in same way that use this IDE or that IDE. But all my friends try to understand the difference. Doing something programmatically is different and using IDE is different.
If I want a process to be programmatic then suggestion of IDE is not useful. It might be possible some one is asking this question because he is building complete process and this step is part of it. How opening IDE would help him on different machines and OS where CI is working?
I too building one tool on similar lines. I achieved it up to some level but it programmatically open IDE and close it automatically and fixes source code too. But opening same in Linux might be a question for me.
Understanding some one's view before answering is really very important.
I am working on a project of java. I opened the project in debugging mode, and goes through the program. One thing where I got stuck is that, if I step into a specfic function, it dont go into it. Instead if I put a breakpoint inside that function then program goes upto that point. I am using Eclipse 3.7.2. I dont know why eclipse is showing such a behaviour. Any help will be appreciaed.
dystroy already said in a comment what I was planning to say in this answer: the most common cause for me experiencing this is when the actual runtime class instance is a dynamic proxy, usually from either hibernate, or Spring, or a mock object framework (when testing) such as Mockito. In those cases, you generally have to do exactly what you have done, and put a breakpoint inside the method being stepped into.
Since recently it's much slower running a program in Debug mode in Eclipse Galileo.
I'm not aware of any changes.
Do you know what could be the cause? Running it normally is not a problem.
Another "debugging break" is the use of method entry/exit breakpoints.
Did you try to remove all breakpoint definitions once?
Sometimes i think Eclipse is getting out of synch with some of its internal/displayed state. Perhaps you should try to setup a new (not copy) of your workspace. This sometimes helps me to recover from spurious features.
This is how you can remove all breakPoints
Eclipse -> Run -> Remove All Breakpoints - for removing all Breakpoints for all Time
Eclipse -> Run -> Skip All Breakpoints - for temporary remove breakpoints
I faced this issue lot of time. Solution is simple, Remove all breakpoints.
(Run >> Remove All Breakpoints)
I was just running a program in Eclipse debug mode that was almost instant without debugging but when I ran it in debug mode, it was really slow. I went through and deleted a ton of random useless breakpoints I wasn't using and then the program sped up A LOT (200x or so).
Disable 'Show method result after a step operation'.
I have found that i often forget that i have a bunch of expressions added to the expressions panel that are no longer needed that are none the less being evaluated (or are failing to evaluate) and this slows stuff down a good deal. Make sure that you keep those expressions cleared out when not needed.
Close eclipse... clear %temp% folder, temp folder... disable breakpoints... in most cases this will definitely solve the problem.
What kind of JVM are you attaching to? I found in my experience, that in debug mode IBM JDK is slow like hell.
For all JVMs, check if you have conditional breakpoints with expensive condition. Try disable breakpoints. You may have exception breakpoints or expressions. Try disable or remove them.
In my case, Eclipse was trying to build files, which I was doing manually.
Going to Window -> Preferences -> Run/Debug -> Launching, and then disabling "Build (if required) before Launching" underneath General Options solved the slowness.
Clearing temp files on Windows fixed it for me
"C:\\Documents and Settings\\{user}\\Local Settings\\Temp"
Normally Java Virtual Machine turns off Just in time compiler (JIT) when running in debug mode. On IBM WebSphere, the IBM JDK is heavy de-optimized and will be very slow.
By the way debugging also make impossible to recompile and optimize the code.
Relay on logging for complex debugging: it will save your days on production, where you cannot debug for sure.
With all the learning over the years working with eclipse, here are couple of suggestions
keep your open projects to minimal what you actually need
keep it lean and thin - uninstall the plugins/features which you don't use (mylnn, validations etc).
No matter what you do, the eclipse tend to get slower over the time. The ultimate solution to get a responsive IDE is to recycle your existing workspace (create new workspace and bring in the projects which you need).
Before you run your application in debug mode press on (disable all breakpoints) and you wont experience slow loading or any problems. After your application has started just enable the breakpoints and then you can debug your code.
I faced this issue recently after upgrading my macOS version.
I wasn't able to fix the slow debugger with all the above solutions, I ended up installing a newer version of eclipse, and everything works prefect after that.
It happened to me once and the problem was, I had the folder with ALL my projects source code in the Source Look-up. This way, not only the debugger got really slow (because it probably crawled all my files) but also I could not do a lot of things such as inline execution.
The takeaway: check your Source Look-up. When debugging right-click in any thread from the Debug view, choose Edit Source Look-up and see what what you can/should remove from there. In my case, it was a spurious folder, other times you may have too many projects, folders, JARs etc. and may remove some.
Recently i was having extreme slow performance debug, both in eclipse and visual studio code (vs code)
In my case, the problem was with lombok configuration in JPA entities.
I changed the #Data anottation to #Getters and #Setters.
Looks like hashCode() and equals() implementantion of lombok was in conflict with JPA.
I've had the same problem. The work around i'm using is to just set a single break point and run to it. After that I don't try to step over or continue i just restart the test and move my break point to the next line I want to view. I am using JUnit with Mockito in Intellij. I'm guessing it has something to do with the byte code manipulation not matching the actual code in intellij. (In intellij, there is an implementation internal to intellij for running JUnit tests. Mockito may not play will with it)
I'm getting the following NullPointerException while trying to use the Play FBConnect module:
Caused by: java.lang.NullPointerException
at tags.fbconnect.FBConnectTags._button(FBConnectTags.java:26)
at tags.fbconnect.FBConnectTags$_button.call(Unknown Source)
at /app/views/main.html.(line:17)
at play.templates.GroovyTemplate.render(GroovyTemplate.java:203)
This seems to be the line where its occurring: https://github.com/rbamba/play-fbconnect/blob/master/app/tags/fbconnect/FBConnectTags.java#L26
Unfortunately I'm not sufficiently familiar with Play modules to debug this myself.
edit: In response to a comment, I believe the fbconnect module is correctly configured, since this is being reported earlier in the log:
13:12:13,225 INFO ~ Module fbconnect is available (/home/****/play-1.1.1/modules/fbconnect-0.3)
edit2: I've actually got it to progress past this point on my local machine, but still getting this NPE on my production server.
I can't see anything specifically wrong with the plugin code. To explain a little of what is going on,
// the line of code with the error
String url = Play.plugin(FBConnectPlugin.class).session().getLoginUrl(scope);
Lets break this down a little
Play.plugin(FBConnectPlugin.class)
This line asks Play to return the initialised plugin, from the list of plugins configured within Play. If the Plugin is not set up, then it returns null. This is the most likely reason for the error.
.session()
This simply gets the session object from the FBConnectPlugin, which is a statically created object, so will not be null.
.getLoginUrl(scope);
This builds the URL up. This method is not called, otherwise you would see it in the stack trace.
Therefore, the problem is that you have not configured the plugin correctly. Check over the documentation again to make sure why it has a problem. Alternatively, you may want to check out the FbGraph module. I installed this a few days ago, and have a Facebook app up and running already. It is very simple, and the documentation is excellent.
The answer is a little long-winded, but as you said you did not understand how modules worked, I thought it was worth explaining.
I spoke to Regis Bamba, one of the programmers who works on fb-connect.
I eventually decided to use the fbgraph module instead, and I'd probably recommend this to anyone thinking of using fb-connect because its more powerful, and seems to be better maintained. Even Regis recommended using it :-)
Regardless, here is what Regis suggested to get rid of the "java.net.URISyntaxException":
The solution is to manually replacing it with its encoded value, before encoding the whole string.
The getAuthUrl() function in FBConnectSession.java should be:
public String getAuthUrl(String authCode){
return "https://graph.facebook.com/oauth/access_token?client_id=" +
WS.encode(id)+"&redirect_uri=" +
WS.encode(Router.getFullUrl("FBConnect.callback")) +
"&client_secret="+WS.encode(secret)+"&code="+WS.encode(authCode.replace("|","%7C"));
}