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.
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.
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
We have a rather large-ish monolithic software we would like to refactor at a larger scale. First step will be to derive several artefacts, which can be compiled independently. Given the size of the application we would like to automate that as much as possible.
An example:
+ package1
| |
| + Service1
|
+ package2
| |
| + Service2
|
+ interfacepackage
Assuming, Service1 is only used from within package1, it should not be touched. Assuming Service2 is used from Service1 I would like to automatically generate a minimal interface for Service2, put that interface in the package interfacepackage and change the dependency within Service1 to the interface.
Doing this manually would be no trouble at all. Both Idea and Eclipse provide semi-automatic refactorings, but we would like to formulate them as meta-rules. I had hopes, that either eclipse or intellij have a programmatic interface to define such rules, but I have not been able to find them yet.
I have even found the eclipse refactoring scripts but these seem to be restricted to refactorings of named classes, so if I knew all services which should be refactored, eclipse refactoring scripts would help but not if I want to define conditions on classes to be refactored.
Where should I look for a solution?
Clarification: Comment: So what's your problem?
We have a high 3 digit number of services which make up this monolith. These are in approx. 20 different packages. The whole software is approaching 1 million lines of code. My problem is simply the size. Doing refactorings manually could take months, we might miss something doing it manually. Also, de-tangeling the services is the first step only. So we are expecting a lot of similar refactorings applied down the road.
IntelliJ IDEA has an "open api" that can be used for plugin development.
The advantage is that IntelliJ parses the java code, and the "meta model" is available to you as a plugin author.
In IntelliJ, the "AST" model refers to the "Abstract Syntax Tree". This structure is invaluable for plugins that do refactorings.
You can easily see the package structure, class names, code, and so on.
https://www.jetbrains.org/intellij/sdk/docs/basics/getting_started.html
Note! Java functionality for plugin development has been externalised as a plugin.
https://blog.jetbrains.com/platform/2019/06/java-functionality-extracted-as-a-plugin/
Please also have a look at my own plugins on github, where I have posted the source code.
https://github.com/Steve-Murphy/unencapsulate-plugin
From a high level point of view I am looking to create a centralised list of libraries/dependencies that are either out of date and should not be used or can be used under warning.
We are using SonarQube for code inspection/coverage and my preference would be to use work the "Blacklist" into here through rules/analysis. This would be the preferred option as it is indeed centralised and allows the selection of severity e.g a library totally blacklisted as opposed to a warning. Though I have seen this mentioned on forums I have not seen a practical example of doing it.
My question so is there a way of doing this and if so how? All other opinions are welcomed.
I have looked at mavens bannedDependencies feature but I don't like the fact that it would break a build, allow the developer to edit and is not centralised.
The Disallowed dependencies should not be used rule template is what you want. It will let you specify dependencies by group and artifact id pattern, with or without version numbers.
This rule is available from version 3.10 of the Java plugin.
This question is related to, but not a duplicate of, this question.
My issue is slightly different; I have a "utility module", shared between the client and server code, and it contains no GWT-specific code.
I understand that normally, all the sources are pulled into one specific project, where everything is compiled together. But there is one issue with that: I only get to know if my utility project is "GWT compatible", when I compile the main project. This is way too late; I haven't even got around to start on the main project, but I want to know before I make a "commit" to my SCM, that my utility project is "GWT compatible".
In other words, I want to validate the utility project for GWT compatibility, independently from it's use in a separate project (module).
There's a large part of the JRE that is not covered by GWT, and it is particularly likely in a utility module that non-GWT-compatible classes or method be used. That is what I want to validate against.
EDIT: I could add a "dummy entry point", I suppose, but that makes the project depend on GWT, which I don't want to, since it is "general" code, also to be used by people that don't use GWT. If it matters, I use Maven as build system.
EDIT2: No matter what I do, I will only get real compilation/validation with an entry point (does NOT need to reference any of the classes). Neither <force>true</force>, nor <failOnError>true</failOnError> will do. Is there a way I can define that entry point, for the shared project, such that only gwt-maven-plugin sees it, but not javac (so as not to add an unneeded dependency in the Java code)?
The compiler actually always visits all code on the source path (note: not quite the same as the classpath), by starting at the requested module with any <source> tags, and then checking each <inherits> along the way. If it finds something that isn't compatible or isn't compilable, it will mark it as broken, and move on - as long as nothing actually depends on it (i.e. an EntryPoint, or something that an EntryPoint depends on) you'll just see this message:
Validating newly compiled units
Ignored 1 unit with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
If you include that -strict flag, the compile will actually fail when it hits something that can't be included correctly.
This work is done in the very early stages of the compile, while constructing the TypeOracle, which is used for Generators, long before any JS is built. That type oracle is passed to generators, which need to be able to ask questions like 'what interfaces on the sourcepath have a JSO implementation' and 'what are all possible subclasses of List'. Generators can do a huge number of things, including emit even more types which then need to be parsed, compiled, and the process continues until a full JProgram is created of all possible types, based on the current set of modules.
That JProgram then gets compiled down based on what can be reached from the roots - the entrypoint, as well as a few other details such as how to emulate Java details like casts, arrays, longs, exceptions, etc.
If -strict was not specified, and the compiler ends up needing to reach something which is unavailable due to earlier compilation problems, that is the time you find out. Using -strict to stop earlier will help ensure that you catch those issues sooner.
One more fun fact: By default, with com.google.gwt.user.User in your module (or any other <inherits> that depends on it), you already have an entrypoint, or several! These do some quick checking that your page is working correctly, such as using a strict doctype, or the browser actually matching the expected user.agent setting. This means that it is usually possible to compile a module even without an entrypoint (except with gwt-maven-plugin:compile, which will not consider a module for compilation just by those built-in ones).
EDIT: Okay, even one more: From http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html, combined with -strict, it looks like you can force the validation to run without actually compiling to JS:
-validateOnly Validate all source code, but do not compile
I don't think it's possible because the GWT compiler does not compile any unused code.
This means that your shared utility "module" may have code in it that is not compatible with GWT, but it will not cause any problems as long as GWT code never calls such incompatible classes or methods. Without an entry point GWT compiler won't know which code is used and which is not - it will assume that all of it is unused.