Kamil Grabowski Weblog

Jakiś czas temu na mojej uczelni mieliśmy kolokwium z przedmiotu “Podstawy programowania w Javie”. Kolokwium na pierwszy rzut oka wydawało się banalnie proste, więc po raz kolejny liczyłem na 100% punktów.

Podczas rozdania wyników niestety okazało się troszkę inaczej, a nasz ćwiczeniowiec (Kuba Staszczyk) powiedział nam “Nie mów hop, dopóki nie przeskoczysz!”. W sumie to i dobrze, bo 100% zwalniało z ćwiczeń, a koleś co ćwiczenia powie coś ciekawego, tym bardziej, że w javie piszę od października – właśnie na studiach, ponieważ wcześniej nie odczuwałem takiej potrzeby.

Pytania, na których się przejechałem wydały mi się na tyle ciekawe i zagadkowe, że postanowiłem o nich napisać na blogu. Warto jeszcze podkreślić, że kolokwium odbywało się “na kartce”, więc nie było możliwości przetestowania tego na kompilatorze, choć z drugiej strony pytania wydały się tak trywialne, że nie wiem czy po kompilator bym sięgnął. Tak więc do dzieła!

Pytanie: Co wyświetli poniższy kawałek kodu:

int x = 4;
System.out.println("Value is " + ((x > 4) ? 99.99 : 9));

Odpowiedzi:

1. Value is 99.99
2. Value is 9
3. Value is 9.0

Jak działa operator trójargumentowy każdy wie: jeśli warunek (x > 4) jest spełniony to wynikiem będzie wartość po znaku zapytania (99.99), a jeśli warunek nie jest spełniony to wynikiem będzie wartość po dwukropku (9). Oczywiście dłużej się nie zastanawiając zaznaczyłem odpowiedź drugą a mianowicie, że program wyświetli “Value is 9″, ponieważ x nie jest większe od 4, tylko równe 4 (wyrażenie nie jest prawdziwe), więc zwrócona zostanie wartość po dwukropku, czyli właśnie 9.

Jakież było moje zdziwienie, gdy dowiedziałem się, że jestem w błędzie, ponieważ program wyświetli “Value is 9.0″! Pomyślałem sobie “Jak to możliwe!? Przecież wartość 9.0 nie jest nigdzie zdefiniowana!”.

Dziś siadłem do tego problemu i go głębiej przeanalizowałem. Jak się okazało java robi sobie niejawne rzutowanie i fakt, operator trójargumentowy zwróci 9, jednak nie jako integer, ale jako double. Dlaczego tak się dzieje? Ponieważ jednym ze zwracanych wartości (99.99) jest typu double, więc kompilator sobie rzutuję drugą wartość też na typ double, stąd mamy 9.0. Mam nadzieję, że poniższych kilka przykładów wyjaśni sprawę:

// Zdefiniujmy sobie metodę Foo, która będzie nam wyświetlać
// jakiego typu jest przekazany argument oraz wartość tego argumentu
public static void foo(Object obj) {
  System.out.println(obj.getClass() + " # Value = " + obj);
}

// Dalej wykonajmy kilka testów
int x = 4;

foo( x > 4 ? 99.99 : 9);
foo( x > 4 ? 'c' : 100.0);
foo( x > 4 ? 'c' : 100);
foo( x > 4 ? 'c' : "d");
foo( x > 4 ? "c" : 'd');

Poniżej wyniki:

class java.lang.Double # Value = 9.0
class java.lang.Double # Value = 100.0
class java.lang.Character # Value = d
class java.lang.String # Value = d
class java.lang.Character # Value = d

Co się stało?

1. Nastąpiła niejawna konwersja z integera na typ double (typ double, jest pojemniejszy niż integer)
2. Konwersja z chara na double (double jest pojemniejszy niż char)
3. Konwersja z integera na chara (wartość 100 odpowiada znakowi ASCII “d”). Tutaj trochę nie rozumiem co się dzieje, ponieważ zgodnie z rozumowaniem idziemy, ku pojemniejszemu typowi (char ma 8 bitów, integer 32-bity) a tu się nie zgadza.
4. Brak konwersji, zwracamy stringa, tak jak powinno być
5. Brak konwersji (!) zwracamy chara, choć spodziewałem się stringa, gdyż jest pojemniejszy (jednak nie jest typem prostym?)

Ostatni punkt odnośnie typów prostych i złożonych mnie zaciekawił, więc postanowiłem to samo zrobić z typami złożonymi: Integer, Double, String, pomimo, że spodziewałem się tych samych wyników:

foo( x > 4 ? new Double(99.99) : new Integer(9) );
foo( x > 4 ? new Character('c') : new Double(100.0) );
foo( x > 4 ? new Character('c') : new Integer(100) );
foo( x > 4 ? new Character('c') : new String("d") );
foo( x > 4 ? new String("c") : new Character('d') );

I się nie myliłem:

class java.lang.Double # Value = 9.0
class java.lang.Double # Value = 100.0
class java.lang.Integer # Value = 100
class java.lang.String # Value = d
class java.lang.Character # Value = d

Wyniki takie same jak na typach prostych. Jedyne rzutowania to:

• integer -> double
• integer -> char

Szczerze to poza powyższą regułą (?) gubię się jeszcze w tym niejawnym rzutowaniu, ponieważ jestem przyzwyczajony do tego co mam w znanych mi językach: Ruby oraz C++.

Ruby

x = 4
puts "Value is " + (x > 4 ? 99.99 : 9).to_s
# wynik: Value is 9

C++

#include <iostream>

using namespace std;

int main() {
    int x = 4;

    // Wyświetli: "Value is 9"
    cout << "Value is " << (x > 4 ? 99.99 : 9) << endl;

    return 0;
}

Jak widzimy tylko w Javie jest inaczej, ponieważ kod w javie wyświetli nam “Value is 9.0″. Powoli się przekonuje, że w javie nie jest tak samo jak C++ czy Rubym ;) Tak miedzy nami to cienias ten Integer ;))) Każdy go rzutuje jak chce ;P

Ok, teraz czas na drugie ciekawe pytanie:

Pytanie: Co wyświetli poniższy kod:

String str1 = "xyz";
String str2 = "xyz";

if( str1 == str2 )
    System.out.println("Hello World");

Odpowiedzi:

1. Hello World
2. Nic nie wyświetli

Pierwsza myśl jaka przychodzi do głowy, to że nie wyświetli niczego, ponieważ w javie operator == (jeśli jego argumentami są typy złożone) zwraca true, jeśli obiekty “wskazują” na ten sam obiekt w pamięci. W naszym przypadku zmienne str1 oraz str2 wydawać się by mogło to dwie zupełnie różne zmienne.

Jest jednak inaczej, ponieważ kompilator optymalizuje nasz kod podczas procesu kompilacji i widzi, że oba stringi mają tą samą zawartość, więc robi tak, że str1 oraz str2 wskazują na ten sam obszar pamięci (są referencją do tego samego obiektu), więc operator == zwraca true i program na wyświetli “Hello World”.

Jak widzimy kompilator nie śpi i robi kupę dobrej roboty … przez którą na kolosie możemy mieć problemy ;)

Poniżej jeszcze kilka właściwości stringów w javie:

String str1 = "Hello World";
String str2 = "Hello World";
String str3 = "Hello ”+ "World";
String world = "World";
String str4 = "Hello" + world;
String str5 = new String("Hello World");

Co tu mamy? Zmienne str1, str2, str3 kompilator wrzuci do tego samego obszaru pamięci, przez co będą wskazywać na ten sam adres w pamięci. Zmienna str4 oraz str5 nie zostaną umieszczone w tej samej komórce mimo, że już podczas kompilacji można stwierdzić, że te stringi są sobie równe (niedoskonałość optymalizacji przez kompilator?). Prawdopodobnie dzieje się tak, że str4 zostało stworzone z połączenia dwóch różnych obiektów klasy String natomiast, zmiennej str5 “ręcznie” przydzieliliśmy pamięć przez wywołanie new String(“Hello World”);

Ciekaw jestem, czy w przyszłości zostanie to jakoś inaczej zaimplementowane.

PS. Z góry przepraszam, za wyrażenia typu “wskazuje”, “komórka pamięci” zamiast używania poprawnego słownictwa w javie. Tak jak mówię, z javą mam do czynienia 3 miesiące i nie wszystko jeszcze potrafię powiedzieć w “javowy sposób” :)

PS 2. Na uczelni często pojawiają się takie ciekawostki, które nawet w dobrych książkach jest trudno napotkać – po nie właśnie zdecydowałem się pójść na studia :) Będę się starał je wszystkie opisywać na blogu :)

PS 3. Oczywiście kolosa mam zaliczonego, bo reszta była ok poza jeszcze trzeba mniej ciekawymi błędami, których można by było się w sumie domyśleć, ale nie pamiętam już co to były za pytania :(