-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Directory names should have a standard naming convention. #31
Comments
Might look like this: https://github.com/java-native/native-lib-loader/tree/issues/31-dirconvention Review wanted. :-) |
Awesome, thanks @bmhm. I don't have a lot of time to review in detail, but I looked it over quickly. Thanks for taking initiative on this. I'm all in favor of improving the directory naming convention, and in particular making it more configurable to meet everyone's use cases. |
Sure. I think it needs some more attention, like: Reading custom properties, etc. |
I'm fiddling with the default entries at the moment. I removed AIX Little Endian, as it does not seem to exist. But Linux supports both LE and BE on ppc64. So the question is: How do we recognize which is which? I need some help with this, perhaps anyone of you has access to a Linux PPC64 system and can execute those commands. public class WhatOS {
public static void main(final String args[]) {
System.out.println("Name [os.name] = " + System.getProperty("os.name"));
System.out.println("Version [os.version] = " + System.getProperty("os.version"));
System.out.println("arch [os.arch] = " + System.getProperty("os.arch"));
System.out.println("bitness [sun.arch.data.model] = " + System.getProperty("sun.arch.data.model"));
System.out.println("bitness [com.ibm.vm.bitmode] = " + System.getProperty("com.ibm.vm.bitmode"));
System.out.println("endian [sun.cpu.endian] = " + System.getProperty("sun.cpu.endian"));
}
} We would need the output for at least:
By the way: ResultsAIX 7.2 ppc64 @ openj9$ java WhatOS
Name [os.name] = AIX
Version [os.version] = 7.2
arch [os.arch] = ppc64
bitness [sun.arch.data.model] = 64
bitness [com.ibm.vm.bitmode] = 64
endian [sun.cpu.endian] = big
$ uname -a
AIX <HOST> 2 7 <HASH> Raspbian stretch arm6l @ oracle-hotspot$ java WhatOS
Name [os.name] = Linux
Version [os.version] = 4.14.50+
arch [os.arch] = arm
bitness [sun.arch.data.model] = 32
bitness [com.ibm.vm.bitmode] = null
endian [sun.cpu.endian] = little
$ uname -a
Linux raspberrypi 4.14.50+ #1 Fri Sep 21 11:29:13 CDT 2018 armv6l GNU/Linux Ubuntu 18.04 arm64/aarch64 (cortex-a57) @ OpenJDK 1.8.0_191 64-Bit Server arm64$ java WhatOS
Name [os.name] = Linux
Version [os.version] = 4.15.0-45-generic
arch [os.arch] = aarch64
bitness [sun.arch.data.model] = 64
bitness [com.ibm.vm.bitmode] = null
endian [sun.cpu.endian] = little
$ uname -a
Linux ubuntuarm64 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:32:18 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux |
Before I create pull request I will rework the branch to use existing conventions. https://github.com/trustin/os-maven-plugin Same as |
Do you think we need a seperate dir for softfloat and hardfloat? |
I might add one or another pull request at a later time which will sort out the folder names (retaining compatiblity, of course).
Standard path name proposal
Somethink like
os-arch-bitness[-special]
could work nicely and is a bit more extensible.Implementation details
A small singleton instance (using an enum since we are on Java 6 now) would suffice for the default mappings. The Map could hold something like this: Map<OsInfo, List> where the OsInfo is a simple POJO which holds the OS name, arch and bitness, and optionally a
special
fragment (like fp on ARM). The value is a list of search paths. The enum instance would only hold the defaults, though.Configuration options
Config
class would then load the defaults from the enum and add the additional entries.Example entries for the defaults
etc.
Other advantages
We could replace the big and unmaintainable
switch
statement with this lookup table. In fact, this is the main issue.I might create a pull request in the future for this.
The text was updated successfully, but these errors were encountered: