Announcement

Collapse
No announcement yet.

Falcon: A New, Faster JIT Compiler For Java/JVM

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bug77 View Post

    If you have to worry about reflection, usually it's your code that needs a second look
    That's not true, there are valid reasons to use reflection. You just have to know when that is and when it shouldn't be used - in other words, be a decent developer.

    Comment


    • #12
      Originally posted by smitty3268 View Post

      That's not true, there are valid reasons to use reflection. You just have to know when that is and when it shouldn't be used - in other words, be a decent developer.
      I was hinting that if you've reached the point where you have to ask about its performance, you've probably used it too much.
      Legit reflection use cases are rare. Very rare.

      Comment


      • #13
        Originally posted by bug77 View Post

        I was hinting that if you've reached the point where you have to ask about its performance, you've probably used it too much.
        Legit reflection use cases are rare. Very rare.
        In performance sensitive code, yes. But i think there are plenty of cases where you might want to use it somewhere in an app, and it just so happens that you still want to AOT compile the app because other parts of it are performance sensitive. In fact, I'd always do that just to speed up the start time assuming it's possible, and it would be a shame if that automatically meant reflection of any type was no longer an option.

        Comment


        • #14
          Originally posted by smitty3268 View Post

          In performance sensitive code, yes. But i think there are plenty of cases where you might want to use it somewhere in an app, and it just so happens that you still want to AOT compile the app because other parts of it are performance sensitive. In fact, I'd always do that just to speed up the start time assuming it's possible, and it would be a shame if that automatically meant reflection of any type was no longer an option.
          But I don't think AoT inability to handle reflection means you can't use reflection any longer. Afaik reflection and code generation don't jive well with JiT either, but you can still use them.
          AoT seems to be working just fine for Android (ok, it's not entirely the same thing), so I'm not worried.

          Comment


          • #15
            Originally posted by bug77 View Post
            Considering Java 9 is only a couple of months away
            Well, maybe. True, it's currently scheduled for the end of July... but it *has* already been delayed several times (and by over a year), so even this close, I wouldn't be surprised if it slipped again.

            Comment


            • #16
              Originally posted by bug77 View Post
              Legit reflection use cases are rare. Very rare.
              You think so? I'd say it's one of the most heavily-used APIs in the Java world... and legitimately so. Dependency-injection frameworks depend on it. Most database persistence frameworks like JPA / Hibernate) depend on it. Proxy-based transaction management depends on it. Many of the UI frameworks like JSF or JSP depend on it. Many of the XML/JSON serialisation frameworks depend on it. You get the idea... for any kind of enterprise code, reflection is *everywhere*.

              Comment


              • #17
                Originally posted by Delgarde View Post

                You think so? I'd say it's one of the most heavily-used APIs in the Java world... and legitimately so. Dependency-injection frameworks depend on it. Most database persistence frameworks like JPA / Hibernate) depend on it. Proxy-based transaction management depends on it. Many of the UI frameworks like JSF or JSP depend on it. Many of the XML/JSON serialisation frameworks depend on it. You get the idea... for any kind of enterprise code, reflection is *everywhere*.
                That is all true. At the same time 99%+ of the Java applications aren't dependency injection frameworks or JPA or JTA implementations. If you get my drift.

                And a special giggle for mentioning JSP and JSF in 2017

                Comment


                • #18
                  Originally posted by bug77 View Post
                  That is all true. At the same time 99%+ of the Java applications aren't dependency injection frameworks or JPA or JTA implementations. If you get my drift.

                  And a special giggle for mentioning JSP and JSF in 2017
                  Clearly you don't do much enterprise development...

                  Comment


                  • #19
                    Yes, reflection is inherently slow and code using it can be rewritten to be faster. It's also flexible so you can find out faster if your great idea is a good idea. Some day there will be a language that, restricted and decorated, can compile down to templated c++ with stack allocation, but is as easy to write as javascript would be if it came with python containers. I keep expecting this out of Java and other JVM languages.

                    Comment


                    • #20
                      Originally posted by Delgarde View Post

                      Clearly you don't do much enterprise development...
                      Depend on your definition of "enterprise". But I do tend to keep away from gigantic projects where no one knows what's going on any longer.

                      Comment

                      Working...
                      X