Skip to main content

Is it possible to fork OpenJDK while continueing to receive updates?

4 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

Is it possible to create a new language from OpenJDK that would not be called Java yet would consist taking OpenJDK, applying diffs and would automatically pick up updates from the OpenJDK codebase as it evolved?

Specifically I'm thinking this alternate language would be equivalent to "Java 3.0" which would be Java with changes that break backwards compatibility to clean up the language (only breaking where absolutely required). The emphasis would be on improving language readability and API consistency.

http://mindprod.com/jgloss/gotchas.html has a nice list of things to consider. Deprecated methods also come to mind. And finally there is also the matter of Generics' wildcards and Reification.

I also think it would be possible to build an automatic Java 2.0 -> 3.0 source-code and bytecode converter.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robilad
Offline
Joined: 2004-05-05

Anything's possible if you try hard enough. ;)

You can fork OpenJDK as often as you desire, and patch it to your hearts content, and so on.

Chances are pretty good that sooner or later your fork and openjdk would diverge significantly enough for picking up updates to no longer work automatically, assuming you do significant work on your fork, rather than just cosmetic changes, so you need to figure out how much effort you can afford to spend on such a project for the next 5-10 years.

You'd also need to spend time promoting your language. As someone who has spent some time working on and with alternative runtimes, 'It's like Java2, just that your programs don't run any more', is not a very appealing proposition to the majority of existing Java developers.

cowwoc
Offline
Joined: 2003-08-24

> You'd also need to spend time promoting your
> language. As someone who has spent some time working
> on and with alternative runtimes, 'It's like Java2,
> just that your programs don't run any more', is not a
> very appealing proposition to the majority of
> existing Java developers.

I agree, which is why automated migration is going to have to play a central role (and changes are likely to be limited to changes which can be automated in this way).

kirillcool
Offline
Joined: 2004-11-17

> I agree, which is why automated migration is going to
> have to play a central role (and changes are likely
> to be limited to changes which can be automated in
> this way).

And who would provide this automated migration? Surely not people working on OpenJDK, right? Why would they want to actively encourage forking? And what are you going to do when OpenJDK introduces a feature that is incompatible with your changes? Blaming OpenJDK would be easy, of course, but not really honest.

cowwoc
Offline
Joined: 2003-08-24

> > I agree, which is why automated migration is going
> to
> > have to play a central role (and changes are
> likely
> > to be limited to changes which can be automated in
> > this way).
>
> And who would provide this automated migration?
> Surely not people working on OpenJDK, right? Why
> would they want to actively encourage forking? And
> what are you going to do when OpenJDK introduces a
> feature that is incompatible with your changes?
> Blaming OpenJDK would be easy, of course, but not
> really honest.

That's not what I was trying to say. The Java 3.0 developers would obviously be responsible to producing automated migration and if Java 2.0 introduces a feature incompatible with 3.0 they'd have to find a way to deal with it.