> 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.
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.
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
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.
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.
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:
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.
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.
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.
There is no way that git command-line interface can be called anything remotely close to fine. It's really sad that something as badly designed as git command line is taking over the world.
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.
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.
55 comments
[ 2.5 ms ] story [ 146 ms ] threadIt'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.
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.
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.
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 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.
Got some links to these GPL licensed OpenJDK forks?
https://www.eclipse.org/openj9/
https://github.com/SAP/SapMachine
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
OpenJ9 uses a whole different JVM even though they use the OpenJDK standard library.
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.
As in GPL violations? (I've never had the pleasure(?) to use java properly, so I'm not familiar)
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
How interesting, more and more activity? year by year
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.
Why do you capitalise it like this? It's not an abbreviation.
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'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.
especially since it's owned by an American company and I assume hosted within the United States
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.
> proprietary lock-in tools they add to Git
Git + their other stuff = GitHub.
> one central point of failure on github?
>> Not really, since everybody who cloned a repo has a full copy of everything.
(everything != Git repo)
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.
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.
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.
https://fossil-scm.org/home/doc/trunk/www/index.wiki