Nauka Javy i wrażenie zastoju.

Siemka,

Uczę się Javy, do tej pory pisałem tylko aplikacje konsolowe, jednak chciałbym czuć, że sie rozwijam tworząc coś co może cieszyć oko, ogarniam programowanie obiektowe, streamy, lambde, lomboka, interfejsy, klasy abstrakcyjne itp. jednak wydaje mi sie, że na nauke Springa jest za wcześnie i stoje na rozstaju dróg.

Uczyć i szlifować dalej Jave, tworzac jakieś małe konsolowe programy, czy brać się za springa?
Jeśli ma to jakieś znaczenie, jestem studentem 2 roku, w przyszłym tygodniu będę miał wytyczne dotyczące projektu, jednak to co wiem teraz to, to że będzie to z wykorzystaniem Swinga, a jak wiadomo tendencja apek desktopowych na rynku jest spadkowa i znajomy polecił mi nauke Swinga tylko i wyłacznie na tyle, żeby móc zaliczyć projekt na uczelni.

Z góry dzięki za wszystkie Wasze porady :)

Ze Swingiem prawda: apek desktopowych robi się mało a sam Swing jest do ogarnięcia dla studenta.

ogarniam programowanie obiektowe, streamy, lambde, lomboka, interfejsy, klasy abstrakcyjne itp.

Nie wiem co znaczy, że ogarniasz. Żeby zrobić prostą stronę w Spring Boot warto znać składnię i chociaż pobieżnie, żeby nie mieć niespodzianek. Przykład:

class Point2D {
	private int x, y;
	public int getX() {return x;}
	public int getY() {return y;}
}

class Point3D extends Point2D {
	private Integer z;

	public Integer getZ() {return z;}
}

//gdzieś w jakiejś metodzie
Point3D point = new Point3D();

point.getX();
point.getZ();

No i w takiej sytuacji getZ zwróci null a getX zwróci 0. Przez takie pierdółki można szukać kilka godzin czemu Spring sypie błędem. Dobrze, żebyś wiedział np.

• jaka jest różnica między int a Integer,
• co się stanie jeśli nie napiszę żadnego konstruktora,
• co to jest POJO - to przydaje się do beanów.

Tego typu rzeczy są omawiane w wielu książkach z Javy. Niby drobnostki a w Springu potrafią urosnąć do rangi czegoś, na co klniemy. Spring robi dużo rzeczy "pod maską". Z tą świadomością jest trochę lżej :)

IMO lepiej zrobić sensowną aplikacje w natywnej Javie z jakąs tam logiką niż brać za Springa i CRUDa. Jak umiesz Javę to Springa podstaw możesz nauczyć się w 2 tygodnie.
Więc lepiej napisać w Swingu/JavaFX klienta poczty, odtwarzacz muzyczny czy gierke niż robić CRUDa w Springu jak nie masz pomysłu na aplikacje.

A co chcesz pisać?

Pod robotę to te tematy są do obczajenia:

• Naucz się dobrze korzystać z IDE (IntelliJ)
• Naucz się unit testować aplikacje (polecam JUnit 5 + assertJ +- Mockito)
• Naucz się korzystać z bibliotek np. log4j, Guava, Apache Commons, Vavr, Immutables, Lombok
• Naucz się korzystać z systemu buildu (Maven lub Gradle, nie trzeba się uczyć 2)
• Naucz się statycznej analizy kodu (wymagana znajomość systemu buildu, FindBugs, CheckBugs)

Droga webdeva:

• W końcu Spring lub Quarkus lub Micronaut
• Hibernate lub inna implementacja JPA
• Jak odpalać swoje aplikację w Dokerze

Droga mobilniaka:

• Android

Droga desktopowca:

• JavaFX, potem TornadoFX

Można też na wspak i zacząć pisać to co Ciebie interesuje, a reszta sama wyjdzie...

PerlMonk napisał(a):

• co to jest POJO - to przydaje się do beanów.

No to proszę wytłumaczyć co to jest POJO i jak przydaje się do beanów.

Dzięki Wam za rady, z tego co wyczytalem warto abym nauczyl sie swinga, po to żebym zrobil projekt na studia + zebym dalej uczyl sie „suchej” javy, ale zeby moje apki mialy jakiś wyglad niz tylko CLI?

Nie wiem, ja bym się nie uczył raczej „na sucho”, tylko wziął za cel napisać np. klona reddita (może być samo API, jeśli nie lubisz frontu) i do tego nauczyć się tyle z każdej technologii, ile potrzebuje. Nie widzę sensu masterowania technologii/języka X, skoro w praktyce mogę nigdy tego nie wykorzystać. Fajnie jest się specjalizować, ale do jakiegoś stopnia dobrze jest iść „szeroko”.

jarekr000000 napisał(a):

PerlMonk napisał(a):

• co to jest POJO - to przydaje się do beanów.

No to proszę wytłumaczyć co to jest POJO i jak przydaje się do beanów.

Najprostszy możliwy obiekt, czyli (w tym momencie) i pola + gettery i settery dla tych pól. Przykład podałem wyżej:

class Point2D {
    private int x, y;
    public int getX() {return x;}
    public int getY() {return y;}
}

Jak taka wiedza się przydaje do beanów?

1. Pola objęte ORM mogą potrzebować getterów i setterów. Czyli nie getDupaX tylko getX.
2. Metody, które nie są używane przez gettery i settery ani konstruktor domyślny, nie są potrzebne do ORM. Mogę sobie napisać metodę dupa, ale jest ona niepotrzebna w mapowaniu, jeśli nie została wymieniona jawnie

Wiem, że ktoś z forum chętnie mnie zje za pisanie takich rzeczy. Ale nie piszę tego dla poklasku tylko dla osoby, która się uczy. Jak będzie chciał, to dopyta.

Najprostszy możliwy obiekt, czyli (w tym momencie) i pola + gettery i settery dla tych pól. Przykład podałem wyżej:

No to nieprawda. POJO to po prostu obiekt bez magii frameworków. ArrayList czy CompletableFuture to takie samo POJO.

A POJO (plain-old-Java-object) isn't rigorously defined. It's a Java object that doesn't have a requirement to implement a particular interface or derive from a particular base class, or make use of particular annotations in order to be compatible with a given framework, and can be any arbitrary (often relatively simple) Java object.

@40naKlate:

chciałbym czuć, że sie rozwijam tworząc coś co może cieszyć oko

To że coś nie ma GUI, nie znaczy że nie będzie cieszyć oka ;) Programując w Javie zostaniesz backend developerem, więc będzie się liczyło to jak tworzysz kod po stronie backendu a tam nie ma GUJI ;)

Uczyć i szlifować dalej Jave, tworzac jakieś małe konsolowe programy, czy brać się za springa?

Przestań pisać programy a rozwiąż jakiś realny problem, możesz do tego wykorzystać też Springa, który jest jednak jednym z wymogów pewnie w 99% ogłoszeń.
W pracy nie pisze się kodu aby napisać, tylko po to aby np. dodać nową funkcjonalność do do systemu czy naprawić błąd.

Proponuję napisać np. bibliotekę - sam backend, do którego sobie będziesz strzelał Postmanem. Dobrze sobie wszystko obłóż testami, napisz do tego analizę, przypadki użycia i wrzuć na PH... znaczy GH :D

@40naKlate: Na moje to twój problem polega na tym, że próbujesz nauczyć się obsługi każdego dostępnego w Castoramie narzędzia, zanim zbijesz ze sobą dwie deski gwoźdźmi.
Napisz jakąś konkretną apkę i jeżeli będziesz potrzebował czegoś to się douczysz w trakcie.

Pojęcie pojo powstało w opozycji do pojęcia bean. Początkowo beany musiały dziedziczyć po klasach bazowych. Potem pojawiła się moda na pojo z adnotacjami (które nie były jeszcze prawdziwymi pojo) a teraz jest moda na pojo bez adnotacji.
Podsumowując - obecnie klasa może być beanem i pojo jednocześnie a pojo to klasa niezależna od frameworku, za równo nie dziedzicząca z klasy bazowej z frameworku jak i nie mająca adnotacji z frameworku. A bean to klasa zarządzana przez framework DI

Dobrze mówię? Bo już w Javie nie pracuję od pół roku to mogłem pozapominać

@KamilAdam: tak, choć doprecyzuje -
Beany w sensie Springowym to obiekty zarządzane przez kontener, zaś JavaBeans to obiekty z prywatnymi polami, getterami i setterami implementujące Serializable. Obiekty w cudzysłowie bo takie coś to ma mało wspólnego z obiektowym obiektem :p

Zależy co chcesz robić... jesli web dev to ja bym od razu na Springa przeszedł po poznaniu podstaw jak się tworzy klasy

40naKlate napisał(a):

Uczyć i szlifować dalej Jave, tworzac jakieś małe konsolowe programy, czy brać się za springa?

Spring to nie jest żadna magia, w każdym razie jeżeli chociaż trochę masz pojęcie o Javie. Zdecydowanie natomiast, jest to framework z dobrą krzywą nauki.

Jeśli ma to jakieś znaczenie, jestem studentem 2 roku, w przyszłym tygodniu będę miał wytyczne dotyczące projektu, jednak to co wiem teraz to, to że będzie to z wykorzystaniem Swinga, a jak wiadomo tendencja apek desktopowych na rynku jest spadkowa i znajomy polecił mi nauke Swinga tylko i wyłacznie na tyle, żeby móc zaliczyć projekt na uczelni.

Smutna prawda o Java jest taka, że ten język nie ma w sobie nic przyzwoitego, co obsługuje UI. Na desktop masz Swing (stare), JavaFX (delikatnie młodsze, ale moim zdaniem jakość ta sama), w obu przypadkach aplikacje wyglądają jak z 1999 roku :) UI w WWW też nie istnieje, robi się backend w Javie + frontend w czymś tam, co akurat jest modne w tym sezonie. Do aplikacji desktopowych ciężko mi znaleźć cos rozsądnego poza .NET. Oczywiście są jeszcze wynalazki typu Electron, czy Flutter, ale gros tych frameworków, zmusza cię do pakowania 100 linii kodu w pakiet z przeglądarką, a jak przyjdzie zrobić coś na poziomie usług systemowych, to uderzasz w ścianę..