[
https://issues.apache.org/jira/browse/FINERACT-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216605#comment-17216605
]
Michael Vorburger commented on FINERACT-1214:
---------------------------------------------
[~aleks] I think I may be changing my mind on this one... :D So, the more I
work on e.g. https://github.com/apache/fineract/pull/1428 and
https://github.com/apache/fineract/pull/1433, the more I'm starting to wonder
after all if we REALLY want to have several Java clients (those "utilities" I'm
starting to contribute would have to be copy/past maintained for all such
"variants")..
For the Java 8 vs 11 "problem", we COULD just simply build the one and only
{{fineract-client}} for Java 8 (utilities should not use Java 11 syntax -
easy), so that it can be used on Android, no? About Rx... does anyone REALLY
need that? The "Synchronous vs. Asynchronous" section on
https://square.github.io/retrofit/ clarifies that the {{retrofit2.Call}} which
our SDK now returns instead of the Rx Observable (following
https://github.com/apache/fineract/pull/1420), quote:
{quote}Call instances can be executed either synchronously or asynchronously.
Each instance can only be used once, but calling clone() will create a new
instance that can be used. On Android, callbacks will be executed on the main
thread. On the JVM, callbacks will happen on the same thread that executed the
HTTP request.{quote}
so... someone remind me again why are we considering complicating our lives :P
as maintainers with building, publishing, maintaning and answering questions
about several variants of a Fineract Java SDK?
We can still have a JS/TS clients (and have FINERACT-1210 about that), but as
far as this issue is concerned, how about calling it quits and done and perhaps
just leave as-is?! The original problem I raised above IS solved now.
[~Grandolf49] do you have any interest in helping to test the current as-is
fineract-client on Android? Do we have to make the JAR built using Java 8
instead of Java 11 bytecode? Best further discussed in a separate new issue?
> SDK Swagger Client Java API methods returning Rx Observable are not intuitive
> for Java developers
> -------------------------------------------------------------------------------------------------
>
> Key: FINERACT-1214
> URL: https://issues.apache.org/jira/browse/FINERACT-1214
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Assignee: Aleksandar Vidakovic
> Priority: Major
> Fix For: 1.5.0
>
>
> I am, for the first time, attempting to fool around with our shiny new SDK
> Client Java API, for FINERACT-1209.
> I've noticed that we have configured all the service methods to returned Rx
> Observable. I'm aware of what that is, and perhaps I'm just too old and
> grumpy, but I'm not sure I like that... and am concerned that average Joe
> Java develpers using this SDK may get confused by it.
> Isn't the reality that in many many typical usages folks would just always do
> {{.blockingSingle()}} anyway? And even if we went all-in reactive in our
> SDK... A REST API call doesn't really return a _Stream_ - so the API as-is
> doesn't seem natural, to me.
> Should we go mad and build and publish SEVERAL Fineract SDK Swagger Client
> Java API libraries? io.reactivex for anyone smoking that, good ol' plain
> simple non-reactive, modern Java 11, older Java 6, 7 AND 8 (Android?)... the
> more the merrier?!
> [~aleks] [~ChinmayKulkarni] [~ptuomola] [~manthan]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
