What's new in Servlet 3.1? - Java EE 7 moving forward
blogs.oracle.com
What's new in Servlet 3.1? - Java EE 7 moving forward
1–10 of 29 posts
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#2I worked on a bigger JavaEE project with serverlets and all the other things...
after doeing things like: "someurl".toURI.toURL; to get a valid url and some other stuff that i really dont wanne start with...
I just refuse do code something for the web with Java and Servlets and RMI or Beans or Java Technologie X...
now i code in Javascript and ruby and iam so much happier as a developer :)
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#3I worked on a bigger JavaEE project with serverlets and all the other things... after doeing things like: "someurl".toURI.toURL; to get a valid url and some other stuff that i really dont wanne start with... I just refuse do code something for the web with Java and Servlets and RMI or Beans or Java Technologie X... now i code in Javascript and ruby and iam so much happier as a developer :)
I like Play framework as an statically typed alternative, doesn't have most of the things we like less about Java, feels like RoR / Django, but is still statically typed (and supports Scala which I think is much more fun than Java once you get passed the "Scala is complicated" myth)
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#4I worked on a bigger JavaEE project with serverlets and all the other things... after doeing things like: "someurl".toURI.toURL; to get a valid url and some other stuff that i really dont wanne start with... I just refuse do code something for the web with Java and Servlets and RMI or Beans or Java Technologie X... now i code in Javascript and ruby and iam so much happier as a developer :)
To be honest, it scales up pretty well lines of code-wise. You just need to break it up into smaller apps.
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#5I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that leverages some cool JS framework.
At my workplace, we have this debate going on about what to do with our GUIs (that are used only internally). The alternatives are 1) keep them in Java Swing, 2) progressively rewrite components in Java FX 2, 3) go web. These are operational GUIs that talk RMI with our Java servers (which we won't rewrite).
What's your take on this decision? Do you think it is shortsighted to stay in the Java world for the GUI side, or am I being overly optimistic when I say we should just start over in web technologies?
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#6I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that leverages some cool JS framework. At my workplace, we have this debate going on about what to do with our GUIs (that are used only internally). The alternatives are 1) keep them in Java Swing, 2) progressively rewrite components in Java FX 2, 3) go web. These are…
I think you have to weigh the importance of the internal application and it's need for a rewrite. It just may not be worth it. If you do, I would recommend web, but you'd still have a significant JVM-based-language backend I'd assume since you have to use RMI as your communication protocol. I personally would not do JavaFX because you aren't really stepping up enough to make the rewrite worth it.
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#7I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that leverages some cool JS framework. At my workplace, we have this debate going on about what to do with our GUIs (that are used only internally). The alternatives are 1) keep them in Java Swing, 2) progressively rewrite components in Java FX 2, 3) go web. These are…
If it ain't broke don't fix it. Why do you want to replace them? Is the development burden of maintaining them in Swing really that high? Would it make life easier to have the UI be available on the web? If either of these is a "yes" then make the case on those grounds; "everyone is writing..." is a terrible reason for doing something.
In any case I see no point rewriting them in Java FX, that would just be replacing one dying technology with another.
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#8I tend to think everyone is writing web Python or Ruby servers backed with some NoSQL database, that expose a RESTful interface to a fancy HTML5 client that leverages some cool JS framework. At my workplace, we have this debate going on about what to do with our GUIs (that are used only internally). The alternatives are 1) keep them in Java Swing, 2) progressively rewrite components in Java FX 2, 3) go web. These are…
The question should be "why do you want to go away from java swing ?" What are the problems/limitations you encounter ? If there's no serious reasons to change, why change ? (well, there's the fun to rewrite all, the fun to learn technologies, but from a business standpoint, that's not reasonable)
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#9I worked on a bigger JavaEE project with serverlets and all the other things... after doeing things like: "someurl".toURI.toURL; to get a valid url and some other stuff that i really dont wanne start with... I just refuse do code something for the web with Java and Servlets and RMI or Beans or Java Technologie X... now i code in Javascript and ruby and iam so much happier as a developer :)
I like Play framework as an statically typed alternative, doesn't have most of the things we like less about Java, feels like RoR / Django, but is still statically typed (and supports Scala which I think is much more fun than Java once you get passed the "Scala is complicated" myth)
Scala may be "more fun", but, personally, I still have reservations about it being used in-the-large and I think calling the observation that Scala is, yes, complicated a "myth" is unnecessarily dismissive. You may not find it as such, but the language's kitchen-sink approach to features does have its drawbacks; I find that part of it manageable but that doesn't mean it's not complicated, it means I can deal with it.
I'm more concerned about legibility of Scala code. I've been using Scala in anger for about two years now and I still find myself writing what seems to me to be idiomatic Scala code that I have a lot of trouble reading three days later. (Play makes this worse, I find, because of the way that objects are exposed into your scope--these objects are super handy, but tracking down where they're coming from and what they're doing produces nontrivial cognitive load.)
Re: What's new in Servlet 3.1? - Java EE 7 moving forward
#10Earlier quoted context omitted.
I like Play framework as an statically typed alternative, doesn't have most of the things we like less about Java, feels like RoR / Django, but is still statically typed (and supports Scala which I think is much more fun than Java once you get passed the "Scala is complicated" myth)
Scala may be "more fun", but, personally, I still have reservations about it being used in-the-large and I think calling the observation that Scala is, yes, complicated a "myth" is unnecessarily dismissive. You may not find it as such, but the language's kitchen-sink approach to features does have its drawbacks; I find that part of it manageable but that doesn't mean it's not complicated, it means I can deal with it.…
[deleted]