8.2 SPLE: Approaches and tools
8.2.2 Annotative or negative approach
The annotative approach consists on having the code for all the features together and using some annotations with a particular syntax to delimit the code related to each feature. This way, in the moment of derivation of a product, the engine does not assemble or compose the features together but it does just the opposite, removing all the code related to the features that have not been selected.
The main advantage of using annotations is that the code produced by the SPL can be as good as the annotated source code is, without any added complexity imposed by the technique. That is, in the compositional tools we have reviewed, such as AHEAD or FeatureHouse, it does not matter how nice the code that implements the features is, because the derivation process will mess the final source code. In the annotative approach, the derivation process is not as intrusive and the quality of the annotated code is maintained in the final code.
However, in this case it is the code of the platform the one that is hard to read and maintain, specially if the annotations are undisciplined and complex
or the variability is implemented with fine-grained extensions [KAK08]. Fine-
grained extensions, or fine granularity variability, are points of variability that are implemented at the level of lines of code. That is, in the compositional approach one of the restrictions is that the developer can usually only implement variability at the method level, modifying the behaviour of a method depending on the selected features. In the case of the annotative approach, we do not have this restriction and variability can be applied at any level to the point we can even change a line of code depending on the selected features. This is a big advantage, but abusing this
kind of annotations only leads to the #ifdef hell [SC92]. Traceability is also hard
to maintain beyond the file-level, since the annotations take place at the different
8.2. SPLE: Approaches and tools 105
Preprocessors are the most popular alternative to implement a SPL following the annotative approach.
Preprocessors: CPP, GPP and GNU M4
CPP2 is one of the most common alternatives used by the industry [GLA+09,
JB09,PO97,SLB+10,TSSPL09,BRN+13] to implement SPL, even when there
are many works criticising CPP annotations [SC92,LST+06,SLSA13]. Annotated
code is prone to simple errors and makes type-checking and debugging process an arduous task, even when the developers try to maintain discipline for their
annotations [SLSA13]. However, recent research works are focusing on this
approach, trying to analyse the use of annotations [HZS+15,LKA11,LAL+10] and
to improve it [KAK08,FKA+13,KATS12].
One known downside when working with CPP is that only a few programming languages (C and variants, mostly) support these annotations. So, working on Java code annotated with CPP, for example, is tricky since the common code editors will not be able to check for syntax and grammar compliance. The same happens with JavaScript or CSS code annotated with CPP or any other kind of code not related
to the C family. There are code editors like FeatureCommander [FPK+11,FKA+13]
that facilitate working with CPP annotated code by colouring the different features, but still do not help solving this kind of issues.
GPP3 and GNU M44 are general preprocessors. That is, they are independent
of any programming language and mostly they provide the same functionality than CPP. Both of them allow custom delimiters so the annotated code does not interfere with concrete language IDEs or tools.
The downside of these alternatives is the difficulty of using them to implement a SPL, specially for our context, web-based GIS, because:
1. These alternatives are old software assets. CPP is the only that can still being installed and configured “easily”, but making GPP or GNU M4 work is really hard even in Unix-based systems. In any case, all of these tools are strange to the current development of web applications, and they cannot be easily integrated with the tools that are being used nowadays.
2. CPP annotations interfere with any IDE or compiler of any language code that is not based on C. GPP and M4 allow for the definition of customs annotations, but doing it requires a hard effort.
2https://gcc.gnu.org/onlinedocs/cpp/ 3
http://en.nothingisreal.com/wiki/GPP
106 Chapter 8. SPL implementation techniques & Scaffolding: state of the art
3. They are not designed to be used to implement SPL. They all lack of any variability managing beyond the simple annotations, and of course they do not validate the specifications of the products.
Antenna and Munge
Antenna5and Munge6are tools that enable conditional compilation on Java. That
is, they are similar to CPP but for Java. In fact, the annotations mimics the CPP syntax, but they are written in Java comments to not interfere with code editors. Besides, there are plugins for Eclipse to facilitate the use of them.
The big difference between the two alternatives is that Antenna comments out code annotated with features not selected, so the compiler omits it, while Munge acts like a proper preprocessor and the annotated code is processed to obtain code without annotations and ready to compile.
FeatureJS
FeatureJS [MSC+14] is the only tool we have found that is focused on the JavaScript
language, one of the most popular languages nowadays. We agree with the analysis
made by Machado et al. in [MSC+14] regarding the state of SPL researching and
tools for web-based applications: the domain of web systems is not often considered as a potential domain for developing SPLs, unlike other domains such as embedded systems or mobile applications, and most of the literature proposing new research
initiatives handling SPL for web systems [BRPD05,TBD07,PJ05,LGBH09,GG02,
FAB+13,CD03] are mostly concerned with modelling the variability at a high-level
abstraction but without doing the same at the implementation level.
FeatureJS mixes composition and annotations, but, as far as it is detailed
on [MSC+14], it does not provide any way of refining artefacts, so the compositional
feature is equivalent to annotating the whole JavaScript code file. Anyway, refining and composing JavaScript code does not seem feasible due to its own characteristics and its flexibility, as they also remark.
CIDE
CIDE [KAK08] is an eclipse-based IDE which annotates the features directly on
the Abstract Syntax Tree and shows the different features with different colours. CIDE appeared as a way to improve the legibility of the annotated source code to overcome some of the issues of fine granularity variability.
5
http://antenna.sourceforge.net/
8.2. SPLE: Approaches and tools 107
Using CIDE imposes an obvious IDE restriction, since it is based on Eclipse. Moreover, the last version available is built for Eclipse Galileo, from 2009, which does not support Java 8 syntax, among other things. Moreover, the community support for this version of Eclipse is minimum.