This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 206813 - NetBeans should be built using OpenJDK
Summary: NetBeans should be built using OpenJDK
Status: RESOLVED WONTFIX
Alias: None
Product: ide
Classification: Unclassified
Component: Code (show other bugs)
Version: 7.0.1
Hardware: All All
: P3 normal (vote)
Assignee: Antonin Nebuzelsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-30 20:20 UTC by emi
Modified: 2013-12-27 13:54 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emi 2011-12-30 20:20:01 UTC
The NetBeans binaries (and the builds on http://deadlock.netbeans.org/ I guess) are made using the Sun JDK.

I suggest we start using OpenJDK because this is what Oracle seems to be pushing towards.

In particular on Ubuntu, it seems Sun JDK is going to be removed from the official repositories[1] with OpenJDK as the recommended compiler.

1. https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-December/001528.html
Comment 1 Marian Mirilovic 2012-01-03 11:43:38 UTC
sent to NB 7.2 release boss to make decision
Comment 2 Jesse Glick 2012-01-03 19:53:59 UTC
(In reply to comment #0)
> made using the Sun JDK

Well, Oracle JDK now.

> OpenJDK [...] is what Oracle seems to be pushing towards.

Not sure what that means. OpenJDK is the basis for Oracle JDKs starting with version 7. In 6, it is more of a backport.

The final distributed binary should be the same regardless of which JDK is used to build it. The only potential issue is that there may be a bug in some OpenJDK version of javac preventing a valid source files using some exotic bit of syntax from compiling (or a bug in some version of Oracle JDK's javac permitting an invalid source to be compiled). In such a case a user doing a source build of NB using OpenJDK might run into an error - easily corrected in NB sources once reported.

Setting up a special Hudson job to detect such cases in advance could be helpful if this were common, though I doubt it is. The only syntax issue I know to be common is that @Anno({1,2,}) is valid but rejected by older Sun/Oracle JDK 6 versions; 6u30 accepts it, latest OpenJDK probably does too, but since our Hudson builds generally run 6u22 or thereabouts we do not use this syntax in NB sources anyway: @Anno({1,2}) is always safe.

Recommend WONTFIX unless and until a concrete reason to do this emerges.
Comment 3 emi 2012-01-03 21:36:03 UTC
I did have issues on simple apps with OpenJDK 6 that went away by grabbing the Oracle JDK 6 so I basically don't trust OpenJDK that much.

If OpenJDK would be used to build (and test) NetBeans it would show some kind of commitment from Oracle. It seems a big deal to switch to another compiler and runtime, even if it has some common ancestry.

I imagine that the compiled binary would be about the same, but I can't be certain that using OpenJDK as a runtime (not just javac) would still pass all the NetBeans build tests, for example.

I'm also a bit confused by your reply. On one hand you say there are low chances using OpenJDK would impact anything, but on the other hand you are also reluctant to actually use it.

Anyhow, you can close this bug. I'll do some test builds myself and see if it's ok or not.
Comment 4 Jesse Glick 2012-01-03 22:58:36 UTC
(In reply to comment #3)
> I can't be
> certain that using OpenJDK as a runtime (not just javac) would still pass all
> the NetBeans build tests

Unit tests may indeed show some variance between OpenJDK and Oracle JDK. Not sure offhand if our Hudson instances devoted to tests include OpenJDK as a parameter. (These are not available on the public internet currently.) At any rate, cross-platform variance (especially Windows vs. anything else) is likely to be far higher. We could run tests on OpenJDK 6 but JDK 7 is the recommended platform for NB, and OpenJDK 7 and Oracle JDK 7 are built from the same code base so it is not a very interesting test parameter.

> on the other hand you are also reluctant to actually use it

Well, to spend the effort switching installations, especially when Hudson JDK autoinstallers work on Oracle JDKs only.