Java References vs OutOfMemoryError

3

2

1

... and here it comes: How I Learned to Stop Worrying and Love OutOfMemoryError  

Go go go, read it! ;)

I have found this article while searching something exactly like it on StackOverflow: SoftReferences vs Weakreferences / OutOfMemoryError so I'm just (re)sharing it.

All my interest about java references' is thanks to Marek Defeciński and his todays speech about them   (you can easy find him @ web - he's well known megrer on GitHub* ;) ) 

(* - Jacek Laskowski today talked about GitHub and it's social aspect that motivates people to constant growing their skills - great job!)

Comapring floating-points

Seems straight-forward... "Use delta!"


But today I tried explain it to my fiend, and... it wasn't that easy for me. So as title of my blog says "if you can't explain it simply you don't understand it well enough" - it was time to use google :)


And here it comes: http://randomascii.wordpress.com/2012/06/26/doubles-are-not-floats-so-dont-compare-them/ - I really recommend reading it, even as a Senior Developer you can be surprised by some things (I was).

Some sample to encourage you - yes, it's worth your damn precious time:

   float x = 1.1;
   if (x != 1.1)
      printf(“OMG! Floats suck!\n”);

On a fairly regular basis somebody will write code like this and then be shocked that the message is printed. Then somebody inevitably points them to my article and tells them to use an epsilon, and whenever that happens another angel loses their wings.

As mentioned in above article choosing the right epsilon the key. Here is nicely explained how to how to make  that choice.

And lastly, link provided by Tomek - a lot of reading ;)

Java puzzle ;)

    Integer a = 200, b = 200;

    System.out.println(a < b || a == b || a > b);

    System.out.println(a <= b || a > b);

I'm not the type of guy who TYPICALLY likes stuff like that. IMO code used in many java-mind-fucks is just unreal to be found in application written by someone that is not out of his mind ;) But this one posted here I find to be just lovely :)


If you have your own favorites, post them as a comment :)


Ok, but lest focus on above code sample.

Here is short answer and explanation: FALSE and TRUE. True because of both `a` and `b` are damn numbers, so it has to be truth no matter what. And false, because: `a` is NOT lower than `b`; `a` is NOT grater then `b` and `a` and `b` are not pointing to the same Intereger object. Cache size is <-128, 127> - check the Integer javadocs if needed.

But that's not all, things can start being interesting from now on. You can actually make both of those sysouts TRUE! How?

Take a look here:



from java.lang.Integer:

    /**
     * Cache to support the object identity semantics of autoboxing for values between
     * -128 and 127 (inclusive) as required by JLS.
     *
     * The cache is initialized on first usage.  The size of the cache
     * may be controlled by the -XX:AutoBoxCacheMax=<size> option.
     * During VM initialization, java.lang.Integer.IntegerCache.high property
     * may be set and saved in the private system properties in the
     * sun.misc.VM class.
     */

    private static class IntegerCache {
        static final int low = -128;
        static final int high;
        static final Integer cache[];

        static {
            // high value may be configured by property
            int h = 127;
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
            if (integerCacheHighPropValue != null) {
                int i = parseInt(integerCacheHighPropValue);
                i = Math.max(i, 127);
                // Maximum array size is Integer.MAX_VALUE
                h = Math.min(i, Integer.MAX_VALUE - (-low));
            }
            high = h;

            cache = new Integer[(high - low) + 1];
            int j = low;
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);
        }

        private IntegerCache() {}
    }

It's like mindfuck inside mindfuck - no1 expects this :)

Anyway, empowered with that knowledge, lets hope it's not useless, but alike to the python paradox. Knowing that little trick does NOT make you a better programmer, but there is a big chance that you ARE already a good programmer if you know about it ;-)

Some simple Windows tools that will make you happy

Currently I'm migrating from one PC to the other, so there are couple of things that I HAVE to take there with me:
 

Map Any Key to Any Key on Windows 7 / XP / Vista - can be useful if you have page up and page down keys next to arrows, IMO home / end should be placed there.

Ditto - Clipboard Manager - remembers all CTR+C 's :)

Unlocker

Producer-Consumer sample - Listing files

Listing files is reeally slow operation.

That's why I decided that it will be a good use case to have some fun with java's concurrency.

Producer-Consumer pattern seemed to fit my needs.

1. Producer is listing all files from given directory. 
2. Consumer is filtering proper files and propagates this data to GUI in real-time. 
3. Both are connected by BlockingQueue: 

BlockingQueue<List<File>> myQueue = new LinkedBlockingQueue<List<File>>();

Please find my sources @ https://bitbucket.org/pawelmichalski/repo/src.

... Actually I should write something about my code to justify some of my implementating decisions, but it's being late right now in Poland :) so consider this entry as asking for code review in some free time.


cheers.

CodePro AnalytiX by Google.

Some of my older posts contained my recommendation for The Pragmatic Programmer book. I must say that's a truly awesome book. But it's not for everyone. It's addressed to those who CARE. Care about their work, career, self-development, etc... I'm so amazed by this book, that I'm willing to summarize some of its chapters, but right now I just need to quote single thing:


Now that you have some guidelines on what and when to add to your knowledge portfolio, what's the best way to go about acquiring intellectual capital with which to fund your portfolio? Here are a few suggestions.

Learn at least one new language every year.

Read a technical book each quarter.

Read nontechnical books, too.

Take classes. 

Participate in local user groups. Don't just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.

Experiment with different environments.

Stay current. 

Get wired. 

I didn't strip that the-one-and-only point from the comment because it's the one that I find the easiest and most rewarding, yet so often ignored.

I'm proud member of Java User Group Łódź. During the latest prelection, one of the questions asked to presenter has inspired my to find some tool for measuring code metrics... I just wanted to have some fancy tool, that would make me smile and tell me "your code looks great!" ;). So I did what I do in most cases - I went to stackoverflow, and THIS is what I have found.

What made me curious was answer,  that was posted long after question was asked, and yet it has the most up-votes. It was about CodePro AnalytiX by Google - plugin for Eclipse. Wow, that's even more than I was searching for!

Key (at least for me) features:

Metrics: just metrics. Those that seem to be bad, are colored red.

Code Audit: yet another tool like Sonar or findbugs.

JUnit Test Case Generation: This is really cool, try it. How does it work? (from specification):

1. generates a list of values for the fixture (if the target method is an instance method) and each of the arguments,
2. determines which combinations of values to use to invoke the method,
3. computes the result of invoking the method,
4. figures out how to validate the result, and finally
5. generates one test method for each combination of values.

Of course in most cases  (sometimes - as on image - it works better) 'tested' is only:

assertNotNull(result);

but even though it works as great stub that can be filled with real testing code.


Similar Code Analysis: Searches for code duplication - works better than WinMerge ;)

There are much more of features that CodePro has to offer, find them by yourself. It's so enjoyable.

One last remark: CodePro has different versions for different Eclipse versions. Latest is 3.7 - for Indigo. But it works good with the new Juno, too - trust me ;)

Opowiastka

Dziś będzie opowiastka, więc będzie po polsku, bo tak łatwiej.

Z okazji zmiany numeru telefonu na fejsbuczku, portal ten zaskoczył mnie czymś, co chyba trzeba potraktować jako rodzaj troski...

Prawda, że to miłe? Ktoś nade mną czuwa!

No dobrze, ale co z tego? No w sumie nic... bo w realnym życiu, a przede wszystkim w realnej pracy, czuwać powinniśmy sami nad sobą. Jak?! Ano oczywiście testami...

Wczoraj, w sumie to całkiem świeżo po przeczytaniu powyżej przytoczonego maila, kumpel w pracy zapytał mnie o kod, w którym jakiś czas temu coś zmieniałem... Od tego czasu minęły ponad 2 tygodnie, a ja zdążyłem zwiedzić 2 projekty, więc mój bufor zdążył się wyczyścić i zapełnić czymś zupełnie innym. Owe "coś" to były zmiany nietrywialne - w sumie bardziej przepisanie niemal od zera części funkcjonalności, niż refaktoring. Pytanie sprowadzało się mniej więcej do: czemu to nie działa?! No i miałem problem... Kod, którzy przerabiałem przez ponad 2 dni, okazał się wadliwy. Można by te zmiany zrevertować, gdyby nie to, że na ich bazie szedł cały późniejszy development i w międzyczasie doszło już pewnie kilka lub kilkanaście commitów kolegów z teamu. Więc najprostszą i w sumie jedyną opcją było wytropienie błędu.

Testów było mało, ale wszystkie przechodziły... Na co więc komu takie testy? teoretycznie psu na budę... ale tylko teoretycznie. Przypomniałem sobie, że ten mój refaktoring też był otestowany, bo inaczej bym się za to w ogóle nie zabierał, bo tyczyło się to problemu, z którego wiedzę domenową mam nadal bardzo nikła, więc moja praca z tym kodem wygląda następująco: ok, kompiluje się, to fajnie... ale czy działa jak należy? - nie mam pojęcia! 

Funkcjonalność, którą miałem przebudować, polegała na tym, że dla danego wejścia do metody, powinno się uzyskać ściśle określone wyjście, które wynikało z wiedzy domenowej. Pierwotnie była to zwykła metoda prywatna, którą trzeba było gruntownie przebudować i przenieść do commonsów, ale efekt miał pozostać taki sam. Zacząłem więc od testu, który mi wypisze (tak, nie użyłem loggera, lecz System.outy!) wszystkie możliwe wyniki działania tej metody. Parę sekund po tym miałem już listę spodziewanych rezultatów, którą mogłem iterować i wewnątrz assertEquals'ów, których liczba rosła wraz z posuwaniem się naprzód wspomnianego przerabiania kodu. (Nawiasem mówiąc, myślę, że jest to podejście, które mógłbym polecić każdemu, kto ma zmieniać coś, o czym ma dość nikłe pojęcie - najpierw solidnie przetestować  pierwotne działanie a dopiero potem poprawiać/psuć kod początkowy.) Na sam koniec kod z commonsów działał dokładnie tak jak ten pierwotny, ale był napisany znacznie lepiej (o czym przekonałem się dziś, kiedy musiałem dołożyć nową funkcjonalność).

Wszystko ładnie pięknie - były testy, kod udawał, że działał. Stało się tak, dlatego, że testowałem kod z commonsów w oderwaniu od kodu, który go używał. Musiałbym powiększyć zakres moich początkowych testów, a na to byłem zbyt leniwy. Okazało się, że zrobiłem coś w rodzaju literówki - w kliencie użyłem nie tej metody, o której myślałem ;) Ale "literówki" każdemu mogą się zdarzyć (zapraszam na ponowne rzucenie okiem na mail od fejsbuczka).

Dobre testy bronią nawet przed literówkami! (można np. testować zamierzony komunikat błędu z exceptiona  aby uniknąć literówek;) ale wróćmy do rzeczy poważnych) A nawet jeśli nie, to stanowią dokumentację dla kodu, pokazują czy działa i jak działa, dzięki czemu mogą bardzo wydatnie przyczynić się do przyśpieszenia momentu w którym wykryjemy i naprawimy błąd.

Skoro mowa jest o testach, to mogę polecić wpis mojego znajomego, Mariusza Sieraczkiewicza Wielkie kłamstwo o czystym kodzie i testach jednostkowych, a nawet bardziej komentarz, którzy pojawił się pod nim:

Motywacja i chęć doskonalenia swoich umiejętności to jedno, ale same chęci nie wystarczą. Zdecydowana większość osób, które nie uznają testów jednostkowych - tak na prawdę nie wie jak pisać testy i kod, który da się testować. Mnie to nie dziwi, bo wg mnie trudno jest znaleźć dobre materiały na ten temat. Dodatkowo sama teoria nie wystarczy, potrzebna jest praktyka. Tutaj jest problem, bo jeśli zapragniemy zdobytą wiedzę teoretyczną wdrożyć do projektu, nad którym pracujemy w pracy - to tak jakbyśmy uczyli się jeździć na nartach zaczynając od zjazdu ze ścianki. Katastrofa murowana. Trzeba zaczynać od rzeczy małych i prostych. I powolutku poznawać o co w tym wszystkim chodzi.

To wyżej tłumaczy dlaczego tak mało osób używa technik TDD. Jest jednak jeszcze jeden problem: bardzo łatwo jest popełnić błędy podczas poznawania tajników metodyki TDD i zostać jej zagorzałym przeciwnikiem.

Na to wszystko nakłada się jeszcze kolejny aspekt - testy jednostkowe to tylko mały i stosunkowo prosty kawałek układanki. Schody się zaczynają kiedy przychodzi nam ogarnąć testami szerszy zakres: mówię o testach funkcjonalnych i integracyjnych. Tutaj trzeba już czegoś więcej niż poznania kilku prostych zasad, jak ma to miejsce w przypadku testów jednostkowych.

Podsumowując: pisanie o tym, że trzeba pisać testy i że te testy to jest podstawa itp. rzeczy - to nie wystarczy. Tutaj potrzebna jest edukacja "od podstaw", jak czynią to np.:

• Steve Freman i Nat Pyrce w swojej doskonałej książce (polecam!),
• Misko Hevery na swoim doskonałym blogu (polecam!),
• Gregory Moeck w swojej doskonałej prezentacji o tym dlaczego nie pojmujecie mock'ów (polecam!),
• i inni... (szukajcie, a znajdziecie).

Zadałem sobie nieco trudu i rozszyfrowałem wszystko o czym napisał Witold Szczerba ;)

1. Doskonała książka - Growing Object-Oriented Software Guided by Tests
2. Misko Hevery i jego blog 
3. Gregory Moeck i jego rzeczona prezentacja
4. i inni ;)

powodzenia!