TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Deletion of gcj

284 点作者 mynameislegion超过 8 年前

11 条评论

rekado超过 8 年前
This is a little sad because this means we will have to keep around old versions of GCC with GCJ in order to be able to bootstrap the JDK from source (without a binary bootstrap JDK). Only OpenJDK6 (with the extensive IcedTea patches) can be bootstrapped with GCJ alone, so we also have to keep OpenJDK6 around in order to be able to build the latest JDK.<p>Bootstrapping becomes harder and more legacy software needs to be accumulated in order to actually build new software from source.<p>(I&#x27;m working on GNU Guix, a functional package manager, and I wrote the package definitions for the JDKs.)
评论 #12626268 未加载
评论 #12627984 未加载
评论 #12626348 未加载
评论 #12627813 未加载
评论 #12626368 未加载
lsd5you超过 8 年前
It was used for creating the native builds of XWT [1] 15 years ago. At the time I found it amazing to see Java programs becoming native (a lot snappier and generally faster too). It seemed (naively) to be beyond what was possible.<p>However, the main problem with GCJ was it used conservative garbage collection - boehm GC - and as such was fundamentally broken for long running programs (what java is good for). Without wanting to denigrate it too much, it seems to me that a lot of &#x27;good&#x27; work has been put into this approach which was essentially a cul-de-sac.<p>I had a related rather general thought recently about documenting features in projects. Sometimes the hardest thing to know is whether something is in fact a good idea or not (both in theory and in practice) and the amount of effort&#x2F;quality of documentation is probably not a good indicator of this. So in the case of the GCJ garbage collector, there was always a lot of talk about how clever the garbage collector was and all the technical aspects, but unless you were already an expert, how would you know if it was infact a good idea or not.<p>[1] That is this one, there are several now doing similar things (!). <a href="http:&#x2F;&#x2F;www.xwt.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.xwt.org&#x2F;</a><p>The code lives on here <a href="https:&#x2F;&#x2F;sourceforge.net&#x2F;projects&#x2F;vexi&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sourceforge.net&#x2F;projects&#x2F;vexi&#x2F;</a>
评论 #12627563 未加载
dragonquest超过 8 年前
This is why you should always create something, even if you think it will never be accepted by a large audience. It is worth it for the journey itself.<p>Reading this post made me wish I had spent more time with &#x27;gcj&#x27;. Though in all honesty I know I gave up on it because I didn&#x27;t want to go the tougher way - the the normal JDK was just there. Creation is beautiful, and its ending bittersweet for the creator and the witnesses.
评论 #12627134 未加载
aardvark179超过 8 年前
<a href="http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;8166089" rel="nofollow">http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;8166089</a><p>One Java AOT option goes away, and a new one is arriving.
评论 #12626966 未加载
评论 #12626349 未加载
okket超过 8 年前
GCJ was deemed obsolete in 2010, amazing that it was still around until now...<p><a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;3032727&#x2F;java-jre-vs-gcj" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;3032727&#x2F;java-jre-vs-gcj</a><p>Did anyone used GCJ for something in production?
评论 #12626849 未加载
评论 #12626339 未加载
评论 #12626185 未加载
评论 #12630862 未加载
correktlogic超过 8 年前
What a shame about gcj being dropped. I remember using GCJ with CNI to interface with native C++ code was a much more pleasant experience than using JNI.<p><a href="https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcj&#x2F;About-CNI.html#About-CNI" rel="nofollow">https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gcj&#x2F;About-CNI.html#About-CNI</a>
wodencafe超过 8 年前
It seems the most beloved feature of GCJ was its ability to compile Java to native code.<p>Is this something that could be implemented in the Java JDK &#x2F; OpenJDK? Understandably a lot of work, but Oracle is looking at AOT now, for performance reasons.<p>The performance improvements could be taken even further by something like this, Java to native code compilation.
myhf超过 8 年前
Google cache: <a href="http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:zFK8UNRnBpkJ:tromey.com&#x2F;blog&#x2F;%3Fp%3D911" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:zFK8UNR...</a>
akx超过 8 年前
gcj being killed means someone needs to reimplement pdftk in... well, something else. D:
评论 #12631059 未加载
pritambarhate超过 8 年前
Not directly related to topic, has anybody used Excelsior JET to compile Java apps to native code? How was your experience? Did it improve the start up time of the app? Did you find it any faster than using a JVM?
fake-name超过 8 年前
I skimmed the article, and all the comments here, and I still have no fucking idea what &quot;gcj&quot; is. It&#x27;s apparently related to java. Maybe at least define your acronym once?
评论 #12631150 未加载