Compatibility features

[solind]

These are the remaining changes I had to add to sshj for compatibility with Joval's jSAF provider code. They're all relatively minor so I hope it makes sense to group them together:

1. Re-wrote try-with-resources and inferred generics constructors (no functional changes) so that the project can be built using Java 6.
2. Added a method to the Channel interface to make it possible to determine whether an EOF has been received.
3. Added some missing SFTP response codes.
4. Fixed a typo in an SFTP enum.

[hierynomus]

Hi David, unfortunately Java6 compatibility is a no-go, as per #234, the ed-25519 library we depend on is java7 only.

[solind]

Interesting. I actually compiled the ed25519-java project using Java 6, made a Java 6 build of sshj and it worked fine. (We don't allow build frameworks to pull down dependencies for production builds, we compile everything from source).

[hierynomus]

Hi David,

Unfortunately the ed25519-java project is released only with a Java7 build. So I also only support java7. Also because Java6 is EOL, and Java7 is also officially EOL-ed by Oracle, see: http://www.oracle.com/technetwork/java/eol-135779.html

So for me, adding back in Java6 support is a step backwards, also because my CI builds run with java7+, and do not test for java6 compatibility anymore. So there is absolutely no guarantee that these changes will be kept in.

[solind]

I know, they're dinosaurs, but I think we have customers who are still using it. I see it more on AIX and old versions of Linux using OpenJDK (not Oracle's VM).

How about this, what if I take responsibility for any Java 6 compatibility work? Feel free to break Java 6 compatibility and if it bothers me, I'll fix it? You won't have to worry about it, and the project can officially still require Java 7.

(Obviously though, you'll have to leave me the option of eventually giving up on trying to maintain compatibility.)

[hierynomus]

Hi David,

I had another quick look at the code. Essentially the ed25519-java library indeed is released with Java6, however the VRallev/ECC-25519 library is released with Java7. The latter one bundles the former one.

Looking through the code. I just use the djb.Curve25519 class from that library. Which is a Public Domain class.

What I would propose is that we can add back Java6 compatibility by including the djb.Curve25519 class in the codebase, and depending on the net.i2p.crypto:ed25519-java library. I'll fix this momentarily and then with your changes I'll re-add java6 to the compilation targets on the TravisCI server.

Sound like a plan?

[solind]

Sounds awesome! Thanks!

[hierynomus]

Somehow your indenting is off sometimes ;)

[hierynomus]

Can you merge in master so that the checks are green ;)

[solind]

I'm sorry man. I actually write code in vi (speaking of dinosaurs), and I normally use 1 tab for 8 spaces.

[hierynomus]

I think the right dinosaur settings are:

set autoindent
set smartindent
set expandtab
set shiftwidth=4
set tabstop=4

😉

[hierynomus]

Sorry clicked wrong button there... If you can get the branch up-to-date then we're good to go!

[solind]

I think I just did. :)