When using GWT I get following warning:
Referencing deprecated class 'com.google.gwt.user.client.rpc.SerializableException'
While it's only a warning, it's dead annoying having to look at every single time I run the project.
The warning occours since my RPC throws java.lang.Exception, and thus never actually uses the SerializableException, but GWT isn't clever enough to figure that out.
Is there a option to turn off the warning, or fix this, besides compiling my own version of the gwt-user/gwt-servlet libraries?
Thanks.
Edit: To clarify, this is GWT 2.0, and the project is being run from the Google Plugin in Eclipse.
Someone on the GWT's Google Group suggested using SerializationException instead of just Exception. Although, the javadocs for SerializableException suggest that Exception should be fine too :/ Which version of GWT are you using?
Deprecated. As of GWT 1.5, Exception
implements Serializable and can be
used in place of this [SerializableException] class
Lombardi's blog has a discussion of why exactly this is happening in the source.
Yeah, it's silly for Google to claim throwing Exception is a fine thing to do when it generates a lot of unnecessary JavaScript for subclasses of Exception and, in your case, generates warnings about those subclasses.
But this is all the more reason to throw a more specific exception (one that doesn't have a deprecated descendant). Unchecked exceptions on your RPC can still be handled by an UncaughtExceptionHandler.
You could set the loglevel of the gwt compiler. It seems like you have set yours to "warn", set it to info to get rid of the message.
If you are using eclipse do the following steps:
right click on the project
Google >> GWT Complie
Set the Log Level to info
Although extending SerializationException is a workaround, the contract of SerializationException indicates that it should not be used as a parent class of your custom RPC exceptions. It's there to indicate issues with the serialization itself and not with the logic within your services.
The underlying issue is that the compiler generates unnecessary code. To avoid the error simply make sure that your code does not use SerializableException anymore and add the following line to your module descriptor.
<extend-configuration-property name="rpc.blacklist" value="com.google.gwt.user.client.rpc.SerializableException"/>
Once the compile issue is fixed, you can remove the line again. Here is a link to the issue you might wanna star/follow:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4438
Related
Environment: IntelliJ IDEA Ultimate 2022.2 Build 222.3345.118
I have overridden the method with #Deprecated annotation.
I want to suppress deprecated API usage on certain methods. But the Option+Enter action has only useless suggestions.
We tried to suppress it by means of SupressWornings and //noinspection ScalaDeprecation. I would like to disable Inspection as a last resort because there are some warnings that I want to suppress and others that I do not want to.
In Scala you can use the #nowarn annotation to this end. You can see a very nice rundown of how to use both this annotation locally or other options on the overall project on this blog post by Lukas Rytz.
In your case, I believe you can use the following annotation:
#nowarn("cat=deprecation&origin=your\.package\.YourDeprecatedClass")
You can see an example of how I used this on this commit.
As you can see, the annotation can be applied even to individual expression via type ascription, but you can also apply it to methods. In general, I like to keep my #nowarns as specific and fine-scoped as possible. You can also tell the compiler to warn you when a #nowarn is not doing anything, so that you don't have to keep unused annotations around the code.
If you have deprecated APIs that you need to use (e.g. even though they are deprecated, you still need to test them) and the usages are all over the place, you might want to evaluate the option of configuring the warning suppression as a compiler option with something like
-Wconf:cat=deprecation&origin=your\.package\.YourDeprecatedClass
passed to the compiler. Here is an example of this as well (we use Bazel instead of SBT but I'm fairly sure that setting up SBT for this is quite simple).
For any other information, the blog post I linked above is an excellent source.
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.
Currently I'm working on an annotation in Java and everything works great. My AbstractProcessor creates the new files and can emit errors and warnings when needed. What is not working are real time errors and warnings. So what do I mean with that?
Assume I annotate a non parent method with #Override. The IDE will give me a real time error that I can not override this method since it is not part of the parent class. Same also goes for deprecated methods. Whenever you try to call one of these methods you get a warning about it. Note that these errors and warnings are emitted immediately and I do not have to rebuild my project to get notified about them.
Actually my warnings and errors are only emitted when I rebuild my project so how can I implement real time errors and warnings? Not sure if that matters but I use Intellij as IDE.
It depends on your IDE.
For example, I use eclipse. After setup the annotation processor. It can show the error immediately when I save the file. Like this:
For your IDE, this page may help.
I have a Guice enabled application working fine, but when I optimize it (i.e., shrink size) with Proguard, I get the following error message (I catch it with an uncaught exception handler):
java.lang.ClassFormatError: LVTT entry for 'that' in class file
com/google/inject/internal/util/$ImmutableList$RegularImmutableList
does not match any LVT entry
This prevents the application from operating properly. I do not obfuscate the code.
Does anyone know what is happening? Is there a solution/workaround?
Thanks.
Please make sure you are using the latest version of ProGuard, version 4.6 at this time of writing.
Based on other reports, there may however still be a bug (#3161222) in the optimization step, not always processing the optional LocalVariableTable and LocalVariableTypeTable attributes correctly. Therefore, three simple work-arounds:
compile without these attributes (javac -g:lines,source), or
let the obfuscation step remove the attributes (don't specify -dontobfuscate, don't specifiy -keepattributes LocalVariableTable,LocalVariableTypeTable), or
don't optimize (-dontoptimize).
The attributes are intended for debugging, and generally not very useful or even desirable in obfuscated code.
Sometimes ProGuard will rip out more things than it should when shrinking. ProGuard will remove any references to classes/members that it believes are not used in your application unless you explicitly tell it to preserve those classes/members.
You can preserve classes/members using ProGuard's keep options. The example usage page has a few examples of keep options.
I see this happen sometimes when my applications reference an interface implementation which doesn't appear to be referenced when you're just looking at the code. I just add a new keep option every time I find that something is missing. Perhaps someone else has a better suggestion for how to track these things down?
try this:
-keepattributes Exceptions,InnerClasses,Signature,Deprecated,SourceFile,LineNumberTable,LocalVariable*Table,*Annotation*,Synthetic,EnclosingMethod
-optimizations !code/allocation/variable
Do I have to take a look at the java api everytime I instantiate an object / call a method from a class in it? Also, do I always have to know which classes are in the java api and which are not?
If the exception is checked, then the java compiler will force your invoking method to either catch the exception or declare that it could throw the exception.
If the exception that is thrown inherits from Error or RuntimeException - I.e. is unchecked, then you have no way of knowing besides javadoc and looking at the code.
A good example of the latter, is NumberFormatException, thrown by Double.parseDouble(String). The only way to know is that the javadoc tells you it could throw this exception.
Modern IDEs (Eclipse, Netbeans, IntelliJ etc) provide easy access to this documentation.
I use Eclipse IDE which will make sure you account for all thrown exceptions. I highly recommend it.
http://www.eclipse.org
Knowing what exceptions a function throw is not different from knowing what arguments it needs, and what type it returns.
You either know it, look it up, or use an IDE that does this for you. BTW for checked exceptions you will get a compile-time error, so that can also be an option.
For you second question, In general...
Packages that start with "java." or "javax." are in the J2SE API.
Most packages starting with a internet domain prefix like "com." or "org." are supplied by third parties. Don't count on com.sun being stable though.
Packages with none of prefixes the above are likely not following the package naming guidelines or predate them.