Podczas programowania w CDC zawsze wynajduję koło na nowo, ponownie wdrażając takie rzeczy jak Arrays.toString(Object[]). Dlaczego tak jest? Czy CDC (i FP, PBP itp.) nie może być podzbiorem obecnej edycji SE, zamiast być oparte na starej (czy mogę powiedzieć przestarzałej?) wersji Javy?

Może być ku temu dobry powód, ale tego nie dostrzegam.

4
JoaoHornburg 24 luty 2012, 16:29

2 odpowiedzi

Najlepsza odpowiedź

Są one — CDC jest podzbiorem tego, co było „bieżącą” wersją JavaSE, kiedy została zdefiniowana. (np. CLDC1.0 > JSR30 > zatwierdzone w sierpniu 1999 > oparte na JavaSE 1.3)

CDC, CLDC, FP, PBP... to specyfikacje - zamrożone w czasie - nie mogą być aktualizowane. Aktualizacja specyfikacji oznaczałaby uruchomienie nowej (np. CDC2.0) - i wtedy mielibyśmy część urządzeń zgodnych ze starą, a część z nową.

Poza tym należy wziąć pod uwagę założenie „CDC jest… wysoce zoptymalizowany pod kątem urządzeń o ograniczonych zasobach, takich jak produkty konsumenckie i urządzenia wbudowane” — ao urządzeniach o ograniczonych zasobach mówimy w 1999 roku.

1
gabriel_agm 24 luty 2012, 17:02

Odpowiedź brzmi po prostu, Prawo Moore'a.

W swoim zwykłym sformułowaniu wyraża się to jako „liczba tranzystorów w opłacalnym w produkcji chipie mniej więcej podwaja się co 18 miesięcy”.

Jednak patrząc z innego punktu widzenia, można by również powiedzieć, że jeśli „zdolność” (tj. liczba tranzystorów) jest utrzymywana na stałym poziomie, wówczas koszty mogą z czasem spadać.

Taki pogląd przyjął komitet wykonawczy Java ME, więc urządzenia referencyjne nie mają większej mocy niż 4 lub więcej lat temu – ale są znacznie tańsze. Ma to znaczenie dla przestrzeni, w której CDC próbuje grać, ale oznacza to, że urządzenia są zwykle słabsze w porównaniu z tym, co jest potrzebne dla podzbioru SE.

Trwa zmiana bazy specyfikacji CDC, aby zbliżyć ją do SE. Java 8, ze swoją obsługą modułowości, również to ułatwi.

Ostatecznie celem jest konwergencja ME do podzbioru SE, ale zajmie to jeszcze kilka wydań.

2
kittylyst 24 luty 2012, 16:48