Future Not Completed But Looks Like it Has











up vote
0
down vote

favorite












I am a Scala newbie trying to understand Futures. I typed in the following in the REPL:



scala> import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.ExecutionContext.Implicits.global

scala> import scala.concurrent.Future
import scala.concurrent.Future

scala> val m = Future(println("Message"))
Message
m: scala.concurrent.Future[Unit] = Future(<not completed>)

scala> Future(println("Another Message"))
res4: scala.concurrent.Future[Unit] = Future(<not completed>)
Another Message


In the first case I am assigning a Future computation to a variable m. I haven't called m yet but the Future actually produces the "Message" string output. But I also get a Future(<not completed>) message. What is going on here? Has the future completed or not? The string output tells me it has. Can somebody clear this up for me?










share|improve this question


























    up vote
    0
    down vote

    favorite












    I am a Scala newbie trying to understand Futures. I typed in the following in the REPL:



    scala> import scala.concurrent.ExecutionContext.Implicits.global
    import scala.concurrent.ExecutionContext.Implicits.global

    scala> import scala.concurrent.Future
    import scala.concurrent.Future

    scala> val m = Future(println("Message"))
    Message
    m: scala.concurrent.Future[Unit] = Future(<not completed>)

    scala> Future(println("Another Message"))
    res4: scala.concurrent.Future[Unit] = Future(<not completed>)
    Another Message


    In the first case I am assigning a Future computation to a variable m. I haven't called m yet but the Future actually produces the "Message" string output. But I also get a Future(<not completed>) message. What is going on here? Has the future completed or not? The string output tells me it has. Can somebody clear this up for me?










    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I am a Scala newbie trying to understand Futures. I typed in the following in the REPL:



      scala> import scala.concurrent.ExecutionContext.Implicits.global
      import scala.concurrent.ExecutionContext.Implicits.global

      scala> import scala.concurrent.Future
      import scala.concurrent.Future

      scala> val m = Future(println("Message"))
      Message
      m: scala.concurrent.Future[Unit] = Future(<not completed>)

      scala> Future(println("Another Message"))
      res4: scala.concurrent.Future[Unit] = Future(<not completed>)
      Another Message


      In the first case I am assigning a Future computation to a variable m. I haven't called m yet but the Future actually produces the "Message" string output. But I also get a Future(<not completed>) message. What is going on here? Has the future completed or not? The string output tells me it has. Can somebody clear this up for me?










      share|improve this question













      I am a Scala newbie trying to understand Futures. I typed in the following in the REPL:



      scala> import scala.concurrent.ExecutionContext.Implicits.global
      import scala.concurrent.ExecutionContext.Implicits.global

      scala> import scala.concurrent.Future
      import scala.concurrent.Future

      scala> val m = Future(println("Message"))
      Message
      m: scala.concurrent.Future[Unit] = Future(<not completed>)

      scala> Future(println("Another Message"))
      res4: scala.concurrent.Future[Unit] = Future(<not completed>)
      Another Message


      In the first case I am assigning a Future computation to a variable m. I haven't called m yet but the Future actually produces the "Message" string output. But I also get a Future(<not completed>) message. What is going on here? Has the future completed or not? The string output tells me it has. Can somebody clear this up for me?







      scala






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 8 at 11:14









      Mojo

      296




      296
























          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          A Future will start executing as soon as it is created (Depending on the ExecutionContext implementation and assuming resources are available for it to run.)



          The fact that you see your message printed to the console indicates your Futures have completed.



          Try the following and see what happens:



          Future{
          Thread.sleep(5000)
          println("Message")
          }





          share|improve this answer























          • That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
            – Mojo
            Nov 8 at 11:27










          • This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
            – Terry Dactyl
            Nov 8 at 11:28






          • 1




            @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
            – James Whiteley
            Nov 8 at 11:29








          • 1




            @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
            – James Whiteley
            Nov 8 at 11:38






          • 1




            Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
            – James Whiteley
            Nov 8 at 11:39


















          up vote
          1
          down vote













          It is completed, what you see Future(<not completed>) is just the `toString() from the Future.



          try:



          import scala.concurrent.ExecutionContext.Implicits.global

          val f = scala.concurrent.Future{
          println("Message")
          }

          println(f.toString())


          Future execute always eagerly.






          share|improve this answer





















            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














             

            draft saved


            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206620%2ffuture-not-completed-but-looks-like-it-has%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            2
            down vote



            accepted










            A Future will start executing as soon as it is created (Depending on the ExecutionContext implementation and assuming resources are available for it to run.)



            The fact that you see your message printed to the console indicates your Futures have completed.



            Try the following and see what happens:



            Future{
            Thread.sleep(5000)
            println("Message")
            }





            share|improve this answer























            • That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
              – Mojo
              Nov 8 at 11:27










            • This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
              – Terry Dactyl
              Nov 8 at 11:28






            • 1




              @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
              – James Whiteley
              Nov 8 at 11:29








            • 1




              @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
              – James Whiteley
              Nov 8 at 11:38






            • 1




              Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
              – James Whiteley
              Nov 8 at 11:39















            up vote
            2
            down vote



            accepted










            A Future will start executing as soon as it is created (Depending on the ExecutionContext implementation and assuming resources are available for it to run.)



            The fact that you see your message printed to the console indicates your Futures have completed.



            Try the following and see what happens:



            Future{
            Thread.sleep(5000)
            println("Message")
            }





            share|improve this answer























            • That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
              – Mojo
              Nov 8 at 11:27










            • This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
              – Terry Dactyl
              Nov 8 at 11:28






            • 1




              @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
              – James Whiteley
              Nov 8 at 11:29








            • 1




              @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
              – James Whiteley
              Nov 8 at 11:38






            • 1




              Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
              – James Whiteley
              Nov 8 at 11:39













            up vote
            2
            down vote



            accepted







            up vote
            2
            down vote



            accepted






            A Future will start executing as soon as it is created (Depending on the ExecutionContext implementation and assuming resources are available for it to run.)



            The fact that you see your message printed to the console indicates your Futures have completed.



            Try the following and see what happens:



            Future{
            Thread.sleep(5000)
            println("Message")
            }





            share|improve this answer














            A Future will start executing as soon as it is created (Depending on the ExecutionContext implementation and assuming resources are available for it to run.)



            The fact that you see your message printed to the console indicates your Futures have completed.



            Try the following and see what happens:



            Future{
            Thread.sleep(5000)
            println("Message")
            }






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 8 at 11:28

























            answered Nov 8 at 11:24









            Terry Dactyl

            1,073412




            1,073412












            • That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
              – Mojo
              Nov 8 at 11:27










            • This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
              – Terry Dactyl
              Nov 8 at 11:28






            • 1




              @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
              – James Whiteley
              Nov 8 at 11:29








            • 1




              @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
              – James Whiteley
              Nov 8 at 11:38






            • 1




              Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
              – James Whiteley
              Nov 8 at 11:39


















            • That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
              – Mojo
              Nov 8 at 11:27










            • This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
              – Terry Dactyl
              Nov 8 at 11:28






            • 1




              @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
              – James Whiteley
              Nov 8 at 11:29








            • 1




              @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
              – James Whiteley
              Nov 8 at 11:38






            • 1




              Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
              – James Whiteley
              Nov 8 at 11:39
















            That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
            – Mojo
            Nov 8 at 11:27




            That's a bit weird it starts executing after creation when I didn't even call it. I would have expected it to start executing when I call m in my example above.
            – Mojo
            Nov 8 at 11:27












            This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
            – Terry Dactyl
            Nov 8 at 11:28




            This link explains what is going on behind the scenes: beyondthelines.net/computing/scala-future-and-execution-context
            – Terry Dactyl
            Nov 8 at 11:28




            1




            1




            @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
            – James Whiteley
            Nov 8 at 11:29






            @Mojo m isn't lazy or a def. It will get computed when it is defined. If you want it to wait until it's called before it computes, pop it in a function or make the val lazy.
            – James Whiteley
            Nov 8 at 11:29






            1




            1




            @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
            – James Whiteley
            Nov 8 at 11:38




            @Mojo yeah it's the same with any vals. if they aren't lazy (or aren't defined as def m = ....), they will be read into memory as and when they are defined. Making a val lazy basically tells the compiler to not worry about working out its value until it is used later on - it might as well be a comment or new line as far as the compiler is concerned at that point (once it has found out that the val is lazy).
            – James Whiteley
            Nov 8 at 11:38




            1




            1




            Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
            – James Whiteley
            Nov 8 at 11:39




            Although as @TerryDactyl points out, different ExecutionContexts run differently so this isn't a universal rule. As far as scala.concurrent.ExecutionContext.Implicits.global is concerned though, you can assume it to be correct.
            – James Whiteley
            Nov 8 at 11:39












            up vote
            1
            down vote













            It is completed, what you see Future(<not completed>) is just the `toString() from the Future.



            try:



            import scala.concurrent.ExecutionContext.Implicits.global

            val f = scala.concurrent.Future{
            println("Message")
            }

            println(f.toString())


            Future execute always eagerly.






            share|improve this answer

























              up vote
              1
              down vote













              It is completed, what you see Future(<not completed>) is just the `toString() from the Future.



              try:



              import scala.concurrent.ExecutionContext.Implicits.global

              val f = scala.concurrent.Future{
              println("Message")
              }

              println(f.toString())


              Future execute always eagerly.






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                It is completed, what you see Future(<not completed>) is just the `toString() from the Future.



                try:



                import scala.concurrent.ExecutionContext.Implicits.global

                val f = scala.concurrent.Future{
                println("Message")
                }

                println(f.toString())


                Future execute always eagerly.






                share|improve this answer












                It is completed, what you see Future(<not completed>) is just the `toString() from the Future.



                try:



                import scala.concurrent.ExecutionContext.Implicits.global

                val f = scala.concurrent.Future{
                println("Message")
                }

                println(f.toString())


                Future execute always eagerly.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 8 at 11:28









                pme

                1,8901123




                1,8901123






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206620%2ffuture-not-completed-but-looks-like-it-has%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Schultheiß

                    Verwaltungsgliederung Dänemarks

                    Liste der Kulturdenkmale in Wilsdruff