What is the difference between
object Application extends App {
println("Hello World")
}
and
object Application {
def main(args: Array[String]): Unit = {
println("Hello World");
}
}
The App trait is a convenient way of creating an executable scala program. The difference to the main method altenative is (apart from the obvious syntactic differences) that the App trait uses the delayed initalization feature.
From the release notes for 2.9 (see http://www.scala-lang.org/old/node/9483 )
Objects inheriting the App trait instead make use of Scala 2.9’s delayed initialization feature to execute the whole body as part of an inherited main method.
Another new feature of the App scheme is that command line arguments are now accessible via the args value (which is inherited from trait App)
These two cases is not same on the scala scripting.
object extends App was not executed by "scala MyObject.scala" command,
but the object containing the main method was executed by "scala MyObject.scala" command.
Which was described as scala looking for object with main method for scripting.
When using REPL or scala workseet of Eclipse,
need to call MyObject.main(Array[String]()) explicitly for both cases.
This simple tip be helpful for beginner like me.
App trait is implemented using the [[DelayedInit]] functionality, which means that fields of the object will not have been initialized before the main method has been executed.
Related
What is the difference between
object Application extends App {
println("Hello World")
}
and
object Application {
def main(args: Array[String]): Unit = {
println("Hello World");
}
}
The App trait is a convenient way of creating an executable scala program. The difference to the main method altenative is (apart from the obvious syntactic differences) that the App trait uses the delayed initalization feature.
From the release notes for 2.9 (see http://www.scala-lang.org/old/node/9483 )
Objects inheriting the App trait instead make use of Scala 2.9’s delayed initialization feature to execute the whole body as part of an inherited main method.
Another new feature of the App scheme is that command line arguments are now accessible via the args value (which is inherited from trait App)
These two cases is not same on the scala scripting.
object extends App was not executed by "scala MyObject.scala" command,
but the object containing the main method was executed by "scala MyObject.scala" command.
Which was described as scala looking for object with main method for scripting.
When using REPL or scala workseet of Eclipse,
need to call MyObject.main(Array[String]()) explicitly for both cases.
This simple tip be helpful for beginner like me.
App trait is implemented using the [[DelayedInit]] functionality, which means that fields of the object will not have been initialized before the main method has been executed.
I'm struggling with running Scala Hello World project using IntelliJ IDEA Scala plugin. The project is created without any problems but when I create function which should be run, the run button doesn't appear. I've got no idea why it doesn't work.
Version of IntelliJ - 2020.3.1 (Community Edition)
Version of Scala plugin 2020.3.18
I've created Scala/sbt project (I'd also tried Scala/IDEA)
Vanilla options (but I'd also tried other versions of JDK, Scala and sbt)
The run button is missing
My code is:
class Hello extends App {
println("Hello world")
}
I've tried creating Scala worksheet and It works.
When you extend App, it needs to be as object Main extends App, not class Main extends App.
See Scala 2.13 specification 9.5 (emphasis mine):
A program is a top-level object that has a member method main of type (Array[String])Unit
The main method of a program can be directly defined in the object, or it can be inherited. The scala library defines a special class scala.App whose body acts as a main method
As Suma mentioned in his answer, you should use object, and not class. The code of the Hello file should be:
object Hello {
def main(args: Array[String]): Unit = {
println("Hello world")
}
}
As stated in YOUR FIRST LINES OF SCALA. Please note that if you prefer to extend App, all of the statements will be executed, as stated in the last link:
The argument of the scala command has to be a top-level object. If that object extends trait scala.App, then all statements contained in that object will be executed; otherwise you have to add a method main which will act as the entry point of your program.
Which means you have another option:
object Hello extends App {
println("Hello world")
}
I have created a gif that shows an example.
Hi I'm newbie in Scala.
As far as I know there are 2ways to make entry point in scala, one is define main method with object and the other is extending App trait.
I wondered how App trait works, so I checked the source for App trait, but there are full of confusing code...
The code said that the App has initCodes which are extended from App trait, and these are added in delayedInit method that inherited from DelayedInit. Also the App trait has main method, which will be entry point.
But the What confusing me are
Who call delayedInit? Is it called before the main method is called?(I guess Yes)
Why initCodes is ListBuffer not a element? I think there is only one entry point in application, so I don't think it should be plural.
Where can I check these knowledge? I tried to search in document but I couldn't
Who call delayedInit? Is it called before the main method is called?(I guess Yes)
The delayedInit would be called automatically by the Scala compiler as the initialisation code of the object/class that extends the DelayedInit trait. I expand more on this answer below.
Why initCodes is ListBuffer not a element? I think there is only one entry point in application, so I don't think it should be plural.
Because it is possible to have a hierarchy of classes, where the initialisation code of each class in the hierarchy gets executed as part of executing the program. An example is also provided below.
Where can I check these knowledge? I tried to search in document but I couldn't.
I got to learn about the dynamics by reading the Scala docs and the links it points to. For example this https://github.com/scala/scala/releases/tag/v2.11.0 and https://issues.scala-lang.org/browse/SI-4330?jql=labels%20%3D%20delayedinit%20AND%20resolution%20%3D%20unresolved
I would now try to expatiate more on the answer above by going into more details into the workings of DelayedInit, and how the JVM specifies entry points to programs.
First of all, we have to understand that when Scala is run on the JVM, it still has to adhere to the JVM requirement for defining the entry point to your program, which is to provide the JVM with a class with a main method with signature of public static void main(String[]). Even though when we use the App trait, it might appear as if we are getting away from do this, but this is just an illusion, the JVM still needs to have access to a method with the signature public static void main(String[]). It is just that by extending App together with the mechanism of DelayedInit, Scala can provide this method on our behalf.
Second, it is also good to reiterate that code snippets found in the body of a class (or object) definition, would be the initialisation code of such a class/object and would be executed automatically when such is instantiated. In Java, it is more or less the code you put in the constructor block.
So for a class:
class Foo {
// code.
def method = ???
}
Whatever code is, it will be executed automatically when you call new Foo.
In case of an object
object Foo {
// code.
def method = ???
}
The code will be executed automatically without you having to call new since Scala would automatically make a singleton instance called Foo available for you.
So basically if anything is in the body definition, it gets executed automatically. You do not need to explicitly execute it.
Now to the DelayedInit trait. One thing to be aware of is that it provides us a mechanism to perform what can be called a compiler trick, where certain part of our code gets rewritten. This is one of the reason why it could be confusing to reason about. Because when you use it, what actually gets executed by the Scala compiler is not the code you reading but a slight modification of it. To understand what is going on, you then need to understand the ways the compiler alters the code.
The trick, the DelayedInit trait allows us to perform is to take the code that is part of the body of a class/object definition and turn it, into an argument that is passed by name, to the method delayedInit defined on DelayedInit.
Basically it rewrites this:
object Foo {
// some code
}
into
object Foo {
// delayedInt({some code})
}
This means instead of having // some code executed automatically, delayedInt is the method that is called automatically with // some code passed to it as arguments.
So anything that extends DelayedInit would have its initialisation code replaced by the method call delayedInt with the initialisation code passed as an argument. Hence why nobody needs to explicitly call the delayedInt method.
Now let use see how this then tie to the App trait and how the App trait is used to provide the entry point to a Scala application.
As you will notice, the delayedInit method on the DelayedInit trait does not provide any implementation. Hence the actual behaviour of delayedInit when it is called needs to be provided by something else that extends DelayedInit.
The App trait is such an implementation. And what does the App trait do? Two important thing related to the topic of discussion:
It provides an implementation of delayedInit which takes the initialisation code it is passed, and puts it in a ListBuffer.
It provides the main method def main(args: Array[String]) which satisfy the requirement of the JVM to have a method with public static void main(String[]) to serve as the entry point to a program. And what this main method does, is to execute whatever code placed in the ListBuffer.
The above characteristics of the App trait means that any object/class that extends it would have its initialisation code passed to delayedInit, which would then add it into a ListBuffer, and then the object/class extending it would now have a main method, which when called (most of the time by the JVM as the entry point) would run through the code in the ListBuffer and execute it.
Basically it turns this:
object Foo {
// some code
}
into this
object Foo {
// the implementation of delayedInt is to put `// some code` into a list buffer
delayedInt (// some code)
def main(args: Array[String]) = {
// the implementation below just runs through and execute the code found in list buffer that would have been populated by the call to delayedInt and
???
}
}
So why have a List buffer to store the code to be executed? Because, as I said above it is possible to have a hierarchy of classes, where the initialisation code of each class in the hierarchy gets executed as part of executing the program. To see this in action.
Given the following code snippet:
class AnotherClass {
println("Initialising AnotherClass")
}
trait AnotherTrait {
println("Initialising AnotherTrait")
}
trait YetAnotherTrait {
println("Initialising YetAnotherTrait")
}
object Runner extends AnotherClass with AnotherTrait with YetAnotherTrait with App {
println("Hello world")
}
When run would output the following:
Initialising AnotherClass
Initialising AnotherTrait
Initialising YetAnotherTrait
Hello world
So the individual initialisation code in the hierarchy that consists of AnotherClass, AnotherTrait and YetAnotherTrait gets added to the initCode list buffer, via the delayedInit method of the App trait, and then they get executed by the main method also provided by the App trait.
As you would have noticed by peeking into the source code, the whole mechanism of DelayedInt is deprecated and schedule for removal in the future.
delayedInit:-
The init hook. This saves all initialization code for execution within
main. This method is normally never called directly from user code.
Instead it is called as compiler-generated code for those classes and
objects (but not traits) that inherit from the DelayedInit trait and
that do not themselves define a delayedInit method.
App scala
delayedInit is deprecated since 2.11.0. Also, it has some outstanding bugs which are not fixed.
initCodes:-
I am not sure about the reason for defining the initCodes as ListBuffer.
Now i understand how my program runs after extending App trait .I went through this link to understand how App trait works . In the link it is mentioned that by extending App trait we are achieving lazy evaluation . Why i would need lazy evaluation ? How lazy evaluation better than direct call to main() instead of extending App trait ?
I think it's the other way around: we don't need lazy eval, but we use it behind the scenes because that's the only way to implement it. From the scaladoc:
The App trait can be used to quickly turn objects into executable
programs.
By using App trait you avoid the boilerplate of writing:
object MainApp {
def main(args: Array[String]): Unit = { ... }
}
There is no way to achieve this syntax: object MainApp extends App {...} with regular means because you would have to override main method to call your code. Thus you can use compiler trick with DelayedInit which will turn your object body into a function call which will be called from main - this is the way to connect your code to the main entry point.
The caveat mentioned by scaladoc is:
It should be noted that this trait is implemented using the
[[DelayedInit]] functionality, which means that fields of the object
will not have been initialized before the main method has been
executed.
which for me personally is a preferred way of doing things. This, in contrast, is different from static initializers in Java that are executed before main method is called.
My Scala version:
Scala code runner version 2.9.0.1 -- Copyright 2002-2011, LAMP/EPFL
Given this code in a file named Static.scala:
object Main extends App {
val x: String = "Hello, World!"
override def main(args: Array[String]): Unit = {
println(x)
}
}
When I run:
scalac Static.scala && scala Main
I see:
null
instead of:
Hello, World!
I thought that x was a static because it was defined in an object, and that it would be initialized prior to the main method being called.
What am I doing wrong? Thanks!
This happens because of how you used the App trait. The App trait uses the DelayedInit feature which changes how the class body (including field initialization) is executed. The App trait includes a main method which executes the class body after binding the args field to the arguments to the program. Since you have overridden main this initialization is not happening. You should not provide a main method when using the App trait. You should either put the application code directly in the class body or not inherit from the App trait.
Try
lazy val x = "Hello World"
That should give you the results you're expecting.
You are not support to have a main method on an object extending App. If you do override it, you'd better understand how, exactly, DelayedInit works. In particular, objects extending App do not have static initialization -- that's the whole point of App.