Category: Code generation
Why were so many proxy types generated?
That's probably because you have not yet completely mastered the best way to compose the set of types that the code generator should generate. For the sake of argument, we will assume that you simply imported several jar files, containing the API that you're interested in as well as support types. You did this because the code generator always complained about missing types when you only imported the jar file that you really care about.
When you do this, the code generator interprets the import of the jar files as an instruction to enable all contained types as proxy type code generation. This can saddle you with thousands of proxy types and might of course be exactly the right thing if you need to publish all these types to an other language. If this is not what you wanted, you can selectively disable types that you don't need in the code generator GUI. You can do this by type or by package by right-clicking on an element in the tree view and deselecting Generate. That can be a lot of work if there are lots of types involved.
Here's what you should have done instead:
- Run the code generator with all jar files on the classpath.
- Import select types and/or packages by name.
Please note that the code generator is really smart about the types that you need but it can only interpret your gestures and not read your mind. As far as the code generator is concerned, there is a big difference between importing a jar file and putting a jar file on the claspath. Having the jar file on the classpath allows you to explicitly specify the types you're interested in. Importing the jarfile tells the code generator that you're interested in all types in the jarfile.
Also note that you should never, ever import rt.jar or any jar files from a JRE directory. rt.jar and its siblings contain the so-called built-in Java types and the code generator has access to them via the JRE library directory that you specified (or picked up by default) when the model was created.