I'm debugging implementation with heavy use of method references. Indirection is used to enable logging and error handling aspects around module executions.
It's easy to step into referenced method using debugger, but stepping out back to call site is cumbersome. The stack contains a lot of proxy classes and aspects between call site and method under execution as shown in this image
Is it possible to configure step into and step out functions to skip classes not belonging to certain package? I know it's possible to use class filters on breakpoints, but I would need familiar feature with step functions.
In the Intellij Idea there is quite a lot of tweaking in Settings/Preferences | Build, Execution, Deployment | Debugger | Stepping. Make sure you check the Always do smart step into option. The option Skip synthetic methods may be what you need, you can also configure to skip some packages. More documentation here https://www.jetbrains.com/help/idea/stepping-through-the-program.html#smart-step-into
Related
I want to modify / make the rule target only public interfaces (not public classes etc). Is this possible ? Im using this rule in Java code but its too strict for my project and I would love to know if there is a way to change it a little bit.
Link for rule: https://rules.sonarsource.com/java/RSPEC-1213
For an existing ruleset on SonarQube, talk to your sonar administrator to change the rules that are enforced on the code and remove that particular one from global enforcement.
There have been a few times I've gone to the admins of the tool for the install that I use and said "this rule isn't one that I care about or will enforce and only makes it confusing" and had them remove that rule from the globally run ruleset.
Is it possible to write your own rule?
Yes, it is possible. From SonarQube's docs: Adding coding rules you have some options. Either you can write a plugin for SonarQube and add that to your instance (docs), or you can write an external application that analyzes the code which SonarQube consumes.
If you don't have your own instance of sonarqube or aren't up to writing the associated plugin or external tooling... you might want to instead lookout PMD (site).
For PMD, writing a custom rule can be much simpler (docs). One of the ways that PMD works is by 'compiling' the Java code into an XML representation of the abstract syntax tree for Java and then running xpath queries against that XML (tutorial).
The xpath rule can then be included in a project's configuration.
What about turning it off for the code that I'm working on?
If a specific rule is one that you don't want to invoke, you could suppress it with #SuppressWarnings("java:S106") (that particular spares warnings is for System.out.println use, but the same structure can be used for other warnings) or by adding // NOSONAR too strict on the line. There are spots where I have such comments where following the rule for a particular set of code is problematic and suppress it for that line, method, or class - with the comment about why that is done.
That particular rule... I'm gonna agree with the Java (and now Oracle) guidelines and follow it. The reason is that if anyone else works on the code, they'll expect it to follow that convention. Having a consistent understanding of what things should be where in code so that another developer doesn't need to go dig through an entire file to find the constructor when it is expected to be at the top (under the field definition) is a good thing. What's more, it limits the future cases where a developer goes through to make things consistent with conventions and results in a lot of style: updating code to follow style guide commits later.
is there a quick way to find (may be by using intellij or maven etc) all the interfaces (java) without any implementation.
I need to do above as we did some clean up of code where we removed a number of classes (and corresponding interfaces) which we think are not in use, but there could be the possibility that some interfaces may be left to be removed (due to manual error as it was huge clean up) which may be used by a bean which may cause run time exception. I am doing manual validation but if some automate way is present then it will be great.
regards
Sanjay
Try to perform (Analyze | Run Inspection by Name | Unsued declaration | Choose the necessary filters).
See the relevant documentation for more options.
I use eclipse and in some of my heavily used libraries (lets stick to slf4j in this example) there is a large amount of methods I will NEVER use.
Its up to the point that if I use those methods its most likely a bug.
(or a bad practice, missing debug info (checkNotNull(Object)), or dangerous to use)
For example there are 10 methods for "debug" alone. I need 3-4 at best.
How can I hide those other 5x 6-7 methods that clogs my code completion?
I know there is a feature in eclipse that hides classes and packages, however I haven't found such a feature for methods yet.
As an alternative I thought about using a "lite" library jar that only provides the methods I need and replace it with the original during the packaging. (I would use maven for this: lite = compile + optional/provided ; original = runtime scope)
However this alternative is tedious to maintain and may cause binary or license incompatibilities.
How can I hide "unwanted" methods from libraries in eclipse.
I need to be able to switch off the 'Duplicate class' error and visual indicator (the red squiggly underline) that you get when you have two classes that are named the same in the same package but in different folders. In this case, 'main' and 'test'.
Background
It could be argued that this is a duplicate of this posting, however, I thought some background would be in order to avoid some of the obvious replies (and also, there is no satisfactory answer to that post).
This question is related to unit-testing and collaborator mocking. As everyone knows, Android violates the basic 'containment over inheritance' guideline for java development. This is why you need Robolectric to test lifecycle overrides without the framework crashing your tests. Your collaborator can't be mocked and injected in the normal way because the class under test is the collaborator.
In this case, my large corporate client has further violated the 'containment over inheritance' guideline by adding several layers of class extensions from Activitys and Fragments that have to be used instead. I can't modify these layers and attempting to mock out the internals is impractical. The simplest solution has been to create duplicates of the leaf classes of this extra layer that provide unit-test-friendly results to the class-under-test.
This works. When you run unit tests the test duplicate is resolved and when you run production code the production duplicate is resolved.
It's just that constant annoying error indication that needs to be suppressed.
Workarounds, IntelliJ plugins, custom class loaders, etc. - all will be considered (with instructions).
It is hardcoded: source
The only way is to change sources and build your own IntelliJ - but you will not be able to use Ultimate version.
Or making an agent to replace the method - HighlightClassUtil.checkDuplicateTopLevelClass.
This might come handy, so you can do it as a normal plugin: How can I add a Javaagent to a JVM without stopping the JVM?
I am currently developing a simple plugin that retrieves results from a Jenkins build. I am extending Notifier and using build.getResults() to get the information. However, when I upload my plugin, I can't set it as a post-build action.
When I run my builds, they break on build.getResults() since I am trying to get the results while the build is still running.
What can I do to properly get the build result ?
Best thing is to look at existing plugins which use Notifier extension point (click to expand implementing plugins list).
Check that you have the Descriptor implemenation (inner) class, as well as config.jelly. Also check jenkins.out and jenkins.err logs for any exceptions (such as malformed config.jelly).
Edit: Actually, Notifier subclass of this plugin looks really simple as Notifiers go: https://wiki.jenkins-ci.org/display/JENKINS/The+Continuous+Integration+Game+plugin , see especially its GamePublisher.java and corresponding config.jelly, and it's GameDescriptor.java, which has been made a full outer class (often descriptor is inner class). Also if you want options into Jenkins' Global configuration, you need a global.jelly, but if you don't have such options, that is something you can just leave out (unlike config.jelly, which you must have for Notifier even if it is empty, like here).
As a general note, it can be really annoying when things do not work, and you do not get any error, your stuff simply is just not displayed by Jenkins... If you just want to get things to work for you, using Groovy build step might be easier, but if you want to get things to work for others, then doing a decent full plugin reduces support requests.
Since this sounds so simple, are you sure you need a plugin ? Take a look at using a Groovy Postbuild step instead; they're much easier to write. There are some good usage examples in the link. If you decide you really need a plugin, see if you can extend an existing one rather than writing your own; it's an easier way to understand the ins and outs of Jenkins plugin writing.