What's new in Servlet 3.1? - Java EE 7 moving forward | Hacker News Reader

What's new in Servlet 3.1? - Java EE 7 moving forward

blogs.oracle.com

30 pointsGarbage26 comments

I 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?

I'd recommend taking a look at GWT - it is pretty much for your exact situation and works very well for that. You will still need to convert from Swing to HTML elements, but if you have done any sort of separation between UI logic and Swing itself, this is usually not too bad.

This way you can swap over your existing java apps to one of those fancy HTML5 clients you're talking about. ;)

I would advise against GWT, after two separate projects - it starts off simple, but then as the project grows the more you regret basing everything around GWT in the first place. This guy will definitely not save time doing it the way you suggested.

You make that statement as if there is no way you could be wrong - yet there are multiple very large GWT deployments running very happily in production. I've done the exact thing - moving a finance system to a GWT frontend (it also retained a desktop frontend), and the system was reasonably easy to convert. You hook up some html in UiBinder, get some RPC working for the data, login form, refactor the widgets to use the uibinder html, use activities/places to handle navigation and backstack, and off you go.

So "definitely not save time" seems a bit harsh? Maybe worded "if you have anything like my experience, you will definitely not save time"?

EDIT: What part of GWT caused you issues btw? Maybe my uses never hit on the trouble parts.

One complaint was that once the project started growing past a certain size, the compile times (into javascript) took significantly longer.

The rapid development cycle that we had in the beginning of the project seemed to disappear. Occasionally some strange GWT bugs started popping up, but figuring out what was wrong was very difficult GWT is by nature Java compiled into JavaScript, and tools like Firebug would give a non descript JS error message. This was several years ago though, around GWT 1.5 or so.

I don't have any GWT 2 experience and I should have emphasized this, however I witnessed another project (a year ago) based around GWT 2 and although with capable programmers, they found GWT to be a burden rather than a benefit, and frankly the result looked horrible.

To GWT or not to GWT is a tough call.

There are features of GWT that I love the most when developing front-end code: resource bundle (auto-gen CSS sprites both the images and in Java code, no more hacky solution), i18n, UiBinder, JUnit (provided you 'architect' the code using MVP), great JS compiler (pruning dead code, producing multiple outputs for browser specific).

GWT infrastructure is definitely years ahead of anything out there in the market.

Having said that there are a few things that I missed from using normal tools like HTML/CSS/JS: fast refresh/update, debugging inside firebug vs attaching your IDE to debug front-end stuff. In general, development in GWT is slower if you don't have fast machines :)

> fast refresh/update, debugging inside firebug vs attaching your IDE to debug front-end stuff.

Have you tried out the new SuperDevMode? It lets you use sourcemaps to debug the java code directly in the browser. Only works with Chrome currently, I think. I tried it out a bit but it felt a bit clunky, and I actually prefer debugging in Eclipse to firebug/chrome, I think. Couple seconds of startup time don't worry me as much as others, I guess. I use the time to think through what should happen and where problems could show up.

At any rate I agree with you on how good the tooling support for localization/css/etc is - I think the learning curve is too steep for most people? The size of the getting started guide is pretty crazy, and there is a lot of confusing deprecated stuff, especially in the panels (some for html quirks mode (IE6), some for standards mode...)

The last version of GWT that I used was 2.1 and I believe SuperDevMode was there already (open in any browser, hookup with this SWT/Swing UI that relays back to your Eclipse IDE). Back then it was very very clunky and slow to the point that if you have large rich UI it may even crash.

Learning curve of the GWT API itself was okay, but the setup ceremony is not (preparing IDE, build, mavenizing, the whole end-to-end from start to finish). I don't know if this can be improved since this may be inherent culture from the Java world.

But like anything in this world: you get some, you lose some (e.g.: no silver bullet). At this time, it's a matter of preferences and specific to each individual situation.

If you have a well-defined project, GWT may suit you well. But if you need something that change quickly and frequently, preparing GWT may be yet-another-too-technical stumbling block.

Ah.. nope, SuperDevMode is a very recent invention from GWT 2.5 - it uses Chrome's new source map tech to allow Chrome to overlay and debug your java code inside Chrome itself. Firefox will soon have the functionality too which will let Firebug work directly on Java code.

https://developers.google.com/web-toolkit/articles/superdevm...

I agree very much with your last statement though - hacking something together with no concern for future changes/requirements in Java nearly always ends in catastrophe.

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.

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)

One argument for going web is recruitment: the pool of active developers that know Java, Swing and Spring is shrinking.

Also, the size of the developer community in the Java/Swing world versus that in web technologies is not even comparable when it comes to sharing knowledge and open-source components. (I work for a lab, so many open-source licenses are compatible for us.)

And, sure... it would be so much fun!

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.

I have gone completely decoupled web html/css/ javascript client architecture talking to restful services, with support for web sockets thrown in too.

Enable your server side for rest and go web.

As much as I'd like to move completely out of Java just because I like the idea of using VIM or lightweight editor with Python/Ruby to fit the ideology of a young hacker with 13" MBP, I've got to be honest with myself that the Java ecosystem provides the most complete and most mature tools (SCM, IDE, etc), libraries, and frameworks to do almost every single tasks out there.

Even with the price of verbosity. Tough proposition...

I 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'm afraid to say this, but you sound exactly like someone with very little experience when it comes to large scale enterprise systems (your "serverlets" sums it up).

Java EE is extremely powerful if you can wield its power, and obviously a good understanding of object oriented programming and design patterns is critical in order to make systems that are rock stable, safe (container managed transactions comes to mind) and scalability.

I think you'll see my point once you start working on larger problems. It's not random that many really big enterprise projects (such as banking software) are based around Java EE, and not Ruby on Rails.

Note that I am not trying to be overly negative - it's just that I see this kind of argument all the time, usually from people with no real enterprise experience.

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.)

I don't think its dismissive, The truth is Scala is _not_ complicated. People can do complicated things with it, but in general the language poses no real barrier to entry. Now the second point you bring up is more of an issue that I run into at times as well. Where I find a solution to a problem that presents itsself as the "Scala" way of doing something, and After i close my browser and go home for the day I forget about why I did that and show up the next day staring at magical Glyphs on the page that appear to work ( ohh i needed :>> not >:> ). To solve that problem you need to stop doing things you don't understand and instead take the long way around and write out function names instead of using the shorthand operators that your provided with. Once you get used to a library you will commit the operators to memory and you will know that :: is cons and ::: is list append and you won't have the "what did I do here" problem nearly as much

That's good for small teams/individual developers, but it really does become a nightmare in 5 years time. How do we know this? Go ask anybody who has had to maintain any kind of Perl code.

Scala is still very nice, but you need to exercise very heavy restraint so you don't end up with write-only code. (Java, and every other language, does admittedly have the same problem: I've seen Java code made up of so many levels of interfaces that tracking down what it does is almost impossible. Obfuscated C/C++ is a true terror. Ruby can get very nasty if you go 'off the rails'. etc etc.)

Right its a problem that exists in every language, there is nothing novel about scala that lends it to being any more cryptic then c++, other then there is a different set of rules as to what can be used where. Operator overloading in C++ is just as bad as scala, but most c++ programmers are used to it since they have seen it for a while. The first time I saw :/ I was really confused as to what it was since that's not an idiomatic C operator, but after seeing it in a few places you get used to the fact that its an operator and you read through it, just like I would if I saw a << in C++

I don't think its dismissive, The truth is Scala is _not_ complicated.

No. You think it's not complicated. I think it's complicated but manageable and that its real problems lie elsewhere. Claiming your position as "the truth" is dismissive and insulting to people who have the temerity to disagree with you.

As for your second bit--the thing is, I do not use "shorthand". The problem, I feel, lies more in the haphazard (to a reader) usage of "code punctuation marks" like braces and so forth. You find situations where they're used inconsistently or not at all, making it much harder for the eye to pick up what are otherwise natural breakpoints within the code for your eye to use to parse the intent of the code. Other design decisions such as including initialization logic in the class body, versus using a dedicated constructor method, contributes, for me, to a general sense of chaos. I do not feel like a lot of effort was put into writing a language that is conducive to reading the next day.

Note that I am not saying that you cannot write clean code in Scala--but I am of the opinion that the language's design is such that it does not encourage it.

No claiming that complexity is _subjective_ is dismissive. there is complexity and there is simplicity. There is also perceived complexity and perceived simplicity. As far as languages go Scala is pretty darn simple. There is very little going on in the background and the core of the language was designed to be a small set of orthogonal features that can be layered to build complex pieces of software. The perceived complexity is something we can argue about as it is subjective which is why you need to take a look at what your doing and how you might alter your practices to make it a more readable and simple implementation. You will always run across bits of a language that you will not understand, that doesn't mean the absolute state of the language has changed just your perception has changed.

This happens every time new developers run across a piece of Object Oriented C code with run time function overloading, their default reaction is I don't know whats going on this is too complex. C didn't magically become a more complex language because we introduced a new guy to function pointers and dynamic dispatch. Likewise Scala doesn't become more complex the first time you need to understand why marking your types as being covarient is important.

"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 don't find the language to be a kitchen-sink at all. It is a fusion of OO and FP, and so would reasonably be expected to support features from each of those paradigms. And it does so quite nicely. It is very well designed for this purpose. However it does provide facilities that allows the libraries to become arguably complicated, especially if you are not used to them. But being unfamiliar with a library's API is not really the same thing as the language being unreadable or obfuscated.

To be honest, it scales up pretty well lines of code-wise. You just need to break it up into smaller apps.

Reply on news.ycombinator.com