Community
Participate
Working Groups
I do not understand why wildcard imports are deprecated? Would it then be at least possible too specify a package import: import package org.foo The reason is that a a package is a module and just like you should not import part of a class you should not import part of a package. If there is a conflict, between packages it would be better to force the user to use the long name in his code highlighting the conflict.
It's merely for technical reasons and based on the assumption that the tooling takes care of managing the imports for you. What kind of conflict are you thinking of? Could you provide an example?
As an OSGi'er I believe in packages. When I use FooImpl.foo() I automatically get the type FooImpl, all members included. A package is very similar to a class, its members are just of a higher order: types. So when I use FooImpl(), I think all its siblings should be in scope as well. It is always very confusing to use for example ServiceReference (from org.osgi.framework) and then Version (from aQute.lib.version) since Version also is defined in org.osgi.framework. It would be really useful if conflicts always used the long name so you would never get confused. One of the most important simplifications in software is size: keep it small. I never understood why the huge lists of imports makes sense, just showing the packages makes it much clearer where your dependencies are since when you use one type of a package, you get it all anyway. So importing just a type is also confusing to me, the lists just get way to long. Since Eclipse and other IDEs have F3 there is also no reason anymore. Having import package org.osgi.framework Would help me (and OSGi by making developers more aware of what packages really are in Java)
Java packages are definitely not types. You could say however that they are named containers of classes and should therefore be referable, but unlike types they don't have a single definition. I think of packages more like namespaces, hence an import is a local alias which turns a long name into a local shorter name. And in fact it's implemented that way. That is Java types are entities we can refer to because they live in a single place. A package however is not referable since there is no single definition of it. I see your point about the confusion regarding types with the same simple name. But I don't think it's something which happens very often and is not easily avoidable. Given the technical problems we would have to fully validate wildcard imports, we decided to mark them as deprecated. So they work, but you don't get any static feedback of whether the import is used, or such a package exists. Because of the lack of validation and because the tooling can manage fully qualified imports well we decided to mark them as deprecated.
Can you argue why a package is not like a type? It has encapsulation, it is a local namespace, it exports (public) types, and it depends on types. How can I reason about default package access if package is not defined? You can even seal a package. Unfortunately the Java runtime does not support the package very well (though there is a Package class) but it is clearly the intention of the language to treat them as modules (look at the JLS intro) and not just a namespace that everybody can play in when they feel like it. The argument that a type is well defined is just as true/untrue for packages as for types. If I can modify a package I can also add a new private class to a class if I wanted to with some class loading hacking. Even methods is quite easy with weaving. I think you confuse the implementation of the language (class loaders, separate class files) with the language itself. In the JLS the package is a module and shares many aspects of types.
I already told you why we deprecated wildcards. It's not because I think packages are second class citizens but because the available technical infrastructure and the architecture we choose makes it hard and expensive to validate wildcard imports for existence and whether they are used. And given that the import section can be fully managed by the IDE (and be folded if you don't want to look at it), we decided to deprecate them. Is this just a conceptual issue for you as an OSGi'er or does it cause a real problem?
It is not crucial, it is just annoying to see the huge list of type imports when I really want to see on what packages I depend :-) Anyway, I close this bug
Closing all bugs that were set to RESOLVED before Neon.0
