Skip to content
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

Open
bmarwell opened this issue Apr 3, 2019 · 7 comments
Open

Directory names should have a standard naming convention. #31

bmarwell opened this issue Apr 3, 2019 · 7 comments

Comments

@bmarwell
Copy link
Contributor

bmarwell commented Apr 3, 2019

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

  • Users could supply additional paths via config file.
  • Users could also supply additional search paths dynamically by providing a new OsInfo object and a List of path fragments.
  • The new Config class would then load the defaults from the enum and add the additional entries.

Example entries for the defaults

  • Windows 64 x86-64
    • windows-amd64-64
    • windows_64 (for compatiblity)
  • Windows 32
    • windows-x86-32
    • windows_32 (for compatiblity)
  • Linux 64 bit
    • linux-amd64-64
    • linux_64 (compat)
  • Linux arm64
    • linux-armv7l-64

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.

@bmarwell
Copy link
Contributor Author

bmarwell commented Apr 3, 2019

Might look like this: https://github.com/java-native/native-lib-loader/tree/issues/31-dirconvention

Review wanted. :-)

@ctrueden
Copy link
Member

ctrueden commented Apr 3, 2019

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.

@bmarwell
Copy link
Contributor Author

bmarwell commented Apr 3, 2019

Sure. I think it needs some more attention, like: Reading custom properties, etc.
I’m not sure how I will do this at the moment. I‘m looking forward to your thoughts. You might also get some README.md updates :)

@bmarwell
Copy link
Contributor Author

bmarwell commented Apr 4, 2019

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. uname -a in addition would also be helpful.

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:

  • AIX PPC64 (I think it is always BE)
  • Linux PPC64 BE (Ubuntu 12.x should be available in BE)
  • Linux PPC64 LE (starting with Ubuntu 14.04 LTS)
  • MacOS (is this relevant, Mac on PPC?)
  • Raspian (or any other Linux) on any arm combination

By the way:
The site http://lopica.sourceforge.net/os.html is outdated. And it doesn't contain all the information. Maybe we could host an updates version over at java-native.

Results

AIX 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

@bmarwell
Copy link
Contributor Author

bmarwell commented Apr 5, 2019

Before I create pull request I will rework the branch to use existing conventions.

https://github.com/trustin/os-maven-plugin

Same as

https://github.com/google/osdetector-gradle-plugin

@bmarwell
Copy link
Contributor Author

bmarwell commented Apr 7, 2019

@ctrueden please review Pull request #32

@bmarwell
Copy link
Contributor Author

Do you think we need a seperate dir for softfloat and hardfloat?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants