What changes or code evolution break backward compatibility (mainly binary compatibility)? Is it fully specified anywhere?
I checked the Scala language specification, but didn't see any section on the matter like Java Language Specification Ch. 13 Binary Compatibility.
According to the mailing list, the spec documenting detailing backward compatibility issues does not yet exist but is in the works.
For current status and oulook of binary compatibility (mainly of the scala library), see Martin's message to scala-user mailing list.
For a migration manager preview, see this page http://typesafe.com/technology/migration-manager.
I've added support for Scala to the japi-compliance-checker tool (1.6 version). So now you can identify breaking changes in your code automatically. The tool is available here: https://github.com/lvc/japi-compliance-checker
Sample usage:
japi-compliance-checker OLD.jar NEW.jar
Also I've created a page with analysis reports for Scala versions evolution generated by this tool as an example: http://abi-laboratory.pro/java/tracker/timeline/scala/
Related
I have been trying to scan my code by using SonarQube + FindBugs + FindSecBugs plugins.
The idea is to detect vulnerabilities in the code, and as it says in the github project subject, it works with scala https://github.com/find-sec-bugs/find-sec-bugs
I have installed the plugin as the documentation says, and tried a few scans but nothing related to vulnerabilities in scala is coming up.
So, in order to figure out if the code was really good or there was a misconfiguration on my SonarQube settings, I went to http://find-sec-bugs.github.io/bugs.htm, I took one of the examples (Potential Path Traversal), inserted the example code and I ran the scanner again. It was not found.
The rule (Security - Potential Path Traversal (file read)) is activated in the Quality Profile, and despite it is a Java profile, it is assigned to the project, since the code in the mentioned example is Scala.
I noticed that all the rules coming from find-sec-bugs are java ones, so I'm wondering if they don't work on scala or there is something else I can do to make it work.
Thanks in advance, and let me know if you need any extra information, I'd be glad to provide you.
Looks like the main reason for that to happen is that Scala bug patterns are explicitly excluded for some reasons:
Their are plenty of limitation with the SonarQube architecture regarding the multi-language support.
It is closely tie to the sonar-source plugin design.
Language can't have the same extension (https://jira.sonarsource.com/browse/MMF-672)
Repository can't contains rule that apply to multiple languages. (If you would have Scala only code, the Java core rules would not be enable unless you have one Java file present)
Sensor are couple to the language definition (depends on the most popular plugin that declares it).
etc, etc..
Source: https://github.com/spotbugs/sonar-findbugs/issues/108#issuecomment-305909652
All the exclusions can be seen here: https://github.com/spotbugs/sonar-findbugs/commit/526ca6b29fae2684f86b1deba074a4be8a05b67e
Particularly, for Scala:
static exclusions = ['CUSTOM_INJECTION',
'SCALA_SENSITIVE_DATA_EXPOSURE',
'SCALA_PLAY_SSRF',
'SCALA_XSS_TWIRL',
'SCALA_XSS_MVC_API',
'SCALA_PATH_TRAVERSAL_IN',
'SCALA_COMMAND_INJECTION',
"SCALA_SQL_INJECTION_SLICK",
"SCALA_SQL_INJECTION_ANORM",
"PREDICTABLE_RANDOM_SCALA"]
I'd like to know where to find a "table" that lets me know if a specific opcode is compatible with a specific version of the IBMi O.S.
Example:
LEAVESR introduced in V4R4
Is there anything like this?
This may be of use to you. This page is a list of operation codes available to the RPG compiler in IBM i 7.3. There is a dropdown towards the top that let's you select a different OS version.
This would allow you to compare operation codes between OS versions.
You can also use this What's New page to see every version back to V3R2.
I'm not aware of anything quite as specific as your question, but all elements are documented in a similar way in the ILE RPG Reference manual. The link is for ILE RPG for IBM i 7.3, but earlier releases have the same section according to the release. So, having just the latest gives you essentially the complete list of changes for all releases.
If you download a .PDF every few versions/releases, you can have a full history of "What's New" even if some future release truncates the section. If you think over the latest section, it should become clear that just having new op-codes isn't totally sufficient.
I was wondering if anyone can explain where and how comment documentation in Scala is applicable - in particular, the Eclipse plugin. For example, is there a way to comment a procedure, that might later show as a help-hint while using Eclipse? I'm not entirely sure how to get these Javadoc like effects when using Scala Eclipse. I've checked the various FAQs for the plugin, it's possibly not supported but I can't find an explanation either way.
You need to use Scaladoc, but it isn't supported completely yet.
ScalaDoc on hover/completion is not yet integrated in the Scala IDE.
The good news is that this feature is currently under development and we plan to have intial support for it in the coming months. A Pull Request for adding ScalaDoc in support in the Scala Presentation Compiler has been recently merged.
A Pull Request on the Scala IDE project will follow. You can track progress on this feature here
I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.
Where I work, we use mostly Java. We've always made extensive use of CheckStyle to enforce our coding standards for Java.
We're now branching out into Scala. Many of the same considerations as in Java apply (indentation/whitespace, naming conventions, ...) - and arguably having a consistent coding style is even more important given the power of the language.
However, there does not seem to be a Checkstyle equivalent for Scala.
Does anyone know of one?
Yes. It is called Scalastyle. (Same sort of focus as Checkstyle and findbugs). It's currently in version 0.2.0, we're adding rules all of the time
EDIT (Dec 2012):
Scalastyle 0.2.0 was released last month, with a total of 46 rules. There is, in no particular order:
A maven plugin
An eclipse plugin
An SBT plugin
Under development are:
An Intellij plugin
A sonar plugin
Contributions/bug fixes are always welcome: github.
For code formatting, you can use Scalariform.
It can be used standalone, integrated into an editor, or as an SBT plugin that runs it automatically before every compilation.
Codacy integrates Scalastyle (amazing work from Matthew) along with custom rules (like checking for Option.get() and warning you when you do them) and works as an improved Sonar for Scala.
Free for open source.
You also have abide from the Typesafe team and scapegoat from the makers of SCoverage.
There's sniff, which detect "code smells" based on regular expressions. It can be used as a Specs2 test, which is nice.