SonarQube and checking for literal strings - java

I'm looking at the SonarQube product for use on a project, and we have a historical issue in making sure that all literal strings are pushed out to a resource file ready for internationalization.
Does the SonarQube regime include any checks to find literal strings that should be moved to a resource file? Our tech stack is Java and Javascript.

I'm not aware of such a feature. This would require a specific check that knows what string should or should not be localized - for instance like what's done on Eclipse plugin when using the //$NON-NLS-x$ comment.

Related

Who is responsible for docs and implementation of the JavaDoc-tool?

This question is related to an issue raised for Maven, which doesn't seem to escape paths forwarded to argument files supported by the JavaDoc-tool on Windows. The problem is that it's unclear from the documentation of JavaDoc itself how paths under Windows should be provided in those files.
The following is for Java 7:
If a filename contains embedded spaces, put the whole filename in double quotes, and double each backslash ("My Files\Stuff.java").
https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
The following from Java 8:
If a file name contains embedded spaces, then put the whole file name in double quotation marks.
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
In docs of Java 11 that part is completely missing, no mention of quotes, spaces or backslashes anymore:
https://docs.oracle.com/en/java/javase/11/javadoc/javadoc-command.html#GUID-EFE927BC-DB00-4876-808C-ED23E1AAEF7D
If you have a look at the URIs, in former versions of Java they were Windows-specific, while the last one is not. So I guess things have been refactored and some details of the argument files have been simply lost.
So, I need a place where I can talk to people about those differences in the documentation AND in the end how things are supposed to work on Windows. If backslash is an escape character in paths only and all that stuff. I would simply like to get some awareness from people who might know why the docs lack some details now and maybe even provide those details again.
So who/where do I write to? I don't know if it's Oracle or the OpenJDK project or someone completely different. Thanks!
I think, but don't take that authoritatively too lightly, that the javadoc tool is just an optional tool (can anyone show a formal obligation for any JDK to include a javadoc tool implementation ?) with a kind of de-facto standard set by the original owners, Sun thence Oracle.
But de-facto is only de-facto. Meaning formally and strictly speaking, that no JDK implementer has any obligation to make his javadoc tool behave like all the others do.
I think the best two places are the javadoc-dev mailinglist as well as the bugs database. Starting at some point in time (9, I guess) the have unified the parsing of the #files across tools. I have failed to find the code in the Mercurial repo last time.

Is there any functional reason for including the version number in the name of a JAR file?

In Java, I often see JAR files named with the version number of the software (jsoup-1.11.2.jar), while others are not (freemarker.jar).
Is this just a best practice/convention, or is there some functional reason for it?
Simple answer: no, this is purely a convention.
Obviously, tooling that checks versions can do that easily when version numbers are hard-coded like this. But there is no generic (like jvm based) tool relying on it.
And beyond that - sometimes this scheme is even counter productive. In our self grown build setup we have to always remember to update the build scripts after replacing JAR files - because a new version changes the file name (because version part of the file name).
Having the version in the name of the file allows you to quickly determine which of the n files you have is the latest. Also if you have no way of determining what the version is from within the program it can be helpful.

Get help in Eclipse on Java keywords

Is there a way to get put the cursor in a Java keyword and get help for that keyword? I know it works for apis, but what about the language itself.
I found a feature request for this at https://bugs.eclipse.org/bugs/show_bug.cgi?id=197903
Not without some plugin (if any even exists). Maybe just check official documentation (ex. http://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html as a starting point). There really arent that many keywords, and they are fixed (at least per version, unlike classes, methods, etc.). Wikipedia has a page that also includes a brief summary at http://en.wikipedia.org/wiki/List_of_Java_keywords#List.

Automatically build resource class based of XML in Java

In Android applications, resources are specified in xml documents, which automatically are built into the R class, readily accessible within the source code as strongly typed.
Is there any way I could use a similar approach for a regular Java desktop application?
What I'd like to accomplish, is both the removal of strings from the code (as a separation of "layers", more or less) and to make it easy to add support for localization, by simply telling the program to choose the xml file corresponding to the desired language.
I've googled around a bit, but the things I'm looking for seem to be drowning in results about parsing or outputting xml, rather than tools utilizing xml to generate code.
Eclipse's message bundle implementation (used by plugins for example) integrates with the Externalize Strings feature and generates both a static class and a resource properties file for your strings:
http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html
For this integration to work Eclipse needs to see org.eclipse.osgi.util.NLS on the class path. From memory, the dependencies of the libraries it was available in were a little tricky for the project I used this approach in, so I just got the source and have it as a stand-alone class in my core module (see the comments for more on that).
It provides the type safety you're looking for and the IDE features save a lot of time. I've found no downsides to the approach so far.
Edit: this is actually what ghostbust555 mentioned in the comments, but not clear in that article that this isn't limited to Eclipse plugins and you refer to your resources via static members of a messages class.
I haven't seen any mention of others using this approach with their own applications, but to me it makes complete sense given the IDE integration and type safety.
I'm not sure if this is what you mean but check out internationalization- http://netbeans.org/kb/docs/java/gui-automatic-i18n.html
Are you looking for something that parses XML files and generates Java instances of similar "struct-like" objects, like JAXP, and JAXB?
I came across ResGen which, given resource bundle XML files generates Java files that can be used to access the resources in a type-safe way.
http://eigenbase.sourceforge.net/resgen/

Structural comparison of two ASTs in Eclipse

I am working on an incremental builder for Java code in Eclipse. Eclipse provides a ResourceDelta that tells me which resources have changed since the last build. However, I would like to have more detailed information, e.g. what methods or what field definitions changed. There seems to be functionality similar to what I want in the "compare with -> each other" view. However, this code is quite disconnected from the build engine and seems incompatible with ResourceDeltas. What would be a good way to figure out what I want? The best solution I can see is to compare two ASTs, but I also could not find any built-in support for that.
JavaCore does supply this information via the IElementChangedListener and IJavaElementDelta interfaces. Here's a quick code sample to get you started:
JavaCore.addElementChangedListener(new MyJavaElementChangeReporter(), ElementChangedEvent.POST_RECONCILE);
More details available in Manipulating Java code from the JDT Plug-in Developer Guide.

Categories