Announcement

Collapse
No announcement yet.

GCC Looks To Turn Off Java, Replace With Go Or ADA

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

  • #11
    Ah, I see. I red it that GCC plans to add support for Go, not to just enable it.

    Comment


    • #12
      Originally posted by peppercats View Post
      Does anyone actually use GCJ?
      That's my thought too. There's a bunch of talk about it being important prior to Java being open-sourced, but as a Java developer, I don't see it - we've never seriously considered it as an alternative to the at-the-time proprietary releases from Sun. If anything, it was more than a hindrance - with it being installed by distros, it tended to get in the way, causing $PATH confusion with the versions we actually wanted to use...

      Comment


      • #13
        If GCJ had actually supported the whole thing, it would've been useful: if for nothing else, to get proper binaries for open-source Java applications.

        The huge first-start lag of Java remains to this day.

        Comment


        • #14
          Originally posted by curaga View Post
          If GCJ had actually supported the whole thing, it would've been useful: if for nothing else, to get proper binaries for open-source Java applications.

          The huge first-start lag of Java remains to this day.
          Which applications you mean? Can you point the one that is OSS and runs better than OpenJDK? And where the startup time is so much improved that much, so will make no sense to go to OpenJDK?

          GCJ has an outdated profile (I'm almost sure it doesn't support 1.6, and certainly not Java 1.7, and the world goes soon into Java 1.8 with InvokeDynamic used in the language) , an outdated runtime (which has a very bad GC) so is really not a good option for the applications you say that are so good (by not using OpenJDK). I tried to compile more than two classes projects and I couldn't do it with GCJ. I didn't submit a bug because Java was a side task for me. But I am sure that even for Java developers was no interest. Even Google which has developers in GCC team and also has people interested in Java (as of Android) but GCJ is not interesting for anyone.
          The huge first-start lag of Java remains to this day.
          May you count this "huge", some real figures would be really nice? When I start Java applications they don't start slower than Visual Studio (which is written mostly in C++) or KDE applications in my Gnome environment.

          Comment


          • #15
            Can you point the one that is OSS and runs better than OpenJDK?
            They don't, that was my point. None of them even compile using GCJ.

            There are many FOSS Java apps that I would use if I could have native binaries. Jitsi comes to mind first.

            May you count this "huge", some real figures would be really nice? When I start Java applications they don't start slower than Visual Studio (which is written mostly in C++) or KDE applications in my Gnome environment.
            Sure. It takes five seconds on the machine I'm typing on to start Tilitin from a cold start. It's a light-weight accounting program.
            A larger delay is visible using FOP (7-8s), which is a XML-FO typesetter program. Those two are the only Java programs I have. Both behave better from warm caches, but that's irrelevant, as the complaint is about cold starts.

            VS is a terrible comparison, since the thing takes a minute to start, far longer than any Java app
            If KDE apps take as long to cold start as Java, KDE is doing something wrong.

            Comment


            • #16
              Originally posted by curaga View Post
              They don't, that was my point. None of them even compile using GCJ.
              There are many FOSS Java apps that I would use if I could have native binaries. Jitsi comes to mind first.
              (...)
              VS is a terrible comparison, since the thing takes a minute to start, far longer than any Java app
              If KDE apps take as long to cold start as Java, KDE is doing something wrong.
              In fact Idea starts much faster than big KDE applications from Gnome for me. The first startup. And the reason is: loading libs (even native) if are from an alien runtime (alien =being different from the environment is already running) starts much slower as a cold start. At least on my machine AmaroK starts definetly slower than Mono or Java applications (which tend to be Gtk based).

              I can say one application which runs much slower with Java than with it (LibreOffice with Java plugins), but I noticed many snappy Java applications. Also, as we both understand the Java tradeoffs, waiting/ignoring the first 5 seconds (the startup ones), Java runs really nice. Many Java applications are responsive and fast.

              Comment


              • #17
                Originally posted by AnonymousCoward View Post
                You didn't read the article, or did you?

                It's about "stressing the codebase", because languages like java use less used codepaths and so on.
                I didn't read the article. I read the mailing list which mentioned testing the feature could be done with a test unit instead an entire front end.

                So, like I said, better to just drop Java and leave it at that. Go and Ada has nothing to do with it.

                Comment


                • #18
                  Originally posted by Delgarde View Post
                  That's my thought too. There's a bunch of talk about it being important prior to Java being open-sourced, but as a Java developer, I don't see it - we've never seriously considered it as an alternative to the at-the-time proprietary releases from Sun. If anything, it was more than a hindrance - with it being installed by distros, it tended to get in the way, causing $PATH confusion with the versions we actually wanted to use...
                  Couldn't agree more. Now that we have openjdk, and with openjdk being the official java 8 reference implementation, I couldn't care less about gcj

                  Comment

                  Working...
                  X