Announcement

Collapse
No announcement yet.

A Developer Hopes To Restore GCC's Java Front-End

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

  • #11
    Originally posted by caligula View Post

    Fwiw, many of the old gcj compiled programs weren't compatible with openjdk. Also the performance was crap. The only advantage here is that gcj is able to compile faster than native image.
    In what way were the programs incompatible with OpenJDK? I stayed clear of Java after graduating from college with one very minor exception, but I was under the impression that compatibility issues were solved after Sun released OpenJDK under the GPL, which should have resulted in GNU Classpath being retired for OpenJDK.

    Poor performance would either be from inefficient algorithms in GNU Classpath or bad assembly code generation in GCC. The former would have been solved by adopting OpenJDK while the latter likely could be fixed with improved middle end optimization passes. Actually, I guess there is a third category, which would be the garbage collector design used by GCJ. I have no knowledge about it, but that is an area where GCJ likely could be improved.
    Last edited by ryao; 07 January 2023, 07:39 PM.

    Comment


    • #12
      Originally posted by Jonjolt View Post
      Bad idea, they need to not make reference to Java, JVM, or JDK. They can do whatever they want there are other implementations who have not paid for a TCK license, but they made sure to leave those names out.
      This is a little bit more complex. End will make that clear.

      Originally posted by ryao View Post
      What about Apache Harmony?
      Development is dead. And most likely stay so. Harmony stopped development in 2010.

      Originally posted by ryao View Post
      The extent to which Oracle has been able to abuse the legal system over Java has been ridiculous. Google was able to protect itself from the nonsense by dropping Apache Harmony for OpenJDK, but it should not have had to do that.


      Most people don't look at the OpenJDK license and notice its the GNU Classpath license this oddity exists for a reason. OpenJDK comes about due to another legal case when Sun promised in legally binding documents to release Java under GPL then decided to not do this for quite some time yes those documents go back in the 1900s. That failure to deliver lead to the create of Apache Harmony in 2005. Sun could not do anything about Harmony usage or copyright infringement while they had a document saying SUN would release Java GPL and they had not since Apache Harmony was only providing what Sun was not delivering. This leads to SUN rushed license choice. with the 2007 OpenJDK release(yes rush took over a year to audit the code to release). Yes also those early promises meant SUN would never be able to do anything against GNU Classpath other than directly compete with it and beat it that way.

      SUN after OpenJDK release did have money for legal actions but could be uncooperative. SUN acquired by Oracle in 2010 then legal action SUN legal looked at taking to stop Harmony back in 2005 against Harmony kicks back into life this time promise had been fulfilled leading to Harmony stopping dead when Apache is told absolutely they are never going to get license that allows Apache license in 2010 and google being in the cross hairs. Fun of being acquired all companies considered legal actions get reviewed.

      Google with Android just had really bad timing.

      ryao it simple to miss that early Apache Harmony could legally get away with breaking copyright law in places because SUN was breaking law because they had promised to open source the Java code under GPL and they had not.

      https://en.wikipedia.org/wiki/Apache_Harmony yes 2007 just before the release of OpenJDK the people at Apache foundation were 100 percent sure they would have to get license from SUN to allow the Apache license on Harmony. SUN never gave that then Oracle said absolutely no. Yes if Apache had got that license that the copyright problems in Harmony would have been resolved.

      Google using Harmony in Android you could say was lack of due diligence there are problems with Harmony copyright are known before Android starts. Of course at that time SUN did not have the money to follow up on it. Oracle had the money to follow up on these issues leading to the Google vs Oracle cases.

      ryao there is a quite a number promises SUN had failed to keep so allowing Harmony to exist as a tainted project. Yes the old saying here two wrongs don't make a right really apply. SUN did something wrong and the harmony project did stuff wrong both had to pay for what they had done.

      ryao lot of people claim Oracle abused the legal system. Oracle had the money to push the legal system to end but they did not really abuse the system. Apache Harmony was known to be legally questionable by the Apache Foundation before Oracle turns up. Apache Harmony was also classed as legally questionable by SUN back in the day as well. Only one party that might not have known it was legally questionable was Google the party getting caught in the court room mess.

      To know that Harmony was legally questionable you need to be sitting on "Java Community Process Executive Committee" or "Apache foundation closed meetings" records of old meetings of that as in early 2007 though to 2010 are clear that Harmony is questionable. Google was not part of this committee and those meeting records for a long time were not public record yes google is in court before they are on the public record.

      Comment


      • #13
        Originally posted by ryao View Post
        In what way were the programs incompatible with OpenJDK?
        As of October 2010, is GNU's Java compiler dead? Are there any active alternatives (especially for compiling Java to native code)? LLVM solutions would be preferred.


        GCJ uses CNI instead of JNI. There's also a new FFI that is supposed to replace JNI.
        Nowadays, there are new problems. Almost every Java release has introduced new bytecode constructs and language features. Supporting all the new features requires tons of work.

        I was under the impression that compatibility issues were solved after Sun released OpenJDK under the GPL, which should have resulted in GNU Classpath being retired for OpenJDK.
        GCJ does not support OpenJDK https://stackoverflow.com/questions/...njdk-libraries

        Poor performance would either be from inefficient algorithms in GNU Classpath or bad assembly code generation in GCC. The former would have been solved by adopting OpenJDK while the latter likely could be fixed with improved middle end optimization passes.
        This has some info https://lwn.net/Articles/130796/

        I guess there is a third category, which would be the garbage collector design used by GCJ. I have no knowledge about it, but that is an area where GCJ likely could be improved.
        Yes, the G1 GC and ZGC are "somewhat" more efficient than Boehm GC. Some say they're two the most advanced GCs ever built.

        Comment


        • #14
          That would be actually pretty cool. I know it is not that usable for most people, but it would allow for some fun tricks. I hope something works out.

          Comment


          • #15
            Originally posted by caligula View Post
            Yes, the G1 GC and ZGC are "somewhat" more efficient than Boehm GC. Some say they're two the most advanced GCs ever built.

            Having this in a polished open source package sounds like Boehm GC sounds a better option than GCJ.
            Also a Dlang library that replicates most Java functionality could also be a target (and possibly exportable for C like consumption)

            Comment


            • #16
              Originally posted by ryao View Post

              What about Apache Harmony?

              https://harmony.apache.org
              Not sure if you have seen the giant red banner saying its been retried for more than a decade on the site, this proposal will also suffer the same fate.

              Comment


              • #17
                Originally posted by theuserbl View Post
                And after gcj, reactivate DotGnu (https://www.gnu.org/software/dotgnu/).
                While dotnet core tooling is worse in 6.0 than 5.0, it's still very usable.
                I don't feel anyone would find dotgnu worthy of their time even for just building a personal portfolio as a developer. GCJ might be better for opportunists.

                Comment


                • #18
                  Originally posted by mdedetrich View Post
                  Not sure if you have seen the giant red banner saying its been retried for more than a decade on the site, this proposal will also suffer the same fate.
                  No red banner and the decade without development is not the major problem.


                  2010 when Apache resigns from "executive committee of the Java Community Process (JCP)" over a licensing issue that cannot be resolved.

                  Maybe October 2010 when IBM stops developing Harmony over the license issue.
                  Maybe the fact SUN in 2007 refused Apache Harmony for license to cover Apache licensed implementation.
                  Maybe the fact Apache Harmony started in 2005 because SUN had not upheld legal written promise/contract so in that time frame 2005-2007 could break copyright law without SUN being able to-do anything due to SUN breach of contract.

                  The fact Apache Harmony was from 2007-2010/2011 basically zombie walking that Apache foundation hoped they could convince SUN/Oracle to give them a license to fix the problem is one of the things that screwed google over in the Google vs Oracle case..

                  Apache Harmony to put Startrek to it "He's dead, Jim". There is no way to bring Apache Harmony back in most likely our life times. Apache Harmony like it or not is just a tainted unusable code base. Cleaning Apache Harmony of it taint problem is either get Oracle or who have the Java core license to license it or fight that party in court and win. Yes winning the fair use case with Apache Harmony is insanely low. The solution that outside out life times most likely is been around for when Apache Harmony runs out of copyright and comes public domain.


                  Restarting GNU Classpath that has not been touched in a decade now is not going to dig yourself into a legal black hole with almost no chance of winning. Yes none of this tainted with possible illegally acquired code like Apache Harmony has.

                  Starting java runtime completely from scratch would most likely be simpler and cheaper than attempting to bring Apache Harmony back.

                  Comment


                  • #19
                    Originally posted by fithisux View Post
                    Having this in a polished open source package sounds like Boehm GC sounds a better option than GCJ.
                    Boehm GC does well but it can only scan the heap and stack for raw memory. It has no concept of what type everything is. So effectively some random float with a char next to it on the stack might happen to have the same value as a pointer to some GC heap memory so it would not clean it up (a false positive reference).

                    GCJ has the slight advantage that it includes a little more information about the data so the GC can make more informed decisions.

                    What this means in practice depends on the specific software I imagine. Personally I prefer the more mechanical approach by RAII (but do use Boehm GC as a cyclic shared_ptr detector).

                    Comment


                    • #20
                      Originally posted by Redfoxmoon View Post
                      I could maybe, *maybe* see this being useful for bootstrapping openjdk, but heh... java.
                      On its own GCJ is not that useful for bootstrapping as it depends on Java if you want to rebuild it completely from source. We do have a way to bootstrap java from C:
                      1. Fastjar 0.98 is written in C (Provides our initial JAR program)
                      2. Jikes 1.22: Java compiler written in C
                      3. GNU ClassPath 0.93: can be build with fastjar and jikes
                      4. Jamvm 1.5.1: Java VM written in C. We now have full Java Runtime Environment (though fairly old)
                      5. Ant 1.8.4
                      6. ecj-3.2: more capable Java compiler
                      7. GNU Classpath 0.99
                      8. JamVM 2.0.0: Now we have a more capable JRE
                      9. Then you need to build a newer unreleased snapshot of GNU Classpath which has a better support for Java 1.6
                      10. ecj-4.2
                      11. Icedtea 2 (which is basically OpenJDK 7)
                      12. Icedea3 / OpenJDK 8
                      13. OpenJDK 9 and so on until the latest OpenJDK.


                      Comment

                      Working...
                      X