5 ms·

I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that lev

I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that leverages some cool JS framework. At my workplace, we have this debate going on about what to do with our GUIs (that are used only internally). The alternatives are 1) keep them in Java Swing, 2) progressively rewrite components in Java FX 2, 3) go web. These are operational GUIs that talk RMI with our Java servers (which we won't rewrite). What's your take on this decision? Do you think it is shortsighted to stay in the Java world for the GUI side, or am I being overly optimistic when I say we should just start over in web technologies?

kodablah 14y ago
I think you have to weigh the importance of the internal application and it's need for a rewrite. It just may not be worth it. If you do, I would recommend web, but you'd still have a significant JVM-based-language backend I'd assume since you have to use RMI as your communication protocol. I personally would not do JavaFX because you aren't really stepping up enough to make the rewrite worth it.
lmm 14y ago
If it ain't broke don't fix it. Why do you want to replace them? Is the development burden of maintaining them in Swing really that high? Would it make life easier to have the UI be available on the web? If either of these is a "yes" then make the case on those grounds; "everyone is writing..." is a terrible reason for doing something. In any case I see no point rewriting them in Java FX, that would just be replacing one dying technology with another.
traxtech 14y ago
The question should be "why do you want to go away from java swing ?" What are the problems/limitations you encounter ? If there's no serious reasons to change, why change ? (well, there's the fun to rewrite all, the fun to learn technologies, but from a business standpoint, that's not reasonable)
- espinchi 14y ago
  One argument for going web is recruitment: the pool of active developers that know Java, Swing and Spring is shrinking. Also, the size of the developer community in the Java/Swing world versus that in web technologies is not even comparable when it comes to sharing knowledge and open-source components. (I work for a lab, so many open-source licenses are compatible for us.) And, sure... it would be so much fun!
RyanZAG 14y ago
I'd recommend taking a look at GWT - it is pretty much for your exact situation and works very well for that. You will still need to convert from Swing to HTML elements, but if you have done any sort of separation between UI logic and Swing itself, this is usually not too bad. This way you can swap over your existing java apps to one of those fancy HTML5 clients you're talking about. ;)
- sgt 14y ago
  I would advise against GWT, after two separate projects - it starts off simple, but then as the project grows the more you regret basing everything around GWT in the first place. This guy will definitely not save time doing it the way you suggested.
  - RyanZAG 14y ago
    You make that statement as if there is no way you could be wrong - yet there are multiple very large GWT deployments running very happily in production. I've done the exact thing - moving a finance system to a GWT frontend (it also retained a desktop frontend), and the system was reasonably easy to convert. You hook up some html in UiBinder, get some RPC working for the data, login form, refactor the widgets to use the uibinder html, use activities/places to handle navigation and backstack, and off you go. So "definitely not save time" seems a bit harsh? Maybe worded "if you have anything like my experience, you will definitely not save time"? EDIT: What part of GWT caused you issues btw? Maybe my uses never hit on the trouble parts.
    - edwinnathaniel 14y ago
      To GWT or not to GWT is a tough call. There are features of GWT that I love the most when developing front-end code: resource bundle (auto-gen CSS sprites both the images and in Java code, no more hacky solution), i18n, UiBinder, JUnit (provided you 'architect' the code using MVP), great JS compiler (pruning dead code, producing multiple outputs for browser specific). GWT infrastructure is definitely years ahead of anything out there in the market. Having said that there are a few things that I missed from using normal tools like HTML/CSS/JS: fast refresh/update, debugging inside firebug vs attaching your IDE to debug front-end stuff. In general, development in GWT is slower if you don't have fast machines :)
deleted 14y ago
[deleted]
shaydoc 14y ago
I have gone completely decoupled web html/css/ javascript client architecture talking to restful services, with support for web sockets thrown in too. Enable your server side for rest and go web.

kodablah 14y ago

I think you have to weigh the importance of the internal application and it's need for a rewrite. It just may not be worth it. If you do, I would recommend web, but you'd still have a significant JVM-based-language backend I'd assume since you have to use RMI as your communication protocol. I personally would not do JavaFX because you aren't really stepping up enough to make the rewrite worth it.

lmm 14y ago

If it ain't broke don't fix it. Why do you want to replace them? Is the development burden of maintaining them in Swing really that high? Would it make life easier to have the UI be available on the web? If either of these is a "yes" then make the case on those grounds; "everyone is writing..." is a terrible reason for doing something. In any case I see no point rewriting them in Java FX, that would just be replacing one dying technology with another.

traxtech 14y ago

The question should be "why do you want to go away from java swing ?" What are the problems/limitations you encounter ? If there's no serious reasons to change, why change ? (well, there's the fun to rewrite all, the fun to learn technologies, but from a business standpoint, that's not reasonable)

espinchi 14y ago
One argument for going web is recruitment: the pool of active developers that know Java, Swing and Spring is shrinking. Also, the size of the developer community in the Java/Swing world versus that in web technologies is not even comparable when it comes to sharing knowledge and open-source components. (I work for a lab, so many open-source licenses are compatible for us.) And, sure... it would be so much fun!

RyanZAG 14y ago

I'd recommend taking a look at GWT - it is pretty much for your exact situation and works very well for that. You will still need to convert from Swing to HTML elements, but if you have done any sort of separation between UI logic and Swing itself, this is usually not too bad. This way you can swap over your existing java apps to one of those fancy HTML5 clients you're talking about. ;)

sgt 14y ago
I would advise against GWT, after two separate projects - it starts off simple, but then as the project grows the more you regret basing everything around GWT in the first place. This guy will definitely not save time doing it the way you suggested.
- RyanZAG 14y ago
  You make that statement as if there is no way you could be wrong - yet there are multiple very large GWT deployments running very happily in production. I've done the exact thing - moving a finance system to a GWT frontend (it also retained a desktop frontend), and the system was reasonably easy to convert. You hook up some html in UiBinder, get some RPC working for the data, login form, refactor the widgets to use the uibinder html, use activities/places to handle navigation and backstack, and off you go. So "definitely not save time" seems a bit harsh? Maybe worded "if you have anything like my experience, you will definitely not save time"? EDIT: What part of GWT caused you issues btw? Maybe my uses never hit on the trouble parts.
  - edwinnathaniel 14y ago
    To GWT or not to GWT is a tough call. There are features of GWT that I love the most when developing front-end code: resource bundle (auto-gen CSS sprites both the images and in Java code, no more hacky solution), i18n, UiBinder, JUnit (provided you 'architect' the code using MVP), great JS compiler (pruning dead code, producing multiple outputs for browser specific). GWT infrastructure is definitely years ahead of anything out there in the market. Having said that there are a few things that I missed from using normal tools like HTML/CSS/JS: fast refresh/update, debugging inside firebug vs attaching your IDE to debug front-end stuff. In general, development in GWT is slower if you don't have fast machines :)

deleted 14y ago

[deleted]

shaydoc 14y ago

I have gone completely decoupled web html/css/ javascript client architecture talking to restful services, with support for web sockets thrown in too. Enable your server side for rest and go web.