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

Support Java 1.6 (and below if possible) #11

Closed
andyrozman opened this issue Jan 13, 2015 · 7 comments
Closed

Support Java 1.6 (and below if possible) #11

andyrozman opened this issue Jan 13, 2015 · 7 comments
Milestone

Comments

@andyrozman
Copy link

Hi !

I have application which is built with Java 1.5. Is there specific reason, why Java 7 is used... I have seen that JNA 4 is done with 1.7, is this the only reason? Would it be possible to create 1.5 binaries? I mean I can build them, question is what was reason to use J7?

Take care,
Andy

@gary-rowe
Copy link
Owner

The reason for Java 7 was that Java 6 (and earlier) has reached end of life and continued use should not be encouraged. I would urge you to upgrade your JVMs to 1.7 if possible.

Obviously, if that is not possible due to environment restrictions then the code is open source under MIT licence so you should be able to recompile it to a lower byte code level. I've not done this myself but I'd be interested in the outcome so I could add it to the support notes.

@andyrozman
Copy link
Author

When making a library that others can use, it is good to go with oldest version you can (this would be probably 1.5 in your case since Generics are used), so that as many as possible can use it...
I tried using in on Java 5, but there were some issues:

  • there were some @OverRide tags, overriding methods which you are implementing from interface
  • JNA 4 Java version is higher than 1.5 (perhaps 1.6). I tried with last of 3.x versions (3.5.2) and it works.. Did you need any specific functionality from JNA 4, or did you just take the latest when project was started...

@gary-rowe
Copy link
Owner

I accept your point about targeting as low a JVM as you can, but there comes a time when backwards compatibility becomes a burden to the main codebase.

I could remove the @OverRide annotations but it feels wrong to remove that safety net. It's good programming practice to allow the compiler to warn when code isn't actually overriding/implementing a method. This annotation is compatible with Java 6.

When selecting JNA I just went for the latest since it is most likely to have the least bugs and most mature code.

Overall, I could just about be convinced to lower the minimum JVM to 1.6 but I just can't condone 1.5 on the grounds that it's been EOL since October 2009.

@andyrozman
Copy link
Author

I agree with Java 5 here... If you implement some method (from Interface) you don't override it you implement it...

Even if you support just Java 6, you would need to go with latest JNA 3.x release.

I work for professional company and I know that one some projects we still use Java 5 (custom implementations).

@gary-rowe
Copy link
Owner

OK, I'll look into aligning with Java 6 on my next refresh of the project.

@gary-rowe gary-rowe removed the support label Jan 16, 2015
@gary-rowe gary-rowe changed the title Java 1.5 Support Java 1.6 (and below if possible) Jan 16, 2015
@gary-rowe gary-rowe modified the milestone: Release 0.3.0 Jan 16, 2015
gary-rowe added a commit that referenced this issue Jan 29, 2015
@gary-rowe gary-rowe added the awaiting review This code is awaiting the original creator of the issue to review the solution and provide feedback label Jan 29, 2015
@gary-rowe
Copy link
Owner

Made various adjustments to support Java6 and JNA 3.5.2.

Ready for review and close.

@gary-rowe
Copy link
Owner

Code is now compiled under JDK1.6.

@gary-rowe gary-rowe removed the awaiting review This code is awaiting the original creator of the issue to review the solution and provide feedback label Jan 31, 2015
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