我认为您应该避开代码生成模板。这里的问题是集合类的处理超出了正常的代码生成范围。如果一个类有一个成员,其类型是另一个包中的类,EA 会生成正确的导入语句 - 但前提是模型中存在这些类,而集合类不存在。
有三种方法可以解决这个问题:
1) 接受生成的代码已损坏。
生成代码,然后在 IDE(NetBeans、Eclipse 或您正在使用的任何工具)中打开它,让它在添加正确的导入语句时进行有根据的猜测。
这既快速又简单,但您需要检查结果。还有一个风险:如果你的“B”类导入了一个包含“List”类的包,编译器不会抱怨,但引用的“List”类不是来自 java.util 的那个,这意味着你'没有得到你认为你做的代码。
2) 对集合类建模。
创建一个包含子“util”和模板类“List”的包“java”,然后更改模型,以便 A 与此“List”类型具有“1”关系,而不是与 B 的 0..* 关系(不是 B),而是用类型 B 实例化的。正确的关系是模板绑定。
对集合类进行建模的方法是将 rt.jar 导入到您的项目中。不过,这需要很长时间,并确保禁用自动图表生成,否则可能会耗尽内存。但是您将一劳永逸地导入所有实用程序类。
如果您想安全起见,请从 Java 选项(工具 - 选项 - 源代码工程 - Java)中删除集合类,这样 EA 就不会尝试使用它们。但如果您更改所有关系,EA 将不会使用配置的集合类。
这会产生最正确的模型,并且还解决了如何引用其他实用程序类(例如日历)的问题,但是如果您有一个没有集合类的大型模型,则可能需要做很多工作。
3) 对集合类使用完全限定的名称。
在 Java 选项中,而不是List<#TYPE#>
输入java.util.List<#TYPE#>
. 如果类型由它们的完全限定名称引用,Java 编译器不需要 import 语句。
这是非常快速和容易的,并且生成的代码是正确的。缺点是代码变得有点笨重。
如果您只需要收集类来工作,我会选择这个。如果您想参考其他常见的实用程序类,我会说导入 rt.jar 并重新设计模型。