OpenJDK is now on GitHub | Hacker News Reader

OpenJDK is now on GitHub

mail.openjdk.java.net

164 pointscarimura51 comments

It's really weird a choice in the email to provide links that looked like they weren't on GitHub to redirect to the GitHub URLs... For a moment, I was wondering if they had like a self-hosted GitHub Enterprise setup or something, until I noticed the URL redirected anyways.

That's intentional. Links will contain the redirecting address on our domain so that when we move off of GH (some day; nothing lasts forever), links will continue to work.

...I can't argue with that unassailable logic. Particularly since I use the same when I insist on using my own domain for my email address now, regardless of what provider I use behind it, after the difficulty of handing out my replacement address to everyone who used to have my old Gmail account...

This strategy has saved our bacon at work more than a handful of times. All the URLs we ship in our apps point to a "lookup" server (just Nginx with a huge list of redirect rules), such that if the URL we were using in the app disappears, we can change it on the server side rather than requiring a client update.

https://github.com/openjdk/jdk/graphs/contributors

How interesting, more and more activity? year by year

Yeah, that timeline starts towards the end of Sun's life, when investment in Java was at an ebb. Since the acquisition by Oracle, investment in Java has grown.

Is anyone else worried about the mass centralization of Open Source projects at one central point of failure on github?

especially since it's owned by an American company and I assume hosted within the United States

Not really, since everybody who cloned a repo has a full copy of everything.

Reminds me of the saying that writing git was just a backup strategy for Linus Torvalds: FTP-mirrors were the first step to ensure that the kernel was never lost, git was needed to mirror the source-history as well.

Except all the proprietary lock-in tools they add to Git like the issue tracker, PR's, discussion, wiki, released binaries, container registry, access control settings, etc.

I think you mean Github, those features are not part of git.

That's what they said - 'add to Git'.

> proprietary lock-in tools they add to Git

Git + their other stuff = GitHub.

Of course the immediate parent meant GitHub. It is the grand-parent comment that conflated the two:

> one central point of failure on github?

>> Not really, since everybody who cloned a repo has a full copy of everything.

(everything != Git repo)

Not me. The fact that it's in git makes it easy to mirror and export, so I don't consider github to be a central point of failure. Issue tracking and PR handling lives in the github UI, but the significant change here is a change from Mercurial to Git, which I hold as a positive development.

Fundamentally git is a data storage format that is very well-defined, with a standard command-line interface which is fine, not great. Mercurial has an arguably better command-line interface, but a data structure that is not well-defined or documented, and the main interface to hg is through python-based plugins, which is just awful.

Agreed, if it were not for the nature of how git works I would then be a little worried.

You even see GitHub mirrors for got projects hosted privately, which is good.

If github went away, tons of projects would need to rework their workflow, but very few people would actually lose their code, which is the most expensive asset to restore.

No bigger problem than someone is using software developed by an American company and hosted on platform of another company

It has its trade-offs I guess.

But I think people are forgetting what a nightmare it was before websites such as GitHub.

Just browsing the source of open source projects used to be a terrible experience. Let alone the issue trackers - Bugzilla!

I'll take unfortunate centralisation over source code browsing like https://hg.openjdk.java.net/jdk/jdk/ and pull requests like https://cr.openjdk.java.net/~ngasson/8251923/webrev.1/.

And the issue trackers, which is what most people complain about on GitHub, weren't distributed before, so we haven't lost anything there.

In some ways I think it’s a pity that none of the attempts to store issues in the git repo itself have taken off. It would be an interesting world where the state of a bug was tied to the state of the source.

not in git, but relevant: vcs with issue tracker built in. Fossil.

https://fossil-scm.org/home/doc/trunk/www/index.wiki

It's definitely an improvement to figuring out which "Download" button on the Sourceforge page gets you the code rather than BonziBuddy.

Bandwidth is expensive, the only way you get hosting like this for free is that a company makes profits other ways. We cannot afford to self host.

Entirely depends on how much. Bandwidth is not very expensive, and once you're at-scale it goes to 0.

I am, pepperidge farm remembers and so do i a couple of years ago the US leveraged their power to block access to Iran and a couple of other countries afaik

Unfortunately, similar to a number of other Enterprise Open Source projects, despite being on GitHub, potential contributors still cannot open any tracked bugs, and need to print and scan a CLA before submitting any code.

I apologize as it's slightly off-topic, but for anyone that is stuck working on old gear that still uses a java interface/JNLP and doesn't want to run JAVA 6 - here's an open source project that's keeping JNLPs alive and as secure as they can:

https://openwebstart.com/

https://github.com/karakun/OpenWebStart

Been a life saver for me (and I am in no way affiliated).

When I switched to OpenJDK I was dead in the water for JNLPs until I found it.

> JAVA 6

Why do you capitalise it like this? It's not an abbreviation.

Nor an acronym.

I think capital JAVA is enterprise notation

Thanks for the tip...have a application still running on 1.4.21 ;(

Do you happen to know if it completely rolls back all the old SSL-related policy?

Asking because I've never gotten Dell DRAC Remote Console over Java working (5 and 6/i), and the alternative is, well, ActiveX...

Neither work though. It's been a while, but I don't even think I could get an XP VM to access it.

I believe it does - I've used it with Brocade FC switches which had the same issue.

That's good to know--I'm dealing with a home lab server (running ESXi,) which makes it a little awkward, since any solution that involves an older version of Windows would end up residing as a VM on...my ESXi server, whose (i)DRAC I'm trying to access!

I'll try it out on a (physically) separate machine considering your comment. Thanks! I'm glad to know I'm not the only one dealing with hardware companies' awful software.

Title clarification: OpenJDK specifically, there are many name-branded JDKs in circulation.

Most of which take the OpenJDK source, sprinkle in some "secret sauce" and then compile the entire thing for convenience of users.

It's not a trivial undertaking to compile OpenJDK from sources.

There are not very many JDK implementations that don't have OpenJDK sources at their core.

OpenJDK is also treated as the reference implementation, and is where JEP's and things are worked out. Effectively, OpenJDK is "upstream" Java.

> It's not a trivial undertaking to compile OpenJDK from sources.

uh? assuming you already have a working C toolchain and JDK installed, you just hg^Wgit clone; bash configure; make.

edit: you may have more trouble compiling it on windows, but compiling anything on windows is a pain unless it uses the entire proprietary non-portable microsoft-specific project management tools.

RE: compiling on windows

Apple is honestly giving Microsoft a run for their money here. Many FOSS apps seem to have given up on OSX and few ever tried with iOS.

IMO it's harder to compile for macOS than for windows.

I don't have a macbook. I can legally run a trial copy of windows in virtualbox to test out cross-compiling stuff, or spin up a windows EC2 instance for a few hours, or even use circleci or other CI system's windows workers to build stuff.

For macOS, I can't legally run a VM on my hardware, ec2 doesn't support it so I can't spin up a VM, and most CI platforms don't support it (probably because many of them just resell fleets of ec2 instances).

Many FOSS developers are just hacking away on 3 year old laptops or desktops for fun, and can't afford a $2k investment just to support one more operating system for their little project.

I agree. Among all the open-source projects I've built, the OpenJDK is one of the easiest and most straight-forward I've encountered — even when cross-compiling for 32-bit ARM. They did a great job rewriting the build system a few years back.

Even on Windows it just takes a few hours of setting up a build VM machine from scratch, installing a few tools, to first full build. It is more inconvenient than Linux (as is all Windows building, indeed) but far from being hard to do.

I did that regularly some years ago for the company I work for, because we needed OpenJDK Windows binaries, and there wasn't such a convenient thing as AdoptOpenJDK. So in order to not get caught in stupid licensing debacles with Oracle it came down to just compile the Windows binaries by yourself.

> Most of which take the OpenJDK source, sprinkle in some "secret sauce" and then compile the entire thing for convenience of users.

Got some links to these GPL licensed OpenJDK forks?

https://github.com/corretto/corretto-8

https://www.eclipse.org/openj9/

https://github.com/SAP/SapMachine

also:

https://adoptopenjdk.net/

https://github.com/alibaba/dragonwell11

https://github.com/alibaba/dragonwell8

https://developers.redhat.com/products/openjdk/overview

https://www.azul.com/downloads/zulu-community/

https://bell-sw.com

Great list! Thanks!

Sap and corretto are mostly friendly forks that just backport bug fixes from newer versions of OpenJDK for their customers.

OpenJ9 uses a whole different JVM even though they use the OpenJDK standard library.

Awesome! Thanks!

> There are not very many JDK implementations that don't have OpenJDK sources at their core.

Well yeah, especially not open source, as you can't get a TCK for non-OpenJDK open source implementations of the standard library. Oracle forbids it.

> Most of which take the OpenJDK source, sprinkle in some "secret sauce" and then compile the entire thing for convenience of users.

As in GPL violations? (I've never had the pleasure(?) to use java properly, so I'm not familiar)

Dunno what previous poster is referring to, but none that I know of.

For example Amazon Corretto is on GitHub, and Amazon gives a pretty good breakdown of the patches that make it different from the equivalent OpenJDK version (funnily enough, most of the changes are actually just backporting bug fixes from OpenJDK11 into Amazon's equivalent of OpenJDK8)

There's the Oracle JDK which has some onerous licensing, but IIRC the actual JDK is the same, they just include some extra binaries in the distribution

Not literally secret. They are just the changes that are particular to an environment or specific use case. They are just not things that are likely to get upstreamed so they are maintained as a fork.

Fun trivia: it all started with the Blackdown JDK. I vaguely recall it taking up until 1.2 to stabilize but that's a fuzzy memory from a younger me. https://en.m.wikipedia.org/wiki/Blackdown_Java

Reply on news.ycombinator.com