This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Steps to reproduce: - Put a Class element on a diagram and name it 'MyClass' - Insert 'private Runnable a' attribute into the Class element - Generate code for the element The generated code has 'import Runnable;' import. -------------------------------------------------------- package pack; import Runnable; public class MyClass { private Runnable a; public MyClass() { } } -------------------------------------------------------- The code is not compiled: -------------------------------------------------------- UMLProject1Sources\src\pack\MyClass.java:3: '.' expected import Runnable; 1 error BUILD FAILED (total time: 0 seconds) --------------------------------------------------------
can't reproduce in ide-coco-061101_7 imports are now not generated for classes from for java.lang.*;
The key requirement is to create Class element inside package. In this case uml will create datatype in root and will generate import statement because datatype and class elements are in different packages.
I just tried this on Buzz where the import statement was not generated in Buzz. Trying using coco build 061117_6, the import statement was generated and code is not compilable. So, this is a regression from Buzz.
Not sure what to do here. If the datatype element in the UML project is physically located in the default package and not in the java.lang package (or any other appropriate package), then Generate Code is just following orders, albeit, blind and stupidly because you really can't import from the default package. So I guess if the element is found in the default package, then generating its import statement should be ignored because this is not supported by Java. And if the element truly does belong in the java.lang package, it will work fine, but if the element is from any other package, then there is potential for the proper import not being generated, but that's OK, because there is the fault of the model, not the Generate Code action.
Confirmed that if an element that truly belongs in the java.lang package, but its element (datatype or class or interface, etc) lives in the default package (directly under the Model node) in the model, then it's import statement is not generated, and the code remains compilable. But if the datatype/class/etc is under the Model node in the model project, but it is not a valid type from the java.lang package, an import will still not be generated, but the generated code will not be compilable. Two possible paths of action: 1) Prevent elements from be created in the model's default package (under the Model node). 2) Allow elements to be generated there, but warn that code will not be generated for them. In either case, if the type is recognized as a valid type from the java.lang package, perhaps a dialog should ask if the modeler would like the element to be placed in java.language package in the model. This could be a global option that the modeler can indicated to "Always" do this or "Ask" to do this. Also, would have to based on a particular/specified Java platform (JDK 1.5, 1.6, etc) which should be a property of the UML Project, but is not yet (see issue 82529 for details). iTeam should discuss the best actions to take in the next release.
verified
Reproduced in build ide-coco-061128_11-ml.zip It is a regression from build ide-coco-061127_12-ml.zip The generated code for a class element is: ----------------------------------------------------- package pack; import int; import Runnable; public class MyClass { private int a; private Runnable b; public MyClass() { } // set and get methods here } -----------------------------------------------------
see also issue 75643 UML adds invalid imports to Java source files which is in RESOLVED/LATER state.
This is specific to method parameters. The param types were not being put through the same tests for "import-ability" as types for attrs and return types, but now they are.