Overgang van het Swing Application Framework (JSR 296)

Een paar jaar geleden introduceerde JSR 296 een raamwerk voor het maken van desktop-applicaties in Swing. NetBeans zorgde voor een nauwe integratie met de referentie-implementatie. Ik dronk de Kool-Aid (r) en creëerde een aantal programma's van eenvoudige statistische rekenmachines met één paneel tot grote multi-window, multi-ruit data-analyse en simulatieprogramma's.

De JSR is sindsdien grotendeels verlaten en de volgende versie van NetBeans (7.1) zal geen ondersteuning meer bieden. Ik ben op zoek naar advies over hoe deze groep bestaande applicaties kan worden overgezet naar een nieuw framework.

Er lijken verschillende mogelijke keuzes te zijn, waaronder:

En er zijn anderen.

Heeft iemand ervaring met de overgang van JSR 296 naar een van deze alternatieven? Ik zou liever niet de leercurve van al deze onderzoeken doorlopen als iemand anders het eerder heeft geprobeerd.

Naast het verplaatsen van het project, kan iemand zijn of haar ervaring relateren aan het onderhouden van een ononderbroken versiecontrolegeschiedenis tijdens de overgang? Hoe zit het met het verplaatsen van het helpsysteem? Werkte dat goed?

Bedankt voor het advies dat u kunt geven.

6
@santiagobasulto: Ja, web-apps zijn tegenwoordig een goede optie en alle mogelijkheden worden toegevoegd met HTML5 en CSS3. Ik heb ze vermeden vanwege de validatievereisten van de sterk gereguleerde sector waarin ik meestal werk. (Op welke browsers is dit geval gecontroleerd? Welke versies van deze browsers? Wat doet de app wanneer deze wordt gebruikt door een niet-geanticipeerde browser? Etc.)
toegevoegd de auteur clartaq, de bron
@Shakedown: Bedankt voor de aanwijzer. Het leek erop dat Spring RCP was verlaten tot je commentaar me ertoe bracht opnieuw naar het forum te kijken. Ik zal wachten en zien wat hun "nieuwe richting" is.
toegevoegd de auteur clartaq, de bron
@Bill: Je hebt gelijk. U kunt de bibliotheken nog steeds gebruiken, maar ze zijn niet langer in ontwikkeling - geen bugfixes, geen uitgebreide mogelijkheden. Dat is de reden waarom BSAF een aantrekkelijke optie is - ze zetten hun ontwikkeling voort, in wezen waar het werk op de JSR is gebleven. Het is net iets saaier om nieuwe projecten helemaal opnieuw te starten zonder de IDE-ondersteuning.
toegevoegd de auteur clartaq, de bron
Ik ben nieuwsgierig, wat doen netbeans nu dat je niet kunt leven zonder JSR-296? Je moet misschien bibliotheken toevoegen, maar je zou het nog moeten kunnen compileren. Matisse zou nog moeten werken. Of is het het feit dat netbeans eindelijk de steun verliest die de laatste strohalm is?
toegevoegd de auteur Bill, de bron
Houd daarvoor een oude versie van netbeans in de buurt. ;-) Serieus is dat de toekomst van de JVM-desktop JavaFX is en dat de toekomst er nog niet is. Ik geloof dat Oracle meer geneigd is om het te doorstaan ​​dan ooit zou zijn geweest.
toegevoegd de auteur Bill, de bron
Een andere optie om te overwegen is Spring RCP
toegevoegd de auteur Nate W., de bron
Ik kreeg datzelfde probleem 2 jaar geleden te maken. Tryed Eclipse RCP, cool framework maar heeft mij niet overtuigd. Dus ging ik diep in web-apps. Ik vind dat je zo moet kijken.
toegevoegd de auteur santiagobasulto, de bron

3 antwoord

BSAF is actief ontwikkeld, dus ik zou niet (en eigenlijk niet, de vork hebben gebruikt vanaf zijn geboorte aangezien het origineel sindsdien helemaal niet werd onderhouden :) zie om het even welke reden om het niet langer te blijven gebruiken.

2
toegevoegd

Ik zou een iets drastischer suggestie doen, laat Swing echter vallen. Overgaan naar iets anders is niet-triviaal, als je op Java bent, zou ik gewoon naar GWT gaan. Gezien Oracle alleen geïnteresseerd is in enterprise Java en ze een strak commercieel gericht bedrijf zijn, zou het zeker volgen dat Swing op dezelfde manier zou gaan. We zijn ongeveer 5-6 jaar rechtstreeks vanuit Swing naar JavaScript verhuisd, de stap in die richting is de afgelopen 12-18 maanden erg sterk geworden.

0
toegevoegd
Mijn persoonlijke ervaring is direct met JavaScript. Er zijn veel JS-bibliotheken die zijn uitgekomen om algemene functionaliteit te bieden. Highsoft-grafieken, onvoldoende geheugen, highcharts.com/demo/scatter , scatterplots. Er is een eerlijke selectie van bibliotheken voor GWT, in dezelfde gebieden. GWT vertaalt zich naar daadwerkelijk JavaScript dat wordt uitgevoerd, dus technisch gezien moeten GWT en native JS vergelijkbare snelheden voor interactie hebben. Mensen zijn meestal een beetje bang om native JS te schrijven, maar ik raad ten zeerste aan om het een paar weken te proberen, het is niet zo slecht. U krijgt uiteindelijk veel betere controle over uw toepassing.
toegevoegd de auteur David, de bron
Ik mag jouw manier van denken wel. Maar ik vraag me af of GWT (of ZK, wat dan ook) kan omgaan met zeer interactieve apps. (Ik heb bijna geen ervaring met GWT en ZK) Mijn apps tonen bijvoorbeeld veel gegevens, meestal een scatterplot of histogram, en de gebruiker tekent rechthoeken of polygonen om subsets van de gegevens te selecteren. Zou GWT hiermee omgaan, dit is een redelijk snelle manier? Kent u een democode (of een werkende website) die iets soortgelijks doet? Bedankt!
toegevoegd de auteur user949300, de bron
Het vergelijken van GWT met Swing is als het vergelijken van Kladblok met Word. Als u een weboplossing nodig hebt, is GWT geweldig, maar kunt u alleen veel gelimiteerde applicaties maken.
toegevoegd de auteur MartinZ, de bron

It is still possible to develop with (B)SAF in NetBeans 7.2 if you want to. As of this writing the integration needs an owner. See: http://netbeans.org/bugzilla/show_bug.cgi?id=204661#c59

0
toegevoegd