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.
Original submitter: sunflower Description: Steps to reproduce: - Create a class element and name it 'MyClass' - Insert attribute 'private Object myAttribute' into class element. 'Object' class element appears under 'Model' node in the UML project. - Drag and drop 'Object' class element on diagram. - Draw 'Generalization' link from 'MyClass' to 'Object' class element. - Build the project. The project is not compiled because of 'Object' is not correctly imported: pack\MyClass.java:3: '.' expected import Object; 1 error BUILD FAILED (total time: 0 seconds) =================================================== package pack; import Object; public class MyClass extends Object { private Object myAttribute; public MyClass() { } public Object getMyAttribute() { return myAttribute; } public void setMyAttribute(Object val) { this.myAttribute = val; } } ===================================================
Reivew: bug is as reported. This is common issue with all the well-known Java object types. For some reason, they are added to the default package, and sometimes even duplicated in the proper package (like java.lang) but not removed from the default package. This will also happen when source code is modified and the import statement is generated after the model has been updated.
This is working as designed. When you create the "Object" class in the root of the tree, how are we suppose to read the users mind, to know that was suppose to be "java.lang.Object". We have to assume, that the user want to create a new class in the default package. So, that is what we do. As far as putting the import statement into the file. If you create a Class named "Foo" and put it into the default package. Then you create a package named "bar" and put a class named "Sue" into "bar". Now make "sue" extend "Foo". You will get an error and the hint want to import "Foo". The import created by the hint, is the same as we will create, and it will not compile.
In this case, you should put the "Object" class in a "java", "lang" package structure.
The UML must not to generate uncompilable java code in any case.
Garbage in, Garbage out. If the user does not give us valid information, we can not generate valid source code. A class that is in a package, can not reference a class in the default package. That is now a compile error in java. Therefore, even if we did not put an import statement, we will get a compile error. The java editor has the same problem. Matter a fact we are using the same import manager to generate the import statement. So, if anything you should create an issue against the editor team.
Please, carefully read the summary of the bug. The problem is not that user creates his class under default package. The problem is that UML module puts the java.lang.Object class under default package. It is a bug of course that if anybody uses the 'Object' datatype which was generated by the UML module then java code is not compiled. You need to fix the problem. For example do not put the 'Object' datatype under the default package or do not insert import into javcacode if Object is from default package.
Yes, but UML is not and should not be Java centric. If we are Java centric will will start to run into problem when we start to support languages like C++ and VB. Therefore, we can not assume that Object means java.lang.Object. The correct solution is to support libraries, which we have an RFE for already.
this issue actually consists of several issues: issue 79526 - custom type datatype is generated in default package enhancement issue 85705 - objects from java.lang package should be created as datatypes in appropriate package issue 85702 - imports generated in java src are different for diffrent object usages
The issue was divided into three issues.