john-waterwood

Exciting news, can be a game changer against .NET Core being MIT licensed...

We're able but we don't do it, since there's a 9 to 5 job with a manager that always screams we work to slowly, and then after work we have to pick up kids, do the dishes and what have you.

> The problem is that, at the moment, the interests of Java's owner are not aligned with the interests of such community, and not enough people seem to care.

There's two ways to not care:

1. I don't care if it goes away, since who uses that stuff anyway? 2. I don't want to invest anything to further the project, but I really like using it and it's crucial for my business!

At this point I think the latter is the problem.

Of course Java. It's still one of the best platforms out there, especially if you weigh in performance, stability and availability of open source libraries and free or cheap hosting.

Google for "GIL Python" and have a laugh (or cry). I think that's enough backing for my statement to begin with.

Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster.

Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale.

Enough backing? It's just the start of why Java EE is the better tool ;)

>EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months

That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP 6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc

>The other 50% lay dormant for years

So this exactly the same as with a Java EE implementation or any other open source project for that matter. Many get fixed in hours, others weeks or months and some years or simply never. Spring is not inherently better here as their track record proves. That your personal reports were of no success maybe says more about yourself than of any Java EE implementation. I got many bugs fixed and have seen others reporting bugs that have been fixed in no time.

>Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years

I was more referring to this one: http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cyc...

The actual time spend on the spec is less (see table). Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.

With Java EE being clearly the better tool compared to Python and Ruby.

Python is laughable. One word; GIL. Nuf said.

You're mixing up things.

JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/

You're quoting an individual bug that has been open for some time. Did you also looked at the many bugs that were fixed after a few hours after being reported? Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?

Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want). That's the time between 2 spec releases. It's about the same time as between major supported JBoss releases, so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases (Spring 2 2006, Spring 3 2009, Spring 4 2013).

And Java SE doesn't release a major new version montly, let alone yearly either. A spec should move fast enough to stay relevant, but slow enough to provide the stability needed so lots of other technology can build on it.

Fixes don't take years with Java EE!!!

We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.

I tried rails once. Startup was fast, but after 3 months we got stuck and things weren't so fast anymore.

Modern Java EE let's you start about as fast as rails, especially when starting from a good Maven archetype. The code is immensely simplified. I got a backend service with JAX-RS and CDI running in literally no time!

Wow, just wow!

We're all free to have our opinions ;)

About the reason for the consulting shop to pick EE because of the installed base, that was indeed my point regarding the first facet.

The first facet (huge base) is what appeals to enterprises. The second facet (modernisation & aimed at small users) is what appeals to startups.

That EE had a huge installed base is pretty well known I think. But that EE now also aims at small shops? Perhaps not so much ;)

I hear you. I personally stand by the title choice because IMHO there are two facets to Java EE. I'm not saying that it's a fact (I simply don't have the data to back it up), but those 2 facets I see are:

* huge installed enterprise base

* modernisation of the platform aiming it a both small and big users

I've been active in Java/Java EE for some time, and I know that these facets can be at odds with each other.

For instance Java EE people wanting to support enterprises exclusively still think in needs of enterprises, which means there's always a dedicated ops team, an installed server that nobody but ops can touch and developers that communicate with ops via tickets.

This warrants having data sources and security modules configured outside the application and maintained by ops.

For small users this is silly overhead. When you're the only one developing an app the security module can be right inside the app.

Some Java EE people have introduced mechanisms to do so, but the enterprise people who are still there hate it, saying a server should always be maintained by an ops team. The very idea that a small shop doesn't have an ops team just doesn't occur to them.

Long story, but the simplifications that are making Java EE incresingly suitable for small shops and startups, while maintaining access to the power of the full platform to me doesn't seem well known yet.

Yeah, EJB 3 is itself really not that new, but it took some time for implementations to come out. JBoss AS 5 took ages and EAP even longer. Then people had to upgrade from their older versions and then had to discover how much the new APIs had improved.

I don't have hard numbers, but judging from popular comments online I'm carefully guessing that it wasn't until ~2011 until people really started to see how simple EJB had become.

The old stigma still clings to it, much undeserved.

There's very little need to go to Spring today. Base Java EE includes nearly everything that one needs.

Plain Servlets is what you get when using just Tomcat, but Java EE goes beyond that with really great support for bean management and DI (CDI), persistence via ORM (JPA), declarative validation (bean validation), REST (JAX-RS), MVC web franework (JSF), etc

JSF and EJB are the reason why Java EE is lately considered the "secret weapon".

The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.

EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.

Modern EJB on the other hand is a POJO with a single annotation:

    @Stateless
    public class Bean {
        // do something 
    }

That's all. There are no required framework or business interfaces, no obligation to put ejb beans in a separate EJB module and there are no specific compiler tools needed. It's a total day and night difference.

In modern Java EE there's no reason whatsoever to avoid EJB.

There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.

In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.

Again a night and day difference and no need to avoid it anymore.

Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)

Not just karma, too many lazy engineers choose their stack almost solely on a quick scan on HN to see what's cool.

You can date many startups by first looking at their stack, and then checking when that stack was cool here.

When startups choose tech these days based on what HN thinks is cool and hip at the day the decission is made, you can't blame tech companies noticing this and trying to turn the odds in their favour.

Like a plotter, effectively infinite resolution (not really infinite because of the phosphor elements being finite, but still).

The limitation shifted elsewhere of course, and that's in the complexity of the scene, specifically the number of objects.

Still, interesting tech and can even be adapted to control a laser unit that renders on say a big building or even the clouds (the real ones).

App servers like TomEE, JBoss and GlassFish are not hard to install at all, and certainly not to dev against. What's the author smoking?

These servers are just unzip == fully installed things. We have them checked in and just deploy them automatically whenever there's a need for an update, pretty much as every other library out there.

I wonder are we missing something or do people just wrongly think there's "something" difficult, where there's no need at all for things to be difficult?

Thinking Java EE is primarily about EJB and JMS is pretty old school.

These days CDI is the centrepiece of Java EE, along with services like Interceptors and Bean Validation. JPA, JSF and JAX-RS also play pretty important roles, which are all things you don't find by default in Tomcat.

Actually, nearly every time I see people using Tomcat they add many of the things mentioned above. You might as well start with TomEE then and work from there.