I have designed a GUI connect to DB button using Swing in java now i want to make it webapp application I need to host it on my website. Do i need to replace all my coding as swing is only for desktop application. Or is there any other way?
It will partly depend on how well you've structured your application. If there's no layering involved - if the GUI classes connect directly to the database, for example, then yes, you'll need to rewrite the whole thing.
If, however, you already have a separate data access layer, business logic layer and presentation layer, then you may only need to completely rewrite the presentation layer - while checking the other layers for things like concurrency safety.
The stateless nature of web applications - aside from session-based state - may mean you need to redesign the application significantly, of course. This may in turn mean that your existing "backend" layers aren't quite appropriate. While the theory is that they'd be presentation-layer-neutral, in my experience it would be quite unusual to manage to write an app targeting a single UI technology without some of the usage assumptions leaking through into underlying layers.
Check GWT, its a great framework that allows you to code in java...
If I'm getting it correctly, you need to reuse a database connection code. In that case:
You need to remove only the code that references Swing components. The ones that start with J. More accurately - the ones that are in package javax.swing or java.awt. The rest of the code can stay.
However, if your database connectivity code is too coupled to the GUI code, you'd better start that from scratch and just copy-paste of the parts in your Swings application.
In case you have a big Swing application, then you might want to use an automatic converter to web (ajax) application instead.
One such solution is AjaxSwing. There may exist others as well.
Take a look at AjaxSwing. It is a web deployment platform for Java Swing applications. It allows companies that built Java desktop applications to run them as web applications. Because it produces pure HTML/JavaScript you can also run Swing application on iPhone, iPad and Android phones.
Yes you need to replace all the GUI layer with web-app stuff (jsps, controllers etc). It should be relatively easy if you kept the business layer separated from the GUI layer. I suggest taking a look at Spring Framework, it is very useful for developing web apps.
If you want a Swing like application on the web, you can use an Applet.
You can turn your swing application into an applet, then it will run in a web browser, provided a JRE is installed on the client machine.
What can be reused depends upon your architecture. Look at Wicket, which offers a programming model very similar to Swing. That would not avoid rewriting of the GUI but makes the "mental mapping" easy.
Related
I need to build a desktop application for internal users for certain business. It also needs web based GUI for external users. I know, with web GUI both internal and external users can access it, but there are certain factors which are outside our control - due to which, desktop application is really unavoidable. For the purpose of this question, I would like to focus on the way to support both Desktop client (Swing) and Browser client.
Are there any best practices to be followed? I could think of below:
Expose service classes as web services and use these from both Swing client and web client
Expose service classes as EJB (business is into Java EE techs) and use Swing client as EJB client. Web client can use controller classes to interact with EJB
Are there any known benefits of using either approach, apart from technology agnosticism offered by web services?
Also, for swing client, I am thinking of using Java Web Start for easy distribution. I have never used it before, but from what I understood, it can support automatic version check at startup and update the client when required - is this correct?
If you need to avoid dependency to Java/JVM on the browser (which you most likely at least want to), you should definitely go with mixed Swing-Vaadin approach. Build the internal application with Swing or JavaFX and web part with Vaadin. The programming model in Vaadin is so close to typical desktop UI library that it is really easy for the same developers to work with both code base, and naturally you'll use exactly the same backend.
See the example application I recently built to demonstrate a setup like this.
I have a fairly large Java application in production (30k lines of code). It uses a decent sized library of business objects I wrote in Java and I have a Swing interface thrown on top of it.
However,it functions as a standalone desktop application currently with no server-side at all (except for a MySQL database and some text files housing central data). As data volume and calculation needs increase, this is becoming a problem running on just a quad core workstation with five threads and 4GB of RAM.
I'm thinking of going the modern route and create a web based application using PHP, HTML, CSS, Javascript, etc. However, I don't want to rewrite my Java business object libraries from scratch in PHP (and I dont like the loose type style of PHP). I'd prefer to keep everything in Java so I can use my current business object library. That way I only have to scrap the Swing interface and serve up dynamic web pages instead, and have a Java server use the current business object libraries to calculate everything.
I've done research but I dont know what I'm looking for as there seems to be several disparate options. Does Apache have a Java web server solution or something that accomplishes this? What is the best way to transform a Java application into a web application?
Rewrite the UI layer with Vaadin. Vaadin UI code is almost like Swing code and is executed in the JVM (typically in Java EE server or in plain servlet container with e.g. Spring). That is why you can most likely recycle the most essential parts of your application.
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
I need to make a web app that I would be able to install as a desktop application on a client PC (database, jetty+war, firefox/chrome/sth portable).
The application is a quite big search app (I MUST use Lucene). There are only few screens, some dependencies in search queue, etc.
Now I need help in choosing correct components. Application must be:
Light - minimalistic and user friendly frameworks (Java + JavaScript)
Efficient - working on old PCs and working fast
Developer Friendly - I would love to write it with pleasure ;)
So my questions are:
Do you have any suggestions about choosing components?
What frameworks, what obfuscator?
Do you have any comments about making a web application a desktop application?
What are the main risks?
Many Java web apps distributed in this style are done so alongside a lightweight application server or web container such as Jetty or Tomcat.
When you click to start the application, this actually starts the container which internally hosts your application. (You're application can be packaged as a WAR internally.)
For lightweight databases, possibly look at SQLLite, HSQLDB, or Apache Derby. These can also be distributed alongside the application. Or maybe you can just collect database credentials as part of your install process and let the customer maintain their own database.
The arrangement you describe will involve work and custom scripting. You're going to the trouble of creating a thin, multi-user, web application and then throwing away the main benefit - the shared single instance. Customers, eh, who'd have them! :-)
Maybe you could take a look at Google's GWT. You can write Java code and it will then "compile" it to JavaScript. Using it feels like using a desktop app. Gmail, Google Wave,... have been created using this technology.
I think you don't even need a webserver, but the compiled result is pure JavaScript + static HML pages. If you then create a Chrome application shortcut it'll really look like a desktop app ;)
The only thing is that the learning curve will be a bit steep initially but if you're eager to learn, then it's really cool stuff and you can manage it easily.
Ha, I'm in the same boat. But I have many screens like normal web apps.
My suggestions is:
1, take web easy, no framework. Since there's little web pages, html+jquery+css is recommended;
2, lightweight database is not important. Because mysql does cost little memory, and it's user-friendly, large community.
3, So pay your attention on your search engine, and happy coding.
Does anyone know of any tool that can facilitate/ease porting of an app to both Java Swing and GWT?
I've got a few "screens" that makes complete sense to have both in a desktop app and in a browser and I was wondering if there was some kind of common API that could be targeted that would facilitate creating these two different "views" (see my comment)?
I think it's entirely possible, but it would mean a different take on the server side of things.
If you do interface-based POJO development of the server-side components that the UI communicates with to do the work, you leave yourself the option of either an in-memory implementation or one that acts as a proxy to a remote component. The Swing desktop UI might use the in-memory version of the server-side, while the GWT version talks to the distributed version.
If you use Spring, it's easy to inject the appropriate implementation for each UI. Both only know about the interface and are oblivious to the implementation details.
I imagine a single code base that might be packaged in different ways. The Swing desktop app would be packaged and delivered as a JAR file. It wouldn't include the GWT or web tier controller classes. The GWT code base would include web configuration and controllers, because controllers are really part of the web tier.
The service interface and everything behind it would remain the same for both. The only difference would be that the Swing desktop configuration would inject the in-memory service layer implementations of the service interface. The web configuration would inject the web-based implementations of the service interface.
Whether my attempt to read your mind for requirements is correct or not, this approach has value regardless of how you decide to implement the service and client tiers.
I'm a Spring fan, so I'd recommend the use of Spring.