Bartłomiej Żyliński

Hi,

I am using JMH to run benchmarks. The calculation of the final results is also done by JMH.

I just got the data I needed from the JMH results. You can see this operation in the following class: AggregatorsUtil.java.

If you would like to know more about the computation done, then I am afraid that you will have to dive into the JMH internals.

Hope this answers your question.

Hi,

Personally I will go with using LDAP only as a store for users and their authentication information. Then I would use Keycloak as an authentication tool.

Here is the documentation on how to configure Keycloak for usage with LDAP.

Thanks!

Thanks!

You are right A<T> is inconsistent with letter M<T>, I will fix it.

Thanks ! Great to hear that.

Good suggestion with Keycloak alternatives. I will cover it in one of my future articles.

Fixed, thanks!

Firstly, sorry for not making it clear enough but the definition is not mine, it is quoted from Robert C. Martin's Book "Clean Architecture" - I am not brave enough for trying to redefine SRP.

Yes, you are right, “Joe” can be an actor, according to the book actors are entities whose decisions can result in changes inside the system. Such entities can be users, stakeholder, developers working on the code or even some other parts of the system.

If "Joe" is the only person whose decisions may end up in changes inside “Account” class, the class itself is not impacted in any way by the rest of the system and changes inside the class are being done by a single developer then as far as I understand this definition Account is in line with SRP.

On the other hand if there is another user "Bill" who is "Some High manager in transfers division" and needs some changes being done in transfer logic and he does not know about “Joe” existence (or simply “forgets” to inform him about such change). Then “Joe” still uses the "transfer" method not knowing about changes made.

Another example can be when “Joe” needs to make some changes in UI and in transfer logic. UI task goes to a developer (from front-end team) and back-end task goes to another (from transfers team) then we have two actors (developers) whose actions result in changes inside a class. Despite the fact that “Joe” wanted both changes.

Hi Robert, thanks for your comment !

In general you are right according to the presented definition. Unfortunately there is a catch in all of this. I mentioned it in the paragraph with the database example.

Here the situation is quite similar - the frontend which relies on the HTML display method from Account is just another actor which may affect the class.

So in such a case one have two actors: a group of people interested in the functionalities of the transfer method and a group of people who use data prepared by display method.

In theory one can build the class in such a manner to make it immune to changes requested by frontend actor but if it is really possible is quite a different thing.

1. It depends, in some use cases, I mentioned them in the article, voids are must have and "fighting" with them may not be profitable.

2. About how to replace them again it depends - each case should be decided separately.

For long running jobs returning true/false or some enum gives us little more information then using void while on the other hand when we want to update a property of an object it may be better idea to create a new object with this property updated than using setter.

3. About Kotlin - there is a Void type in Java which is responsible for doing exactly that, representing void as a type, but what is really handy here is the Kotlin way of declaring methods.

In my opinion Kotlin way:

fun doSth(...args): Unit

is more descriptive (slightly but still) than Java way:

void doSth(...args)

1. Sorry that it took me so long to answer your comment.

2. In my opinion it is very hard to separate void methods from side effects, because side effects are the only reason why void exists. On the other hand side effects are not tight to void methods. Every method can perform any kind of side effect, if it should is another topic.

3. By lack of contract I have meant we have input and output, which holds true for normal methods, while void methods only have input and you have to reason about exact output.

4. I agree with your argument about bad design, but the less "typefull" your API is the easier it is to make it bad.

5. About the tests - as I said in point 2 there are no void methods without side effects so if side effects are harder to test void methods by extension are also harder to test.

6. Now I can see that the code sample may have added more clarity to my arguments.

From what I understand about HIPAA it is more legal matter then code itself.
You have to check what exactly is allowed for such entities while integrating with 3rd party service providers. For sure you will have to add some security checks while implementing some way to interact with outside world.

Thanks. With this "for beginners" it depends, for sure not for people with zero Java knowledge but if you know some basics it can be a good point to start your adventure with JVM.

Thanks

There are no funny or bad questions. We are here to share knowledge.

In case of monads and functors this explanation sounds very nice.

Functors apply a function to a wrapped value while Monads apply a function that returns a wrapped value to a wrapped value.

Additionally monad require only three things parameterized type M<T> and two functions 'bind' and 'unit' which must have certain signatures.

In case of function signatures monadic ‘bind’ function should return value already wrapped in monad. If you change the signature of functions passed to monad for ‘T->U’ will get compilation error somewhere in ‘bind’ implementation and you will have to implicitly call ‘unit’ function to wrap value in monad.

Secondly, if you decide to change 'bind' signature to ‘(T-> U) = U’ you will lose the possibility to chain function calls and your implementation will no longer be able to satisfy monad laws.

As an example, you can try to use non-monadic hashCode function in the Stream::flatMap ('bind') method you should get a compilation error pointing that hashCode function has an inappropriate signature.

Hi,

I have never heard of any official naming convention for monadic function names other then unit and bind. I think that the combination of 'of' for 'unit' and 'flatMap' for 'bind' is such standard in case of Java.

I decided to name my function 'map' instead of 'flatMap' because it is more widely use and I thought that 'flatMap' can be misunderstood as the combination of 'map' and 'flatten' operations what is not exactly equivalent of 'bind' function.

In my LogMonad 'map' function is an equivalent of monadic 'bind' which has the following signature (T -> M<U>) = M<U> that is why I decided to implement functions from an ‘Example’ class in such a way.

Bartek