support graalvm native image

I took a look at the graalvm and have no problem creating a profile - though wouldn't it need to be a native shared library as opencsv is not a stand alone application?

As long as it is added as a new profile feel free to make the change yourself and submit a merge request as it will be a while before I have free time to take a look at this.

I'm not sure what you mean by "profile", do you mean https://www.graalvm.org/latest/reference-manual/native-image/guides/optimize-native-executable-with-pgo/ ?

PGO is a graalvm native image optimization, and does not critically determine whether or not opencsv will run properly on the native image.

"Support for graalvm native image" means that opencsv, as a library, can execute correctly when used as a dependency in a standalone application.

I'm sorry, but I've always used github and don't really know how to use sourceforge. So I'm going to briefly explain what is required for opencsv to be able to support native image here.

When opencsv runs in a native image environment, if need to use resource files and reflections, the parts opencsv used must be registered with the native image during compiling. The registration is declared through some files in the source code.

opencsv uses several resource bundles, so these bundles must be registered with the native hint. In order to register the resource file, the opencsv jar package must have graalvm's resource-config.json file in it. To comply with the specification, the file path should be "resources/META-INF/native-image/com.opencsv/resource-config.json" in the source code.

resource-config.json content(this has been confirmed):

{
  "bundles": [
    {
      "name": "convertLanguageToBoolean"
    },
    {
      "name": "mustMatchRegex"
    },
    {
      "name": "opencsv"
    }
  ]
}

Similarly, if opencsv relies on reflection for certain classes to work, there should be a "reflection-config.json" file in the same directory to register them.

reflection-config.json content(this is untested):

[
  {
    "name": "java.sql.Class[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.Date[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.Calendar[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.File[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.Date[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.Time[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.Timestamp[]",
    "allPublicConstructors": true
  },
  {
    "name": "java.sql.URL[]",
    "allPublicConstructors": true
  }
]

Once those json files are put in source code, opencsv will work in the graalvm native image.

Please refer to the graalvm documentation:
https://www.graalvm.org/latest/reference-manual/native-image/dynamic-features/Resources/
https://www.graalvm.org/latest/reference-manual/native-image/dynamic-features/Reflection/

Also see other libraries that already support native images:
https://github.com/itext/itext-java/blob/develop/io/src/main/resources/META-INF/native-image/com.itextpdf/io/resource-config.json

Hello czp. When I talked about a profile I meant that I was willing to add or allow someone to add a graalvm profile in our maven pom.xml. You can see an exampe of that in the maven section of the graalvm page.

The benefit of this is that IF changes required to make the native image are incompatible with our current requirements (like requiring a newer version of Java than Java8) we can loosen those restrictions for the graalvm profile for people who priortize that but leave the defaults alone.

If you look at the opencsv page you will see we did something similar for java9 modules.

Thanks for your patience, now I know that 'profile' means maven profile. But that's what I don't understand.

opencsv as a dependency library, rather than as a standalone application, only needs a few additional resource files to support graalvm. This does not cause jdk version incompatibility or jdk provider incompatibility. It also doesn't ask for the jdk version at compile time, unlike java9 module-info.

The graalvm files (as written above) are just normal resource files that don't affect anything until the program is finally run in the graalvm native image(outside opencsv). So I think adding a maven profile to opencsv like java9 module-info is over-engineered.