Thanks indeed for getting engaged - this is the right forum for this kind of feedback.
My two cents in-line:
Sent from my iPhone
> On May 23, 2014, at 3:07 AM, Eran Medan <ehrann.mehdan_at_gmail.com> wrote:
>
> Hi
> This is my first post to this group, please let me know if this is the right place for this kind of feedback / question.
>
> I really like Java EE, and I really wish it had more adoption among "non classic EE" projects. such as new startups, SaaS products etc. (dominated by Rails, Django, Play, Node.js etc)
>
> There are several items I think are missing and I was wondering if Java EE plans include any of the following:
> MVC alternative to JSF (either Rails like or Spring @RequestMapping like, I think Jersey MVC is the closest in it's concept to it. I think JSF is great, but we need a "Rails like" alternative as well)
This is very much in consideration for Java EE 8. I would say stay tuned and stay engaged here.
> Ability to run a simple Web profile on Tomcat (easy deployment to Heroku / Amazon Elastic Beanstalk is crucial. People don't want to setup a Glassfish / WebLogic / WebSphere for a simpe web app)
If you looking for something that is Tomcat centric but supports Java EE properly, the best bet is really working with the TomEE community.
For other cloud providers you mention, I would say the real issue is that they should make Java EE an option. Otherwise why not move to a platform with better standards support such and OpenShift, Cloudbees or the Oracle cloud?
> Database migrations and deployment automation. Ability to deploy to any app server automatically without any proprietary APIs, and ability to have DB and War version handling across DEV, QA and Prod
You have to remember that Java EE is primarily an application programming API and not a framework. For this reason, something like this is probably out of scope for Java EE. As such, there are also some great database versioning solutions out there that work well with most technologies including Java EE and Maven (they've been around since the J2EE era). They also frankly do a much better job than the features that come with kitchen sink frameworks like Rails that go far beyond a programming API/runtime and tries to address every problem by itself including tooling.
> Better and more official package management and dependency management
This may be possible after Java SE finishes it's modularization efforts. Even then, keep in mind again that tooling is something separate from a programming API. The tooling part will likely come from something like your IDE or the GlassFish command line.
>
> Now for the why:
>
> Why MVC alternative?
>
> I filled the recent survey, and wasn't sure what are the plans down the road for including Jersey MVC officially (or another MVC solution)
>
> The motivation behind my hope to see this happening is to simply get rid of the need to use Spring, or any other MVC framewor (e.g. Play) for non enterprise Java Web Apps
> (e.g. I would like Java EE to be a real alternative for any new SaaS startup out there. an alternative to Spring, Play, Rails, Node, Django etc)
>
> In modern web frameworks, routing for a REST JSON web service, is done the same exact way as routing for a view + controller (Rails, Django, Play)
>
> However in the official JAX-RS implementation, it seems to be targeted only for web services. E.g. if I set the JAX-RS application root on "/" then I will have to manually compile JSPs, serve static files etc (or find out how to forward it to the default servlet, see my related stackoverlfow question on the topic: http://stackoverflow.com/questions/10874188/jax-rs-application-on-the-root-context-how-can-it-be-done
>
> If I could return a View from a JAX-RS @Path then I would not need any URL rewriting and I will not need to rely on Spring @RequestMapping anymore.
>
> What are the MVC "JSF alternatives" plans for Java EE 8 / 9 / future? Will Jersey MVC make it to Java EE 8? something else?
I think at this point we understand the problem domain relatively well. Chances are anything we do here will like be based on the early JAX-RS MVC work (that actually started before Spring MVC).
>
> Why ability to run on Tomcat?
>
> One of the needs for it to really be a "Rails/Play/Spring killer" is ability to publish on heroku / amazon elastic beanstalk (which means Tomcat and not Glassfish)
> For the love of God I couldn't get CDI (which is a really nice to have feature for good architecture) to work on TomEE.
You should work closely with the TomEE folks on this. From what I have seen CDI support seems to be fine on TomEE.
> basic CDI should work without a full blown app server (or at least ablity to do it via open source dependencies, as long as you can push it to heroku, it should be fine. People are using Spring just because of the lack of support for some features in tomcat e.g. CDI. it shouldn't be the case)
>
>
> Why db migrations / versioning / deployment?
>
> Ability to sync code + db changes between dev, QA, UAT and production is critical. Right now I don't know of a good db migration solution for Java EE unless you 100% use JPA and reverse DDL I guess (I'm not that familiar with it). But I think the Rails approach for automatic db schema migrations / versioning is a good starting point. Ability to push an app in a standard way (I mean not just copying it to the autodeploy folder, because each web server has it's own convention) I am looking for a Java EE utility that looks like "deploy_web_app myApp.war -s serverName -u user -p password --context optionalOtherContext" that will be standard for all app servers. as well as Java EE standardized "stop_app_server" and "start_app_server" so automated installers can be App Server agnostic when pushing a web app to a server. Just like JPA abstracts over DB implementation. starting stopping and deploying should be abstracted from the actually app server.
> Having nice versioning / packaging for Web Apps will allow tools like Puppet to automate deployment of large Java EE web apps across local cloud infra or to customers, without the need to know the intimate details of WebLogic, WebSphere, Glassfish or JBoss. if all app servers will be required to expose an API via Java EE extensions to start, stop deploy and undeploy, then this will be possible
Sans the DB migration and modularity parts, some of this is already on the radar, so you should stay tuned and provide your input at the most beneficial time with the right EG.
>
>
> Why better package management?
>
> Currently there is no standard package management in Java, or Java EE. maven is a community project and not a real standard. it will be nice to have something like what npm is for Node, gem is for ruby etc.
> I would like to see an npm like repository with a first come first served "simply" naming for popular Java packages. they should handle configuring your PATH, adding anything to the /bin folder if need be, etc.
> a simplified version of maven dependencies within Java EE that has maven as a reference implementation will be nice. But also ability to install Java based utilities like this - "jpm install foo"
> this will improve adoption IMHO if people could do "jpm install java-sample-webapp", and then "cd java-sample-webapp" and then "jpm run" and have a working Java EE self contained web application to play with.
> dependency management should be standardized in any case, and convention over configuration, and DRY should be first priority.
> I recently worked with a Puppet developer, who simple refused to learn maven because it was way to complicated for him to pull a simple artifact from artifactory. we moved to curl. he was expecting something like mvn install artifact-id:version and instead had to do something like "mvn -DgroupId=... -DartifactId=... -Dversion=... dependency:get" I lost him there :)
>
>
>
> Summary
>
> I really like Java, and Java EE. I think that with Java 8, a whole new world of developers can and should be able to "go back to good old Java" and enjoy it. Java EE 7 is way more DRY and convention over configuration than ever before. It's very high performance, and very strong in terms of capabilities. There is no reason why it will be only found in big enterprises and not in Y-Combinator startups like dropbox, AirBnb, Stripe...
> But I hardly see any new developments of new startups using Java EE. I see hybrids, Spring's recent versions, Dropwizard, Grails, vertex, Play for Java/Scala, Akka for Java/Scala, Spray etc. but I haven't encountered anyone doing a pure Java EE project for a "modern" / recent startup in quite a while. It has become the sole domain of enterprise applications. And even then Spring seems to be filling a lot of gaps there. I don't think we need Spring's overhead nor any other of the alternatives. I think Java EE can do a huge comeback for lightweight MVC web apps, it's not that far from there.
I hope you don't mind me being brutally honest here - as to startups as far as I have seen, the problem seems to be largely the personality types that get involved with Silicon Valley style startups. They are more concerned with impressing their rather small and shallow clique of friends than doing actual revenue generating work that can be maintained in the future. That sort of mindset will always favor the latest obscure fad than anything that is based on a more rigorous engineering process such as a standard - call it teenage rebellion if you will :-).
I guess what I am saying is that it is probably best to stick to analyzing actual technical merit (as you clearly are trying to do) and educating a broad community rather than being too concerned with what any particular narrow group of people may or may not be thinking or doing. This is especially true if the group of people in question have a success ratio of about one to fifty as most startups do and have the longevity of maybe one to two years with any given company/project.
At any rate, welcome to the alias and thanks for sharing your thoughts.
>
>