I am using "java.lang.reflect.Type" in web app project all working fine..but I am stuck with code review how to fix "java.lang.reflect.Type illegal package import " -checkstyle warning..
I am more intrested in explanation of this warning.
Thanks
The original IllegalImport check only forbids the sun.* packages, so you are looking at a custom rule definition made by your client.
The rule simply means that you are not supposed to use classes from certain packages. This can make sense for various reasons. If your rule forbids java.lang.reflect.Type, then your client does not want you to use Reflection.
Since you say that you may not modify the rules, you will have to find some way to reach your goal without Reflection.
Usually packages that are for internal use and version specific. They can be dropped/modified anytime. Like sun.*. Look for anything that is not by default in your Checkstyle config.
Reference.
Related
Due to project sec. issues . Not allowed to use com.sun.management.OperatingSystemMXBean . Instead i am trying to use java.lang.management.OperatingSystemMXBean . But in my method i need to know the cpuLoad (getSystemCpuLoad) . how can i get the same using lang.management ? is there any method present in java. lang.* to get the systemcpuLoad ?
I don't think there is an alternative. At least not in the standard Java SE class libraries1.
Not all com.sun.* packages are considered to be closed APIs. In this case the javadocs include this interface. I take that as an implicit statement that this is an open API.
If this is just the generic warning from SonarQube that you shouldn't depend on com.sun.* and sun.* APIs (see RSPEC-1191), my advice is to suppress the warning for this particular case.
I don't see how this is a project "security" issue. Please explain why you think that.
Okay. Let me put my question in this way : How to getSystemCpuLoad method in java.lang.management.OperatingSystemMXBean.
One way is just like your current code (presumably) does. Cast the MXBean instance to a com.sun.management.OperatingSystemMXBean and call the method. (And suppress the SonarQube warning.)
The one thing to note is that the getSystemCpuLoad method is marked as deprecated in Java 17. You should now use getCpuLoad instead.
1 - If you found and used a 3rd-party library2 that provides this functionality, or it you implemented your own (in native code, for example), I think you will be making the problem worse. Now you have an extra dependency to track or extra code to maintain. Bear in mind that the implementation of this functionality is OS specific, so you would need to find or write an implementation that works on all of your platforms, both now and in the future.
2 - Beware of posts that suggest using the SIGAR library. It hasn't been updated in a long time, and there are reports that its problematic on some platforms.
I have a weird behavior in one service I am developing for AOSP.
It seems like I have to include classes even if they are in the same package, while this is normally not needed in java.
If I don't, I get cannot find symbol at compile time.
Is there some special rule applying to AOSP? Maybe some special settings I need to fix in Android.mk?
I bet you have a typo in one of your class's package statements ;)
I'm writing a java webapp based on Spring. Any suggestions for what I might add to the illegalPkgs import declaration for? I just added javax.transaction.Transactional to the banned list because it messed me up when I was refactoring I accidentally used the #Transactional annotation from javax instead of the one from Spring and it broke my JPA transactions. Looking for other packages or specific classes I should ban proactively!
What I have so far
<property name="illegalPkgs" value="sun, java.sql, java.awt, javax.swing, javax.transaction.Transaction"/>
Apart from the default sun or, as some prefer for clarity, com.sun,sun, the IllegalImport check is mostly helpful for checking project-specific rules.
For example, if you want to make sure that everybody uses log4j as logging framework, you might add java.util.logging,org.apache.commons.logging to the list. Possibly more, as this would depend on how far you have control over your transitive dependencies.
Another example is, if you want to constrain the use of reflection to certain parts of your code base, you might add java.lang.reflect,org.reflections.
Using just IllegalImport will not gain you much though. You will probably need other checks, like IllegalType, IllegalInstantiation, or ImportControl, too. In general, using Checkstyle for this is not a silver bullet anyway.
So, I may sound crazy when I say that I want more warnings in my Java code, but hear me out. I'm transitioning to better coding practices, and want the IDE to help. In my older days, I made a library in packages like bht.tools, but now am moving to org.bh.tools. To do this, I'm moving the classes slowly and one-by-one, so that I can also go over their code to make sure best practices are being used there too. This has the added benefit of knowing that any class I import from the new packages has recently been reviewed to be more robust and efficient.
In short, I want NetBeans to show a warning wherever I'm using bht., whether it be in imports, fully-qualified names, etc.. Is this possible?
Yes, you can use the Netbeans Java Hint Module. There is a nice tutorial here.
You probably need do define a TriggerPattern:
Find parts of the source code that satisfy the given pattern, and invoke the method that is annotated with this annotation. The method must be public static, the return type must either be assignable to ErrorDescription or to Iterable. Its sole parameter must be HintContext.
and also a JavaFix
A base class for fixes that modify Java source code. Using this class as a base class makes creating the fix somewhat simpler, but also supports running the hint in the Inspect&Transform dialog. The fix can be converted to Fix by means of the toEditorFix() method.
Read the official tutorial and the org.netbeans.spi.java.hints documentation for full details.
I have a complex Java project that ultimately boils down to 3 major packages:
com.myapp.client --> client-side classes
com.myapp.shared --> client- and server-side utility classes
com.myapp.server --> server-side classes
I would like to write an Ant task that checks that no com.myapp.client classes show up as dependencies for com.myapp.server classes, and vice versa. I call this concept "drawbridging", because you're putting up a drawbridge between client and server code. The Ant task would fail the build if such violating dependencies are found.
For the life of me I can't figure out how to do this. Preferably, something already exists out there, however Google didn't turn back anything.
Short of an existing open source solution, my next guess would be to loop through all the client classes and check their imports for server classes; however according to this SO question the Java compiler throws away import references at compile-time.
So, I'm at a loss here. Any ideas? Thanks in advance!
As Java bytecode references to classes by their fully qualified names it should be quite feasible (but not easy), using a library like BCEL or ASM.
However, I think this question has a pretty distinctive X-Y ring to it, meaning that you're trying to solve a problem that is actually a symptom of the root cause you should be solving, in this case probably by properly compartmentalizing your code just as Brian Roach already suggested.
AntContrib VerifyDesign is exactly what I was looking for. Thanks me!