When you have code at the top level of a file named FileName.kt, Kotlin creates a class named FileNameKt by default. This is where MainKt comes from. However, you have Main.kt in a package named cinema, so you should use cinema.MainKt

Your options are: • either move your file Main.kt to a directory named "cinema" under the kotlin directory; • or run your application by clicking on the green arrow next to "fun main()" instead of trying to re-run the application from the Run dialog. The second option will recompile your file and will find the compiled class in the right place. But for the sake of code clarity, I would recommend the first option.

Just so you have the full picture, let me elaborate a little bit. On the JVM, functions cannot be top-level like in the Kotlin language - they all need to be part of a class. This is why, when you start a JVM program, you need to tell Java which class is the "main class" you want to run, meaning which class contains the

main()

method to call as the entrypoint of the program. Now, simple class names are not unique. To really identify a class, you have to tell Java the "fully qualified name" of the class, which is the name of the package in which the class is, followed by a dot, followed by the "simple name" of the class. When you declare the top-level

main()

function in Kotlin, the "main class" to use in order to run it will be the auto-generated class that contains the top-level declarations of the file. As Landry said, this generated class will have a simple name based on the file name (

Main.kt

->

MainKt

), and the package of this class will be the package declared in the file (in your case,

cinema

). So in your case, without a

package

line at the top of the file, the fully qualified name of the main class is really just

MainKt

, but with the

package cinema

at the top of the file, the fully qualified name of the main class is

cinema.MainKt

.

@Landry Norris, @Joffrey Ok, so under src I should have a folder for package name (cinema), and under that a file called Main.kt. So does this start with package cinema?

src->main->kotlin->cinema->Main.kt

So does this start with package cinema?

Yes, the folder hierarchy is a convention of the placement, but the important bit is the

package cinema

line at the top of the file. This must stay even when you put the file under the

src/main/kotlin/cinema

directory.

To keep things easy for another developer to understand, we generally match folder structure to package name. If I see foo.bar.baz.FooBar, I know to look in src/main/kotlin/foo/bar/baz/FooBar.kt

@Landry Norris there are 2 competing conventions for this. The first is the one we both follow (folders for all parts of the package), the other is what the Kotlin style guide mentions: no folders for the common part of all packages (the root package of the project). To be frank I tried omitting the root package a few times to try the convention, but there were some problems with IDEA so I just stuck to the usual java convention.

I guess I could see how that could be useful. I can’t imagine that working as well with tooling, though.

Probably going to regret asking but would you put any other files, apart from Main.kt, in the package folder?

You can definitely put multiple files in the directory of the package. Actually you should put all the files of the same package in that directory. By the way, if package line in a file doesn't match the subdirectory it lives in (in either of the 2 conventions above), the IDE will usually give you a warning on the package line. You didn't get a warning on

package cinema

in

src/main/kotlin/Main.kt

because this location matches the other convention.

OK, i think I need to get to bigger projects before fully understanding this. Are the other files for diferent objects?

Files are a way to group related things together. In Java, only a single public class can exist in a given file, which forced devs to use many files. In Kotlin, it's not mandatory, but you can still use different files to group different classes and top-level declarations as you wish

OK, I can see how this helps with version control.