Xsemble new version 3.3.0 is a strategic update over its precursor 3.2.2. The majority of improvements that it contains are at in the generated component template code. The first one is more noteworthy as it can ease the static code analysis, helping programmers catch code level problems before manual analysis.
Encouraging Static Code Analysis
Good programmers use static code analyzers (also called the linters) to invite attention to potential problems in the code. We made several improvements to the generated code templates, so that they are aligned to SonarLint, a popular static code analyzer. Although the generated code as per the previous versions was correct in the functionality, making the linting errors go away reduces the noise; and a programmer can quickly find potential problems with the component code being reviewed.
As an example, consider that corresponding to in arguments of components (say “name”), the Java variable created would have “_in” suffix (as in “name_in”). But SonarLint complains about the underscore. Now, disabling the rule is possible, but that would also make invisible any such occurances in other handwritten code. Therefore, we changed the conventions –prefix with camel case. With the new version, the variable corresponding to the in argument “name” would be “inargName”. SonarLint does not complain about this.
We believe that these changes would encourage developers to use static code analysis to improve the code quality.
For now, these improvements have been done for the Java technologies for all 3 supported platforms:
- Java EE
- Jakarta EE
- Spring boot with MVC
They have also been made for PHP technology.
Specific improvements in the generated code are:
- Small case names of package names
- Camel case names of classes and variables with no underscores (latter only for Java code)
For now, we have focused those changes to the generated code templates where the developers would add their code. The glue code that gets auto-generated by Xsemble is not changed yet, but it does not matter to the programmers because their changes do not depend on it. Thus, as long as they write code compatible with the new templates, they are good.
These changes are done in a fashion that backward compatibility is not broken. Thus, your Xsemble artefacts created using earlier versions of Xsemble continue to work without any change with the new version.
However, if you want to take advantage of being more aligned with the linter, then you can merge the new templates with the new code. This can be done automatically or manually, depending on your setting on the specific implementation.
Primitive Types
The default implementation of the simple types defined in X.Core library has changed to use primitive equivalents as opposed to their Object equivalent, wherever applicable. There are 8 primitive types defined in Java, and using those directly means better performance.
We have tested that existing projects work without any change –even though they may not be using these primitive types– thanks to the boxing/unboxing feature inbuilt in Java. Any components created with this version or later will automatically use primitives. Thus, this is also a backward compatible change, introducing an improvement for the future.
Glossary Page
We have added a new glossary page to the Xsemble reference guide. This reference guide is included in the distribution. (Press F1 with any of the Xsemble tools to open the documentation.)
This glossary page lists 48 terms that are specific to Xsemble. It will certainly aid in understanding Xsemble.
