▲ 164 points
back
51 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.
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.
...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...
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 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.
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.
Agreed, if it were not for the nature of how git works I would then be a little worried.
It's definitely an improvement to figuring out which "Download" button on the Sourceforge page gets you the code rather than BonziBuddy.
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.
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.
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
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.
No bigger problem than someone is using software developed by an American company and hosted on platform of another company
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://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.
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.
Thanks for the tip...have a application still running on 1.4.21 ;(
> JAVA 6
Why do you capitalise it like this? It's not an abbreviation.
Nor an acronym.
I think capital JAVA is enterprise notation
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.
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.
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.
> 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.
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
> 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.
> 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?