OpenJDK Migrates to GitHub
infoq.com
infoq.com
It's perfectly fine to say that they are moving to GitHub hosting, but not to put it on the same level as Mercurial: Mercurial and Git are applications/protocols, while GitHub is a hosting service. You should compare application with application and hosting service with hosting service.
- Migrate from Mercurial to Git - https://openjdk.java.net/jeps/357
- Migrate to GitHub - https://openjdk.java.net/jeps/369
And also in JEP 369 at the and there is:
> In order to prevent the Skara tooling from depending upon a particular provider's API, support for multiple external providers has been a strict requirement from the beginning. All of the tooling is also required to work with the open-source GitLab Community Edition (GitLab CE).
GitHub is as much a tool here as Git itself.
Unfortunate really, as Git should be the panacea of distributed systems, open source. Instead we took that, centralised it all on a single big host, and became dependent on its proprietary features.
Still, these systems come and go. Remember SourceForge anyone?
But what probably differs today is that these modern services seem so much more complex they have an increasing gravity/lock in effect.
And all developers on a project have a backup on their local computer. It might not track the master/main HEAD from Github, but in the event of a disaster you still have backups to recover from.
The nature of git's descentralized nature is misunderstood and I fear the misunderstanding comes from people that did not work with CVS/Subversion.
In any case you still need a source of truth from which releases are cut. And Github has been damned convenient to use as one and you can easily take your git repo and move elsewhere if you want to.
Sure, you can't migrate the links, the project's stars, etc, but that's not part of git. On the bright side, given you can mirror the code, you can keep the Github repo as read-only, which afaik is what the Linux kernel has done.
The huge importance of all that data "that's not part of Git", and the workflow and skill set around it.
Add to that a growing body of developers who don't actually know Git, but do know how to press the button in GitHub.
I don't make any claim for the particular JDK project here, but people _are_ migrating to GitHub, not Git.
Merge requests and comments are no longer authored by the correct user, because there's no user mapping - everything ends up getting authored by the user who performed the import.
Inline review comments on MRs appear to be lost or mangled.
Review summary comments on MRs appear to be lost or mangled.
Dates on MRs are lost. Dates on comments are lost.
Putting it in those terms, questions like the storage requirements of an SCM can't be answered (because GH is a hosting service) and usability of a hosting service can't be answered either (because Mercurial is an SCM). Ultimately, it doesn't allow the fundamental question to be answered - was it a matter of SCM, of hosting service, or both?
As a matter of fact, the article is imprecise/confusing, as it partly mixes issues that were originally separate (although later it expands on this).
See the two separate JEPs:
- [JEP 357: Migrate from Mercurial to Git](https://openjdk.java.net/jeps/357)
- [JEP 369: Migrate to GitHub](https://openjdk.java.net/jeps/369)
Based on a quick reading, the main driver has been the SCM.
I get what you're saying, and if this project in question just wants a "hosting service" and to never touch any of its features, then ok.
But the broader point is that these are not hosting services; they're full-on toolsets and workflows that people are migrating to (or towards, in this case).
So when someone says they're migrating "from Mercurial to GitHub", I'm left wondering: what were they previously using for code reviews, issue tracking, etc?
From the article:
> OpenJDK has used the Mercurial source code management solution since 2008 to store source code and conduct code reviews
This doesn't make sense. Mercurial doesn't provide a code review feature, and neither does Git. So what do they currently use for code reviews?
I had to dig in to the site a bit, but the workflow is described in https://openjdk.java.net/guide/codeReview.html. It looks like they use a (Korn!) shell script called "webrev" that will "generate a set of web pages to display the differences", and they then scp over the static html files to a shared public web server. Here's an example I pulled out of their Atom feed: https://cr.openjdk.java.net/~pbansal/8249548/webrev00/. It's not really clear to me how they comment on each others' diffs, but I guess this must be done out-of-band (maybe via email, chat or walking over to their desk).
It really feels like Git is a relatively small part of the migration. Mercurial and Git support more-or-less the same set of features, and neither one is really much better than the other (tbh I like Mercurial slightly better). Moving to GitHub as a code review tool (and possibly other things too) is going to have a much larger impact on the developer workflow than the version control tool.
And talking about forges I hope we will look beyond just Github and consider all of them (gitlab, gitea, sourcehut, gogs, pagure, gitern, etc.) and focus on their interoperability!
Just mentioned in another comment, but ForgeFed [1] could be the solution to achieve this, creating a federation of forges where it doesn't matter which software one prefers.
> The goal of this Project is to investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties.
> Two JEPs are planned for this investigation, first JEP 357: Migrate from Mercurial to Git [2] and second JEP 369: Migrate to GitHub. . [3]
[1] https://openjdk.java.net/projects/skara/
For more detailed information, the OpenJDK mailing lists archive is a good source.
Edit: I was specifically thinking on this main point they mentioned: "Programmatic APIs to enable process assistance and automation of review and processes", which to me means PR and Actions. I was just assuming that they will probably also use the Issues feature too.
The first time I heard about git and github in 2008 I thought this.
Recently, I was searching for a Git - fork project (i.e. a project forked from git itself) which allowed separate machine based accounts for Git branches. It was quite famous, I had used it about 4 years back and I don't remember its name now.
Now, this is the worst case scenario for the search engines -
• 'git fork project' would bring numerous github forked projects.
• 'git original source' would bring the mirror of git in github, but then again there are hundreds of fork.
After, lot of time spent on this in vain, I gave up.
UPDATE: While writing this comment I remembered the USP of that project was 'Branch specific permissions', so I gave a fresh attempt at finding it and I did via SO! It's Gitolite[1].
-github
Ultimately, in this case only recalling the USP or a similarly unique phrase was ever going to help you find the result you were looking for.
Just like we can discuss all day about POSIX, UNIX and various implementations of them, while most people would relate to Ubuntu.
https://blogs.windows.com/windowsdeveloper/2016/03/30/run-ba...
Especially early on when the compatibility layer was only fully tested with a specific version of Ubuntu.
It's pretty bothering that most people equate a distributed open-source code versioning system with a centralized Microsoft service, isn't it?
Excluding the contributors to such small projects as KDE, Gnome, Freedesktop, Debian, Arch Linux, Drupal all of which are self hosting Gitlab.
I would think at this point most developers should know that there are services like GitLab and BitBucket, and thus even if they are not totally aware of how Git works as a protocol they should be aware that Git is not directly tied to GitHub.
That all said ... well good on them, its about time.
Do they have a deal with Google/Bing? Any details about this crawler block?
Now a better solution still would be to self-host on a proper project home page.
Gitea is wonderful and definitely something you can host yourself for friends and family. I've even enabled KaTeX rendering in comments/issues/Markdown files on mine, which is something GitHub probably won't do anytime soon.
I'd definitely check it out.
1) Moving a project to GitHub ingratiates them with their puppet masters and generates a lot of billable hours.
2) Once on GitHub, these "developers" keep complicating the commit procedures so that even doc fixes look like a lot of work. More billable hours.
3) GitHub makes it easy to generate green squares for review actions. Merging a PR that another idealistic person put a lot of work in just requires a click. Half of the credit goes to the core developer. It looks as if the core "developer" is doing a lot of work.
4) If you apply the above methods, you will have green GitHub statistics and increase your market value.
pg has written about similar tactics in an essay where he explains why developers love Java. It is sad that open source is now "embraced" to such an extent that the same tactics apply there.
The idealistic developers are not political enough to prevent the bureaucrats from taking over. Also, they do not have time because they are actually writing code.
Good choice from moving to Git [0], very risky move on moving to GitHub. If this was just a mirror then that would be fine but it is moving from Mecurial to Git and then the whole project to GitHub.
They should do what Xfce, GNOME and KDE have done and they have self-hosted their own repositories on Gitlab, which GitHub requires the Enterprise Edition for self-hosting. Not really an option, unless you want to pay for this.
The risks outweigh the pros for GitHub as I have said before [1] and will say it again. Self-hosting over 'centralising everything' on GitHub.
We created our private instance in 2012 or so, when Gitlab was bot looking for world domination and the entire project was promised to be open source forever, and they were gonna make money off the hosted service and support contracts.
Well, then the VC money hit and now navigating through basic features can be a confusing mess.
So after many years they released merge request reviews to the community edition. This would be great, except you don’t get access to enforcement. So the approval is a purely decorative feature (that would be as easily achieved earlier by simply having any approved hit the button).
To be able to develop any sort of collaborative project you have to install the proprietary version and at that point you’re hardly better off than Github except you’re paying more for less (although I’m not exactly sure of Github’s on prem pricing but the hosted Github is way more bang for the buck than either the hosted or on prem Gitlab). Gitlab also recommends installing the Proprietary edition and using the “free” tier over the community edition so you can upgrade to the paid features, which you cannot on the community edition. So if you don’t want to be blocked in the future you’re installing the proprietary version anyways.
And going with Gitlab you’re also rewarding the scammy bait and switch they pulled some years ago (I’m not sure when this changed because I stopped working with the company I setu it up at, but you can see the archive.org look at their website for the different focus earlier, and the off website messaging was also very different).
1. Issues stay on a self-hosted JIRA.
2. All PRs get an automatically generated patch that's posted to the mailing list, and all comments are two-way mirrored between GH and the mailing list.
3. All links to commits in issues don't point directly at GH but at an indirection through our domain.
4. All bots work on both GH and GitLab
This means that we can move off of GH pretty much instantly if the need arises. But self hosting with GitLab just wouldn't serve our goals. We want speed all around the world, and we don't want to spend resources on administration.
If your project is setup in a way to just git push to another remote and then you're done, then I think it's fine to use Github.
So probably it's OK for now for the majority of the community to use MS's platform Github, because other options exist and it's not hard to move to them or create new ones at any time. Github doesn't own our brains, nor can it do any harm to the powerful GNU GPL.
I never figured out the processes to submit patches in the dark time of sourceforge and mailing lists. Since Github standardized this, I frequently contribute.
Hence why running own infrastructure and mirror to Github makes a lot of sense for bigger open-source projects.
I hope for more decentralization of forges in the future in a more open market, and I have my eye on ForgeFed as means to achieve that.
Not the most important thing... Basically all project I work on still relies on a "central peer" ...
I followed your link, which said that projects can self-host. True. Oracle can self-host if they want to. Should they want to?
I followed your link in that one, which says you should self-host to avoid GitHub-related downtime. So does the next link in the recursive trail, and most of the ones in there. It's true that if you aren't on GitHub, you'll avoid GitHub-related downtime - but how much downtime will your alternative incur, and what is the cost of the staffing needed to reach that point? And what is the downside of being unable to access GitHub briefly for a project like this, such that it becomes worth investing in that staffing?
There's this reply to your comment that I see you didn't reply to: https://news.ycombinator.com/item?id=23818307
> I used to help maintain Xfce's svn and then git server. I'm not going to say it was hard, but it was work, and it was work that took time (time that was volunteer free time) away from working on Xfce itself. [...] That was a foolish attitude that took time away from the actual goal, which was making Xfce better.
I will certainly agree that you should not host your primary website on GitHub; there are services that are designed for reliable website hosting. For something like Java, I'd also say you shouldn't host your releases on GitHub. But Oracle Java remains on Oracle's website, and OpenJDK binaries aren't hosted on GitHub - AdoptOpenJDK's website is behind Cloudflare.
I do also think people should have a strategy for moving off their code hosting provider, including making backups of things like issues/pull requests. But that applies even if (perhaps especially if) you self-host, and I don't know anyone who actually does that, regardless of provider. If you're just interested in the code itself, the nice thing about git is that every developer's laptop is an effective backup, so you can put off figuring out a business continuity plan until an actual problem arises.
A few links in (https://news.ycombinator.com/item?id=23102942), you seem to claim that GitHub is insecure because Microsoft's org account was "hacked". It turns out that one account belonging to an MS employee who was a member of that org was broken into https://www.zdnet.com/article/hacker-gains-access-to-a-small... . That risk doesn't seem particularly fundamentally different with self-hosting, since the attack was on the user account, not the service itself.
One link beyond that (https://news.ycombinator.com/item?id=23057769), you point out that you'd need to trust GitHub not to snoop on your private data, which is true, but irrelevant in this context.
Let me be clear - I am not an advocate of moving things to "the cloud" / hosted services for its own sake, and in fact, I believe that most of the time, people are better-served by putting a couple of servers in colo than by using some public cloud service. (My own employer runs an internal GitLab instance and spends a decent bit of staff time on keeping it operational and upgraded, and I think that's a great idea for us and for our needs!) But that's because I believe it's actually better for them to do so. I don't see the argument that people are actually better off running their own git hosting for open-source projects, in general.
Well... I was right.
Wasn’t Sun’s main issue that they were selling extremely expensive hardware and a proprietary OS that were completely overtaken by x86 and Linux?
I remember getting to play with the very expensive hardware they’d handout to startups in the late 90’s and early 00’s. It was good hardware, but it wasn’t so much better than the slightly more buggy and much less costly Linux systems at the time.
Geniuses with tech, but maybe not so good on the business side?
More importantly, I wouldn't trust a word that Larry Ellison says - particularly when the primary purpose of the article was to boost the Oracle share price by explaining that Sun would be additive to that quarters profits. I'm not saying that Scott McNeally or Jonathan Schwartz were great execs - I have no idea - but I think you have to look at the goal of the article.
Also a good read: https://www.atlasobscura.com/articles/hanoi-rat-massacre-190...
It turned out the hunters would rather amputate a live animal’s tail than take a healthy rat, capable of breeding and creating so many more rats—with those valuable tails—out of commission. There were also reports that some Vietnamese were smuggling foreign rats into the city. And then the final straw: Health inspectors discovered, in the countryside on the outskirts of Hanoi, pop-up farming operations dedicated to breeding rats.”
If they had learned these skills from companies like RH/SUSE/IBM, then Java would have been in much better hands today.
Secondly, with Sun you would never had gotten AOT, because they saw it as something that 3rd party vendors like Oracle and IBM should care about, they were fully into "JIT or bust", and MaximeVM would have followed the same path as SPOTs, instead of turning into GraalVM.
So if you have any problem with Oracle, thank Google in first place.
Android is now using OpenJDK and (I assume) not paying anything to Oracle for it. I think they could theoretically have rebased on top of OpenJDK in early 2007 if they expected it to be a serious legal problem, and Sun would have been no better off.
Android is not using OpenJDK as such, that is Google's marketing.
What Google is doing is cherry picking code from OpenJDK and adapting it to Android.
What they care about is keeping Kotlin's FFI to Java libraries relevant.
In Android 11 there are a couple of Java APIs all the way to 13, that they again cherry picked from.
https://android-developers.googleblog.com/2020/07/11-weeks-o...
It is quite easy to track from their Gerrit which stuff gets copied from OpenJDK and what keeps being ignored.
They always end their Java update announcements asking for what APIs are relevant, while for anyone else it is clear that only 100% matters.
And we aren't even getting into language features or JVM bytecodes that don't have parity with ART ones.
Android Java is Google's J++.
Also for selling Kotlin they always use Java 7/8 code style when comparing against Kotlin code.
With the classpath exception, dynamically linking class files is allowed. Normally this would be a form of creating a derived work thus triggering the virality of the license. This is crucial because it meant phone manufacturers could not take the OSS version and be able to ship it without having to OSS all their proprietary stuff linked against it. Sun was making a bit of money licensing J2ME to just about all phone manufacturers. The Gnu classpath was unusable for mobile phone manufacturers for the same reason: it would expose them to its viral clauses.
The Google & Oracle conflict is related to this because when Google bought Android (in 2004?), they ended up using Apache Harmony, which was a newly created project backed by IBM with an Apache licensed implementation of the Java standard library. It allowed Google to opt out of Sun's restrictive licensing deals, dodge licensing issues with gnu licensed code, and at the same time ignore the design by committee style API design that Sun insisted on with the rest of the industry.
Basically, it enabled them to run the whole of Java as they had their own vm and standard library implementation. Given improvements in mobile hardware, this was an obvious thing to want to do technically by that time. After Android shipped, there was little to no point at all to J2ME and it quickly became a thing of the past.
So, when Oracle bought Sun in 2010, all of that had already happened half a decade earlier. IBM pulled the plug on Harmony shortly after the acquisition and Google eventually incorporated much of Openjdk into Android to replace their Apache Harmony based implementation and also to modernize the code base. This is still licensed with the classpath exception; so they can do this.
Google had the opportunity to fix up their screw up by buying Sun, which they didn't, most likely hoping that Sun would sink silently, and they would get away with their little power games and industrial torpedoes.
Unfortunately for them, and fortunately for us Java devs, as I wouldn't like the Android architects to design Java, Oracle did not thought the same way.
Android Java is more like cowboy coding, whatever needed to keep Kotlin relevant libraries going on Android.
And to know what Java API is available one needs to crawl Android documentation to track down on which API level they got added into the platform.
The irony is that I am yet to see Android Studio, Gradle and Kotlin running to top of ART/desktop, a JVM free toolchain. Which apparently would be the direction that Google is driving into.
So I had to deal with Solaris, Aix, HP-UX, and Windows NT/2000.
We also rented servers for in-house development.
Their rates were just like everyone else on the Fortune 500 world.
Me: Hahahaha, yeah, sure…
Microsoft is currently embracing open source and people wonder why that is. Their history around FOSS is worrying and some question if it's part of "Embrace, Extend, Extinguish".
Plus it's very ironic that Microsoft is now the hoster of Java's source code after their failed proprietary Java implementation (J++) which eventually lead to the creation of C# after being sued by Sun.
So yeah, they failed to win the court process if that is what you mean.
Also something that many seem to forget, .NET was also released with J#.
Another fun fact, JNI is hard by design as means to promote WORA, and Project Panama that is supposed to replace it has several ideas similar to P/Invoke.
Finally many that celebrate Sun's victory over Microsoft regarding J++, are too eager to pick Android Java side nowadays.
[1] https://adtmag.com/articles/2019/11/06/microsoft-openjdk.asp...
And the VSCode plugins are developed in cooperation with Red-Hat.
What is it specific that you dont get ? I actually thought hg is conceptually simpler.
And hg to me has always felt BSD like, Git was Linux like. Unfortunately everything with BSD failed to gain any popularity. Including BSD license in itself. ( Yes I know Netflix are using it in their Edge Appliance )
Coming from git to hg, it was a step back in time to branches that can’t ever actually be deleted and bookmarks are... not obvious.
Can you actually create two bookmarks on your current commit and then move forward on just one? who knows? I never figured it out.
I might worry about a monoculture around a hosted service like github, but not git itself.
Or consider openssl since libressl came out. Yes it's possible that codebase improvements would have happened anyways, but having open source competition is great.
It obviously isn't 'factually' better - that's a matter of opinion not fact.
And in my experience, both Mercurial's model and UI is very over-complicated with far too many concepts. Git has a smaller number of simpler primitives and primitive operations. I think that makes the underlying model of Git better and that's why I prefer it.
As it stands, it's just a lot easier to use Git everywhere though, just so developers don't have to learn a new tool.
https://pijul.org/ is the only somewhat somewhat interesting alternative I know about, but it's implementation is in alpha territory, and development seems dead.
https://github.com/facebookexperimental/eden
Previous discussion https://news.ycombinator.com/item?id=23124095
It’s no longer “Choose Git or Mercurial?” that is the topic, but instead it is which Git branching model to choose.
If you’re doing really complicated merges (which you should avoid anyway), then yes Mercurial is better in my opinion.
But given the prevalence of Git, e.g. it is much easier to find a new dev with Git experience and also much easier to Google a Git problem, it seems only natural that more and more Mercurial repos will be converted to Git.