RFR: JDK-8212091 : Move native code under platform specific folders and files

[Magnus Ihse Bursie]

> 16 feb. 2019 kl. 04:03 skrev Alexander Matveev <alexander.matveev at oracle.com>:
> 
> Hi Magnus,
> 
> http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/
> 
> Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes.
> Webrev updated with files moved, instead of add/remove.

Thank you!

This looks good now from a build point of view, but you'll need a review from core-libs as well. 

/Magnus

> 
> Thanks,
> Alexander
> 
>> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote:
>> 
>> 
>>> On 2019-02-15 04:31, Alexander Matveev wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>> 
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage).
>>> 
>>> - Moved native code under platform specific folder.
>>> - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX.
>>> - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small.
>>> - Defines are used in Platform.cpp to initialize platform specific classes.
>>> - Removed all pragma warning and fixed all compilation warnings.
>>> - Removed unused code.
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212091
>>> 
>>> [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/
>> The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name.
>> 
>> Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system.
>> 
>> It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files.
>> 
>> (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.)
>> 
>> /Magnus
>>> 
>>> Thanks,
>>> Alexander
>