Thank you, David and Tim. Before I ask you to go a bit more into detail, I wanted to add a few of my motivation points - everything is minor and I can live without it, but when choosing between wildcards and full import, I tend towards wildcards: - when writing junit4 test, every time I use a new assertXYZ, I have to switch to the imports add a * to the static Assert import and then go back to the code. - If we receive patches, the imports don't always match - using wildcards might help with it (yes, very weak point) - We used to have organize imports on save in the Eclipse settings, some day this vanished ... not sure why, I thought it's because of the keeping the order of the imports the same and to change less lines in the commit. If we decide to omit wildcards, I'd prefer to activate that setting again.
> It's much easier to debug that way ... I haven't noticed a difference in debugging in Eclipse - is there one? > and to ensure that I have the exact ones I know there are ambiguities - e.g. I don't like it, when similar classes have the same name (e.g. Shape) - but this is more an issue of class design. One could also argue in contrast, if the classes can't be imported uniquely with wildcards, there's something dodgy in their naming ... and we'd find out earlier, before users will notice it, as we can't control their namespace optimization > In the ooxml classes, it makes it easier to confirm that I'm triggering the > classes that we need downstream in ooxml-schemas for Tika. So there are cases where the ooxml-lite task is doing its job not correct? Would the classloader load all the wildcards? - this would be a definite no-go for wildcards. I could imagine, that it doesn't fetch indirect references (e.g. enum classes), but that would happen either way. Andi. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
