[JSch-users] Could ChannelSftp.LsEntry be declared static

[laogao]

Hi,

It seems (as of version 0.1.51) the inner class LsEntry is declared as
"public class LsEntry" inside ChannelSftp. I believe there is a subtle
difference between inner (non-static) classes and nested (static) classes,
which is causing me some headaches using JSch e.g. from Scala (could be
circumvented but the code looks weird). I'm wondering if this LsEntry could
be declared static, i.e. as nested (static) class, since it doesn't seem to
require (or depend on) concrete instances of the enclosing class
(ChannelSftp). Or is there something I blindly overlooked?

Thanks,
laogao

[Atsuhiko Yamanaka]

Hi,

+-From: laogao <***@gmail.com> ----
|_Date: Tue, 20 May 2014 01:09:33 +0800 __
|
|It seems (as of version 0.1.51) the inner class LsEntry is declared as
|"public class LsEntry" inside ChannelSftp. I believe there is a subtle
|difference between inner (non-static) classes and nested (static) classes,
|which is causing me some headaches using JSch e.g. from Scala (could be
|circumvented but the code looks weird).

What kind of headaches do you have?
Usually, we are writing its tests by using scala, and we have not had
such problems yet. It is helpful to share your problem.

As for handing LsEntry class, for example, we have been doing as follows,

import collection.JavaConverters._
val c = session.openChannel("sftp").asInstanceOf[ChannelSftp]
c.connect();
c.ls("/tmp/").asScala map {
case f: ChannelSftp#LsEntry => err.println(f.getFilename);
}

| I'm wondering if this LsEntry could
|be declared static, i.e. as nested (static) class, since it doesn't seem to
|require (or depend on) concrete instances of the enclosing class
|(ChannelSftp). Or is there something I blindly overlooked?

I agree that, but the changes for the modifier of public methods will
cause binary incompatibility, and there is no plan to change it.


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel [phone]
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk

[laogao]

Hi Atsuhiko,

Thanks for clarifying. I did overlook the impact w.r.t. binary
compatibility.

I understand the problem could be circumvented in Scala by type projection,
i.e. ChannelSftp#LsEntry . Still it would be nice if we can import LsEntry
in Scala directly (or let Scala "see" the class so to speak). This could be
useful to a) avoid reflection, b) be more REPL-friendly, and c) help
writing tests/mocks from lib users' perspective.

Maybe there's a chance in the future we can do something about it.

Thanks & Best Regards,
--
laogao

Post by Atsuhiko Yamanaka
Hi,
|_Date: Tue, 20 May 2014 01:09:33 +0800 __
|
|It seems (as of version 0.1.51) the inner class LsEntry is declared as
|"public class LsEntry" inside ChannelSftp. I believe there is a subtle
|difference between inner (non-static) classes and nested (static) classes,
|which is causing me some headaches using JSch e.g. from Scala (could be
|circumvented but the code looks weird).
What kind of headaches do you have?
Usually, we are writing its tests by using scala, and we have not had
such problems yet. It is helpful to share your problem.
As for handing LsEntry class, for example, we have been doing as follows,
import collection.JavaConverters._
val c = session.openChannel("sftp").asInstanceOf[ChannelSftp]
c.connect();
c.ls("/tmp/").asScala map {
case f: ChannelSftp#LsEntry => err.println(f.getFilename);
}
| I'm wondering if this LsEntry could
|be declared static, i.e. as nested (static) class, since it doesn't seem to
|require (or depend on) concrete instances of the enclosing class
|(ChannelSftp). Or is there something I blindly overlooked?
I agree that, but the changes for the modifier of public methods will
cause binary incompatibility, and there is no plan to change it.
Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel [phone]
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk