Sunday, August 05, 2007

A Business Case for Supporting Jython

The facts:

  • Sun and many other organizations have started considering moves to Mercurial. In Sun's case, it's a mandate for all Sun-managed OSS projects (OpenSolaris, OpenJDK, etc).
  • Moving projects to Mercurial frequently (usually?) requires IDE/tool support.
  • Sun's IDE/tools and those of many other organizations are Java-based (NetBeans, Eclipse, and so on).
  • Mercurial is written in Python.
  • Jython is an implementation of Python for the JVM.
Therefore, Jython Mercurial support would be an excellent vector to Mercurial adoption within Java organizations (Sun included, I'd wager). Corollary: getting Mercurial running on Jython is an excellent business case for contributing time and resources to Jython.

Put simply: if you want to become an OSS rockstar tomorrow, get Mercurial running on Jython.

(credit for this idea goes to OpenJDK ambassador Tom Marble...I'm just trying to needle the OSS world into making it happen)

5 comments:

fcohen said...

Excellent stratgizing! And timely too since Jython 2.2 is in its final release candidate stage.

PushToTest is releasing TestMaker 5 this coming week. We had planned to migrate to Subversion from CVS. Perhaps we should migrate to Mercurial?

Is there a migration guide to go from CVS to Mercurial? And is there some sort of comparitive guide explaining the advantages of Mercurial to Subversion?

-Frank

Charles Oliver Nutter said...

fcohen: I don't have any offhand, but I've seen some very convincing presentations on Hg and I know there are scads of articles out there comparing and presenting migration options. I'd expect they're largely Python scripts to import your CVS repository, but I'd also expect they probably work well.

The largest obvious advantage to Mercurial is that you have the entire repository available to you offline, so you can version, branch, revert, and commit without pushing anything to a common repository. Then when you're happy with what you've got, you can choose to do that push (the details here are a bit fuzzy to me).

The largest obvious disadvantage to Mercurial is that you have the entire repository available to you offline. In the case of a large project, that could be a lot of data you don't need. But I believe a future (or current) version of Hg supports partial repository pulls. Again, details a bit fuzzy for me here.

Paul Boddie said...

Interesting logic, proposing that people run Mercurial on Jython in their JVM-based IDEs rather than spawning Mercurial on CPython processes (and using the existing migration tools as is). I think Mercurial has seen a lot of adoption on its own merits, but obviously the Python connection provides some interesting benefits. I don't disagree with your arguments, though, and I've provided Jython compatibility in some of my own software because people should have the option of using Python on whatever platform.

Of course, Sun should just wise up and support Jython fully and officially, anyway. That Jython has been around for 10 years or more, and yet Microsoft comes along with broader support for dynamic languages on a runtime which was once said to be deficient, really says a lot about Sun's Java-the-everything culture.

Meanwhile, the Mercurial Wiki says more on migration:

http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryConversion

And this page could do with a Subversion equivalent, I suppose:

http://www.selenic.com/mercurial/wiki/index.cgi/CvsCommands

Jason R Briggs said...

Famous last words, but a Jython implementation of mercurial would seem to be some while away. I had a quick look (quick == one lunchtime + a couple of excessively long compile cycles) and there are rather too many dependencies on libraries that just aren't available in Jython (BZ2, and heapq/itertools spring immediately to mind). Integrating shared libraries would be a non-trivial exercise, so one would be left with re-implementing those libraries in Jython or Java. For example, providing an interface to Apache Commons Compress that looks like the bz2 Python module. In itself, not particularly difficult, but not the ideal solution.

So much for my starry eyed dreams of OSS rockstar fame: "here's an implementation I prepared in my lunchbreak..." ;-)

Byron said...

Also looked into it. The snag I hit was the bdiff.py module. I didn't find an equivalent Java library for it.