I am starting my career in programming and I have being trying to learn as much as I can, specially in "new" technologies as Angular 2+, although I like a lot more working on the back-end.
I am currently working in a company that has 4 main applications all running using Java EE 7 in a JBoss application server. The applications have a user interface with is currently based in Java Server Pages (JSP) and Java Server Faces (JSF) (mainly using PrimeFaces framework). My project is related to the migration of the User Interface from those "horrible" xhtml JSF pages to something like Angular 6+.
Needless to say that this this transition should happen with minimum changes to the back end. However, in the way the Back end was originally conceived, the back end is not RESTful (no REST API). So, it is all based on Beans, which makes the back end to be closely tight to the front end, making scalebility an issue.
All that being said, considering that creating such RESTful service, although not completely off the table, is not an option now, I have the following questions:
1) Is it possible to 'feed' the data to my Angular UI using a JSP !? I did some research on the topic, and it seems it is somehow possible.
2) Considering it is possible to use the JSP pages, how much of Angular "great tools and functionality" I would loose in this process (routing, two-way-binding, service injection, etc)?
It would be great to have some unbiased opinion, since I know where the people at my company stand on that issue (they would prefer to not spending the time creating the REST API at this time) and I know where I stand (I would rather create the service, since it would be a great learning oportunity for me). Still, facing the challenges of a real world application, I would like to know the community opinion.
Thank you for the help,
biased opinion, even though you asked for a non biased one
I'm not an authority on JSP, but from what I know, these are server side templates rendered on the backend. If this is the case then you cannot use this with angular. Maybe you can make it work somehow by extending the webpack config and custom plugins which load the .jsp files, but you will definitely lose either the AOT performance from angular or the dynamic nature from JSP. And besides that, angular is moving to all AOT anyways.
My suggestion is the same as yours, write a RESTful service. It shouldn't take too long, because the requests/responses are already available. Just make sure to follow to correct REST guidelines.
Then create the angular app based on the templates from jsp. I suppose you can copy these one on one, and change the syntax from jsp to angular, and obtain the necessary data from the REST api and populate these in your template
Related
Can I use Java backend for a browser game with Javascript frontend?
Since I already have knowledge in Java aswell as Javascript I was confused if I should forget Java for this purpose and skip to NodeJS for the backend, although I want to focus on Java in my future.
Would I need to learn Java Servlets and JSP or would a book aboout Java Networking be enough to deal with communication, or are both required since Servlet are part of a webapplication running on a web container, and Java Networking is not standalone.
You can! The choice of your technology stack for the frontend does not necessarily need to influence the choice of your backend technology (and vice versa).
Architecture
You can serve your game view directly from your java application. You could use JSP (or other templating solutions) for visual representation and/or include more logic via javascript.
You could also go for a more distributed approach, where your frontend would only be responsible for fetching and displaying the game state, while your backend would be responsible for serving and maintaining the game state. Your frontend could then inquire about and ask to modify the game state via http, and the backend might answer with the current game state represented as, for example, JSON.
Technologies
While reading about Servlets and JSP or basic networking can be of some value in itself; For this specific purpose, I'd rather look into some options to get you started more quickly. You might find using an established, modern framework easier - Since you're familiar with Java and want to focus that, I'd point you towards Spring Boot 2. Getting a web application running that accepts and serves JSON via an http endpoint can be done quite quickly. In my experience, it's well adopted in the industry as well, so you might benefit from that, too.
You are, however, free to chose in what language or framework to implement your backend: A server written in NodeJS any other language can be used for the same purpose, as long as you know how frontend and backend are going to communicate.
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'm asking this question because I'm having some difficulty choosing a framework (or selection of technologies) that I can learn and use for developing a web-based UI for a small Java application:
For background information relating to the app I'm developing please read this question:
So, developing the Java application is going ok and now I'm in a position where I would like to develop a web-base UI for it.
The application and database (MySQL) currently run on a Debian Linux box, as such I've decided that it would sense to use Tomcat to run the Web App. The Web App is to serve the following purposes:
1. Manage the execution of the App by CRUDing data from the MYSQL database.
2. Display status information about the app (i.e. what orders it's placed, what orders are pending, etc.)
3. Produce on demand reports on stuff like the running profit and loss, historic and realtime prices and pricing analytics
So far so good now here's the problem:
There are a bewildering number of choices for how to develop the UI, to name a few I've looked at:
JSPs + Spring MVC
JSPs + Sping WebFlow
JSPs + JSF + Facelets
Wicket
JSPs + JSTL
etc, etc...
The choices seem endless. Is there's a clear industry standard for developing web based UIs using Java related technologies? If so what is it? Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Thanks and Kind Regards
Personaly, I prefer another approach,
I would go for Eclipse of course, Spring (or other IOC container), Hibernate / JPA + JAX-RS or JAX-WS for the server layer, but not nessecarily JSF / JSP for UI.
For presentation layer, I would rather go with Flex, GWT, or a JQuery in an SOUI approach. (the service layer returns incremental updates in the form of XML or JSON, I swore not to mention the term AJAX)
Your service layer would serialize partial object graphs by demand from the presentation layer, which will act as a disconected client (work on an "offline" dataset , and update dirty on demand)
But that is just my wet dream, and in my current project I'm stuck with Spring MVC, and JSP + JSTL
I would give Jboss SEAM a test drive, just because Gavin King is behind it, but I think its JSF based.
I don't know why I don't see JSF as a SOFEA / SOUI approach, as JSF and AJAX go together well, but for some reason, JSF didn't win my enthusiasm as much as the above suggestions (Flex as a favorite)
See my related question: Web architecture: MVC, Lazy initialization, Data transfer Objects, Open Session In View, is there a consensus approach?
Is there's a clear industry standard for developing web based UIs using Java related technologies?
Well, Sun's Java EE standard is Java Server Faces (JSF) but the version 1.x of JSF is IMHO a kind of failure. This explains why they are so many alternative out there. But NO, there is no clear winner.
Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Actually, Matt Raible has done very famous presentations on presentation frameworks that you'll find in Comparing JVM Web Frameworks Presentation (the latest version goes beyond Java frameworks only). Really, have a look at both of them, this is very, very good material (with real life metrics).
Personally, I'm a JSF 1.x skeptic so I would not go in this direction (there isn't lots of demand for JSF in my country anyway) but rather choose an alternative. I think that Struts 2, Spring MVC, Stripes (this one is my preferred one), Wicket (this one is getting more and more attention) are all decent choices, they'll all get the job done, the 2 first one being I believe more asked on the job market (but not the smartest). For the final choice, I'd follow Matt's advice: Eliminate, Don't Include. If the popularity on the jobs market is an important criteria, then I guess Stripes and Wicket will get eliminated. If configuration verbosity is a concern, Stripes wins. If you're looking for a kind of Swing experience, Wicket is your friend.
Now, I need to mention that the freshly released JSF 2 and CDI (JSR 299) should be a big improvement (according to the people who worked on it). As I said, I'm a JSF skeptic and I need to take a second look (because Gavin says so). But I still didn't so I can't say anything for now and I won't make any bet on the adoption and future market demand of this new version. But it's worth noting that JSF 2 with CDI should be a really new and different experience.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've been doing PHP/MySQL web development for a while and I'm fairly competent in it. Lately however, I've learnt Java and fallen in love with it, and I'd really like to do more Java work now.
I've gotten my first opportunity with a client who needs a web 2.0ish web app built, and he has agreed to let me use anything I want to, including Java. However, I haven't done any web dev. in Java before, I've only went through the official Java tutorial, learnt a bit about applets and build a 2D pacman game, and have done some simple work in Google Web Toolkit.
I need to get started with this project in the next 2-3 days max, so I don't have much time to read long books about the topic. This is what I've learnt so far:
Setup a Tomcat on my dev machine to work with Eclipse
Learnt the basics of servlets, the doPost(), doGet() and init() methods, etc
Built a mini MVC app which displays a HTML page, lets you pick something from a dropdown and when you hit submit, it retrieves your submitted value through request.getParameter() in the doPost() function, and then forwards on to a JSP page which shows which value you picked.
I think these are the next few things I'd need to learn:
How to access/use databases
Sessions and Cookies
Possibly more about the syntax of JSP pages.
There seem to be hundreds of topics about Java web dev which I don't know anything about., but I don't have time to learn everything. I need someone to point out any other crucial things I'd need to learn, in order to build this web app (with perhaps 20 screens) using Java and Google Web Toolkit.
Also, I'm coming from a CodeIgniter background which is an MVC framework in PHP that makes things like form validation, sessions management (it uses database sessions), pagination, and common tasks like these very easy. If there is a similar, lightweight framework in Java that can take care of things like this, please mention it as well.
Thanks.
You should skip basic servlets and use a web framework, from Struts + Tiles (simple to get to grips with - a few hours at most) to Spring, etc. In your case I would also use Hibernate for database abstraction - you don't get up to speed with JDBC in such a short time.
There are so many different Java Enterprise technologies it's pretty hard to know where to start. As previously mentioned, the head first JSP & Servlets book is excellent. I currently work on an Enterprise app that was made years ago with just Servlets. We have migrated over to JSP's as time has gone on but we are not using any of the newer frameworks. So it is for sure a valid way to do it, although dated.
The thing about java, is that most enterprise development is a conjunction of a bunch of different technologies. For example, you could create an app using JSP's for the views with a Servlet back-end, using Hibernate for you DB connections, JDOM for your XML, JUnit for your testing framework, Log4j or AspectJ for your logging framework, Lucene for search, JBoss for deployment (and deployment can be pretty non-trivial) etc. etc. etc. You aren't going to go out and learn all of those technologies in the next 3 days.
What I would suggest is (as previously mentioned) to pick a framework, and there are many to choose from such as Tapestry, JSF, Wicket, Struts, etc. that will abstract away a lot of the underlying technologies. Any java technology you pick will have a good community behind it willing to help.
Another thing to consider, since you seem to be in a hurry to get things working, is that (in my opinion at least) Java is not a FAST language to build things in. It is very verbose and unless you grasp the nuances of good Java web design it is very easy to shoot yourself in the foot. Perhaps you should look at some of the other technologies that are available on the JVM (so that you have all the Java libs available) such as Groovy.
Groovy allows you the ability to program with Java syntax if you choose, or a dynamic Ruby-like syntax. Additionally, Grails is pretty much a Rails clone for Groovy and will let you write a web app in no time at all.
Whatever you choose to do, good luck and welcome to the wonderful world of Java Web Apps.
As a start, I would recommend you pick up Head First Servlets & JSP. It will give you a nice overview of Java web development. From their you would be better able to pick a web framework to use.
I'd recommend Matt Raible's app fuse .
It will give you a crash course in hooking your app up to a database, using a mvc framework, as well as some of the java build tools.
This App fuse demo will show how quickly he gets things rolling.
For basic simple java based web-app follow below things
Install IDE (eg. eclipse,netbeans)
Install web/application server (eg. Tomcat/Jboss)
Configure server in IDE
Create new dynamic web project with JSP/Servlet
learn/develop and run sample applications which includes advance technology like Spring,Struts,Hibernate,EJB etc.
I believe design is more important than technology, so keep learning design patterns. all major frameworks are based on different design pattern.
I would suggest that you try JSP first. JSP is simpler since you don't have to deal with the underlying server technology, not for simple applications atleast. It will get you up to speed. Later, as you gain experience, you can use servlets directly.
It will also fit well with your PHP intuitions.
It's true that starting with Java Web development is not as easy as PHP, especially with CodeIgniter, a framework that I've fallen in love with.
I'd recommend Grails, but first pick up a book on the subject. I've found that in order to get productive quickly you'll need a proper reference. Personally I used The definitive guide to Grails.
I would recommend grabbing a copy of the Servlet 2.5 Specification for reference purposes. It's a fairly nice read, and not too dry for a specification.
It explains about Sessions, Filters, Listeners, threading model, etc...
Also, take a look at the JSP Model 2 architecture (better link) which explains the best use of servlets and JSPs.
I wouldn't recommend looking at Struts or Spring if you only have a few days to get up to speed from scratch. Once you have gained familiarity with servlets and JSPs, then you could look at Spring MVC for an approach that supports easier unit testing for controllers.
You should better learn basic servlet and JSP lifecycles before you touch any framework.. that ll be better, coz you will have a good grasp of the inner workings.. Head First Servlets and JSP is the book you should go for..
I would consider using Groovy on Grails. It's a lot easier to get started and it has a lot of of things that you need built-in. GWT is available via a plugin as is JQuery.
The nice thing about Groovy is that it is basically a superset of Java with the great quick start speed of Rails.
And it will deploy as a .war to your Java EE app server.
I love the Sam's book, 'Teach yourself J2EE in 21 Days'. Awesome for concept reference and basic syntax. Should be pretty cheap by now too.
If you have a Java based web application (J2EE webapp - never mind which other underlying frameworks are being used), and you wanted to introduce a Flash based front-end, would you use Laszlo or would you rather expose a ReST-like XML interface and build and deploy a Flash application that uses that?
On one hand, Laszlo is quite amazing - doing for Flash what JSP does for HTML. It is easy to work with. It fits in very well with the rest of the web application (which is JSP based).
On the other hand it might be better to develop a complete Flash app decoupled from the server and use an XML-over-HTTP mechanism to bind the two. This would have the added advantage of being able to use the same XML interface for an AJAX front end if needed.
What would you do, and why?
I would create the contract-first services, deploy them separately, and then write the RIA client to access them.
Coming up with the schema first has the added benefit of completely decoupling the two during development. The RIA developer can create some synthetic XML streams to use for data while waiting for the services to come on-line.
I might have considered Laszlo in the past, but today, I'd stay within the Java stack and use JavaFX.
Laszlo is the product that never made it, there isn't a big enough ecosystem of developers around it.
I'd use Adobe Flex for the front end. The same benefits of using a markup language for doing flash, but it has a much larger developer base and open source projects to draw upon. For the data communication, use either REST or if you want to get clever, use BlazeDS.
OpenLaszlo is a complete RIA framework, so I'm pretty sure that you can 'compile' it to a completely standalone app that communicates with the server over HTTP. It's really very similar to Flex. The advantage Flex has is a much bigger community, a full-blown IDE, and more resources (Adobe), while OpenLaszlo is a little more innovative in that you can deploy to Flash or AJAX from one codebase.
I've actually spent some time working on a implementation similar to what you're suggesting. I had a complied Open Laszlo front end embedded in a web page with a Django (a python MVC library) REST interface on the backend and no Open Laszlo server. It works reasonably well, but there are a couple of things to watch out for. Open Laszlo only supports calls to GET and POST, so you won't be able to easily use the DELETE and PUT methods in your REST API. The other is the lack of community around Laszlo (as mentioned elsewhere). I can sometimes be frustratingly difficult to answer some basic questions when using Laszlo, particularly around the XML HTTP API and XML replication features in the framework. I personally never really looked at the Laszlo back end server seriously as I wanted an open API that could be consumed easily by other clients.
All this being said, the implementation does work and can be effective if you're willing to work around the limitations mentioned above. Plus Open Laszlo is free, which can be a really big plus if your working on a budget.