Support for Netscape/Mozilla plug-in on Linux AMD64 native platform

[Jonathan Springer]

Dalibor Topic wrote:

> Mark Reinhold wrote:
>
>> I expect that the long-term goal of any more serious porting effort will
>> be to integrate into one of the mainline JDK code bases.  At that point
>> its corresponding Project would be archived, and further work on the port
>> would happen in the mainline.
>
> That'd be perfect.
>
>> So who'd like to propose a Porters Group?  Dalibor?
>
> It would be a pleasure.
>
> I'll work with Greg and Kurt on a proposal, and would be glad to serve
> as the group's initial moderator for the time being.
>
> Meanwhile, we'll need (at least) two more existing members to join me as
> initial Porters Group members .. so please reply to this post, if you
> are interested in being an initial member of the group, or send me an
> e-mail off-list.

I am interested.  Thanks,

-Jonathan

--
Jonathan Springer     |
Reservoir Labs, Inc.  |  http://www.reservoir.com/

[Volker Simonis]

On 11/5/07, Dalibor Topic <robilad@...> wrote:

> Mark Reinhold wrote:
> > I expect that the long-term goal of any more serious porting effort will
> > be to integrate into one of the mainline JDK code bases.  At that point
> > its corresponding Project would be archived, and further work on the port
> > would happen in the mainline.
>
> That'd be perfect.
>
> > So who'd like to propose a Porters Group?  Dalibor?
>
> It would be a pleasure.
>
> I'll work with Greg and Kurt on a proposal, and would be glad to serve
> as the group's initial moderator for the time being.
>
> Meanwhile, we'll need (at least) two more existing members to join me as
> initial Porters Group members .. so please reply to this post, if you
> are interested in being an initial member of the group, or send me an
> e-mail off-list.
>

I'm also interested, altough I'm not a current member of any group.

Follwing some thoughts about the problems and challenges a porting
group may be faced with:

After reading the posts on this topic in this and the two related
threads in the last days, I understood that Sun is not willing and
doesn't has the ability to officialy support, test and maintain other
ports. This is understandable. However, I also understood from the
various posts that Sun is willing to encourage and at some point even
integrate other ports into OpenJDK or as Mark Reinhold put it: "I
expect that the long-term goal of any more serious porting effort will
be to integrate into one of the mainline JDK code bases". This is very
good news!

The question now arises, how Sun can help other ports to become
integral parts of the JDK and what does Sun expect from other ports to
achieve this goal?

More concrete, we are speaking here about  three different things:
a. platform ports (ports to an operating system not officialy supported by Sun)
b. architectural ports (ports to a processor architecture not
officialy supported by Sun)
c. platform/architectural ports (a combination of a. and b.)

For the VM part (i.e. the Hotspot), the conditions for potential
porters are already quite promising. The Hotspot project is already
nicely separeted into a shared part, that more or less depends only on
Posix libraries and a C++ compiler and three platform/architecture
dependant parts that are located int the 'os/', 'cpu/' and 'os_cpu/'
subdirectories.

So in a perfect world, a porting group would at most need to work in
these three subdirectories for their respective port. In practice
however, the things are a little more complicated, because the shared
code implicitly makes some assumptions about things like byte order or
stack growth direction that are inherently platform dependant.
Moreover the shared code still contains artefacts like "#ifdef <OS>"
or "#ifdef <CPU>".  And finally, we have the includeDB database, that
may require some platform dependant files even if these files are
empty, just to make the project compilable.

The big question now is, how responsive Sun will be in handling
changes to the points mentioned in the previous paragraph to support
ports? A real port will definitely need at least minor changes in
shared code because of the problems mentioned before although these
changes should get smaller with every new port if they are done
carefully.

I personally think it will be crucial to handle such changes and to
handle them in a timely manner in order to support other ports for two
reasons: first of all it will make the Sun suported platforms
themselves more robust and second, it will keep other ports from
forking away from the OpenJDK source tree.

So far we just spoke about the VM part of the JDK. However the JDK
library (i.e. the j2se subdirectory), although  it doesn't contain
that much architecture specific code like the VM, isn't much easiers
to handle either. The problem here is that currently distinguishes
only two different platforms (i.e. subdirectories), namely
'j2se/src/windows/ ' and 'j2se/src/solaris/'. There's a "linux/'
subdirectory, but  in fact, all the code for the Linux OS is in the
'solaris/' subdirectory and the differences between the two is only
separeted by preprocessor macros. This will make ports to other
Unix-like operating systems harder with every new port that will be
integrated.

So again here the question arises if Sun is willing to factore out the
code in the "j2se/" subdirectory in the same way that it was done for
the Hotspot. In my eyes, this is a crucial requirement it Sun is
taking the goal of integrating other ports into OpenJDK serious.

Finally, even pure Java code contains artefacts like:

if System.getProperty("os.name").equals("Linux") ....

Of course, such code has to be changed as well if other ports are
supposed to work within OpenJDK.

Concluding this post, one can say that open sourcing the JDK was
certainly a huge effort. However, building a strong and active
community around OpenJDK, will be not less work. The fact that a
portng group is in the process of beeing created is certainly a step
into the right direction but a lot of efforts, both from Sun and the
community will be needed to make OpenJDK a success.

Volker

[Dalibor Topic]

Jonathan Springer wrote:

>
> I am interested.  Thanks,
>

Thanks for offering your help, Jonathan.

In order to be an 'Initial Member' of a group you need to already have
member status inside OpenJDK, i.e. be on one of the existing teams,
according to the interim governance rules.

I know that you're working on the mipsel-linux port, which is something
I'd love to see in the porters group, but I have no idea if you are
already officially a Member of OpenJDK yet.

If you are not yet a Member, no worries, Mark Reinhold, David Herron and
Tom Marble (thanks guys!) have kindly offered to be Initial Members of
the Group, so that bootstrapping requirement for the proposal of the
group is already fulfilled.

I'd be happy though to assist you with a proposal for a mipsel-linux
port as soon as the group is created (proposal + two weeks time for
discussion + a vote by IGB), though, and that should get you initiated
as a member.

cheers,
dalibor topic

[Jonathan Springer]

Dalibor Topic wrote:

> Jonathan Springer wrote:
>
>> I am interested.  Thanks,
>
> Thanks for offering your help, Jonathan.
>
> In order to be an 'Initial Member' of a group you need to already have
> member status inside OpenJDK, i.e. be on one of the existing teams,
> according to the interim governance rules.
>
> I know that you're working on the mipsel-linux port, which is something
> I'd love to see in the porters group, but I have no idea if you are
> already officially a Member of OpenJDK yet.

No, you're right.

> If you are not yet a Member, no worries, Mark Reinhold, David Herron and
> Tom Marble (thanks guys!) have kindly offered to be Initial Members of
> the Group, so that bootstrapping requirement for the proposal of the
> group is already fulfilled.

Great, thanks.

> I'd be happy though to assist you with a proposal for a mipsel-linux
> port as soon as the group is created (proposal + two weeks time for
> discussion + a vote by IGB), though, and that should get you initiated
> as a member.

Sounds good, I will revisit this then.

--
Jonathan Springer     |
Reservoir Labs, Inc.  |  http://www.reservoir.com/