I'm using Eclipse to develop a Java program. But in my program I have some methods in Eclipse which are striked through. What does it mean ?
It means that your method are deprecated. You may find another way to do the same thing
All those methods/class which eclipse found start with #Deprecated annotation is displayed with a strike through.
A method is made deprecated to discourage the user/client of the method not to use it. Because this method might be remover from the later release of the API/package. In this case the there may be an alternative method to use. A good java doc should contains what to use in alternate of the deprecated method.
It is a deprecated method. From the documentation:
A program element annotated #Deprecated is one that programmers are
discouraged from using, typically because it is dangerous, or because
a better alternative exists.
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.
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.
When using GCC to compile C or C++, you can mark functions with attribute((warn_unused_result)) which will cause the compiler to complain if you invoke a function that returns something and then don't assign it to anything.
I have some methods in a Java library I develop that have methods like this - calling them and then throwing away the result is always a bug. I would like API users to be able to identify such bugs via static analysis, such as with FindBugs or IntelliJ inspections.
I am wondering if there is a method annotation that is commonly used to mark methods or functions as "must use result". FindBugs has some special case bug-finders for the standard library, but a general way would be useful.
There is totally a standard annotation for this, and it is #CheckReturnValue. FindBugs has it; see e.g. here.
Guava uses it internally -- e.g. in the configuration methods for Splitter -- from JSR 305.
Use
import javax.annotation.CheckReturnValue;
.
.
.
#CheckReturnValue
Some good examples of #CheckReturnValue are available on the Google error-prone project wiki. (If you like static analysis tools such as FindBugs, you should definitely check out error-prone; it works on the source/AST rather than the bytecode, which makes it complementary to tools such as FindBugs.)
If you're reading this in 2019 or later: annotate the method with #edu.umd.cs.findbugs.annotations.CheckReturnValue available from com.github.spotbugs:spotbugs-annotations. SpotBugs is an actively maintained successor to FindBugs.
We know that there are several deprecated items in Java.
Will they be removed?
Have any deprecated items ever been removed from Java?
Will they be removed?
Unlikely since java has always been about maintaining backward compability, but it can happen. I see deprecations as a warning that the API is either unreliable or somehow seriously flawed.
(Thread has several of these).
Has any of the deprecated items in the past has been removed from java?
AFAIC not removed but never implemented Thread.destroy(), as it was along with several other Thread methods inherently unsafe.
This question has been asked elsewhere.
Quite frankly, what the Java team usually do, is to deprecate the method and remove its implementation to the suggested method instead. The deprecated method is just an unimplemented method.
According to the documentation here.
You can see that it says
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
So a deprecated method or class is basically a older method or class that is discouraged from being used as there are newer more logical ways to perform that action.
Will these methods ever be removed?
Probably not. It will continue to work as before the deprecation, you just have to deal with the pesky warning. In order to keep older programs still running correctly that aren't being updated, almost all deprecated classes and methods won't be removed solely for that reason.
Deprecated APIs are interfaces that are supported only for backwards compatibility. The javac compiler generates a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated APIs, though there are no current plans to remove such APIs – with the exception of JVMDI and JVMPI – entirely from the system.
Have any deprecated items been removed?
In the java.* class, no. There have been a few changes in the javax.* class but in regular java there has never been a deprecated method or class removed.
Why at runtime is anyone interested in knowing that a method is deprecated? Can some provide me with some examples?
There are some frameworks and tools that instantiate objects to work with them.
For example, many JavaBean UI editors create instances of the beans and interact with them as the user manipulates the UI they're designing.
Having the #Deprecated annotation available at runtime allows tools such as this to flag deprecated methods, events, properties for the user.
You're assuming that #deprecated is only of interest in the compile phase (IDE, compiler), but its not a stretch to imaging instrumentation scenarios where you require that information.
For example, an IDE can inform you of the number of call sites for a deprecated method, but how would you go about determining the percentage of time your application spends in deprecated methods?
One's runtime is another one's design time, e.g. when writing code that uses an API.
Good question, and I'm stretching to come up with a convincing scenario. All I've got is that I could imagine a application which used a classloader which didn't allow the use of deprecated code. This would require RetentionPolicy.RUNTIME.
That's all I've got...
Couple practical uses that come to mind:
With Velocity you can have a custom Uberspector which logs the actual calls from Velocity templates to any deprecated method and then just by reading the log you can see where the method is used and you can go and edit it out.
With Wicket you can have a security policy which disallows instantiating any class based on the .class contents so it could be possible to make a system which prevents the instantiation of #Deprecated classes if you're not an admin.
Imagine you compile MyClass.class with deprecated methods. If your #Deprecated annotations got lost, your IDE or compiler couldn't warn you when you call those methods from another class.