Oprogramowanie Huba Direct Connect jadchub

JADCHub pojawił się w 2026 roku jako eksperymentalny hub ADC napisany dla Java 25. Publiczny projekt GitLab utworzono 2026/05/24, a DCHUBLIST ogłosił oprogramowanie 2026/07/11 z ciągiem wersji 0.9.0-SNAPSHOT. Taka wersja oznacza migawkę rozwojową, a nie stabilne wydanie produkcyjne.

Projekt wyróżnia się testowaniem nowoczesnego projektu Java wobec wymagań huba Direct Connect. Opublikowany opis wymienia wirtualne wątki Java, rdzeń bez frameworka, architekturę heksagonalną, porty i adaptery oraz ręczne wstrzykiwanie konstruktorów. Dostępne instrukcje budowania obsługują zarówno natywny plik GraalVM, jak i samowystarczalne archiwum Java.

JADCHub należy zatem traktować jako oprogramowanie rozwojowe. Jest przydatny do badania aktualnej implementacji serwera ADC i testowania klientów, ale zachowany zapis projektu nie ustanawia stabilnej linii wydań, długoterminowej polityki zgodności ani dojrzałej ścieżki aktualizacji.

Przegląd I Status

Pochodzenie Projektu

Projekt jest utrzymywany w przestrzeni nazw ADCHub na GitLab. Pierwszy publiczny temat DCHUBLIST opisał go jako hub ADC Java 25 bez frameworka aplikacyjnego. Ten sam temat dostarcza materiałów źródłowych i instrukcji budowania dystrybucji natywnej oraz opartej na JVM.

Nazwa występowała jako JADCH oraz JADCHub. Projekt GitLab używa JADCHub, więc tej pisowni należy używać przy odnoszeniu się do samego oprogramowania. JADCH jest użyteczne jedynie przy identyfikowaniu słownictwa pierwotnego tematu forum.

Architektura I Cele Budowania

Opublikowany projekt używa wirtualnych wątków Java do obsługi współbieżnych połączeń bez przydzielania tradycyjnego wątku systemu operacyjnego każdemu klientowi. Opis projektu wskazuje także architekturę czystą lub heksagonalną. Takie podejście oddziela rdzeń protokołu i aplikacji od adapterów sieci, magazynu i konfiguracji.

Udokumentowano dwie ścieżki budowania. Budowa GraalVM 25 native-image tworzy plik wykonywalny w target/jadchub. Budowa Maven package tworzy Uber JAR uruchamiany z Java 25 i włączonym przełącznikiem funkcji preview. Kompilację natywną przedstawiono jako preferowane wdrożenie, natomiast JAR pozostaje przydatny do debugowania i rozwoju.

Konfiguracja I Model Listenerów

Opublikowane polecenia startowe przekazują config/application.yml do pliku wykonywalnego albo JAR. Rekordy użytkowników są przechowywane oddzielnie w config/users.yml. Pakiet rozwojowy zawiera domyślne konto administratora o nazwie admin i haśle changeme; te dane należy zastąpić, zanim listener zostanie wystawiony poza kontrolowany system testowy.

Przykładowa konfiguracja wiąże IPv6 i IPv4 przez nieokreślony adres ::, a adres i port są kontrolowane w YAML. Przykład forum używa lokalnego listenera adc://localhost:1511. Konfiguracja TLS jest także opisana przez certyfikat, klucz prywatny, minimalną wersję, zestaw szyfrów i ustawienia wymagalności.

Obecny Status

DCHUBLIST obecnie raportuje jedno publiczne wdrożenie identyfikujące się jako 0.9.0-SNAPSHOT. Ta obserwacja dowodzi, że build rozwojowy był połączony z publicznym pingerem. Nie zamienia migawki w stabilne wydanie ani nie ustanawia, że każda reklamowana funkcja jest kompletna.

W bieżącym zapisie projektu nie widać numerowanego stabilnego wydania, macierzy zgodności, przewodnika migracji ani opublikowanej polityki długoterminowego wsparcia. Operatorzy powinni przypiąć dokładną rewizję Git używaną w teście i oczekiwać zmian formatów konfiguracji lub magazynu, gdy projekt pozostaje we wczesnym rozwoju.

Działanie I Odtwarzanie

Budowanie I Uruchamianie

Budowa natywna wymaga GraalVM 25 z native-image i używa profilu Maven native. Budowa JVM wymaga Java 25 i uruchamia spakowany JAR z włączonymi funkcjami preview. Zachowaj projekt Maven, przypnij wersje Java i GraalVM oraz zapisz commit Git przed porównywaniem zachowania buildów.

Awarię przed otwarciem listenera trzeba badać na podstawie wyników budowania, wersji Java, ścieżki konfiguracji i składni YAML. Awaria po otwarciu listenera wymaga logu połączenia ADC, wersji klienta i pierwszego statusu lub polecenia różniącego się od oczekiwanej sekwencji logowania.

Bezpieczeństwo Pierwszego Uruchomienia

Zastąp przykładowe hasło administratora przed dopuszczeniem połączeń zdalnych. Trzymaj config/users.yml poza publicznymi katalogami web, ogranicz jego uprawnienia systemu plików i nie publikuj go w raporcie błędu. Klucze prywatne TLS wymagają takiej samej ochrony.

Zacznij od listenera wyłącznie loopbackowego, sprawdzając zachowanie konta, negocjację funkcji, zgodność klienta i zachowanie restartu. Przenieś usługę na interfejs publiczny dopiero po sprawdzeniu danych administratora, ustawień TLS, logów i procedury odtwarzania.

Kopia Zapasowa I Odtwarzanie

Twórz kopie całego katalogu config, materiału certyfikatów, danych użytkowników, logów, dokładnej rewizji źródeł i wersji łańcucha narzędzi budowania. Sam plik binarny nie wystarczy do odtworzenia wdrożenia we wczesnym rozwoju, gdy później zmieni się pasujące źródło lub schemat konfiguracji.

Podczas aktualizacji między migawkami porównaj strukturę YAML i format rekordu użytkownika przed zastąpieniem pliku wykonywalnego. Przetestuj nową rewizję na innym porcie ze skopiowaną konfiguracją niebędącą sekretem. Nie zakładaj, że migawka odczyta dane utworzone przez późniejszy albo wcześniejszy commit.

Zweryfikowane Zasoby

Poniższe zasoby dokumentują bieżący projekt, jego pierwotne publiczne ogłoszenie oraz wersję zaobserwowaną przez działającą hublistę. Żaden z nich nie stanowi gwarancji stabilnego wydania.

Powiązane Materiały Direct Connect

ADCH++ dokumentuje dojrzały serwer ADC w C++ i stanowi użyteczny kontrast z architekturą Java JADCHub. uHub opisuje inną skoncentrowaną implementację huba ADC z ustaloną historią wydań i dokumentacji.

LuaDCH-NG jest istotny przy porównywaniu współczesnego serwera ADC zorientowanego na skrypty z kompilowanym projektem Java JADCHub. Użyj Pomoc, gdy wdrożenie rozwojowe potrzebuje pomocy nieopisanej w publicznym temacie projektu.