“Renew (The Reference Net Workshop) is an extensible Petri net IDE that supports the development and execution of highlevel Petri nets and other modeling techniques.” [3,10]. Renew allows to add Java inscriptions to elements in Reference nets, which leads to possible syntax errors. One important feature of an IDE is the instant feedback to the developer if syntax errors are detected. This enables the developer do deal with these errors at the moment they are entered and found rather than getting confronted with a large set of syntax errors at compile time. This paper presents the quick fix feature, which accomplishes this task of finding and displaying the error, suggesting possible fixes for that error and finally applying the fix automatically.
Many modern integrated development environments (IDEs) such as Eclipse [
In this paper, we define the quick fix in Section 2, outline our architecture of
this feature in Section 3 and discuss the evolutionary concept behind it during the
past development phases in Section 4. At last, we provide a detailed description
of our suggestion mechanism based on examples in Section 5. Moreover, we
illustrate, how this mechanism can be used as an auto-complete feature. The
practical usage of the quick fix is discussed in Section 6 while also pointing out
current limitations. After concluding, possible extensions and pursuing uses of
the quick fix feature are presented in the outlook in Section 8.
The American Heritage Dictionary describes the etymology of the quick fix as
follows: “An easy and quick repair or remedy, especially a hastily contrived
remedy that alleviates a problem only for the time being” [
In contrast to the refactoring [
Possible Fix
Use other constructor, use factory class
Use other method, change given
parameters
Use other field from same class or field
with that name from other class
Declare variable in declaration node
Change variable type or assignment
content
Create new import statement for class
found in classpath
seems very similar but the former is considered to be out of scope for this paper
and is dealt with in [
The typical process for the quick fix is illustrated in Figure 1: First, a syntax error has to be found and presented to the developer, so it can be addressed. Next, possible fixes have to be suggested. The developer can decide, whether there is a fix among the suggestions that alleviates the error and is semantically correct. If so, the fix needs to be applied to the current implementation, otherwise the developer can discard the suggestions and solve the problem on his own. If the developer considers the applied fix not to be appropriate, the fix can be undone, which reverts it to the starting point. In Section 3, we explain the architecture to implement this process in the context of Renew.
Depending on the defined grammar the parser is doing its work on, a variety of different syntax errors can occur. For Renew, we want to address the syntax errors listed in Table 1 using the quick fix feature. 3
Renew enables us to use Java code as inscriptions in Reference nets for
transitions, arcs and places. Furthermore, an additional figure, the declaration node,
contains Java import statements and variable declarations. These inscriptions
are not pure Java code but Java enriched with additional Reference net-specific
syntax (see [
Whenever a parsing of an inscription is triggered, e. g. after changing it or before a simulation process is started, syntax exceptions may be thrown by the parser or any back-end class and need to be caught and dealt with by the user interface. More precisely, a throw of this SyntaxException is the trigger for the quick fix. Each different trigger should comply with a different subclass of that exception and thereby provide the information on what suggestion mechanism should be associated with it. Moreover, the exception should hold detailed information about the error to enable contextualization of the specific suggestion mechanism.
Transferring this to Table 1, each row defines a tuple consisting of a trigger (column 1) and a suggestion mechanism (column 2). 4
In a very first approach, we developed a frame which would simply display the specific error message given by the parser. This is shown in Figure 2 and Figure 3 in the upper part of the dialog. In this example, this includes the corresponding line and column as well as the specific error message. This functionality implements step 1 of the quick fix process (see Figure 1). In addition to the error message, this information includes the specific figure, whose inscription contains the syntax error. The developer can find the originating inscription by pressing the Select button as seen in Figure 3. Especially in very large nets, this information helps to find the culprit quickly and understand, why the net cannot be compiled. Moreover, we added the option to trigger the syntax check manually by clicking a button in the IDE. This allows the developer to constantly check the net for errors while extending it incrementally. However, sometimes the messages generated by the generic JavaCC parser tend to be rather cryptic, especially regarding structuring errors, such as a missing closing bracket or semicolon.
A first improvement considers to add a list of possible expressions for a given syntax error. For example, a list of a class’ defined methods is presented to the developer if the parser cannot parse a given method call. This feature required a fundamental change providing the error message, because we need to include contextualized information about the net and make use of the Java Reflection API to determine the suggestions. The developer is now able to compare the implementation with the possible, correct alternatives and rectify it. As a result, we now supply the user interface’s error dialog with a detailed error message and an array of feasible fixes. This leads to automation of the second step of the quick fix process. A much more sophisticated suggestion mechanism is explained in Section 5.
The application of suggested expressions is an error-prone manual task, so we wanted to automate it, too. To achieve this, we need information about the precise location of the error’s origin in the source code. JavaCC generates tokenbased parsers, which are able to supply information about exceptional tokens and their location in the parsed text. This information can be used to add or replace source code in the implementation based on what has been entered already and which suggestion the developer chose to be applied. For example, if the developer tries to add values to a map, the following two expressions have to be treated differently: map.pt(key, value); map.add(value); In the first line, the developer seems to have made a typing error and forgot the u in put. In this case, we can leave almost everything as it is and just add the missing letter. In the second example, the developer tries to add a value to the map as if it were a simple collection. In this context, we need to alter the method name as well as the parameter specification, prompting the developer for an additional one. As this simple example demonstrates, the application of quick fix suggestions is not trivial and has to be specified precisely for each suggestion. The specification also has to support a parameterization, so the different contexts can be handled appropriately.
Every action the developer performs in the editor can be undone using Renew’s Undo operation. This also applies to the application of quick fixes allowing the developer to “preview” and undo it, if not satisfied.
As a result, we have automated nearly all activities of the quick fix process, except the decision for the correct fix among the suggestions. Considering this step, we support the developer by ordering the suggestions by relevance. In some cases, the suggestion mechanism is nearly sure, which suggestion is the right one, in other cases it is only able to provide a broad list. This is obviously dependent on what the developer has already entered and will be explained further in Section 5. 5
The first, trivial suggestion mechanism described in Section 3 is a bottleneck for our quick fix process, leading to a high number of Abort decisions due to missing suitable fixes. To address this, we introduce a much more sophisticated mechanism for Java class members (Subsection 5.1) and variable declarations (Subsection 5.2). 5.1
At first, we want to provide a suggestion mechanism for class members. In the Java world, this includes class fields and methods.
Considering fields, the choices consist of the declared and accessible fields for a denoted class in the source code. If an entered field is unknown, the quick fix can provide a list of fields using the Java Reflect API. However, this can lead to a lot of choices being presented to the developer, when the class defines a great amount of fields. In order to address excessive lists of suggestions, lists may be filtered to fields having the same prefix as entered by the developer.
Similar to the fields, methods can also be searched by using the Java Reflect API. Filtering the list of methods declared by a class may also be done by comparing prefixes. In addition to that, the entered parameters need to be considered when providing suggestions to the user. If the developer entered a method giving the wrong parameter types, the feature can suggest possible method overloads. An example of this mechanism is demonstrated in Figure 2.
This mechanism only considers available class members, which have been declared once in the source code. Generating missing class members the developer references in the net could also be a viable solution. However, we use an external Java IDE to manage and develop our Java source code. In that case, we would need an inter-process communication channel to propagate the required changes to that IDE. Furthermore, the changed source code would need to be compiled in order to be recognized by Renew, so that the syntax error disappears. We consider this to be too much effort in the current state of development. 5.2
Variables, that are used in the Petri net can be declared in Renew’s declaration node. If the net contains a declaration node with at least one declared variable, all used variables have to be declared. An undeclared variable causes the quick fix to suggest possible types for that variable and adding the corresponding statement in the declaration node.
When assigning a value to a variable, the value can either be a literal, a newly constructed object or the returned value from a method call. Determining the type in the first case is trivial, because the corresponding literal’s primitive type can be evaluated by the compiler immediately. An example of this is given in Figure 3, note that the corresponding package java.util has already been imported. To determine the type of a newly constructed object, the constructor’s class name has to be well-known, which means the class name is either fully qualified or an already imported class, as seen in Figure 3. Given the case of a well-known class name, the corresponding declaration statement can also be generated easily. Moreover, the information of a fully-qualified class name can be used to construct an import statement for that class or its whole package right away. The last case is also rather trivial, because the return type of a method and its corresponding class object can be determined using the Java Reflect API. 5.3
Without suggestions for Java class members, the developer needs to look up every used member in the API documentation. That would require one or more additional applications and their windows to be present in the developer’s working environment and tool set. On the one hand, the developer can fix typos or missing parameters etc. using the quick fix suggestions. On the other hand, the quick fix can change the workflow by providing an overview over the class’ members, if the developer enters an empty member name on purpose. Pursuing this approach, the quick fix can be used similar to an auto-complete feature regarding Java class members. For that purpose, we enable the possibility to use an underscore as a wildcard character in order to get a list of all fields or all methods by attaching a pair of round brackets as a suffix. An example of this mechanism is illustrated in Figure 4.
This approach is transferable to variable suggestions analogously considering this example (see also Figure 3): If the developer wanted to construct a new ArrayList and assign it to a variable called list, the assignment on a transition as well as a corresponding entry in the declaration node would be necessary. Now, the developer can specify the former as needed and omit the latter on purpose and let the declaration be automatically done by the quick fix.
In a nutshell, by providing the quick fix feature, we not only accelerate the development process by supporting the developer finding and fixing errors but also change the developer’s workflow while modeling Reference nets. We thereby streamlined the whole development process by enabling a much faster development in an integrated environment. 6
Due to Renew’s various different configurations and large number of plugins
available, the IDE is used in different contexts for many different purposes. For
example, one can use it as a process modeling tool such as creating the net seen
in for Figure 1, simulate basic P/T nets or even develop agent-oriented software
systems using the Mulan/Capa framework [
Developers, that use Renew in conjunction with Mulan/Capa in order to
develop multi-agent software systems, have to deal with a large number of
different ontologies, which in turn contain defined concepts (see [
As already explained in Subsection 5.2, suggestions for variable declarations can currently be inferred, if the right part of the assignment expression is parseable and the expression’s type is known. In particular, this is not true, if the type’s class has not been imported yet, even if it is available in the Java classpath. Supporting this depends highly on the ability to automatically import classes found in the classpath and let the developer choose from possible alternatives. Moreover, variables also occur in arc inscriptions. In this case, inferring the type requires an analyzation of other in- and outgoing arcs regarding the particular place or transition and its inscriptions.
The already mentioned IDEs Eclipse (using JDT [
Firstly, we provide a definition of the quick fix, that is already part of many
modern IDEs such as Eclipse [
Considering the architecture, we show that profound changes to the parser and UI were necessary to realize the implementation. We introduce an extensible architecture using Java exceptions with inheritance as triggers and the opportunity to incorporate arbitrary suggestion mechanisms.
The evolutionary concept behind the feature has been explained in detail in Section 4. Each step incrementally increased the usability of our IDE by providing automation of reoccurring tasks while also requiring precise specifications. Thus, we achieved an automation and support of most of the activities in the quick fix process.
In addition to that, using the quick fix as an auto-complete feature changes the development workflow by also providing a quick overview over the used API as discussed in Subsection 5.3. Thus, the quick fix not only accelerates the development process but also streamlines it in a way, that makes use of more integrated features in the Renew environment. 8
Currently, the triggers for the quick fix mechanism are based on syntax errors found by the net parser (see Table 1). Many common compilers differentiate between syntax errors and warnings, which for example indicate possible runtime errors. These warnings can also be treated using the quick fix analogously to errors while also indicating a lower severity.
Moreover, the extensible architecture allows us to define arbitrary triggers and corresponding suggestion mechanisms. Hence, the quick fix can support achieving not only a correct syntax but also arbitrary properties of the software system. For example, if the property of a cycle-free net is required, a detection algorithm can serve as a trigger for the quick fix while providing possible changes to break the cycle as suggestions.
Furthermore, the intent of “abusing” the quick fix suggestions as a quick overview over an API can be supported by extending the overview with additional documentation content. More precisely, a method suggestion can be extended by providing the corresponding Javadoc.
The current implementation provides quick fixes only for Java related problems. Since the used inscription language also contains Reference net specific syntax it should also be possible to provide fixes for respective errors. The parser is already capable of detecting erroneous syntax, but many problems can first be discovered during runtime. For example, the unifiability of a synchronous channel may fail as a result of a wrong channel name entered by the developer. Extending the quick fix for these kind of errors requires a different architecture and mechanism of error detection.