Live data from Hacker News

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

blogs.oracle.com

21–29 of 29 posts

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

#21
post #11
post #9

Earlier quoted context omitted.

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 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…

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.

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

#22
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...

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

#23
post #19
post #15

Earlier quoted context omitted.

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 t…

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

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

#24
post #19

Earlier quoted context omitted.

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 t…

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 a…

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

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

#25
post #5

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…

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.

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

#26
post #24

Earlier quoted context omitted.

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 a…

> 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 a…

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.

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

#27
post #21
post #11

Earlier quoted context omitted.

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…

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 haphazar…

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.

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

#28
post #19
post #15

Earlier quoted context omitted.

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 t…

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.

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

#29
post #24

Earlier quoted context omitted.

> 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 a…

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 f…

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.

Post reply on HN