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