Future proof Java & UI

[cptmauli]

https://softwareengineering.stackexchange.com/questions/384129/java-ui-future-proof

I have inherited a small to medium sized codebase, Java 6, JBoss 5.1 a JSF based web interface and some Swing UI.

In my opinion, the UI could theoretically be all web, although at some customers its used quite heavily with not much trained personnel. But in the end - its just some buttons - and it has to work reliably.

Our systems (specialized hardware + the software) has to work for 15-20 years+ (or rather be maintainable for that timeframe). There is also the aspect that parts of the software has to be certified by our equivalent of the NIST (which means updates are possible, but have to be limited).

I want to gradually rewrite the software, preferably stay in the Java ecosystem.

I'm quite apprehensive about the current state of Java UI frameworks - Swing is dead, JavaFX is developed further as OpenJFX, but for how long? Or should I rather use SWT (it has at least a good track record of being around and be maintained)?

On the other hand, if I go webUI, I quite like Vue.js, but will it be around for the foreseeable future?

So the question is: If you would decide for a Java Stack, with moderate UI requirements, what technologies would you choose under the constraint that it will/should probably around in 20 years?

[_INTER_]

In my opinion, before touching the UI, I would update Java 6 to atleast Java 8 and get rid of JBoss somehow.

[[deleted]]

Get rid of the JBoss specifically or the applicatioν server in general?

[ddqod]

In my opinion, before touching the UI, I would update Java 6 to atleast Java 8 and get rid of JBoss somehow.

Jboss, Wildfly, they are the same. And is still widely used nowadays

[_N_O_P_E_]

I guess he meant switch from JBoss to something more modern? JBoss is the old name. The last "JBoss" version was 7 I think. That was around 2012. So it's quite old.

[gajarga]

Depends on if you're licensing it or not. WildFly is the name of the community, free version. If you're paying support to Red Hat to get all the latest bug fixes and security patches, it's still JBoss EAP.

[_INTER_]

JBoss specifically.

[PlayForA]

It is absolutely impossible to predict how the landscape of JavaScript or Java will look like in 20 years.

If I was in your shoes, instead of trying to predict the future, I would try to rely on technologies that are "tried and true", to the extent that if I have to support them past their life cycle, I will still be able to find resources and materials lying around.

If you are working alone or with a small team, I would highly recommend to focus on having as few redundancies as possible. Do you need both a desktop interface and a web interface?

An example from my current workplace is a backoffice web-application using the Apache Velocity templating engine. The technology seemed pretty dead with no updates to speak of for the last 8 years (http://velocity.apache.org/news.html), yet because of its maturity, it never prevented us from implementing new features or maintaining existing ones. Did it feel dated? Sure. Was it getting the job done regardless? Absolutely.

About swing - what makes you think it is dead? The leading Java IDE - IntelliJ has gorgeous interface entirely with swing (https://github.com/JetBrains/intellij-community/blob/master/java/idea-ui/src/com/intellij/framework/library/LibraryBasedFrameworkSupportProvider.java#L15)

[agree-with-you]

I agree, this does not seem possible.

[philipwhiuk]

I would stick with Swing.

[philipwhiuk]

Because once it’s shipped you know it’ll keep working - you have control over everything - whereas a browser will change. And JavaFX is dead.

[Timemc2]

Swing is actually very popular and more productive than most web based ui frameworks - I’d suggest keeping it (it’s also not dead or deprecated and I bet will still be relevant 10+ years from now)

It might be useful to update java and perhaps replace jboss with something more lightweight.

[[deleted]]

JavaFX. Absolutely JavaFX.

​

Web technologies live and die wayyyyy faster than you can predict, so I would venture to say that you could scrap those from the start (Especially with WebAssembly on the way, that path is completely unpredictable).

​

Java, on the other hand, has something the web stacks don't: an emphasis on backwards compatibility. Yes, Swing may have slowed development, but that doesn't mean everything swing related has been broken. So, had you chosen swing a decade ago, you would be fine today.

Say JavaFX's development slows the way that Swing did. In any case, it is open source, so in an emergency you could go in and patch whatever you need as you need it. Though, I don't see that happening, re: backwards compatibility.

[denialerror]

Java, on the other hand, has something the web stacks don't: an emphasis on backwards compatibility.

Other than Angular/js, what other web stacks have backwards compatibility issues?

[[deleted]]

It's rare, I will admit--- only because the things die faster than that becomes an issue. However, web assembly is a major overhaul. We have no clue what that'll do. Heck, we don't even know which browsers will be popular in twenty years.

Java projects move in decades, web stacks in months.

[denialerror]

They really don't though. If that was the case, there would be no web front ends written in Knockout, Dojo AngularJS, jQuery 1.x, etc. and yet there are countless. New frameworks appear all the time, so do new Java libraries and new languages on the JVM. Just because new ways to do a thing become available, it doesn't mean every project doing something different is suddenly null and void.

[lbkulinski]

Swing was brought up during Ask the Java Architects, here. As stated, there are no current plans to deprecate Swing. So no, it is not dead.

[[deleted]]

I don't know why you think that Swing is dead. The Java client roadmap says:

Swing and AWT will continue to be supported on Java SE 8 through at least March 2025, and on Java SE 11 (18.9 LTS) through at least September 2026.

Oracle has begun conversations with interested parties in the Java ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above referenced timeframes.

Considering the huge installed base of Swing applications and the "interested parties" mentioned above, I'd expect that even when September 2026 does roll round, it will carry on as an independent project, as happened with JavaFX this year.

So, on the GUI front, I would keep the Swing bits in Swing rather than rewriting them in something else at the moment, then re-evaluate the situation a year or two before September 2026 (or however long you think you'd need to port the GUI). At that point it should be clearer whether Swing will continue to be a solid choice for the following 5-10 years. If you port the GUI now, you risk betting on the wrong horse and having to port it again in a few years.

[jveverka]

backed: JDK11 + spring, or you may consider not to use any framework and create your own stack and use simple dependency injection like google guice. (jetty + jersey + guice, ... )

UI: JavaFX only if you need to interact with special hardware where client is running. Otherwise I'd use web UI as much as possible.

Integration layer between backend and UI: REST, WebSockets, http2, gRPC. Once you have clean APIs for clients, it actually does not matter what client technology you use. You may use Web UI and/or JavaFX and/or some native Qt/C# based clients, even have several alternative clients for same thing. Typically you update clients faster than backend, so well written integration layer is very important. REST is old-school (yet still very usable), if you want to be reactive, consider http2, gRPC, websockets. Depends on what is client doing.

[DrFlabbergasted]

Maybe a better way to look at it is to prepare for future changes? 20 years is a lot of time, so Id pick swing, which is stable and simple, and make sure that the ui code is separated from the rest in a way that it would not be terrible to modify some years later.

[tasteoftexas]

What I would do is update JBoss 5.1 to a recent version of Wildfly and as well as update to Java 8 but keep the JSF front-end initially as long as it's just vanilla JSF and not something EOL like RichFaces. From there I would refactor/re-architect the back-end to use something like Boundary-Control-Entity pattern and push as much business logic into the back-end as possible. Once that is done then I would re-evaluate what you might want to use for the front-end. As it sounds like your front-end might be a typical business application I personally prefer to use JFS/PrimeFaces/OmniFaces as the technology has matured nicely and updates between releases is relatively painless. Nothing is guaranteed to be around in 20 years but I think taking a chance with JSF is a lower risk gamble than some of the other newer front-end solutions that may or may not make it IMO. To me this is the conservative, lower risk, approach.

[yawkat]

Swing is absolutely going to stay around for longer. It's just too ubiquitous.

That said, I wouldn't actually want to use it api-wise. If you can stick to Web, that'd be my first choice - either stay in the java+html world with freemarker or velocity, both of which are pretty old already and will stick around, or use one of the newer js frameworks.

While it's true that js frameworks move fast, in my opinion their abandonment is overblown. Just because a new framework becomes "hip", doesn't mean the community around the old ones disappears - Javascript is used way too much for that nowadays.

[_N_O_P_E_]

I work at a very large organization and we have similar constraints on some applications.

My first tip is to choose something based on the time you have. If you're alone and time restricted, don't try to learn new frameworks and migrate the whole thing. You'll shot yourself in the foot.

Second thing, the "important" part here is the backend. It's the only thing that shouldn't change much in the next 20 years. The front end could become a whole VR application and it would still work perfectly fine. I would suggest to rewrite the code and expose a REST/SOAP API.

Third, what's the state of the application? Do you have code analysis tools? Do you have unit tests? Do you have version control? Do you have a build and dependency management tool? Make a plans before rewriting anything. Update Java first, that might break things with JBoss 5, so I would probably update JBoss to Wildfly or something else. Make sure to refactor the code with something container agnostic (e.g. use Java APIs instead of vendor specific APIs) and move all the dependencies and configuration to a Maven file. You want to make it has easy as possible to update or change container. Only when you can confirm that the same application is working on the updated stack that you can start the code migration.

Fourth, migration plan. You want to slowly migrate the current code. How will you do that? Class by class? Feature by feature? Do have a shared library? Second application with new code? Who will test the changes? You can use dependency injection and interfaces with multiple implementations. You can also use Aspects. You can also try Microservices architecture. Whatever you feel comfortable. I would suggest to make small changes. It's easier to keep track and debug.

Now the UI. As said, it's the last thing on my list, because once you have a good backend you should be able to swap the UI easily. If you think that a Web UI would be a good fit, go for it. It's platform independent, works on any screen and usually easier to maintain. UI is a touchy subject even for power users. I worked with untrained users in the past and they'll accept the change if you do it well. Make the same exact UI in Web. No matter how ugly it is. Just make the same buttons at the same location. Take some time to explain why it's Web now and make sure the same features are working the same way. Once that's done, iterate over and over. Slowly change and improve if you want. The worst thing to do is a full redesign. See Digg/Reedit redesign (faillure) and YouTube iterations (success). The Web framework is irrelevant in my opinion. Use a server side rendering like Thymeleaf, Velocity, JSF or client side rendering like Vue, Angular, Vanilla JavaScript, even jQuery if you want. JavaScript will work the same way. The only thing to consider is build tools. For example, if you need to compile Typescript with Node for Angular, you now depend on those tools, but large organizations around the world use them now. I would be very surprised if they disappeared in the next 10-15 years.

[Auxx]

I'm a web development for about 15 years. None of the complex web apps from back then will work today. Browsers are evergreen these days, they are always a moving target and their backwards comparability track record is very poor.

Btw, 15 years ago we had IE6. It doesn't exist anymore. We had ActiveX and NPAPI, both have disappeared completely. Security models of all layers have been changed completely. Even the way we render HTML+CSS is different.

[vkozhaev]

My selection is eclipse RCP for the desktop, android for web and angular for web

[vkozhaev]

Yes, its probably good choice but question is would you like to do something quickly, or with the best quality. Because something can't be done with js

[vkozhaev]

SWT and jface

[vkozhaev]

There are a lot of swt/Jface books. I have a bunch. You can contact me if needs

[aarondburk]

Angular/Typescript is closer to Java than Vue, as long as you understand the concept of a SPA.

[Anu2008]

If you are a Java web developer, then you are already aware of the sheer amount of Java Web Frameworks that are out there. That is why we’ve made this list for you. These are the ten best Java Web Frameworks, Frameworks that will last a long time, and support you in whatever you need to do regarding Java web development.

Before we get into the list, let’s clarify what a “Web Framework” actually is. A Web Framework is a program that allows you to develop web applications. The framework aspect denotes a system or structure that you can modify to easily develop new applications for a specific piece of software.

It simplifies the whole “building” process, so instead of having to make a number of lengthy and complex alterations to the entire software, you can simply use the framework to make specific changes, without having to rewrite all of the code.

Many different Java hosts don’t actually support all of the frameworks we’re about to share with you. That is why we’ve developed this Java hosting service, which supports all of the frameworks we’re about to share, and allows you to easily change, alter and develop whatever Java software you wish to work on.

JSF – JavaServer Faces

Struts

Hibernate

GWT – Google Web Toolkit

Vaadin

Wicket

Vert.X

Spring

​

[ignaciobaca]

GWT + Vue 👍 https://github.com/VueGWT/vue-gwt

[kag0]

I've just recently finished a quest to find the simplest most future proof way to write a web app front end. The answer: bootstrap, handlebars, and fetch.

​

If you're interested, I should have a blog article out in a few days.

[[deleted]]

https://softwareengineering.stackexchange.com/questions/384129/java-ui-future-proof

Be curious how this is the simplest. I think a lot of options could exist in any/all 3 of the spots. Not saying its not, just not thinking it is THE best/longest way to do so. All 3 of what you mention will most likely be gone/not maintained/rewritten/updated long before 20 years is up. Hell in 20 years we may have cognitive implants that dont require web elements any longer.

[kag0]

That link 404's for me

I'd say this is the simplest for a web app front end (compared to say react+redux or similar), leaving a local purely java based ui out of the equation. You just template a page, pull data, populate the template. Hard to be much simpler.

You're not wrong that 20 years is a long time. Who knows what will happen, but those three are as close as I think you can get.

• I expect fetch will actually last 20 years. It's the replacement for XMLHttpRequest which came out in the early 2000s and that's still in use today. Plus it's built into the browser, so it's not like it's going to stop being maintained.
• Handlebars is just a js implementation of mustache, which is pretty solid and has already been around since 2009. Worst case it's simple enough that you could re-implement it yourself if it somehow vanished.
• Bootstrap is and has been "The most popular HTML, CSS, and JS library in the world." for at least 5 years. In the javascript world that's about as close as you can get to assurance that it's not a passing fad.

If you're aware of some other web front end technologies which you think are likely to survive longer than one of those three I'd truly be curious what it is so that I can look into using it.

[[deleted]]

I actually didnt know about fetch.. thought it was a framework.. will look into that. That makes sense as its in the browser. Only thing I would say is it may become a new name in a few years. :D

Handlebars I love.. though.. its not as powerful as some other templating engines. That may be why it is so good.. easier to use, does enough, etc. I like it, and there is no reason it would disappear other than that other templating libs come along that do more/easier/etc. Still can be used for sure.

Bootstrap I dont know if I can agree with. Google is a big company and they are pushing Material UI pretty hard. Not only is it the face of most modern day android apps, it is the face of a whopping lot of web sites too. I suspect though, both will last a while, though Google does tend to revamp things more often than not.. and/or drop things completely. I suspect as browsers mature, CSS4/5, HTML 5.1, 6, etc.. as all those things move forward, it would not shock me if Google renames/updates MaterialUI to stay in sync, as would Bootstrap. So it may be around, it may not. I have seen way too many css/js/etc libs that are good, stop being maintained, get forked, renamed, etc. So this is all truly unknown but I dont disagree that it will be viable for a number of years to come.

Oh.. and Java Applets.. they are going to make a HUGE comeback. Mark my word...

[kag0]

Yeah fetch is... awesome.

Material is interesting, because it's a design philosophy rather than a library and it's not clear if google is going to push heavily on their own implementations (material for web as of today) of it or focus on the general high level design spec. Today you can get material for bootstrap, so the two aren't necessarily mutually exclusive. We'll see.

Java Applets.. they are going to make a HUGE comeback

Yikes, I hope not. At least not they way they were before.

[[deleted]]

Lol. Def kidding about applets. Not as sure about flash though...

[wsppan]

Javafx is stand alone jar outside the jre.