Johannes Schneider [Deactivated] [Suspended]

Yes. You are right ;-) It contains an "or"....

Yes. You are right ;-) It contains an "or"....

The main idea behind this article is too keep the lambdas clean.
Therefore I suggest do split that one filter up into multiple filter steps.

Instead of one lambda with a name including "And", we have to filteres that will be reusable and can even be replaced with a method reference.

persons.stream()
.filter(user -> user.isMale())
.filter(user -> user.isAdult())
....

To answer my own question:
I think I am able to reproduce the problem with the following code:

Could anybody take a look and see if I am missing something?

(https://github.com/jschneider/com.cedarsoft.monorepo/blob/develop/tests/roach-motel/src/test/java/com/cedarsoft/tests/roach/motel/RoachMotelTest.java)

{code}

package com.cedarsoft.tests.roach.motel;

import org.junit.*;


/**
* @author Johannes Schneider (<a href="mailto:js@cedarsoft.com">js@cedarsoft.com</a>)
*/
public class RoachMotelTest {
@Test
public void it() throws Exception {

for (int i = 0; i < 10000; i++) {
RoachMotel roachMotel = new RoachMotel();

Assert.assertEquals(0, roachMotel.a);
Assert.assertFalse(roachMotel.called);
Assert.assertEquals(0, roachMotel.c);


new Thread(new Runnable() {
@Override
public void run() {
roachMotel.doIt();
}
}).start();


long start = System.nanoTime();

while (true) {
if (roachMotel.a == 0) {
Assert.assertFalse(roachMotel.called);
Assert.assertEquals(0, roachMotel.c);
}

if (roachMotel.called) {
Assert.assertEquals(1, roachMotel.a);
}

if (roachMotel.c == 1) {
Assert.assertEquals(1, roachMotel.a);
Assert.assertTrue(roachMotel.called);
break;
}
}

System.out.println("Iteration took <" + (System.nanoTime() - start) + " ns>");
}
}

/**
* @author Johannes Schneider (<a href="mailto:js@cedarsoft.com">js@cedarsoft.com</a>)
*/
public static class RoachMotel {

private static Object monitor = new Object();

int a;
boolean called;
int c;

public void doIt() {
a = 1;
synchronized (monitor) {
called = true;
someMethod();
}
c = 1;
}

public boolean isCalled() {
return called;
}

private static int someMethod() {
int a = 0;
for (int i = 0; i < 100000; i++) {
a += i;
}
return a;
}
}
}

{code}

More interesting:
How easy is it to show that problem in a concrete example (as simple as possible)?

Could you ever trigger that problem?

In my experience it is often nearly impossible to trigger these behaviors - not until you know an awful lot about the JVM internals (which I don't).

If you don't want to add a dependency - fair game. There may be reasons - depending on the project.

But please, please take a *look* at the Guava/Apache Commons code and copy their solution.

I have seen so many bugs in these "two stupid lines of code" methods - it is unbelievable (most of course by myself ;-)).

There are other alternatives than just: Add a dependency or write own code...

myString == null || myString.length()==0;

should be a little bit faster.

And guess what? That's how it is implemented in Apache Commons....

You even don't need the field "b" at all. And why start with that "large" values of a?

Just initialize with "0" and increment by one.

Well. I am a programmer because I am lazy ;-)

I want the computer to do the hard work. And I will do everything that is possible to avoid tedious work.

I spent 4 hours to develop a programm that solves a boring 1h task...

Okay. So I did the calculation:

- I needed a sheet of paper to do it. Too many variables (for me) - I made a (simple) mistake when calculating the second path

Nothing I could learn from that. Besides that the computer is a lot better at adding numbers then me. (Already had the idea that might be the case...)

Which brings me back to my initial feedback: If you want to show how inner classes work, use a (much) simpler example. If you want to practice working memory, the use of inner classes is not relevant.

I don't get the point of this quiz.

Should I find some gotacha most people don't know about inner classes?
--> Then it should be simpler. And I would love to learn from it.

Is it just to practice calculations?
--> Then I don't want to waste my time on it, because I am too lazy for that ;-)

BTW: I am a very experienced developer and have never seen the "new Outer().new Inner()" syntax.

Therefore this puzzle has had a value for me. Thanks.

So I think the battle is over...

Of course you could just use comments. But annotations are part of the signature. They are instantly visible within (most) IDEs when using code completion. Ever tried to find important information within a very large JavaDoc comment? Annotations can be extracted using Annotation Processors, used for static code analysis. But just look at the examples. The advantages should be obvious. In my opinion those annotations are just much better than any javadoc. And the documentation aspect is just the first step...

One API to rule them all... Could be nice. But I don't know if this is really possible... But if you give it a try: I'd like to take a look at it ;-)

1. Of course this is not faster. But in most of the cases there are much more calls to get than to set. Therefore I prefer an expensive setter over an expensive getter... (for *most* cases) 2. That is what I tried to point out... Thanks for clarifying it...

Of course this is possible. But then you have a call to Arrays.copyOf() for each call to your setter (forgivable in most projects) and getter (critical in most cases).

Yes - of course. Reading every doc, knowing and understanding every detail in depth will protect you from most of the surprises... Interestingly those "surprises" can be found in so many projects out there... I don't dare to even think it: But maybe not everybody is as perfect as you and does not know everything... BTW: I have even seen some projects out there that contain bugs (really!)!!!

Yeah, but when assigning the collection to the field, you also don't have control over the collection... Anybody (at least the caller) might change that collection at any time... So that doesn't seem to be the silver bullet, too...

Could you show me your typical implementation of getter/setter of collection fields? I am really interested in.

Thought up? Maybe. But could you show me how you typically implement getter/setter for a collection field? I have seen that type of implementation several times... And there exists at least one call that shows that this implementation is buggy...

Sorry for that. If it is any consolation, I have heard/read most of the arguments from Subversion supporters. Just exaggerated a bit. So you may use the arguments in your next discussion. They just need a bit polishing...

Hi Jacek. Thanks for your comment. Your analysis is quite correct... Might wanna check the update..

Thanks for all that guys that down voted... That is the biggest confirmation, that there are people out there that *really* argue that way. Have met too many of them, too... So no allegation. I will try if it is possible to change the headline.

Yep. You *will* end writing custom mappings for XStream. So did I... But I think this is not "best of two worlds"... It is a complicated workaround around a "problem" that is self made. And you are cursed to run into it when using XStream for mid/long term serialization... I have written many custom converters in my life. At first that can be done easily. But two or three iterations later there are fancy hacks needed to determine between the different versions. And another iteration later you start thinking about dropping support for old setting files... Custom converters are not the solution. They are a symptom.

Yes - you are right. The title is too generic. But I hope all those XStream (and similar tools) lovers will get that point. The tools itself are great. They are just misused...

Oh, I like your comments: "That is nonsense. We just need to change the language..." ;-). Okay, let us change the language and eliminate wildcards. But until then...

Okay, thanks for your constructive criticism :-). I have created an new entry that shows an example that clearly shows that collections *without* wildcards are nonsense. http://blog.cedarsoft.eu/2008/01/12/why-you-should-only-return-collections-with-bounded-wildcards/