back to article Java EE 7 melds HTML5 with enterprise apps

Oracle has announced public availability of Java EE 7, the first major release of the enterprise formulation of Java since the database giant took control of the platform in 2010. The last version shipped way back in 2009. Support for HTML5 and related technologies is one of the key themes of this release. Among the new APIs …

COMMENTS

This topic is closed for new posts.
  1. Jan 0 Silver badge
    Headmaster

    "Meld" - yuk!

    Since welding involves "melting', the word "melding" is ridiculous.

    Weld things if you like, meld them at peril. Rupert Bear says: STOP IT!

  2. Destroy All Monsters Silver badge
    Angel

    Hmm ... yes?

    I'm currently trying on Grails. Am I a bad person?

    1. Anonymous Coward
      Anonymous Coward

      Re: Hmm ... yes?

      No, not a bad person, but you'll probably come to hate Grails with a passion. It's incredibly buggy, and rather than fix bugs the Grails team prefer to forge ahead with new versions with new functionality that introduces further bugs and often breaks existing functionality. The documentation looks comprehensive, until you actually try to use it and find that in fact much is undocumented - even fundamental things like the return types from core features such as GORM. There's no modularity (plugins are a bit of a joke really). Performance is terrible thanks to the dynamic, meta-programmed nature of the Groovy language that underpins Grails and it also results in atrocious stack traces thanks to all the reflection going on. Scaffolding is a neat party trick, but just as in the Ruby-on-Rails world it's useless for anything other than trivial examples in books or online tutorials. Tool support is poor, and will probably stay that way as the dynamic nature of Groovy and complexity of the "convention over configuration" in Grails make it nigh on impossible to support much more. Convention over configuration and the myriad domain specific languages sound great in principle, but they're poorly documented and behaviour is varied making it difficult to intuitively work out what's some code does. Compile time errors (or warnings in an IDE) that you'd expect with a statically typed language become run time failures, often with spectacular stack traces.

      1. Anonymous Coward
        Anonymous Coward

        Re: Hmm ... yes?

        A couple of other points about Grails. Not many people use it, with Sky.com being the big name that's bandied about by Grails advocates. Funnily enough those sites went tits up last week. The load on those sites (aprox. 110 million hits a month) is in the same ballpark as my last employer were getting on their conventionally coded Java setup, although it scaled to much more than that during last years Olympics.

        Many of the plugins on the Grails plugin directory are incomplete, unmaintained or in a couple of cases only proposals! In the current system I work on we've had a lot of trouble with even supposedly core plugins such as the Tomcat one (had to locally patch around it, since the rapidity of new feature releases meant our version of Grails is no longer supported although the bug was reported while it was supposedly supported). Upgrading any non-trivial Grails system is nigh on impossible, as backwards compatibility doesn't really exist. We're now stuck on 1.2 - getting to 1.3 or 2.0 have both been attempted but have failed.

        SpringSource took on a couple of the Grails developers, but one has since departed (rumour has it he only wanted to work on new features and refused to fix bugs). SpringSource now seem to be playing down their support for Grails, in favour of Spring Roo which offers many of the supposed RAD advantages of Grails but in a more mature Java environment.

  3. Anonymous Coward
    Flame

    Toolbar Support

    Does anyone know which IE toolbars are installed with this version?

This topic is closed for new posts.

Other stories you might like