We Keep Coding

Java EE Microprofile

I know it could be a pretty vague topic but please can someone explain it in plain English. I've read some articles regarding the trending topic java EE's 'microprofile' but was not able to clearly understand its purpose.
My understanding in this emerging concept is that java community finds way to reshape the Java EE model to become a microservices friendly framework or platform.
If we can already create a distributed microservice application in few minutes using spring boot or other API / library then why do we need microprofile?

I am active within the MicroProfile community on a daily basis (and primary author of the FAQ on MicroProfile.io). As Gimby mentions, check out the FAQ.
Basically, the JCP is a standards organization and doing innovation using a process designed for standardizing technology is a no-no. The idea of MicroProfile is to do rapid innovation with Enterprise Java and Microservices that leads to technology standardization. To James' point, yes, it is getting off the ground using Java EE technologies so it will feel more natural for Java EE developers.
Going forward, however, MicroProfile will not be limited to Java EE technologies. It may adopt other non-Java EE frameworks or even create new APIs. Once features/technologies are mature enough, we'll look to standardize them. If you like the idea of standards around Java microservices and want to participate in innovating-before-standardizing, then join the MicroProfile google group and feel free to get involved in doing so. You can have direct input and even contribute code that will eventually be part of a standard.
Hope this helps.

If you like Spring Boot then I'd stick with it really. One of the whole points of microservices is for teams to use the technology that suits their needs and that they are happy with.
IMHO the Java EE Microprofile is focussed on helping help folks who know or like Java EE to move to microservices reusing their Java EE knowledge; rather than having to relearn how to do things on Spring Boot. e.g. so they can reuse CDI if they prefer that to Spring DI

Lift framework with java

I'm building a web application that needs high performance. I intended using Java EE but after researching about it, there are many negative comments about Java EE applications.
I'm thinking about the Lift framework, but it seems that Lift only support Scala, and I only know Java. Does Lift actually support Java? (I can't find any project example that uses Lift with java). I downloaded a Lift framework project application and there is a boot file in it, can we create a same boot file but for Java?

I'm pretty sure Lift is Scala only. If you're looking for high performance and Java then you should check out the Play Framework as it also has the benefit of not requiring a Servlet container to be deployed.

The Lift framework is Scala only. I want to note that in my experience the transition from Java to Scala was not that hard and now that I know it, there are many language features that make development easier and faster for me. You can take a look at this guide for transitioning between languages: http://www.scala-lang.org/node/960 to see if it might be something that might be right for you. From experience, I really enjoy using the Lift framework as it offers a lot of performance and functionality. The documentation is a bit lacking, but the community is great and makes up for that if you get stuck.
As for Java EE having negative comments, that is a bit vague. The Java EE spec includes everything from Servlets to JSF and EJB. Parts of the spec you will find in almost any web framework (including Lift) and others are more specialized. JSF for example has a lot of overhead, but tries to simplify a lot of the typical application lifecycle. EJB similarly tries to simplify the persistence layer through object relationship management (ORM).
High performance sites can be accomplished with most frameworks, but a lot of it will come down how you develop it. Also, because the framework supports it does not mean you need to use a particular component. Spring (http://www.springsource.org/) is a framework that many people have used on high performance sites, and is incredibly configurable (Supports EJB and JSF, but you don't need to use it). Also, Wicket (http://wicket.apache.org/) is a Java framework that offers a similar feel to Lift that might be interesting to you.

I worked with Lift only for a year now, and was never really interested if it would run from java (I wanted to learn new effective conceptions anyway).
So, I don't fully know the subject. But what I know for sure is that Liftweb has java methods almost everywhere to support java, too. So, you can build your app if not fully in java, then most part of it.
Prooflinks are like these:
http://main.scala-tools.org/mvnsites/liftweb-2.4-M4/net/liftweb/actor/LiftActorJ.html
Classes that add support for java by adding java-acceptable method names and such. These classes usually have a "J" letter at the end.
Anyway, I'd suggest to try out Scala, too -- it's great. And even if you use java only -- you probably will get used to Scala anyway, because you probably would want to read the source code sometimes.

WHich is the best path or flow to learn java from web site perspective

I have just started learning java and i have about 8 months time. My main aim is to build web application using java. But as there are many java technologies/frameworks available i am conufused how should i go
IDE i am using is eclipse
The path which i am thinking is below
1)Learn Core Java
2)Project: Build Java Invoicing System with JDBC or mysql to test java knowledge
3)Learn Servlets / JSP to
4)Build small site like simple logon/memberarea/catalogue using servlets/jsp
Now guys I really don't know where the following things stand in my path and which things they will help
1)Java EE
2)Spring or spring MVC, what's the difference?
3)Hibernate
4)Wicket
5)Struts
I really don't know how should i learn those and which things to choose from.
what should be my final project which can be build using those because if i see from my current stage even website can be build using servlets/jsp. then why do i need those other technologies
Can anyone give an example of a project which can be build using new technologies and not using jsp/servlet, so that I can get an idea why we need those?

Lot's of stuff to learn in here so I would take it a bit at a time. I'm going to assume you are relatively comfortable with the Java language and core APIs.
First learn about JDBC and databases. Get a basic functional JDBC example app working (not visual just some a vanilla Java app) that does read/insert/update/delete of some records in a table. This will give you the basis for building whatever app you choose. Almost all interesting applications involve some sort of persistence/database.
Learn the main JDBC APIs (Connection, PreparedStatement, ResultSet) and write some code that uses these to get comfortable.
Learn about how transactions work in databases if you aren't familiar already and how JDBC uses them (Connection.commit and rollback)
Next you could look into the spring framework. This has a several useful features that come in handy when building these applications. The main ones to get to know the dependency injection functionality and the JDBC libraries it has. The DI stuff is a bit of a "duh"? if you haven't used it before but it is very useful/powerful especially for medium size + apps. The JDBC libraries help with the cruft of dealing with the raw JDBC APIs and make your code less error-prone.
Once you've got some basic JDBC and Spring stuff worked out you can then start bringing in a web framework.
This is more difficult because there are so many. In the interest of getting something up and running quickly I would probably go with Wicket. It runs inside a servlet container like Jetty, easy to get up and running with a basic web page or two and relatively easy to evolve of the project over time without going down too many blind alleys. I've found that frameworks like JSF (the Java EE default web/view framework) takes a lot of up front time investment to get going on. Most of these frameworks, including Wicket, can leverage the spring stuff you've got above.
Avoid JSP, it's unpleasent technology and outdated by virtually everything else.
To answer some of your other points.
Hibernate is a tool for mapping an object model to a relational model. In it's most basic form you define a Java class for each DB table with the class having one Java property (variable+getter+setter) for each DB column. You can also add references from one class to another to model database relations. It is good but it takes a bit of getting used to.
Spring I've explained partly above. Spring is much bigger than just DI and some JDBC libraries. It also has transaction management libs and bunch of other stuff. Spring MVC is a web framework which lives under the spring umbrella and makes use of a lot of the spring libraries internally. I've never used it so can't offer an opinion on it.
Java EE is an umbrella term for a large set of "enterprise" specifications/libraries. JSF is a web view framework that is part of Java EE.
That's my very high level advice. To summarise I would learn basic DB/JDBC then some spring stuff and then start building a basic web app using what you've learned already.
Hope that helps. There's plenty of info out there on the web on all these topics and you can always ask questions here on more specific parts if you need help. Good luck and enjoy!
EDIT (to address comment):
All of the above is my recommendation/opinion on how to approach learning Java web development.
In summary
Learning JDBC/transactions/databases is a must
Spring is optional but I strongly recommend. Spring is a big library but you can pick and choose the bits you like/need.
Web frameworks the choice is really yours. From what I have tried (JSF/JSP/Wicket) Wicket is the easiest to get going with so you don't spend too much time frustrated with the getting the initial setup. JSP is awful, it's very easy to make a mess with it. JSF is powerful but heavy and probably more suited to very enterprisy projects than a first web app.
Hibernate is optional but can make life easier simply because you can work with Java objects when you do DB queries/updates rather than writing tedious insert/update statements. Hibernate isn't the only tool like this but it's the one I've used most and does the job well. Just don't go too overboard with the "clever" hibernate features initially.
You could easily use Spring MVC instead of Wicket. That may be a perfectly good choice, I've not used Spring MVC myself so can't comment. I'm sure it will integrate well with spring stuff tho so that would certainly be a positive factor.
Do some more research if you're not sure, there's no end of people happy to give their opinion! But really you just have to dive in and try something.

You are correct. If all your applications are served by servlets, JSPs, and JDBC, then maybe you don't need to learn anything else.
I commend you for learning the fundamentals first before diving into a thicket of frameworks that you don't understand. That's a good thing.
But if you reach the point where you have those down cold, maybe looking at these other technologies can help you improve your game.
1)Java EE
You are learning (part) of Java EE when you use servlets, JSPs, and JDBC. They're a subset of the full Java EE machinery - EJBs, JMS, JNDI, etc.
2)Spring or spring MVC whats
difference
Spring is an alternative framework developed by Rod Johnson and Springsource, now part of VMWare, that is based on dependency injection, aspect-oriented programming, and framework modules. Spring web MVC is one module in the Spring framework, based on servlets, that acts as the front end for web applications.
3)Hibernate
An object-relational mapping technology (ORM), built on top of SQL and JDBC, that lets you map objects to tables. It has its own object-based query language.
4)Wicket
Another web MVC alternative to Spring MVC, Struts, JSF, etc.
5)Struts
The first web MVC framework. It's gone through versions 1.0 and 2.0, and has now been supplated by Java Server Faces. It's still used, though. Like all other web MVC frameworks in Java, it's based on servlets and JSPs.

From a Java perspective it might be best to start looking at Java EE. All the others you mentioned are alternative technologies, which might be useful to you if you decide that what the standard framework offers isn't your cup of tea. But for that to decide, it's never a bad idea to at least know what the standard framework is about.
Truth be told, before 2006 the standard framework had a bad reputation and some of the sentiments that form the basis for recommending alternative technologies are still based on that. Starting with version 5, Java EE got dramatically better. The latest version, Java EE 6 is arguably one of the best Java frameworks that's out there. Of course, the best is a highly subjective term and naturally it won't be the best one for each and every person out there.
At any length, Java EE 6 is a very complete framework that allows a large range of application to be written without depending on any additional library. Being the standard framework, most other frameworks at least depend on some parts of it.
Most typically EJB, CDI and JSF are replaced by alternative technologies. E.g. the core Spring container replaces EJB and CDI and Spring MVC replaces JSF. A full Spring stack typically still uses JPA, JTA, JMS and Servlet from Java EE. Wicket on its turn only replaces JSF, or when used with a Spring stack replaces Spring MVC.
Hibernate is a special case. It doesn't replace anything from Java EE, but is instead often used as an implementation for one of the key APIs of Java EE: JPA. The original creator of Hibernate, Gavin King, is one of the prime supporters of the Java EE framework and is in fact the spec lead of one of the most important parts of modern Java EE: CDI.
Wicket by itself is a very nice web framework, but in practice it isn't used as often as JSF. I won't go into the discussion whether Wicket or JSF is 'better' (this is mostly a religious battle anyway), but due to the popularity of JSF there are simply more people experienced with it and there is a large community offering many things for JSF like component libraries and extensions.
Struts has historically been completely replaced by JSF. The original creator or Struts, Craig Mcclanahan, was the one who started JSF as the successor of Struts. Nevertheless, Struts was once the absolute de-facto standard for web frameworks in Java. It's not often advised to be used for new projects, but till this day it's still used in a huge number of existing applications. So even though it's not really 'hot' to learn Struts anno 2011 knowledge of it may still be very practical for when you have to maintain existing applications.
ps
See this answer for a general description about Java EE: Frameworks for Layering reusable Architectures

I'm sure that nobody seriously can tell you the best way, because this would mean that (s)he would have tried all. Why do you want to learn a Java web application framework? Just to learn it to be prepared for the (next) job? In that case it is likely that you've learned the wrong one.
The next question would be what you want to do with the web application framework. Do you want to make a website a little bit active, e.g. make each page look similar (corporate design), auto-generate menus from an internal structure, or do you want to write a real web application, e.g. with database access.
I'd first define the goal what you want to achieve. IMHO a good way to motivate you to make it right is to take a small project which helps you to solve a small problem.
Then I would start with Java Server Pages (JSP) and servlets to understand the basic concepts. Then you can try to do the same with a few well-known web application frameworks, e.g. Wicket.

Playframework and Django

I have worked with Django before and have recently seen the Play framework.
Is this the Java community's answer to Django? Any experiences with it? Any performance comparisons with other Java web frameworks?
Edit:Almost similar to this question, the responses, unfortunately don't say much about the framework.

Play! is a breath of fresh air into Java and bypasses all the Enterprise cruft that has evolved over the years. Even the namespace is just play not com.playframework. It is supposed to be an answer to Rails, Django etc and is MVC based. It is needed for Java to stay relevant in all but deep entrenched enterprise shops.
Play! reduces the overabstraction and painful configuration of old Java. It is a complete stack it does not rely or play to the old Servlet/EJB methodology like Restlet tried to do (making REST easier in Servlets). Play! is a great REST based Java framework that is a valid contender to other platforms MVC frameworks.
It is very RESTful and it is easy to bind a parameter to a java method. They have also made JPA much easier to use through their play namespace.
play.db.jpa.Model
public void messages(int page) {
User connectedUser = User.find("byEmail", connected());
List<Message> messages = Message.find(
"user = ? and read = false order by date desc",
connectedUser
).from(page * 10).fetch(10);
render(connectedUser, messages);
}
Python is used for scripting instead of builds with Maven which might save a few lives.
I haven't been this excited about a Java framework since Red5 or Restlet. A bonus is they have easy ways to get your app up on Google AppEngine as well using the Java version of GAE.

I have been using Play! now for a few months and in fact have come to love the framework. I struggled with Rails and Django a bit, mostly because I am really not a fan of dynamically-typed languages; however, there was never a really good web development framework for Java to compete with these. In terms of productivity, Rails and Django were the leaders for the MVC arms race that was going on. Play! is awesome, it's concise, scalable, powerful, and it has a great community that is growing all the time. If you're still really into using a language like a Python or Ruby, you can use Play! with Scala too. I am really trying to get into Scala right now because I think it has a great future and it's a lot of fun to use. Anyway, I would recommend giving it a try!

The Play! framework is a really good piece of software, and that the JavaEE bloated environment should be inspired from.
I moved from Java -> Django because of the fast cycle "modify file" / "reload browser", and the Play! framework makes me came back to my favorite Java language.
It could also be compared in some terms to what Grails and in general dynamic languages in Java (Groovy is used in Play!) are trying to import: simplicity, speed and reliability.

I am also a Django user. I've just visited the Play framework and skim thorugh its documentation. It has the simplistic design Django has been known of. It even has app engine support built-in. I'm sure many java developers will support it, and it only need some time to see cool plugins from the community.

We recently started using Play for building a webservice for various mobile applications. I come from a Java environment. I can tell you that the learning curve isn't all that steep--literally in an hour I had the webservice running with basic API already. One week later we were on Amazon Web Services. I definitely see a future for Play as it simplifies web development for Java developers.
Couple of things that I noticed however (asset versioning, etc.) still are not built into the framework, but i'm sure they'll be there in time. I would say it is definitely worth a shot using Play.

I come from a very strong java background. So my answer here could be a little biased.
Play finally brings to the java community what django has been for all these years in the python community, but just a way better.
Play is built on the jvm therefore inheritance all the goodies from a solid platform that has been proving over the years to be the most reliable and scalable one that allows to write and run applications at scale.
I want to say that I did try django. Its popularity among the web community made me curios and I wanted to give it a try.
Strangely I did not find it as easy to use as I had expected.
So many configurations. Too may libraries doing the same thing and often not play very well with each other. A way too much magic.
Furthermore, not having type safety makes very hard to manage and maintain
web application at big scale.
Don't get me wrong, I am pretty sure that people managed to do it, but in my experience I still find java/scala best suited for this, especially when you share the code base with a lot of other developers.
IDE support for Java it is unbeatable. If you implement TDD you will find yourself refactoring code and moving things around on the daily basis. And java IDEs give you all this power. With type safety and more.
My take away is that as long as you find yourself writing a simple CRUD application/prototype/toy without even thinking too much of advanced features and big scale then you can probably find some advantages on using python/django. Otherwise the whole java ecosystem wins hands down. And play is the cherry on top.

Is EJB still alive?

Do you still use session or entity EJBs in your project? Why?

EJB3 is a vast improvement over previous versions. It's still technically the standard server-side implementation toolset for JavaEE and since it now has none of the previous baggage (thanks to annotations and Java Persistence), is quite usable and being deployed as we speak. As one commenter noted, JBoss SEAM is based upon it.
EJB 3 is a viable alternative to Spring, and the two technologies may become more tightly related. this article details that Spring 3.0 will be compatible with EJB Lite (which I'm not sure what that is, exactly) and possibly be part of Java EE 6.
EJB is not going anywhere.

We're working with EJB here and it works quite well with JBoss Seam and JSF, Faclets and MyFaces Trinidad. Good UI, Templating, AJAX and stable production 24/7 running on JBoss 4.2.
It's a good stack for business processes, workflows, messageing, webservices and ui control. Fast delivery of features, easy programming and stable ground based on entitybeans with mysql persistance.
I don't want to miss the featureset of EJB 3 for the tasks our product demands.

See the overview of new features in Java EE 6. EJB 3.1 and WebBeans 1.0 help make a Java EE 6 container environment become easier to use, similar to frameworks like Seam on Java EE 5 or Spring. If you're familiar with Spring 3, this article illustrates how Java EE has evolved to become a comparable framework.

EJB is still there and growing up. There are many new features (SOAP/RESTful webservice, JPA entities, JAXB...) depend on it or at least reuse the philosophy of developing.

Yes, but EJB were stupidly complex for most use cases. Very clever, but real overkill in most cases. Hence the lightweight approach taken now-a-days.
Justin

I've just started back to work on an EJB project. I didn't remember how heavy and hard was to work with this technology. It was luck when Spring, Hibernate and Maven came. Since then everything was different and much easier.
I always could see this technology was never used properly and was taken as a pattern that I never understood.
It was supposed you needed two containers and if it was possible one server for each container. One for Business(EJBs) and another one for Views(MVC). I never saw that.
Well, it's good to know that EBJ is upgrading.