Forum Przyszły Programista - Najnowsze pytania i odpowiedzi w Java

Testowanie WeatherApp - testowanie serwisu

Tue, 02 Jun 2026 18:35:43 +0000

Cześć wszystkim!

mam problem z testem aplikacji pogodowej. Mam 2 klasy: GetLocationService i GetLocationClient.
GetLocationClient to klasa która konkretnie wysyła zapytanie do API i zwraca odpowiedź - jej nie chcę testować.
GetLocationService.ma GetLocationClient jako pole i wywołuje go żeby za jego pomocą wysłać zapytanie:

public class GetLocationService extends Service<Location> {

    private final GetLocationAPIClient getLocationAPIClient;

    GetLocationService(GetLocationAPIClient getLocationAPIClient) {
        this.getLocationAPIClient = getLocationAPIClient;
    }

    @Override
    protected Task<Location> createTask() {
        return new Task<Location>() {
            @Override
            protected Location call() throws Exception {

                return getLocationAPIClient.getLocation();
            }
        };
    }
}

Chcę zamockować działanie GetLocationClient i przetestować, czy GetLocationService poprawnie przekazuje odpowiedź lub zgodnie z założeniem wyrzuca błąd.

Alej jak przetestować createTask()? Czy ktoś testował Service?

Odpowiedź: Aplikacja pogodowa -> javafx-maven-plugin

Fri, 12 Jan 2024 04:28:39 +0000

Cześć Karol! Wydaje mi się, że to wystarczy i to jest właśnie "porządnie" zrobione.

Odpowiedź: No main manifest attribute

Wed, 27 Dec 2023 14:54:16 +0000

Próbowałaś starszą wersje Javy niż 21? Np 19 lub 17 ? I czy w Javie nie trzeba jawnie określić klasę main? Coś jak:

Main-Class: nazwa.projektu.Main ?

Odpowiedź: Aplikacja mailowa

Mon, 11 Dec 2023 14:05:27 +0000

spróbuj użyć innego mila, np na wp.pl.

Jak to nie pomoże:

Załóż sobie nowy świeży projekt w którym przetestuj tylko i wyłącznie funkcjonalność logowania na pocztę i pobierania danych z niej. Jak wprowadzasz nową funkcjonalność do rozbudowanej aplikacji to łatwo o błąd.

Dlatego zawsze nową funkcjonalność najlepiej jest przetestować na nowym świeżym prostym projekcie i jak tam wszystko zacznie działać jak należy, to dopiero wdrażaj ją do swojego głównego projektu.

Odpowiedź: Aplikacja pogodowa

Sat, 26 Aug 2023 12:37:52 +0000

Nieaktualne, problem rozwiązany :)

Aplikacja pogodowa

Thu, 10 Nov 2022 23:27:47 +0000

Cześć.

Kończę właśnie aplikację pogodową i praktycnzie jedyną rzeczą jaka mi została, to zapamiętywanie ostatnio wybranych miast i zapisywanie do pliku. Tu mam zagwozdkę, bo dane na temat tych miast mam w MainViewController, a dostęp do metody stop() w głównym launcherze, a po drodze jeszcze jest ViewFactory. Z tego co wyczytałem w internecie i z dokumentacji, statyczny getter w controllerze nie wchodzi w grę. Czy ktoś mógłby mnie nakierować z której strony ugryźć temat, żeby to nie tylko działało, ale miało też ręce i nogi pod względem poprawności z wzorcami projektowymi>

Odpowiedź: Aplikacja pogodowa - dodawanie danych prognozy

Wed, 27 Jul 2022 17:09:48 +0000

Hej,

Jeśli chcesz użyć kontrolera to nie można go stworzyć przez "new" (konstruktor) ponieważ nie będzie miał zainicjlizowanych pól "@FXML" oraz nie będzie "widziany" przez Java Fx. Aby stworzyć kontroler masz dwie drogi:

1) przez FxmlLoader - tak jak to robisz w klasie ViewFactory:

FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource(controller.getFxmlName()));

2) korzystając z nested controller - więcej o tym tutaj: https://riptutorial.com/javafx/example/7285/nested-controllers

Poniżej patch (bardzo na szybko to robiłem), jak mogłoby to wyglądać dla sposobu 1.

Index: src/main/java/pl/martabuchalska/view/ViewFactory.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/main/java/pl/martabuchalska/view/ViewFactory.java b/src/main/java/pl/martabuchalska/view/ViewFactory.java
--- a/src/main/java/pl/martabuchalska/view/ViewFactory.java	(revision ad22b3a2d142cb4618ea418d31060c7195758bf2)
+++ b/src/main/java/pl/martabuchalska/view/ViewFactory.java	(date 1658941433415)
@@ -8,7 +8,6 @@
 import pl.martabuchalska.controller.ForecastDisplayController;
 import pl.martabuchalska.controller.MainPageController;
 import pl.martabuchalska.controller.WeatherDisplayController;
-import pl.martabuchalska.model.ForecastData;
 
 import java.io.IOException;
 import java.util.ArrayList;
@@ -33,6 +32,13 @@
         //close previous window
     }
 
+    public static ForecastDisplayController showForecast() {
+        System.out.println("Showing weather display window");
+        ForecastDisplayController controller = new ForecastDisplayController(null, "ForecastDisplayView.fxml");
+        initializeStage(controller);
+        return controller;
+    }
+
 
 
 
@@ -47,8 +53,8 @@
         return parent;
     }
 
-    private void initializeStage(BaseController controller){
-        FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource(controller.getFxmlName()));
+    private static void initializeStage(BaseController controller){
+        FXMLLoader fxmlLoader = new FXMLLoader(ViewFactory.class.getResource(controller.getFxmlName()));
         fxmlLoader.setController(controller);
 
         Parent parent;
Index: src/main/java/pl/martabuchalska/controller/WeatherDisplayController.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/main/java/pl/martabuchalska/controller/WeatherDisplayController.java b/src/main/java/pl/martabuchalska/controller/WeatherDisplayController.java
--- a/src/main/java/pl/martabuchalska/controller/WeatherDisplayController.java	(revision ad22b3a2d142cb4618ea418d31060c7195758bf2)
+++ b/src/main/java/pl/martabuchalska/controller/WeatherDisplayController.java	(date 1658941365851)
@@ -4,7 +4,6 @@
 import javafx.fxml.FXML;
 import javafx.fxml.Initializable;
 import javafx.scene.Group;
-import javafx.scene.Node;
 import javafx.scene.Parent;
 import javafx.scene.control.Label;
 import javafx.scene.image.Image;
@@ -138,7 +137,7 @@
     private void populateInitialForecastBox(ForecastData forecastData) throws IOException {
 
         ViewFactory viewFactory = new ViewFactory();
-        ForecastDisplayController forecastDisplayController = new ForecastDisplayController(viewFactory, "ForecastDisplayView.fxml");
+        ForecastDisplayController forecastDisplayController = viewFactory.showForecast();
         forecastDisplayController.setForecastData(forecastData);
         forecastDisplayController.getTrainingFunciton(); // works fine

Daj znać czy o to chodziło :)

Odpowiedź: Programowanie funkcyjne a logger

Wed, 06 Jul 2022 18:45:57 +0000

Rozumiem, ze to do Twojej apki a nie do pracy ? Jeżeli tak - jako ewentualny user - wybieram opcje nr 2 ponieważ jest bardziej human-readable, jako programista myślę, że chyba lepiej zrobić interfejs loggera i wstrzykiwać do klas gdzie potrzebujesz. Na pewno Java ma tez jakieś biblioteki/templatki/wbudowane mechanizmy do tego.

Odpowiedź: JavaFX + Maven - środowisko nie widzi plików Java FX (aplikacja pogodowa)

Mon, 04 Jul 2022 21:50:09 +0000

Link do repo: https://github.com/MBuchalska/WhatWeather.git

W kodzie nie ma jeszcze w zasadzie nic, bo chciałam sprawdzić czy wywoła mi się bazowy widok, bez żadnej logiki. Dodałam do pom bibliotekę gson, jeszcze jej nie używałam. Na próbę dodałam ją też do module-info ale nie zwraca błędu.

Próba uruchomienia daje mi błąd: java: module not found: javafx.fxml ; java: module not found: javafx.controls

mvn clean install zwraca błąd: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project WhatWeather: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: Cannot invoke "java.lang.Throwable.getCause()" because "cause" is null

Robiłam na tym projekcie próbę połączenia z API czysto w klasie Launcher, bez dodatkowych pakietów i tylko wypisywałam wyniki w terminalu, ale to działało bez problemów.

Odpowiedź: Tworzenie pliku jar - błędy

Mon, 06 Jun 2022 16:10:03 +0000

Cześć, na pierwszy rzut oka ciężko powiedzieć w czym leży problem. Czy mógłbyś podać pełny log z wywołania mavena (komenda mvn clean install) i podać linka do repozytorium na githubie? Będzie dużo łatwiej pomóc mając więcej informacji :)

Pozdrawiam

Odpowiedź: Przekazywanie obiektów/danych między kontrolerami, w tym samym oknie aplikacji

Mon, 16 May 2022 21:30:47 +0000

Cześć,

Nie analizowałem jeszcze kodu ale po opisie nasuwa się jedno pytanie: dlaczego chcesz przesłać obiekt z głównego kontrolera do pozostałych zamiast pobierać dane bezpośrednio w tych pozostałych? Metody do pobrania danych można przenieść do osobnej klasy i stworzyć jej instancje w kontrolerach.

Druga podpowiedź gdybyś chciał zostać przy bieżącym rozwiązaniu: nie wiem jak wygląda Twoja aplikacja ale przeważnie dane dla kolejnych dni są wyświetlane w ten sam sposób. Więc może zamiast tworzyć sztywno 5 kafelków, stwórz osobny fxml dla jednego kafelka i w kontrolerze głównym dodawaj kolejne obiekty tego kafelka do ogólnego pojemnika np. za pomocą pętli.

Wiem, że trochę ogólnikowo ale może uda się na coś naprowadzić. Jak będziesz potrzebował to postaram się rzucić okiem na kod.

Odpowiedź: Spring -> MySQL

Tue, 10 May 2022 06:47:34 +0000

DT Netmark'u jednak znał rozwiązanie

W adresie url trzeba usunąć numer portu (co było dla mnie dziwne, ale zadziałało) oraz w cPanelu trzeba umożliwić dostęp do bazy dla zdalnego urządzenia, z którego próbujesz uzyskać dostęp do bazy (pojedynczego za pomocą adresu IP bądź dla dowolnego za pomocą znaku %)

Odpowiedź: TestFx + mockowanie

Mon, 03 Jan 2022 17:49:59 +0000

Hej,

Dzięki za cierpliwość :) a więc tak:

Jeśli chodzi o dwa podejścia które przedstawiłeś, to pierwsze z nich to bardziej test funkcjonalny / systemowy niż jednostkowy, natomiast drugie jest bliższe testowi jednostkowemu. Oba podejścia są poprawne i należy jest stosować zależnie od sytuacji, z tym, że zazwyczaj jednostkowe pisać łatwiej, więc tam obsługujemy wszystkie przypadki brzegowe, natomiast w testach systemowych mamy tylko główne, najczęściej pozytywne scenariusze. Z tym, że jakbyś zdecydował się na test systemowy, to nie sprawdzałbym raczej, czy plik jest tworzony, tylko skupił się na weryfikacji tego co widzi użytkownik i czy to jest poprawne (podejście blackbox: https://www.imperva.com/learn/application-security/black-box-testing/).

Natomiast jeśli o mockowanie, to jak zauważyłeś przy obecnym wyglądzie kodu to nie zadziała, ponieważ testowany kontroler sam zarządza klasami ConvertingCountryNames oraz WeatherClient. Należy tu zastosować odwrócenie kontroli (więcej https://stackoverflow.com/a/3140) innymi słowy instancje tych klas, które chcesz mockować powinny być dostarczone przez konstruktor/inny sposób z zewnątrz (czyli testowany kontroler traci nad nimi kontrole). W ten sposób w kodzie produkcyjnym dostarczysz odpowiednie implementacje, a w kodzie testowym mocki - jeśli będziesz miał problem aby to wdrożyć, to wrzuć to na jakiegoś brancha i zostaw mi linka to zerkne na kod.

P.S nie widzę całego testu, ale aby adnotacje typu @InjectMocks zadziałały potrzebujesz użyć MockitoExtension (https://www.baeldung.com/mockito-junit-5-extension#building-the-test-class)

Odpowiedź: Aplikacja pogodowa - testy jednostkowe

Tue, 14 Dec 2021 15:05:38 +0000

Hej,

Masz dwie opcje:

1. Użyć biblioteki test-fx aby testować interakcje z interfejsem użytkownika. Trudne do napisania i trudne w utrzymaniu, ale o tyle fajne, że testują aplikacje jako black box - interesuje Cie wygląd interfejsu i reakcje na akcje użytkownika, a nie jak wygląda kod. https://github.com/TestFX/TestFX

2. Wydzielić ile logiki możesz (w Twoim przypadku na pierwszy rzut oka nie ma tego za wiele) do osobnych klas z metodą publiczną. Wtedy testuje to klasycznie, a Controller po prostu korzysta z tych z klas jako usług.

Oba podejścia mają swoje wady i zalety, warto znać oba, bo w zależności od sytuacji można skorzystać z jednego lub drugiego. Daj znać czy rozjaśnia Ci to trochę temat.

Odpowiedź: Kilka pytań odnośnie planowania projektu w Javie

Mon, 13 Dec 2021 19:40:08 +0000

Hej :)

Ad 1:

Dobrze podsumowałeś temat i sam sobie odpowiedziałeś :) - ja osobiście też preferuje drugie podejście, wydaje mi się, że taka struktura jest lepsza i jak chcesz użyć klasy, której się nie powinno to bardziej to widać. Pierwsze podejście też jest okej, wciąż widzę, że w wielu projektach właśnie w ten sposób się tworzy kod.

Ad 2:

Tu już odpowiedź nie jest taka prosta i oczywiście zależy :) Jeżeli dany backend jest używany tylko przez frontend i nikogo więcej, to w zasadzie tak jak jest wygodnie + wszędzie tak samo aby było spójnie. Jeśli jednak dany backend oprócz frontendu miałby innych klientów, to już trzeba pomyśleć co dane API robi i jakie dane ma zwracać. Czy dane nie posortowane mają sens? Czy każdy kto zawoła API i tak musi je posortować aby do czego kolwiek się nadawały? Jeśli każdy klient miałby zrobić tę samą pracę, to można to zrobić po stronie backendu raz a dobrze :)

No i jeszcze kwestia kontraktu i zaufania - jeśli tworzysz frontend, który woła backend który nie jest pod Twoją kontrolą, to ja bym tutaj zawsze sortował we frontendzie, chyba, że specyfikacja backendu jasno mówi, że dane wracają posortowane.

Generalnie tu nie będzie złotej zasady i dla każdego przypadku trzeba by się zastanowić.

Mam nadzieję, że nie zamieszałem za bardzo, pozdrawiam.

Odpowiedź: Testowanie funkcjonalności JavaFX

Mon, 29 Nov 2021 18:04:25 +0000

Hej,

Uważam podobnie jak napisał Bartek030, mogę tylko rozwinąć temat JavyFX - kontrolery testuje się w dość trudny sposób, ale użycie TestFX (https://github.com/TestFX/TestFX) to jest dobry pomysł, jednak należy uważać z tymi testami, ponieważ będą dużo trudniejsze do napisania oraz utrzymania od testów standardowych klas. Jak dla mnie z ww. powodów kontroler nie musi mieć wcale testów o ile ma tylko niezbędną logikę wypełnienia widoku (czyli kontroler woła jakąś klase aby mu dostarczyła prognoze pogody i tylko przepisuje z wartości zwracanej do odpowiednich kontrolek UI). Jeśli chcesz zgłebić temat to warto napisać może przynajmniej jeden czy dwa testy dla najważniejszych zachowań kontrolera (czyli pewnie confirmButtonAction w Twoim przypadku).

Odpowiedź: Testy jednostkowe - artykuł o TDD

Thu, 25 Nov 2021 15:46:59 +0000

Hej,

Spróbuj zamockować tę interakcję w następujący sposób:

Mockito.doReturn(true).when(weaponSpy).isDistanceSufficient(entity);

Jeśli chodzi samo podejście, to mam pytanie, czy metoda `isDistanceSufficient` może być prywatna? Może najlepiej z punktu widzenia całego projektu, było by ukryć tę metodę jako prywatną.

Pondato ja bym tutaj zrezygnował z tego mockowania, bo skoro chcesz przetestować metodę `doDamage`, której częścią jest `isDistanceSufficient` to jak zamockujesz tę drugą, to test nie będzie kompletny - chyba że napiszesz osobne testy dla metody `isDistanceSufficient`. Jednak w pierwszej kolejności upewniłbym się, czy metoda `isDistanceSufficient` powinna być o dostępie publicznym/pakietowym czy jednak zmienić ją na prywatną i traktować jako część implementacji.

Daj znać czy rozjaśniłem temat :)

Odpowiedź: Testy jednostkowe - który lepszy?

Mon, 08 Nov 2021 16:15:52 +0000

Hej,

Twoje rozkminy są jak najbardziej OK :) zdecydowanie podejście, aby nie zagłębiać się jak wygląda implementacja danej klasy jest ok i im mniej możemy odnosić się do szczegółów implementacji podmiotu którego testujemy tym lepiej.

Jeśli chodzi o porównanie tych testów to wg mnie test numer jeden jest dokładniejszy. Zwróc uwagę, że test nr 2 jedynie sprawdza czy metoda load cargo została wywołana (czyli defacto tutaj jest odwołanie do implementacji). Natomiast test nr jeden weryfikuje w liniach 28 i 29 poprawność wyniku, nie skupiając się na implementacji (linijke 27 ja bym sobie darował). Czy chodzi Ci właśnie głównie o linijke 27 z verify(cargoRepository).findCargoByName("package"); ?

Daj znać, czy rozjaśnia Ci to temat :)

P.S nie należy mockować tzw. Value Object's czyli klas które głównie przenoszą dane, takie jak Unit. Typowo mockuje się klasy typu *Service, *Repository itp.

Odpowiedź: Java - narzędzia do tworzenia widoku aplikacji

Tue, 26 Oct 2021 11:59:26 +0000

Hej,

W moim doświadczeniu wygląda to tak, że ostatni raz widok aplikacji webowej budowałem w Javie w okolicach 2012 roku :) Jest do tego narzędzie, nazywa się Java Server Faces (https://www.tutorialspoint.com/jsf/jsf_quick_guide.htm), w skrócie JSF. Radziłbym skorzytsać z podejścia opisanego poniżej, ponieważ nie słyszałem aby w nowych projektach ktoś jeszcze stosował technologie typu JSF.

Obecnie odchodzi się od tego podejścia - Java stała się głównie językiem backendu / strony serwerowej, natomiast widok/interfejs/frontend tworzy się głównie w technologiach opartych o JavaScript. Tobie też polecam tak do tego podejść, typowo wygląda to tak:

1. Backend jest napisany w Javie i wystawia REST API.

2. Frontend gdy potrzebuje pobrać dane z backendu wywołuje zapytania typu AJAX. Czyli pobiera dane tak jak aplikacja pogoda pobierała JSONa z API openweathermap, z tą różnicą, że pobiera bezpośrednio JavaScript czyli przeglądarka użytkownika końcowego.

Dlaczego tak? Daje to szereg możliwości - dzięki temu, że powstaje REST API, można dodać potem kolejny widok, np. w postaci aplikacji Android. Nie trzeba też znać Javy, aby rozwijać cześć webową aplikacji (dla Ciebie może to być minus, ale generalnie świat frontendu jak pisałem należy do JSa). Do tego dochodzi bezpieczeństwo, skalowalność itp.

Odpowiedź: Java — jak zamockować połączenie z API?

Fri, 17 Sep 2021 14:25:55 +0000

Hej,

Pomysł z wiremockiem jest dobry, ale wtedy byłby to bardziej test integracyjny niż jednostkowy (ale takie też są przydatne). Aby to zadziałało w obecnej formie musiałbyś zmienić klase https://github.com/suabicii/jfx-weather/blob/master/src/main/java/pl/michaelslabikovsky/model/WeatherData.java tak aby URL/host był podawany przez konstruktor. Wtedy konstruując obiekt w kodzie produkcyjnym używasz tego URL/hosta co dotychczas, a w kodzie testowym używasz localhosta.

Jest też druga opcja, aby w ogóle nie robić połączenia do zewnętrznego serwera http (czy to wiremocka czy prawdziwego). Wymaga to wprowadzenia dodatkowe poziomu abstrakcji, nazwijmy go APIClient, pseudokod poniżej:

public void connectToApi(...) {

     apiClient.call();
}


public interface ApiClient() {
  String call(String url); //could be something else than String
}


public class HttpApiClient() implements ApiClient {
  
  public String call(String url) {
    // production implementation
  }

}

public class StubApiClient() implements ApiClient { //you can use mockito library instead
  private final String response;
  public ApiClient(String response) {
    this.response = response;
  }

  public String call(String url) {
    return response;
  }

}

W ten sposób Twój kod jest odseparowany za pomocą ApiClient od sposobu pobrania tych danych - w kodzie produkcyjnym będzie to faktycznie żądanie HTTP, natomiast w kodzie testowym możesz użyć dowolnie innej implementacji, bądz też mocka za pomocą biblioteki mockito.

Mam nadzieję, że troche rozjaśniłem temat :).

Odpowiedź: JavaFX — ładowanie danych z API w tle i trzy wersje na trzy systemy zamiast jednej

Mon, 06 Sep 2021 18:57:11 +0000

Hej :)

Jeśli chodzi o przetwarzanie kodu w tle, to wydaje mi się, że nie potrzebnie używasz Platform.runLater -> zapoznaj się z dokumentacją tej metody, kluczowy fragment:

Run the specified Runnable on the JavaFX Application Thread at some unspecified time in the future.

Oznacza to, że Runnable który przekażesz zostanie uruchomiony w wątku JavaFX - a to jest ten wątek, którego nie chcesz blokować. Jeśli zamienisz linijke 121 w MainWindowController na

runnable.run();

To progress bar działa i pobieranie wykonuje się w tle, tyle że później dostaniesz błąd że chcesz zrobić zmianę GUI poza wątkiem JavaFX.

Aby to zadziałało, musisz trochę przerobić przepływ danych: Runnable/Callable służy do sciągnięcia danych, po sciągnięciu danych powiadamia kontroler, który już w głównym wątku JavaFX uzyje tych danych:

JavaFX Thread -> Uruchom Runnable aby pobrać dane

Runnable -> Pobierz dane i powiadom wątek główny

JavaFx Thread -> pobierz dane i narysuj na GUI.

---------

Teraz drugie pytanie: sprawdziłem jak to wygląda na MacOS i wg mnie nie jest źle, bo dostaje zipa, który po rozpakowaniu ma skrypt uruchamiający aplikacje w poprawny sposób - i to jest ok. Natomiast jeśli chodzi o samo budowanie aplikacji, to wydaje mi się, że potrzebujesz 3 różnych buildów na 3 różne systemy operacyjne (ponieważ inne implementacje GUI są potrzebne). Czyli 3 osobne konfiguracje tworzą 3 jary i każdy działa tylko na jednym systemie operacyjnym. Stworzenie jednego jara działającego na każdym systemie może być trudne + podatne na błędy. Jednak jakbyś dalej chciał iść w tym temacie, to zobacz sobie plugin jlink oraz rzuć okiem na ten wątek: https://github.com/beryx/badass-jlink-plugin/issues/189.

To tyle ode mnie, daj znać czy to Ci pomogło, jak coś to będziemy drążyć dalej :)

Odpowiedź: JavaFX - stylizowanie

Mon, 09 Aug 2021 12:50:07 +0000

Na podstawie uwag Marcina, naszego speca od Javy, podsyłam dla potomnych jeden z artykułów o tym jak osiągnąć responsywność w JavieFx:

https://guigarage.com/2014/11/responsive-design-javafx/

Nad taką stylizacją - podobnie jak w programowaniu webowym - łatwiej zapanować ustawiając odpowiednie klasy dla naszych elementów i następnie definiując style w pliku .css

Odpowiedź: Openweathermap - parsowanie jsona

Thu, 05 Aug 2021 16:22:22 +0000

Do listy parsujesz głównie dane, które są zapisane w jsonie jako tabela, czyli są w nawiasach kwadratowych. Ogólnie w plikach json spotkałem się z 3 typami danych: zwykłe pojedyncze pola, obiekty, które mogą zawierać zwykłe pola, obiekty lub tabele i właśnie tabele, które mogą zawierać typ zwykłego pola lub obiektu. I listy służą właśnie do parsowania tabel.

Nie jestem pewien czy nadają się one do parsowania pól i obiektów ale raczej generowanie listy elementów, która zawierałaby tylko jeden element trochę mija się z celem.

Poniżej wrzucam dwa linki, które mogą pomóc zrozumieć temat:

FILM, na którym jest pokazany jak można skorzystać z biblioteki gson w maven'ie, w tym jak tworzyć i odczytywać json'y - polecam obejrzeć wszystkie 3 odcinki,

oraz LINK do tematu na forum, gdzie temat json'a w Javie zostaje wyjaśniony trochę szerzej.

Odpowiedź: Klient Pocztowy - javax.net.ssl.SSLHandshakeException

Tue, 03 Aug 2021 16:58:07 +0000

Cześć,

podkleję się pod temat, ponieważ mam problem dokładnie w tym samym miejscu, natomiast błąd wygląda nieco inaczej (treść poniżej), dodatkową informacją jest fakt, że błąd pojawił się po reinstalacji systemu windows, przed wszystko działało prawidłowo (projekt pobrałem oczywiście z gita https://github.com/NewLukasz/FirePost).

Czy może ktoś spotkał się z tym błędem?

Z góry dziękuję za pomoc.

javax.mail.MessagingException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate);
  nested exception is:
    javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    at mail@1.4.7/com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:670)
    at mail@1.4.7/javax.mail.Service.connect(Service.java:295)
    at mail@1.4.7/javax.mail.Service.connect(Service.java:176)
    at com.firepost/com.firepost.controller.services.LoginService.login(LoginService.java:30)
    at com.firepost/com.firepost.controller.services.LoginService$2.call(LoginService.java:55)
    at com.firepost/com.firepost.controller.services.LoginService$2.call(LoginService.java:52)
    at javafx.graphics/javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at javafx.graphics/javafx.concurrent.Service.lambda$executeTask$6(Service.java:725)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at javafx.graphics/javafx.concurrent.Service.lambda$executeTask$7(Service.java:724)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    at java.base/sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:170)
    at java.base/sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98)
    at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:238)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:394)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)
    at mail@1.4.7/com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:549)
    at mail@1.4.7/com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:354)
    at mail@1.4.7/com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:237)
    at mail@1.4.7/com.sun.mail.iap.Protocol.<init>(Protocol.java:116)
    at mail@1.4.7/com.sun.mail.imap.protocol.IMAPProtocol.<init>(IMAPProtocol.java:115)
    at mail@1.4.7/com.sun.mail.imap.IMAPStore.newIMAPProtocol(IMAPStore.java:685)
    at mail@1.4.7/com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:636)
    ... 13 more

Odpowiedź: JavaFX - problem z czcionką tylko w systemie Windows

Sat, 31 Jul 2021 06:37:16 +0000

Hej, nie mam czasu zaglądnąć do kodu, ale poczytaj o kodowaniu znaków, pewnie Twoja aplikacja używa jakiegoś kodowania domyślnego dla danego systemu operacyjnego i stąd te problemy. Ja bym na pierwszy strzał ustawił UTF-8 wszędzie.

Odpowiedź: JavaFx - problemy z uruchomieniem aplikacji

Mon, 26 Jul 2021 15:01:45 +0000

Cześć,

Miałem podobny problem a wynikał z błędnie wpisanej ścieżki do pliku fxml. Dodatkowo jeśli budujesz aplikacje na maven'ie to wszystkie pliki, które nie mają rozszerzenia .java powinny być w katalogu resources (w tym takze pliki fxml)

Odpowiedź: JavaFx — problem z wyświetlaniem danych z API w oknie aplikacji

Wed, 30 Jun 2021 18:25:43 +0000

Hej :) przejrzałem Twój kod, problem leży w tym, jak wydzieliłeś kontrolery CurrentWeatherCityOneController i CurrentWeatherCityTwoController. Jeżeli definiujesz widoki w plikach FXML, nigdy nie powinieneś robić ręcznej inicjalizacji jak teraz robisz w konstruktorach:

   public CurrentWeatherCityOneController() {
        currentWeatherCityOneImg = new ImageView();
        currentWeatherResultCityOne = new Label();
        currentTemperatureCityOne = new Label();
        currentPressureCityOne = new Label();
        currentWindSpeedCityOne = new Label();
        currentHumidityCityOne = new Label();
    }

Zauważ, że w MainController nie robisz inicjalizacji pól poniżej, tylko one są zainicjalizowane przez FXMLLoader

 @FXML
    private ChoiceBox<String> cityOneChoiceBox;

    @FXML
    private ChoiceBox<String> cityTwoChoiceBox;

Zacznij od tego, tutaj przesyłam krótki tutorial jak poprawnie zrobić nested components w JavaFX: https://riptutorial.com/javafx/example/7285/nested-controllers.

Powodzenia :)

Odpowiedź: Maven i JavaFX w IntellijIDEA sieje błędami

Fri, 18 Jun 2021 06:00:02 +0000

Hej, problem może leżeć w tym, że plik FXML powinien leżeć w /src/main/resources/..../view/.

Obecnie leży w podkatalogu java, natomiast maven kompiluje wszystkie pliki .java w nim się znajdujące i ignoruje pozostałe. Pliki nie javowowe należy trzymać właśnie w resources. Prosta rozpiska standardowych katalogów mavena tutaj.

Odpowiedź: Aplikacja pogodowa - wyświetlanie pogody na kolejne dni

Sat, 22 May 2021 00:37:59 +0000

Hej da się tak zrobić;) sam też wpadłem na taki pomysł . Jutro wieczorem będę przed komputerem to Cię nakieruje jak to można sprawnie zrobić.

Odpowiedź: Failed to execute goal org.openjfx:javafx-maven-plugin:0.0.4:run

Mon, 17 May 2021 11:03:03 +0000

Dzięki za rady, ale niestety nic mnie nie naprowadziło na rozwiązanie .

Druga podejrzana rzecz to fragment `<executable>/usr/lib/jvm/jdk-11.0.10/bin/java</executable>` - czy na pewno pod taką scieżką masz JVM'a ? Możesz usunąć całą tę linijke, może pomoże :)

A skąd wiesz, że tam niekoniecznie znajduje się JVM? Jeśli tam go nie ma, to gdzie może być? Dodam, że mam Linuksa Ubuntu 20.04 . Błąd, który wymieniłem w pierwszym poście pokazuje się niezależnie od tego, czy ta linijka jest czy jej nie ma, także usunięcie jej nic nie zmieniło.

Przy takich mało mówiacych komunikatach warto wywołać mavena w trybie szerszego reportowania błędów dodająć `-e -X` do polecenia

Niestety to, co „wypluła” konsola po dodaniu tych flag do polecenia niewiele mi mówi .

Użyłem w miarę najnowszych wersji i nie było problemu z JavaFX

U mnie nic to nie dało.

Jak wspominałem, projekt kompiluje się prawidłowo, zarówno poprzez compiler:compile, jak i mvn clean install, gorzej z uruchomieniem (nie działa javafx:run. jak również próba uruchomienia wygenerowanego plik .jar).

Oto kod na GH, jeśli ktoś z Was chciałby go przetestować na swoim kompie i lepiej zobaczyć, co jest nie tak: https://github.com/suabicii/javafx-mvn-template