Skip to end of metadata
Go to start of metadata

Packages are containers for classes, objects, functions and properties. A Kotlin package is something like a package in Java, but it is not tied up to any physical file-system entity.

Root package

Every module declares a unique root package, that contains all the packages declared in this module.

Header package declaration

A source file may start with a header package declaration (see the grammar):

package foo.bar 
 
// ...

All the contents of the source file are (directly or indirectly) contained by its header package. If the header is not specified, the module's root package is used.

Imports

Besides the default imports declared by the module, each file may contain its own import directives.

Syntax for imports is described here.

One can import either a single name, e.g.

import foo.Bar // Bar is now accessible withou qualification

or all the accessible contents of a scope (package, class, object etc):

import foo.* // everything in 'foo' becomes accessible

If there is a name clash, one can disambiguate by using as keyword to locally rename the clashing entity:

import foo.Bar // Bar is accessible 
import bar.Bar as bBar // bBar stands for 'bar.Bar'

Absolute and relative names

Consider the following example (syntax is fictional):

package a { 
  package b { 
    val x = 1 
    package a { 
      val y = a.b.x // Problem 
    } 
  } 
}

At the line marked "Problem" we have the following potential ambiguity: what does a stand for: the outer package a or the inner one? The rule here is that names are always relative: a is resolved in its scope of occurrence that makes it mean the inner package a, so this code does not compile.

To fix it, we need an absolute name. These start with the package keyword:

package a { 
  package b { 
    val x = 1 
    package a { 
      val y = package.root.a.b.x // Fixed 
    } 
  } 
}

In this example, we assumed that the root package of our module is named root.

Absolute names may be used in imports as well:

import package.root.a.b.a.*

What's next

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

17 Comments

comments.show.hide

  1. Jul 20, 2011

    Anonymous

    Why .root is added for namespace lookups? I think it would be more pleasant to simply write

        namespace.a.b.x

    1. Jul 20, 2011

      Andrey Breslav

      In the example, this is just the full name of the namespace: root.a.b.a.*, and if you start anywhere else, you may have ambiguities, e.g. imagine there's a module with a root namespace called a

  2. Jul 22, 2011

    Anonymous

    How about adding a way to import an entire namespace with an alias, for example like this:

    import foo.* as f
    import bar.* as b

    That way you could access the class Bar in both foo and bar using f.Bar and b.Bar, kinda like Go does it. 

    1. Jul 22, 2011

      Andrey Breslav

      If you say import foo as f, it does what you ask for

      1. Jul 22, 2011

        Anonymous

        YES! Excellent!

      2. May 23, 2012

        Vladimir Lichonos

        So, it's possible to make a cool thing like:

        import bla.bla.bla.bla.bla.a as mybla

        and then write, for example, mybla.MyClassFromBla ?

        1. May 23, 2012

          Andrey Breslav

          Yes

  3. Jul 23, 2011

    B. K. Oxley (binkley)

    I like the connection between filesystem and package structure in Java - it helps me navigate code on disk, and makes jar layout sensible.  What motivates Kotlin to go in another direction?

    1. Jul 24, 2011

      Andrey Breslav

      Mainly separation of concerns. Plus, in Kotlin, there can be many very short classes, that are very convenient to have in one file.

      1. Aug 24, 2011

        B. K. Oxley (binkley)

        In Java I do this already and follow the rule of only 1 public class per file.  When you say many short classes, what are they like?  Are they used outside the package/namespace scope?

        1. Aug 24, 2011

          Andrey Breslav

          By short classes I mainly mean data classes (e.g. bean classes), and they are used outside their declaration scope, of course.

  4. Aug 11, 2011

    Anonymous

    How do logical namespaces map to physical .class and jar files?

    Will there be a connection between namespaces and OSGi-type modules?

    1. Aug 12, 2011

      Andrey Breslav

      Namespaces roughly map to Java packages.

  5. Aug 11, 2011

    Anonymous

    I guess another way to phrase my previous question is: will any support be added to address Jar Hell?

    1. Aug 12, 2011

      Andrey Breslav

      Please see Modules and Compilation

  6. Feb 16, 2012

    lacroix1547

    You said "The Namespace is dead" but there is still two mentions to that on this page.

    1. Feb 16, 2012

      Andrey Breslav

      Fixed, thanks