jdk/src/solaris - time to re-visit it?

[Alan Bateman]

On 24/11/2011 14:39, Fredrik Öhrström wrote:
> :
> It would be great to do the rename. However, we should not do that
> before the build-infra changes
> are in place. The peculiarities of the current build have already been
> worked around and the new
> makefiles are useful, since it is easy to see where the warts are.  Thus
> when build-infra is done, we will
> have a neat list of all things that needs to be cleaned up by moving
> source code and platform
> specific code in src/share is just one of many problems.
>
> I was hoping that when we start incrementally moving towards jigsaw-like
> structuring of the source,
> we can fix this then? When we rename directories, we lose a lot of
> information in the source control system.
> Necessary yes, but at least we should try to do it just once.
>
> As for the naming:
>    posix is the name of a standardized API to unix-like operating systems.
>    winapi is the name of the defacto API to windows systems.
>
> Using two trademarks instead of the actual names of the APIs would be silly.
>
> And you can run posix software on Windows by installing cygwin et al,
> and you
> can run winapi software on Linux by installing wine. But this is not the
> point,
> the point is that the built jvm will run primarily using winapi, or
> primarily
> using posix.
>
> No-one answered my question if we need to track the posix pedigree? I.e.
> gnu, sysv and bsd?
>
> //Fredrik
I agree it's not a good time to do the renaming but I think it's good to 
discuss and think about the how we might organize the code in the future.

I don't have strong opinions on the names but "posix" doesn't seem quite 
right just now as we have code in src/solaris/** that is making use of 
APIs that aren't part of POSIX (I think this was Phil's point too). On 
the pedigree then it might be better to cross that bridge when we come 
to it, meaning that we could only really make use of it in conjunction 
with refactoring work.

You are right that the peculiarities have been worked around to date but 
more have been proposed [1]. Maybe it would be prudent to hold off on 
these changes until the new build is in place.

-Alan.

[1] http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001466.html