Community
Participate
Working Groups
Annotation definition Record AS400Date type Annotation { targets=[ElementKind.FieldMbr, ElementKind.FunctionMbr] } ibmiFormat int = com.ibm.as400.access.AS400Date.FORMAT_CDMY; end external type definition externalType AS400Date type JavaObject{} static FORMAT_CDMY int; static FORMAT_CMDY int; end using the annotation: record Primitives/// dt1 date = "01/18/1962";//should generate the default dt2 date{@AS400Date{ibmiFormat = com.ibm.as400.access.AS400Date.FORMAT_CMDY}} = "01/19/1962"; end ibmiFormat int works for the initial value, but a validation error occurs when I use it on a record field. ibmiFormat fieldRef gives a validation error for the initial value but works when the annotation is used on a record. ibmiFormat any? doesn't give any validation errors, but the initial value is not passed to the generator.
If this defect should be resolved in 0.8.0, please set the target milestone to 0.8.0 or a specific 0.8.0 Iteration.
There appears to be a bug in the mof model code in InternalEObject.slotSet(EField field, Object value) Because of this bug, initial values for nullable fields are not being set when an Annotation object is created. A simple workaround for now is to change the definition to: Record AS400Date type Annotation { targets=[ElementKind.FieldMbr, ElementKind.FunctionMbr] } ibmiFormat any = com.ibm.as400.access.AS400Date.FORMAT_CDMY; end I am making a change to InternalEObject and will test to make sure it doesnt break something (obvious). Ideally, the annotation should be defined as: Record AS400Date type Annotation { targets=[ElementKind.FieldMbr, ElementKind.FunctionMbr] } ibmiFormat fieldRef = com.ibm.as400.access.AS400Date.FORMAT_CDMY; end But validation is not allowing this. We can keep this bug open until the validation rewrite is complete and address the problem at that time (if it still exists).
Paul, Can you clean this defect up based on comment 2? It sounds like there are 2 defects that were found: 1) A bug in InternalEObject, which you are working on 2) A Validation limitation that needs to be resolved in the future Assuming we can use this defect for #1, please adjust the title as necessary, set the Target Milestone, and resolve this defect when the issue is complete. Please create another enhancement for #2 and set the Target Milestone as either the 0.8.0 or Future.
I have opened Bug 368717 to track the validation error that is thrown when using a type of FieldRef for the annotation field. After talking to Joe, it seems that there may be another requirement. He wants an annotation field that can be initialized to a static field in an external type, but the annotation field should also support being a literal integer. I am resolving this bug. If changing the field to ANY works, then please close the bug (reopen otherwise). If there is a real requirement to have an annotation field that supports both an integer literal (int) and a member access (fieldRef), an enhancement bug can be opened for this.
verified
