Restrictions and workarounds
· If the source file contains the sequence "]]>", the sequence will not be reversed correctly. This string corresponds to the escape characters for the string "]]>" that indicates the end of a CDATA zone in XML. To avoid the incorrect replacement of "]]>" by "]]>", use the following code: "]"+"]>"
· When a type declaration cannot be expressed in Objecteering, it is encapsulated in a {JavaTypeExpr} tagged value and the attribute, association or parameter type gets the undefined value. This {JavaTypeExpr} tagged value is not included in the signature of a method. Therefore, if an "m1" method is defined containing the only parameter which has a type that cannot be expressed (a JavaTypeExpr), the creation of a second "m1" method with only one JavaTypeExpr parameter will not be accepted by Objecteering. This situation, however, is very rare.
· The list of the imports generated from the model following a reversal might be too long. To avoid generating useless imports, check the "Use JavaImport note to generate imports" tickbox in the "Code generation" set of parameters. JavaImport notes are retrieved into the model during the reverse. They contain only the imports held in the original file. When this option is used, the JavaImport notes content is used to generate the imports instead of the links present within the model.
· Accessors are only filtered if the "Java/Generation/Generate accessor" and "Java/Reverse/Filter accessor" parameters have been activated.
· If a file does not contain a class with the same name as the file, the model is reversed correctly. However, at the next generation, the original name of the file is lost. To avoid this type of situation, make sure that the name of a file always corresponds to one of the classes it contains.
· Certain formats for comments are not supported. The following constructions must be avoided (bold comments show what to avoid):
· MyVariable = test((/*comment*/a+b)*(c+d));
· MyVariable = input[/*comment*/0]
· int[] Mon attribute /*comment*/;
· private static final String/*comment*/[]
MyVariable =
{
...
};
· private static final String [] MyVariable
/*comment*/= {
...
};
· if (a == 10
&& (/*comment*/
// comment
b>12
){
...
}
· public static final String
// comment
URL_1 =
"http://www.objecteering.com",
// comment
URL_2=
"http://www.objecteering.fr",
URL_3=
"http://www.softeam.fr";
public enum Week{
Monday /*comment*/,
Tuesday
// Comment
, Wednesday,
Thursday,
// Comment
Friday,
/*Comment*/ Saturday,
Sunday
}
When there is a single line comment at the end of file, the Reverse command will fail. To make the reverse succeed, add a return character at the end of the comment.
Example:
Replace:
...
} //comment<end
of file>
with:
...
}
//comment<return>
<end
of file>
Restrictions when reversing source files together with the Multi‑User MDAC - Addition of an "import" in the source file
Reversing a source file in which an element was added (import, implementation, type…) will not work if:
· the element used does not exist within the model
· the object to which the element is to be attached is in read only state
The following error message appears: "Error: xxxx cannot be modified" and the reversal is interrupted.
To be able to reverse the source file, a "Check-out" operation must be carried out on the object concerned by the error message. This will make the reverse operation possible.
Example:
1. The user is working on the "Test" class.
Figure 98. The "Test" class
2. Addition of the "import java.util.*" code within the "Tests.java" source file:
package Bank;
import
java.io.*;
import
java.util.*;
/**
* Test - class with main method
*/
public
class Test
{
3. Reverse of the "Test class:
Figure 99. Reversing the "Test" class
During the reverse, Objecteering will try to model the import of the "java.util" package by creating a "util" package within the "java" package. Since the "java" package is in read-only mode, the operation is impossible and the following message appears (Figure 100):
Figure 100. Error message indicating that the "java" package cannot be modified
4. The reverse failed. To be able to reverse the source file, the "Java" package must be checked-out.
Figure 101. Checking out the "java" package
5. It is then possible to run the reverse on the "Test" class (Figure 102).
Figure 102. Running the reverse on the test class (with the Java package checked out)
Note: In this example, if the "java.util" package had been part of the model, the reverse would have been successful at once, as Objecteering would not have had to create it.
The Multi-user "Update generation work product before check-in" parameter
When the "Update generation work product before check-in" Multi-user parameter is checked, the reversal of the Java file linked to the element on which the "Check-in" operation was applied is launched.
If the reversal is interrupted (for example, due to the restriction described above) the Multi-user operation in process will also be interrupted. The "Check-in" operation will be aborted and the lock file created at the beginning of the operation will remain in the repository.
To get round this problem, it is possible to unlock the repository manually by deleting the current user’ lock file in the lock directory of the Multi-user repository (//repositorylMU/Locks/currentuser.write) and to re-launch the command once the reversal problem has been worked around as described above.
We therefore strongly recommend that:
· the "Update generation work product before check-in" Multi-user parameter be unchecked
· the element to be checked in be updated using the Java Developer "Update" command
Note: In the particular case of the Eclipse plug-in, unchecking the "Update generation work product before check-in" parameter will not cause any problems, the code being systematically reversed by Java Developer each time the source file is saved.