It's annoying and attention grabbing when Intellij will highlight all kinds of stuff like simplify something or a suggestion, or a warning of some kind.
Many times, I like the thank you mam, but stop bothering me. This is not relevant.
However, Intellij will only allow you to ignore the type of warning globally, which is kind of dangerous to do.
I am aware that you can add an annotation, but I don't want to pollute my classes with annotations and comments everywhere. Also, #SuppressWarnings("ALL") is applied even suggestions, not even on warnings.
Can't Intellij manage this using a project file ? Also, Intellij should add a line to the right to show where such a supression has been done.
Problem right now, is that once you supress globally it's almost impossible to undo, or revise.
I mean #SuppressWarnings({"PointlessBooleanExpression", "ConstantConditions"}) is hardly Java related, and should not be added to the code.
It should be managed by the editor. It must also be made so that it's easily editable and an overview can be seen for the entire project files.
Is this possible already?
If enabled in the settings somewhere, you can use //#formatter:off to turn off formatter and //#formatter:on to turn on formatter. Afaik it requires that you turn on the formatter before the end of the file.
Related
I want to debug one of the class from cxf-api-2.7.6 jar file ,downloaded the source file with the help of IntelliJ IDEA,but it does not contain POM file so what are the exact steps to generate the jar file after making changes in the source file.
Any help or suggestion would be greatly appreciated.
Thanks!
You should not modify a library and recompile it. It will be a pain to maintain. You will probably never be able to upgrade your library, and you might break some other behaviors.
If you just need to understand what is happening, you can use intellij debug tools as mentionned by Pim Hazebroek.
If you need to change the behavior of the library, you should :
Check that you are not misusing the library (you could post your usecase on stackoverflow for advice)
Check whether the latest version of cxf addresses your needs.
Use a different library.
Extend your current library (with inheritance for instance)
If however, you really need to modify cxf sources, you could clone https://github.com/apache/cxf, checkout the tag, modify the sources and rebuild.
There is (usually) no need to modify the source and repackage it with the advanced breakpoints in IntelliJ.
Unless you want to drastically modify the behaviour of course... But for simple debugging tasks you can use the "evaluate and log" as demonstrated in String.toUpperCase here:
It even provides code assistence.
Optionally you can uncheck the Suspend checkbox to remove the need to resume it when hit frequently.
I am starting a new project which might be open-sourced later on and/or at least get some external contributors during its life-time.
I am now thinking about what the best approach to code-style / auto-formatting would be. I am a strong supporter of only having auto-formatted code committed to a project, as this eliminates the differences between individual developers and helps keeping individual commits clutter-free of reformatting issues.
My first approach was to use Eclipse built-in style for the project, but I really don't like the default style, because I think line-break at 80 characters is way out-dated for today's screen resolutions. Also, as the name suggests, it's available only for people using Eclipse as IDE.
So I was also thinking about using my own formatter settings and checking the exported settings into the project's repository so that any contributor can pick them up. Again, this would force most people to use Eclipse, as I am not aware of any formatting definition that can be read by multiple IDEs.
Any hint how this is handled in other projects? I searched some github repositories, but to me it seems that this issue is more or less ignored by a lot of projects.
I do understand that this question may be border-line for Stack Overflow, as I don't know if a definite answer is possible and if this triggers a discussion, but it is something I often struggle with when starting a new project.
While screens grow wider, they don't seem to grow taller.
Whatever you other drivers are, preserve vertical space. Put { and } on lines containing other language key words, if you can.
In any case, use a maven plugin or other automated tool in your compile chain to enforce the rules that you care about. That way they are unambiguous.
Also don't create too many rules that don't matter. Each rule costs time to make the code comply.
I understand your concern and in my opinion the best approach is to create code formatting preference file which can be shared along with the project.
For example in eclipse Using a file explorer, navigate to //.settings and copy org.eclipse.jdt.core.prefs to a new location. This file contains all your formatting settings. Hence this can be shared to maintain the code formatting consistencies.
If not that then you might have to rely on the editor specific code formatting.
I definitely look forward to other expert opinion on the same if what I have shared is not optimal as per the requirement.
is it possible to suppress all warnings in IntelliJ for all unchanged lines? I am working in a project with java files larger than 2000 lines and there are warnings everywhere. To get a better overview of my code I want to only inspect my changed or added lines.
Summary from comment conversation:
Bad luck. Turning warnings off is the only solution (no one care about them anyway).
I don't think there is a way to do this. However, going forward you can use the annotation #SuppressWarnings( "unchecked" ) to suppress warnings that you do not care about. This does nothing for existing code unless you apply it to each warning (not what I would recommend), but will achieve the desired effect going forward.
I would like to mark usage of certain methods provide by the JRE as deprecated. How do I do this?
You can't. Only code within your control can have the #Deprecated annotation added. Any attempt to reverse engineer the bytecode will result in a non-portable JRE. This is contrary to Java's write once, run anywhere methodology.
you can't deprecate JRE methods, but you can add warnings or even compile errors to your build system i.e. using AspectJ or forbid the use of given methods in the IDE.
For example in Eclipse:
Go to Project properties -->Java Compiler --> Errors Warnings, Then enable project specific settings, Expand Deprecated and restrited APIs category
"Forbidden reference (acess rule)"
Obviously you could instrument or override the class adding #Deprecated annotation, but it's not a clean solution.
Add such restrictions to your coding guidelines, and enforce as part of your code review process.
You only can do it, if and only if you are building your own JRE! In that case just add #Deprecated above the corresponding code block! But if you are using Oracle's JRE, you are no where to do so!
In what context? Do you mean you want to be able to easily configure your IDE to inhibit use of certain API? Or are you trying to dictate to the world what APIs you prohibit? Or are you trying to do something at runtime?
If the first case, Eclipse, and I assume other IDEs, allow you to mark any API as forbidden, discouraged, or accessible at the package or class level.
If you mean the second, you can't, of course. That would be silly.
If you are trying to prohibit certain methods from being called at runtime, you can configure a security policy to prevent code loaded from specified locations from being able to call specific methods that check with the SecurityManager, if one is installed.
You can compile your own version of the class and add it to the boot class path or lib/ext directory. http://docs.oracle.com/javase/tutorial/ext/basics/install.html This will change the JDK and the JRE.
In fact you can remove it for compiling and your program won't compile if it is used.
Snihalani: Just so that I get this straight ...
You want to 'deprecate methods in the JRE' in order to 'Making sure people don't use java's implementation and use my implementation from now on.' ?
First of all: you can't change anything in the JRE, neither are you allowed to, it's property of Oracle. Uou might be able to change something locally if you want to go through the trouble, but that 'll just be in your local JRE, not in the ones that can be downloaded from the Oracle webpage.
Next to that, nobody has your implementation, so how would we be able to use it anyway? The implementations provided by Oracle do exactly what they should do, and when a flaw/bug/... is found it'll be corrected or replaced by a new method (at which point the original method becomes deprecated).
But, what mostly worries me, is that you would go and change implementations with something you came up with. Reminds me quite lot of phishing and such techniques, having us run your code, without knowing what it does, without even knowing we are running your code. After all, if you would have access to the original code and "build" the JRE, what's to stop you from altering the code in the original method?
Deprecated is a way for the author to say:
"Yup ... I did this in the past, but it seems that there are problems with the method.
just in order not to change the behaviour of existing applications using this method, I will not change this method, rather mark it as deprecated, and add a method that solves this problem".
You are not the author, so it isn't up to you to decide whether or not the methods work the way they should anyway.
I have written a custom build script for my android app. I included some "easy" preprocessing, so I can define comments like
//#ifdef something
... CODE
//#endif
and get rid of the Code part if configured so. The Problem is, that after preprocessing I don't need some modules anymore, so I leave them out. What remains is the import statement for that module which bites me, if I want to build the app finally. I'm searching for a way within my preprocessing, to organize the java Imports inside my script after preprocessing happens. Any Solution without the need for additional "clicks" is very welcome.
Sometimes you're really need preprocessor (quite rare). But you could actually achieve same goal with right build process.
Anyway back to the question you could use next technique:
//#ifdef something
... IMPORTS
//#endif
take a look at http://code.google.com/p/java-comment-preprocessor/
p.s.
example of usage for one of my cases
http://code.google.com/p/java-comment-preprocessor/wiki/ExampleOfUsageForJ2ME