Skip to content

Remove deprecated/discouraged usages of JNA constructs #102

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

Merged

Conversation

matthiasblaesing
Copy link
Contributor

@matthiasblaesing matthiasblaesing commented May 24, 2018

This message on the gst-java mailinglist:

https://groups.google.com/forum/#!topic/gstreamer-java/hlyZ8yEo9gs

most probably resulted from using JNA 5.X-SNAPSHOT with the current gst-java codebase.

The upcoming JNA 5.X version will remove deprecated methods/elements and in addition
will not provide Pointer#SIZE anymore. Pointer#SIZE was part of class loading problems,
leading to deadlocks in the class loader and was removed without deprecation.

The changes are compatible with JNA 4.5.X and the replacements were present for a
long time (10 years + 5 years).

Unittests were run before and after the change and run cleanly.

While testing I noticed, that the version range includes 5.0.0-SNAPSHOT. I have not
looked to deeply into this, but the pom version range most probably should be:

    <dependency>
      <groupId>net.java.dev.jna</groupId>
      <artifactId>jna</artifactId>
      <version>[4.4.0,5-SNAPHOT)</version>
    </dependency>

The -SNAPSHOT version is always considered smaller as its base version. Given
that I might be a minority, having JNA snapshots present.

Pointer#SIZE will be removed from the JNA codebase (it is already
removed in master) as it is the root of class loading deadlocks.
Pointer#setString(int offset, String value, boolean wide)

was replaced by the two methods:

Pointer#setString(int offset, String value)
and
Pointer#setWideString(int offset, String value)

The same holds true for the getter.
@neilcsmith-net
Copy link
Member

Thanks @matthiasblaesing - this was in my list of to-dos (currently tied up with PraxisLIVE tasks), but hadn't realised this might be a problem already - although that message on the mailing list also made me wonder on this. (This is aside from the class initialization deadlock issue obviously, although that's not a problem unless people are using other JNA libraries too).

That POM range was meant to exclude anything JNA 5.x, in fact was meant to exclude all snapshots, except it seems I read the Maven design docs and not the docs for the actual implementation 😖

Note: Contrary to what was stated in some design documents, for version order, snapshots are not treated differently than releases or any other qualifier.

I'm wondering whether to actually use [4.4.0,4.999.0) which I've seen mentioned elsewhere - if you release eg. a 5.0-beta that would actually sort before snapshot and be in range.

@neilcsmith-net neilcsmith-net merged commit d7ab38f into gstreamer-java:master Jun 13, 2018
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

Successfully merging this pull request may close these issues.

2 participants