Java's shitshow, or why I'll never like java, the language:

The fact that you cannot read the length of an iterable at any point in time without iterating through it. Did I just read this from DB? Yes, I did. Do I know how many items I read? No. Why? Because fuck the designers of this shit language and all its shitty third-party libraries. 😠😠😠

Maybe it a memory saving thing?

Although there are a workaround. You could use "SELECT Count()" or go to last row by using cursor.last() and get the row position/size by cursor.getRow().

Java is weird cross over between C++ and C# . It is not easy as C# since simplicity is not in its design but it's not bare as C++ which philosophy is here the tools, build it yourself.

You are right in that JDBC part in Java leave out a lot of thing that why I use extended JDBC (custom library extended over JDBC)

This is not a Java problem... You should read up on how and why iterables work like that. Similarly, that's how enumerables work in C#.

@mr-user
The "memory thing" is the reason why you use an optimized dbs that can manage complex queries, isn't it? Otherwise document management with java would be an absolute nightmare. I also don't understand people who refuse to properly write queries but then write a massive RAM hugging algo. 😐
I finished the task, but I still think the guy writing this service deserves a metal stick up his butt.

@sSam "said by every java dev grandpa"

@NoMad

What is the return json (it return json right?) of that API? If the API don't have filtering,pagination,and versioning I don't know what to say.

Some algorithms hog memory to improve performance and some people just write terrible algorithms.

Some of the problem are due to comprise. We cannot get a hardware so let offload the task to the clients.

@mr-user not even client side. This is still on the server side. There was a bug where one query was not returning proper data and I needed to see the length of the results.

You know, instead of printing a huge chunk of prettified json, I wanted a headcount and maybs some summarized info.

@NoMad

After reading comment , you are actually getting "Iterable" and not "ResultSet" ?

What do you mean by proper data? They return the wrong data or the length doesn't match?

Am I the only one who unit test their database?

@mr-user apparently you are 😛
I can't be bothered going into the details tbh. The query had a problem and I knew it from the start and it's fixed now. The rest of it is responsibility of the next moron who's in charge of this shitshow.

@NoMad If it is a NOSQL database I cannot blame them for not unit testing it since I cannot find who they can even be tested.

If it is a traditional RDMS you can create a transaction and do whatever you want to it and finally rollback. Everything is safe and sound.

Additional Info : It's a pain to test database. You have a write a lot of helper functions and procedure which some will not bother with it.

@mr-user the database was not to blame (nosql) in this one instant but the service/controller(mvc)/server.
Or rather, the developer of the service did not understand their interaction with the database. Can't blame them tho, you do need to have a proper dba to fix/improve these stuff... So, let's say management's failure to understand the proper resources required for the project.
But also, really, java would be a good choice if it was still 2007. Not now. This shit needs migration to a better language.

@NoMad

Don't tell me you are having those being tied down to "framework" problem?

Java developer have the tendency to use "Spring" when they hear "service" or "web". Personally I prefer a light weight library/framework which allow me to toss them out and switch to another one.

Now everything came back to "managements".

@NoMad An iterable doesn't have a length by design - it may not actually *have* a length associated with it (could go on forever), or that length may not be retrievable. I (think) that's the same as most other languages.

Too many API designers though decide that it's an appropriate object to return as an abstraction of a collection even when there *should* be an attainable length. (It's almost never an appropriate return type imho.) Probably because said designers get "return the most abstract thing you can" drummed into them by trainers and lecturers who've never written a real application in their lives...

@AlmondSauce python also does the same, but you can get length in a oneliner like:
sum(1 for e in iter)

Unfortunately, java needs a shitton more writing to give me this same exact result. And ofc, three different other libraries to be added to an already-shit maven project. ¯\_(ツ)_/¯

@AlmondSauce

If they want to return the most abstract thing just return an array or an Object !! You are right in that returning the most abstract thing is not the right choice.

"return the most general type" is completely ass backwards. What interfaces should do is accept the most general type possible and return the most specific one.

Unless there's some shitty variance handling in Java forcing that, in which case *laughs in Scala*.

@NoMad but that Python one liner would construct and force the existence in memory of every iterator object at once, that could crash your system or make it unresponsive if it's from eg. a streaming data source which can be thought of as an infinite list. This has nothing to do with Java, it's what iterators are designed for - index free one-by-one processing of data (I mean you can batch them I guess but not the point here).

If you're needing to do that it sounds like bad library design to me, rather than bad iterators in Java (which are fairly nice imho).

@NoMad You can get length in a one-liner in Java as well, but I won't pretend it's pretty 😂

Stream.generate(() -> null).takeWhile(x -> it.hasNext() ? it.next() != null : false).count();

Think I've got a SO answer on that topic somewhere, perhaps I'll update it with that 😬

Can't say I've ever been a Python fan, but Java's certainly showing its age in some areas. Kotlin's probably my favourite language atm tbh, where it's much saner:

it.toList().size