Hacker News new | past | comments | ask | show | jobs | submit login
Oracle and the fall of Java EE (techsticles.blogspot.com)
191 points by SanderMak on July 8, 2016 | hide | past | favorite | 181 comments



Amen. Be it Hacker News, or the /r/java subreddit, or wherever, it feels like the bulk of Java chatter revolves around...

1. Security vulnerabilities

2. The Ask.com toolbar

3. Oracle abandoning Java EE

... which is extremely frustrating because...

1. Virtually all of the "security vulnerabilities" deal with the browser plugin for using applets, which hasn't been widely used in 15 years

2. The toolbar malware, while stupid beyond measure, only applies to the consumer Java installer, which nobody installs anymore due to item #1 above.

3. Java EE is legacy tech. While deeply entrenched, most of the work out there for it today consists of maintenance or migration to more service-friendly approaches like Spring or Dropwizard.

Java is certainly not perfect. It's also long in the tooth, and is associated with "the enterprise", and so it's not seen as "sexy" by young developers. But for business software, large-scale data processing, and web/REST backends, I've yet to find anything on the horizon that seriously competes with it.

Every year I get bored and go exploring a new alternative language in side projects. Every year I come back, more appreciative of what I have. Python/Ruby/Node have their beginner-friendly charms, but are limited by the lack of type checking and/or chaotic ecosystems. Golang seems really promising, but has a long way to go. C# seems like the most credible challenger for business systems, but the .NET Core ecosystem is probably still years away from being where Java was in 2005.

I don't mind discussing Java's shortcomings. But I'm tired of hearing about irrelevant shortcomings such as applets and Java EE. Because that's just a way to keep a "language war" going without having to point at a serious alternative.


> Golang seems really promising, but has a long way to go. C# seems like the most credible challenger for business systems, but the .NET Core ecosystem is probably still years away from being where Java was in 2005.

Go doesn't have the guts to replace Java, because of the hostile mindset of its community when it comes to writing reusable, general purpose libraries. the famous "you don't need that with Go" is something pushed by go maintainers themselves.

The best bet is .NET core. Microsoft can move quite fast on a project, just look at Typescript or VSCode. And there are already hundreds of thousands of C# devs if not more. C# and F# with .Net core on linux will certainly be the future of entreprise development when the RC mess is sorted out. And MS can still make money on expensive SQLServer licenses.

I don't think the latest JEE was that bad though. It tried to do away with a lot of unnecessary complexity.


>Go doesn't have the guts to replace Java, because of the hostile mindset of its community when it comes to writing reusable, general purpose libraries. the famous "you don't need that with Go" is something pushed by go maintainers themselves.

Go has a pretty comprehensive stdlib. And a huge and growing community of 3rd party libraries. I left .NET and Java for Go around 0.9 and since then I have seen Go flower into an ecosystem I am far more productive than. The Go devs have a bias against complexity, they hate Abstract Factory Factory Singletons :P, but that does have much impact on community developed libraries. The Go community does have a strong bias towards libraries and against frameworks, but IMHO, that is generally healthy. The only concrete example of what you are talking about is the current lack of generics support.


I think the issue here is the hostility of the go community historically to pretty much any kind of criticism on pretty much any front.

(want generics? too bad! don't like the syntax for [thing]? too bad! want a framework? you're doing it wrong! want to test without using actual sending network traffic? BAM! 50 downvotes on SO for 'poor question'. Got some feedback and post it to golang nuts? HA! Prepare to be shouted out)

...but slowly we're seeing things move to a more moderate and mature state now where people are actually solving problems (like vendoring and SetDeadline()), rather than just pretending everything is ok, and building really good things with it, like go-kit.

It's just go growing up and being used seriously by people; but to be fair to the parent post, if you've used go in the past, I can see why you might have some opinions about it not being run by grown ups.

Worth having another look though. These days, it's pretty good.


How did it become good? Has generics been added? or syntax changed? or framework comes bundled with Go? Seems all example you gave are some libraries being written which shouldn't be big deal.


I'm talking about the community, which has tangibly improved.

There are also technical improvements (as I mentioned) and frameworks (as I mentioned). What more do you want?

Generics? No. You still can't have those.

Different syntax? No. You still can't have that.

...but maybe, now, if you go and talk to people about it, they won't flip the table about it, and you can have a conversation about it with folks on the gopher slack where everyone is reasonable and thoughtful both about legitimate concerns and future directions for change.

In my oppinion, that's a big deal...


Can you tell me what is the issue with SetDeadline()?


There's no issue with deadlines; I'm talking about people using deadlines instead of just hanging forever in go routines, and how contexts have been merged in stdlib in 1.7 (https://blog.cloudflare.com/the-complete-guide-to-golang-net...)


Sounds like the Python community.


Not even close.


Traditionally, Microsoft technology has been an all-or-nothing affair. If you want C# you also get IIS, SQL Server, Windows, Azure, Visual Studio, Windows on your dev machine and I wouldn't be surprised if Exchange shows up somehow. You could use Mono, but then you were off the beaten path and on your own. When something new appeared from outside Microsoft, such as git, it wouldn't fit into the MS ecosystem for a while.

Now Microsoft seems to be changing its culture, but I can understand if people are weary.


I don't know Go (didn't got a good first impression), and don't know what those libraries are, but nearly every time I've seen somebody say "you don't need this on language X" it was true, and the problem goes away after the requesting person really learns language X, instead of writing language Y code in X.

Maybe Go is a exception, but there's a lot of people happy to use it. (Yes, there's a lot of people happy to use PHP too. Those things always have exceptions.)


>when the RC mess is sorted out

RC mess is already sorted out with RTM release, isn't it?


And now imagine where Java could be if the ecosystem wasn't completely fucked up by oracle. Imagine a Java with a sane, user friendly installer, an open source community supported by a big corporation, actual development, no completely insane lawsuits.

Instead, developers want to abandon the JVM platform. They actively seek new platforms and create them.

The damage is done.


Oracle pays very senior engineers and innovators to create a stable and still evolving ecosystem. Java is slow and steady. The JVM enables other innovators to explore and create languages radically different than Java. I am very thankful for Oracle's stewardship of Java and the JVM.


On the topic of stewardship, I highly recommend this talk by Brian Goetz titled "Stewardship: the Sobering Parts" [1]

Brian goes about how important compatibility is for the language, the concept not throwing customers code under the bus by bringing breaking incompatibilities. (ie Python 2 --> 3)

Java has its warts and isn't "cool" but I respect their design decisions.

[1] https://youtu.be/2y5Pv4yN0b0?t=1578


Thanks for the link. I haven't watched that talk, but I will, and I was thinking of Brian when I wrote my comment. His work and he work of others on the Java team is important, serious, and hard.


What's so hard about the JVM install? I googled for "java download" and this was my first hit: https://java.com/en/download/

Went there and found a single, totally obvious button labeled "Free Java Download" that detects your browser and Operating System and makes sure you download the proper version of the JVM.

How much easier could it be?


Except for the above malware comments, what exactly does "Install Java" mean?

You cannot redistribute the installer or the installed files. Except other things it means, you cannot make a docker image with java app and redistribute it. Everyone has to download their own java installer and build images themselves.


Yeah, no. https://hub.docker.com/r/madsonic/ubuntu-madsonic/~/dockerfi...

Java (openJDK) is GPL licenced.


Yes. But openJDK might not solve your problem


Is there one feature relevant to running enterprise apps that oracle jdk SE (straight out compiled from openjdk sources) has that the gpl edition does not?


I don't understand where you have this information from.

Plenty of software comes with Java embedded - ie. IntelliJ Idea. Last time I installed Java was on a digital ocean remote box and I did it through apt-get.

Java may have some licensing that cause some open source system distributions not to include it but that is really their game.


yes, you can install open jre through repos.

most applications put "oracle jre" in their dependencies though.


I have no recriminations prepared for you but I am curious; where did you get the idea you can't make docker images for java apps? Did you piece it together mistakenly based on incomplete knowledge or is someone actually spreading that around?


Don't know about other poster, but I always thought that while you can make docker images for Java apps that include the Oracle JRE, there are restrictions if you want to distribute them - see http://www.oracle.com/technetwork/java/javase/terms/license/... . The no modifications clause is problematic for GPL software.


> You cannot redistribute the installer or the installed files. Except other things it means, you cannot make a docker image with java app and redistribute it. Everyone has to download their own java installer and build images themselves.

This is only true for Oracle Java, which is basically OpenJDK and some dev tools. OpenJDK is basically all you need and you can redistribute it or docker images with it. See http://zulu.org/


INSTALLING JAVA

===============

Even if you are Day One brand-new to Java, page #1 in any book will tell you to download a Java Development Kit (JDK). Any Google search would take you straight to the download page for Oracle's implementation, which is fine.

The Oracle JDK does not include any "toolbar" malware. That's only an issue for the Oracle JRE download (i.e. the runtime without any compiler)... which page #1 in book will tell you not to bother downloading ever.

The JDK is open-source, based on the "OpenJDK" codebase (much like the difference between Chrome and Chromium). Oracle's binary build has some restrictions on redistribution (see below), but there are numerous other OpenJDK builds. Every Linux distribution has one, as does homebrew for OS X, and there are at least two for Windows:

http://www.azul.com/downloads/zulu/

http://developers.redhat.com/products/openjdk/overview/

In the past, there were enough differences between the base OpenJDK and Oracle's build that people were wary of using OpenJDK. As of Java 7, and especially now with Java 8, those differences are nearly zero.

REDISTRIBUTION

==============

You absolutely CAN redistribute Java. OpenJDK builds have no restrictions whatsoever. Oracle's proprietary runtime binaries are also redistributable, with the only real restriction being that you can't exclude certain files (i.e. they don't want crippled Oracle runtimes floating around that can't run core Java):

http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2...

Not only are you allowed to redistribute even Oracle's binaries, but the latest JDK includes a "javapackager" utility. It bundles up your code, along with a stripped-down embedded runtime, with an executable wrapper so that you can distribute your app as a zero-dependency standalone (on Windows, OS X, or Linux). Interestingly, I've found that creating an installer for a JavaFX GUI application, with the runtime included, is slightly smaller than the installer for a similar GitHub Electron based app.

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/j...

https://gitlab.com/steve-perkins/MediaGallery-javafx


So why do we have to add a special source repository to do "apt-get install" and why is there a mandatory interactive license approval?


Because (Oracle) Java comes with its own EULA, and the DFSG forbid any EULA in Debian main.

OpenJDK is in Debian main, and does not require user interaction.


Dunno. Do you want the ask.com toolbar? How about updates that install the new version and remove the old version? Or maybe they've fixed the latter issue by now.


Well, the oracle website does tell you how to disable the toolbar, though I agree it shouldn't be there in the first place. As for uninstalling the old version, are you saying you want the new version to automatically uninstall old versions?


Yes. A new security release should absolutely remove the old release or at least disable any ability for less-than-fully-trusted code to invoke it.


On Windows it comes with an unrelated installed-by-default "malware" browser toolbar.


If you need to provision things automatically, you need to jump through hoops to bypass going through that website. For licensing reason the Oracle JDK/JVM cannot be distributed by O/S vendors.


For one, it'd be nice if it only did what it says on the tin: install Java. There's no reason that a platform like the JRE should be installing a piece of crapware.


Why should it detect my browser? I want to run Java Applications Lik Minecraft not Java insecure applets in my browser.


You don't need to imagine it, you can just look at what MS has done with .net and the community that's forming as a result. Java has such a horrendous ecosystem, it's really unacceptable.


1. I check in on .NET Core and ASP.NET Core every few months, to see if the tooling and documentation have stabilized. I just happened to check in yesterday, trying to create a "Hello World" ASP.NET Core web app. The skeleton project created by the "dotnet new" command doesn't match the "Getting Started" documentation on the ASP.NET Core website. After tinkering in frustration for an hour, I gave up. See you again in another few months.

2. What .NET open source community? I'm not aware of single significant open-source community project in that ecosystem that isn't a lagging imitation of something from the Java community (e.g. Akka.NET, MassTransit, etc). There's a lot of excitement around VS Code, and the possibilities of future stuff on .NET Core, but chatter on HN and Reddit isn't the same as actual shipped code.

3. If by "ecosystem" you mean web forums filled with college students chatting about it, then fine. But I think for most people, "ecosystem" refers to the availability of production-grade libraries and infrastructure components. Try naming one server-side niche in which Maven Centrals lags behind any other language in existence.


> Java has such a horrendous ecosystem, it's really unacceptable.

This has not been my experience at all. Java's ecosystem and vast libraries of battle tested software is unmatched on any platform.


You need to explain what you mean by "ecosystem".


We'd be in a much better world if IBM or Redhat had taken over Java.

That being said IBM is working on open-sourcing their core JVM technology to act as platform, not just for Java but other runtimes as well. [1]

There is hope still...

[1]http://www.infoworld.com/article/3014128/open-source-tools/i...


I'm exactly the same way - every language/platform I've explored has been frankly a waste of time sadly. In the meantime, Java instead has learned to scale down beautiful as well. Working in the node ecosystem lately has made me appreciate many times more, it's incredible how unproductive it is.

I still find it the gold standard of language/platform combos.


The npm is a mess.

Granted, Maven Central has the advantage of Java being statically type checked.

But CPAN is awesome. And Perl is dynamic. But modules in CPAN are thoroughly unit tested when you install them.

npm is neither. You find incompatibilities when you run it.


Enterprises dislike unnecessary change, so they wouldn't abandon java even if there was a technically more suitable alternative - they stuck with COBOL long after C was established. They will stick with java for a LONG time, not for a good time.

Yet, java was (as someone recently disparagingly put it) "designed by adults". By people familiar with state of the art language research, what was needed and workable, comprehensive specs of language and VM, and complete stdlibs, docs and tools from the get-go. (That is, disparaging to other languages)

And it's also managed to keep up to date, much better than I'd ever have thought: fast JVMs, language evolution, stdlib extended - and perhaps the greatest number of 3rd party libraries of any language ever(?).

Oracle is wrecking that for EE, and may wreck more.


I was an early Java adopter. And as much as I'm convinced that Larry Ellison hunts humans for sport, the fact of the matter is that Sun got dazzled by bullshit long before Oracle got their mits on it.

The truth is, J2EE 1.0 was not designed by grown ups. It was designed by college kids and academics who ironically enough wouldn't know the 8 fallacies of network computing if it but them on the ass.

Because it DID bite them on the ass and we have nearly 5 years of vendors flaunting and then polluting the spec to prove it.

Then we have Josh Bloch, who everyone but me thinks is great, who introduced Duck Typing to the JDK (MethodNotImplementedException) and only later confessed that he couldn't understand variance. People defend their bad code by pointing to similar code in the JDK, and Bloch stunted the growth of an entire generation of developers. Then repeated the exact same mistakes at Google.

Me, I'm waiting for a language that Bloch had nothing to do with, and I want to get back to working in limited resource environments. My eye is on Rust right now, and I have my fingers crossed.


> Enterprises dislike unnecessary change, so they wouldn't abandon java even if there was a technically more suitable alternative - they stuck with COBOL long after C was established

This isn't a great comparison because C was, and still is, a much lower-level language than COBOL. If you're looking at that from the perspective of a large organization with millions of lines of code, it's hard to justify the claim that C is “technically more suitable”, because the things C does better are largely irrelevant to business apps while the ISO standard for COBOL includes a ton of higher-level features like an indexed database, first-class support for fixed-precision math (a hard requirement for financial apps), a form library, object orientation, etc. which would need to be maintained as library dependencies in C. Any COBOL programmer would be familiar those but each C developer would need to get used to each application's particular selection of libraries.

A better comparison would something like Java or .Net which both have standard answers for most of those questions and, perhaps unsurprisingly, were quickly adopted by companies trying to move new development away from COBOL. As far back as the mid-90s, a popular approach was to move the front-end into Java (or, later, a web app) and start chipping away at the decades of backend COBOL code running on a big central server.


Can Java EE be developed on OpenJDK?

Can OpenJDK create a fork of the whole Java ecosystem when Oracle wrecks it?


I think the fundamental issue which many people do not want to admit is that Oracle puts humongous money in Java and Java EE(in past at least). Without that all the Java activists and Java EE guardians etc are unlikely to ship large working products like new versions of Java/JavaEE.


This. Also, despite the general hatred of Oracle, something else that is hard to admit is they've managed Java a lot better than Sun has done. The people building Java now are long-term team members who clearly weren't recognised and elevated by Sun, but who have been by Oracle.

Love 'em or hate 'em, Oracle didn't turn into a factory farm of cash cows by being entirely incompetent.


I'm not familiar with either Java nor Golang, but I'd love to hear what you're looking at when you see shortcomings in Golang. I am genuinely curious and are very interested in what enterprises are looking at when they are browsing new tech.

My mother is a COBOL programmer for one of the largest banks in the EU, and I always enjoy listening to her explaining their systems (IBM Mainframe, Batch processing, etc).


Not many. The only deal breaker I've hit is the inability to return multiple result sets with the built in SQL package.

I haven't missed generics that muc, but it would be nice to be able to do things like sorting without implementing a sorter interface.

I can live with this though because everything I've written in go so far had been easy to reason about and most importantly it "just works". I can read anyone's code an understand what it's doing. Can't really say that's been true in the 25 years I've been doing this.


I would enjoy a lot reading her stories, you should write those on a blog.


Would be really fun and informative writing a post about her work! I'm gonna ask her tomorrow! :)


I've worked on the Microsoft stack for most of my career, and I'm curious what Java has/does that the .NET stack doesn't. Or is that more about the .NET core stuff for running on Linux-based systems?


I also work in .NET stack but until now(before .net core), the entire CLR was a blackbox and could only run on Windows.Obviously we had Rotor released but license was restrictive and there was Mono but in my experience mono was far from production ready when it came to asp.net. In terms of the IDEs like VS or IntelliJ or a supported production ready server (kestrel like) there was not much option.

I think the place where java still shines is JVM.There are myriads of JVM implementations out there which is suited for all kinds of purposes.And with the same flexibility ,there are functional languages like Scala or Clojure which targets JVM where all existing java libraries can be used for your new shiny language of choice.Of course .NET has F# or DLR (which I feel is another layer added on top of CLR and I couldn't like it).

What I see is .net has ports for most of the java frameworks or libraries e.g spring,hibernate,lucene,akka you name it. With .NET core being open and F# and C# being super awesome on it's territories (yes am biased :) ) ,we may have good contender to java in some more time.


A lot of it is that the JVM is used by devs to build large systems more commonly than .NET, and often work from that gets open sourced. So the JVM just has a larger presence in the developer community. Another reason is that historically many developers disliked Microsoft and SUN did a lot to foster goodwill among developers.

Oddly, SUN got purchased by one of the few companies everyone hates more than Microsoft. That paired with MS's recent shift to open source and opening the dotNet platform has led to softer view of Microsoft overall.


Java was the original .NET. Read history of Sun vs Microsoft. C# was a result of a merger of Java + Delphi, visual .NET components are based on Borland's VCL design. Many Java developers were extremely allergic to MS and the vibe at that time was "freedom", especially from nasty companies. Java also got its foothold in finance institutions due to easier design of distributed and transactional systems than the prevailing super difficult CORBA which propelled its rise everywhere. If you look at distributed systems, Java is still the king there.


There were also several large business sectors that ran almost exclusively Sun hardware. Like the wireless industry 10 years ago. The first project I worked on at scale had to run on Solaris or they wouldn't talk to you.

And our log files had to be localized, which while Java is not perfect, few if any string interpolation libraries match it for being able to deal with written languages that have a different sentence structure than English. It was hard work and one of my coworkers had to invent a new linter to detect unlocalized text in our code, but I couldn't imagine fulfilling those requirements in another language.


The JVM runs on just about everything. The .NET stack doesn't.


Diversity through age. Only a matter of time before .NET spreads. Anything written in "first-class" language can be compiled and run with mods on turing complete systems.


The latest .NET version is fully cross platform.


That's .NET Core, which is incompatible with .NET, so it's a completely new ecosystem so it has no where close to the maturity of Java or normal .NET.


It's far from mature, though, even if it's deemed stable. If I was making decisions for some huge enterprise I'd prefer Java since it's been battletested on Linux for decades.


Microsoft doesn't know the meaning of the word cross platform, and never has. The conditionals on their latest cross platform offering do little to repair that image.

They only go far enough to bait and switch you and then after they get you they cut funding for maintenance and the cross platform bits rot away.


This is a downside of any open-source project and is not specific to Microsoft.


.Net Core =/= .Net


And runs on more platforms than Java.


Care to name some of these platforms which Java doesn't run on which .NET supports? I'm having a hard time coming up with even a very short list.


Also, Xamarin makes .NET runnable on Android with their runtime and compile it down for iOS.

.NET Microframework makes it runnable on IoT.


I don't think Android is a good example of a platform which .NET supports which Java doesn't since Java is the primary development language for Android apps...

I'm also pretty sure that embedded Java is widely deployed in IoT applications.


Well , not .NET but almost:

PS4 (MonoGame/Mono) XBox One (.NET Core on the future and MonoGame/Mono)

At least you can run c# code on those platforms. Java though is unlikely to ever happen.


So the "platforms" are 2 game consoles?


Citation needed.


Sane documentation. It's been ten years since I've used Java, but Sun's Java API documentation was lightyears ahead of what MS was offering. Both in terms of layout/navigation and in actual content.


I am not a big fan of Java and have not touched it in many years, but I agree the documentation was really, really good.

Java' documentation as I remember it is still better than Microsoft's.


I really prefer Scala as my current JVM language. The language is way ahead of Java, but the documentation is a little mind-stabbing .. as is the syntax .. and implicits.


MS saw the rise of java in the enterprise business as a real threat to their core revenue stream, so they copied the entire idea. .NET runtime is akin to the JVM, the architecture is the same. What MS did for differentiation is to decouple the lang from the VM from the start, the you have C#, VB.NET, F#

In the java world there's something similar, but it is no designed from the start for several high-level language flavors.

OpenJDK still was a threat, so they're (MS) more inclined now to open source NET Core.

Today you can choose Java & NetBeans over .NET and V.Studio and will see only minor differences. I mean in tooling and architecture. Today Java seems closer to Open Source than MS, even if MS is "trying". Java & Netbeans are the same on Windows or Linux, of course NET is not.


For far too long Microsoft claimed "runs on all platforms" which to them meant "runs on all versions of Windows". They have recently changed their tune on this somewhat, but it was too little, too late for most of us. I don't think I will ever run windows again in my lifetime.


...have their beginner-friendly charms, but are limited by the lack of type checking...

Haskell people probably say the exact same thing about Java ;-)


For sure they do. But I've spent my time with Haskell and I've seen really simple things obscured under a cacophony of type noise. It's not uncommon at all to see a piece of simple logic with proportionately 3x the amount of type syntax around it or related to it. Especially when you need to do IO or state, as we sadly need to do here on earth, then it seems like Haskell is trying to put a brick wall of type restrictions between you and a simple routine at every turn. Talking not about doing some printouts, but actually making a long-running application where IO and state is ubiquitous.


# 3. Java EE is legacy tech. While deeply entrenched, most of the work out there for it today consists of maintenance or migration to more service-friendly approaches like Spring or Dropwizard.

While I mostly agree with you, Spring _IS_ J2ee based. (i.e. Servlets/JAX-RS both part of J2ee). Sure it doesn't use EJB but I don't think anybody does (non legacy) at this point.


Java EE is just a collection of libraries. JMS, JNDI, etc.

Said mostly in humor (from long suffering):

The distinction between J2EE and Spring is pretty simple. EJB is a data persistence obfuscation library, whereas Spring's DI/IoC "framework" is an exception (stack trace) obfuscation library.


The distinction isn't very clear. As you say J2ee is just a collection of libraries, of which Spring web services happen to use a subset of.Servlets/JAX-RS off the top of my head.

Of course Spring doesn't leverage ALL of J2ee but I wouldn't except anything to use all J2ee. There is a lot there.


Thank you. Maybe you don't know but you have given very apt description of Java land frameworks.


I wouldn't say it's Java EE based, acutally. It's a superset of Java EE. It's wraps the APIs people still actually care about like JPA, Servlet, and works with JAX-RS. The rest of the Java EE APIs are pretty much irrelevant these days, as evidenced by the constant introduction of new "profiles".


> 2. The toolbar malware, while stupid beyond measure, only applies to the consumer Java installer, which nobody installs anymore due to item #1 above.

Here in Brazil, the program used to submit the income tax forms is written in Java (http://idg.receita.fazenda.gov.br/orientacao/tributaria/decl...). This means that a lot of people need Java on the desktop. I have relatives which have Java installed on their computers solely for that reason (yes, I have disabled the Java plugin on their computers).


I wonder how difficult it would be to port C# to the jvm. It really is a better language. There are some parts of the standard library that are better in java, but overall I'd say C# is better there too.


Check out kotlinlang by Jetbrains. It's git the best of java, C# and python


Or Ceylon! It looks a lot like Java in some ways, but with a really novel type system.

Kotlin is nice too though.


You could say that Kotlin has already done it.


Care to list what the C## language has that the Java Language doesn't?

I guess, you don't miss what you don't know.


Just one example, the type system just does more, IMO very useful, stuff.

Richer generics. Dynamic typing is there if you want it. Type inference is great, and then coupled with anonymous types allows for some nifty tool-supported functional-style pipelined programming. (RX and Linq). Upcoming language support for tuples looks pretty sweet too.


I have worked on both languages and I have not disliked anything about java.Not here to start a flame war. I heard many times from who have extensively worked on both that supports for generics in c# is far superior than java.And obviously LINQ goodness and async\await comes to mind


From my limited experience using Java after C# 6.

Type inference, C# properties (vs. getters/setters in Java), generics are way better, and of course Linq.

Java 8 makes this a bit better with lambdas but it's still a bit of a pain not having the above present. I still like Java though.


I've had a mix of maintainable and rough apps on the rails side of things. I think with a good test suite, one can really build a solid app using Java these days. As you said there's a lot more modern approaches now as well. It's something I'd like to explore maybe a bit later this year, after I do some more messing around with Rust :)

Given it sounds like you use Java, what tools/stack do you use with it day to day?


> the browser plugin for using applets, which hasn't been widely used in 15 years

Oh, by all the possible deities, how I wish that was even remotely true...


Amen to that!


#2 is not the case: for still quite a few bank and government software in Belgium :/

Although when not needed on a PC I tend to remove it asap (Java)


> Python/Ruby/Node have their beginner-friendly charms, but are limited by the lack of type checking and/or chaotic ecosystems.

Don't know much about Python but at least for Ruby, the ecosystem is not "chaotic", it's just way faster moving compared to something like Java, which is stale af.

It's quite easy to manage Ruby projects, I think the only disadvantage to this language is it's quite slow. But does it really matter? For most use cases it's just fine.

As for the lack of type checking, I think that's a poor comparison. Type checked code is not always better than dynamic code, and dynamic code it's not always better than type checked code; They are different.

Maybe for an army of junior developers leaded by a 90's senior developer with a mustache and thick glasses, a boring safe language like Java is the best. For a team of experienced developers with deadlines, Rails can get the job done in a quarter of the time.


Step into the Scala/Akka light my friend :)


What are actual Java's shortcomings?


> What are actual Java's shortcomings?

I guess, it depends on the application.

- I would not use Java for desktop applications.

- Not for small quick and dirty scripts that I will use once on a while. I use Perl for that.

- Neither for command tools. Start up times may be an issue.

- For server applications, java is great.


> - For server applications, java is great.

...unless it's not the main application run by the server (like in auxiliary services, message spooler, monitoring agent, some kind of cleanup service, stuff like that). Then its memory usage is a mess.


Mostly OOP's shortcomings. c2 wiki will lead you to much discussion on how "design patterns" are a band-aid patch for the deep, deep problems with massive OOP projects.


The problem isn't OOP, OOP's fine. The problem is how Java implemented Objects in a fairly rigid way which led to all this insane boilerplate. Furthermore design patterns aren't tied to OOP. And finally design patterns =/= JEE patterns .


There are about as many definitions of OOP as there are programming languages.

I'm not a software developer and have no dog in this fight. Sometimes I use Matlab's idea of OOP to factor out code by domain of representation (so simulations of agricultural yields are instances of a LandUnit object with some properties and one or two methods); never to abstract programming out the way OOP design patterns do.

I'm more attracted to the Haskell style of types and type classes, as far as "abstracting progrmaming out" goes, but I don't do any programming in the large, so what the hell do I know. I just pointed to the debate between people who should know, c2 wiki is very good on the things I do know.


Mostly a problem of how people use OOP.

I don't think there is a problem with the Java Language or the JVM.


Well, see, there are deep, deep problems with massive software projects. They don't have to be OOP.

But if you don't use OOP, what are you going to use that makes things significantly better? "There is no silver bullet", as Fred Brooks said.


Imagine you have two java apps on your pc. You want one to have full network access, but restrict the second one. Well, you can't, because application firewall sees both java apps as java.exe


Besides the fact that this is a very contrived example, and that this is not how I would go about managing firewall rules (why wouldn't you use ports / services? You trust the security of your PC on just the name of the application?), this is not true in many cases. To pick one: Eclipse (A Java app) does not identify itself as "java.exe".


Eclipse isn't a java app, it's a native app that happens to start a JVM that drives native widgets. If you ship a new platform tomorrow, and someone ports a JVM to it, java apps will Just Work, but eclipse still won't run until SWT and the launcher get ported.


This seems more like a complaint about the Windows firewall... and most people don't care to restrict network access on a per-app basis anyway--plus, any application with access to other local resources could very likely find some way to send network traffic besides opening its own socket.


Is it fashionable to bash java ?

What about https://github.com/graalvm/truffle or https://bitbucket.org/allr/fastr/wiki/Home or https://www.youtube.com/watch?v=OUo3BFMwQFo ? There is serious innovation happening in java land (through Oracle - without talking about Clojure, etc.)

Java EE exists because of the need to support large legacy, enterprise customers.

For those who are starting out in Java web frameworks, people usually use Spring or Spring Bootstrap (and sometimes the newer Java 8 only http://sparkjava.com/).


It has been fashionable to bash java for the past +10 years.


Yes. And Spring is a large part of the of the reason, not the solution. Every time you see somebody making fun of Java for AbstractSingletonProxyFactoryBean and its like they are actually making fun of Spring, not Java.

Btw, that is a real class, not a made up example.

http://docs.spring.io/spring-framework/docs/3.0.x/api/org/sp...


again, it is the enterprise market.

But then there is spring-boot http://projects.spring.io/spring-boot/#quick-start


I do mostly C#, and don't know very much about the Java ecosystem, and I could barely understand anything in that article due to all of the Java jargon. Can anybody summarize what the point is for somebody who hasn't spent their career knee-deep in the Java ecosystem?


Java EE is basically the official java server-side container. It was designed to scale, it kind of forced a designed pattern (something called 'Enterprise Beans' - one bean for dealing with requests, stateful beans for dealing with sessions etc.)

It got huge and bloated.

Some people came along and created some lighter frameworks.

Arguably - Node.js - the javascript container is the real extension of this: it's incredibly light, can handle zillions of connections, you install the packages you need, it's totally open source. And it's in javascript which is uniquely well positioned to do a lot of 'asynchronous' stuff. Passing functions around with callbacks is possibly in Java but it's just bulky. Mostly due to the nature of typing. It's even kind of bulky in Apple Swift, for example.

Java is a great language, that has made some improvements with lambdas etc.


"Java EE is basically the official java server-side container. ... Some people came along and created some lighter frameworks."

"Container" is the key word here.

J2EE had the notion of an app server hosting your app.

The extreme alternative is to have your app be standalone and "embed" an I/O protocol (HTTP) server. I've had great success with this strategy.


Why want several HTTP stacks on the same machine? Isn't that like wanting multiple TCP stacks or DNS resolvers?


It's no help to have lambdas when you're trying to use an old framework designed before Java had lambdas.


Javascript is not unique in having anonymous functions, it merely had a critical mass of web devs whose design preferences were already skewed by missing multicore support in client apps.


Does Java have an equivalent to the Promise system in Javascript? I find it much more usable than callbacks for async-heavy applications.


No Promises in Java.

Sadly - the language is really not quite as 'async' as we would like it to be.

Java scales much better than Javascript though, and I mean that in the architectural sense.

Past 50K lines of code - the lack of typing in JS can start to be hell, unless you really know what you are dong.

Of course, you move much more quickly early on in JS and that's actually important: you need to be able to 'iterate and adapt' in todays world. So it's kind of a paradox.

If you're building a bank, you do it deliberately with Java or something like that.

If you're building a nimble startup, you can start with Node and if there are systems that reach a certain degree of maturity and the uses/cases and data model start to settle you can fold over systems to Java or something like that.

A great team can use anything in the end though - that said, it's really hard to find super talented and responsible people across the board.


Java has an implementation of Futures, but it's not very good. In the JVM, however, we have Scala Futures, which IMO are far better than Javascript promises. And on top, you have a lot more flexibility deciding how to run those futures, as far as threading goes, because they run on top of Java's very sturdy ExecutorService. There are a variety of executor services for pretty much anything you want.

JVM concurrency is best in class. It's just the Java language itself that moves at a snail's pace.


Java has Futures, which are close, and allow similar patterns of code. But they're not woven into the language as pervasively as Promises are into JavaScript. You need to deal with asynchronous-ness explicitly.

There's also, in true Java tradition, a number of competing implementations of Promise based frameworks. The one I've used, Ratpack, defines and uses promises almost identically to JavaScript/Node.js.



Look into Scala and Futures, very similar.


In either SE or EE, no. Most people use Google's Guava library, which contains Futures that have that functionality.


Java has several APIs. From what I can tell, profiles are pre-chosen sets of APIs. But the author is against these (waste of time), and wants devs to choose for themselves, and the server should be able to efficiently load them when needed. And microservices, just because.


People claim that Oracle is abandonning JEE (which is true) and that this is killing Java (which the author disputes). The author argues that JEE is too monolithic and that monolithic frameworks are falling out of favor in general so abandoning it is a sound business decision on Oracle's part. He concludes that people should "stop bitching" and use the JCP to move JEE towards a more modular approach where everyone can pick and choose components based on their actual needs.


Java EE is described by some as old, heavy, over engineered technology as opposed to Java SE + simple servlet containers with some Spring or other 'lightweight' frameworks.

However in my opinion there is something about Java/Java designers at Sun/Oracle/IBM that lead to over designed APIs and code. Looking at just Java servlet api, it is described in most elaborate manner. It is not about supporting Http Listeners endpoints + some additional features but about any kind of servlets possible for past and future protocols. It is awkward and lacking features for practical Web based applications but still has 74 class just for specifying servlets and no implementation.

So arguments about Java SE vs Java EE vs Spring vs Other hot Java framework seems facile to me. Java it self has set the tone to describe things in most elaborate manner, not most succinct manner and anything on top of that more or less follow that tradition.


About eight years ... nine years ago, I was between jobs and thought I might use the large amounts of free time I had at my hands to learn something that might improve my chances of finding a new job. Lots of companies use Java EE, right?

So I downloaded the JDK, Glassfish and a PDF of a book called "The Java EE tutorial" from Sun.

I found it slightly disturbing that Glassfish (or was it JBoss? It was so long ago...) used ~400-450 MB of RAM before I had done anything to it.

And then I started reading the so-called tutorial. The fact that it had ~1100 pages should have tipped me of, but it did not frighten me. When I looked and the Table of Contents, however, which came with a freaking flow chart on how to navigate your way through the book depending on what you already knew, I ran away screaming. ;-)

And to be fair, in my brief attempt to learn C++ I, too, looked at my first slightly-nontrivial-toy-program when it was finished and found it incredibly over-engineered. So I know how easy it can be to give in to that temptation.

Also, there is this old saying that a given piece of software will reflect the organizational structure that created it, if large corporations send hordes of programmers to attack such a problem as creating Java EE or the servlet API, it is not a surprising result.

In a way, .Net has the same problem, to a degree. I have not used it much, but one of my first toy programs was an address book that got its data from the Active Directory, and the LDAP API was significantly more complex than, say, Net::LDAP in Perl. Not unusable, but the difference is noteworthy.


I have seen those massive J2EE tutorials and blueprints. They came directly from Sun and used to be(still are?) taken very seriously.

Java/EE slogan is 'RAM is so cheap nowadays!' for anyone questioning why applications seems so bloated. If you had temerity to probe further they would drown you in blizzard of serious sounding technical/business buzzwords.


I got a away with the impression that some of those large, enterprise-ey applications are so large and convoluted in the way they are specified that the bloat Java EE adds appears negligible.

After I had the honor of writing a few simple-minded Perl-CGI-script to give my boss an overview of projects our company is working on and their respective profit margins, I begun to understand why. If somebody tells me computers are complicated, I tell them that computers are trivial compared to accounting. Or my brain is just wired that way... Listening to our accountants always makes me feel like me IQ just dropped by fifty percent (or more). So if somebody writes a piece of software that is somehow involved with accounting, it is bound to be very complex with lots of special cases and exceptions.

I have nothing but the utmost respect for our accountants who manage to deal with this insanity without sacrificing a goat to Cthulhu or something.

TL;DR - once one reaches that level of complexity, the complexity JavaEE puts into the mix is probably fairly tame and one has bigger fish to fry or escape from.


I'd slightly disagree because considering we are discussing impending fall of JavaEE where as enterprises seems as complex as ever. So it would mean JavaEE is not really proved right solution to complex enterprise problems.

I feel JavaEE is very large orthogonal complexity which somehow neither solved nor reduced enterprise complexity. It added a jargon speak and multiple layers to bury enterprise problems and reduced net understanding of issues.


My feeling too. I believe it comes from Architecture Astronauting: http://www.joelonsoftware.com/articles/fog0000000018.html Java/enterprise world is pestered by such guys.


I may wrong you, but I won't click on a link to "techsticles"


It's not Jamie Zawinski, so I assure you, you won't end up seeing an actual "techsticle"


Agreed. That name definitely falls under the category of "clever for all the wrong reasons".


Java always had an awesome open source community around it that produced frameworks, libraries and tools that inspired many other communities. but at it's core, Oracle was and still is the exact opposite of open (JVM, J2EE as examples). That makes me wander why Java was always considered the icon of open source.


I would argue that Java's success owes more to Maven Central that it does to anything Sun or Oracle did with the language itself.

Maven Central is Java's CPAN, and that's what you need in order to build a thriving open source ecosystem.


I dislike Oracle as a company. I whish Sun had been acquired by Google instead.

But the Java ecosystem is awesome. The language is great, the JVM is great. As long as you know what you are doing.


As far as I remember, Google was not even interested in buying Sun (at least not wholesale). The other company that was engaged in negotiations was IBM, which could have gone either way, I guess, if they had bought Sun.


Realistically, Java EE "fell" a long time ago, once people realized you could use Spring or Guice or other frameworks to help organize your code without relying on terribly designed APIs from Sun/Oracle for simple things like "I want to handle a http request".


Sure, technology changes. I this case it is positive, moving away from monolithic bags of tricks to lighter services. That is all good for Java. But, we will be looking to moving away because Oracle can no longer be trusted.


To monolithic, interdependent bag of lighter tricks. Microservices don't magically make developers know how to design.


There is nothing magic about microservices and people who think they are run the risk of getting burned bad. Even though each individual component is smaller and easier to reason about complexity still exists but its usually hidden in the interactions between the services. That said there are tremendous benefits of being able to develop/test/deploy incrementally, its all about balancing the trade-offs.


Agree, it makes things harder to design and much harder to debug. The win is down the track.


Everybody hates Oracle, but people still give them so much money! One has to wonder when it will end now that there are alternatives.


Remember that sales is mostly about relationships. Your CEO will hand a few million to someone they trust. Oracle projects an image of being the large company that other large companies trust. SAP has a similar vibe. Your C-Level people don't want to play dice with tech because to them it's often a cost center whose disruption can be terrible for business.

You'll notice most engineering focused companies don't use Oracle because they decide on tech based on different criteria and allow more input from engineering and don't mind building things. They have to bet on tech or else they have no reason to exist.


Last time I looked around it seemed a lot of "engineering focused companies" like tech startups were using garbage like MongoDB, the famously lossy database. I wouldn't assume that big companies are automatically incompetent and "tech focused companies" ignore Oracle for good reasons. It can as well be just fashion and/or groupthink and/or cost reasons.


Web development and engineering are different. I believe we're in agreement.


The DB is an excellent product. It is not just sales and/or execs relations. I've used ORACLE, Postgre, MySql, SQlite, MS-Sql, and also Firebird. From the bunch, ORACLE is not only the expensive one, it also delivers.


Maybe but Google, Facebook, Twitter, Yahoo, eBay, etc... work very well without this database.


....mostly because they have big enough engineering teams to roll their own and/or re-engineer an existing database to keep up with their workload.

Oracle SQL might be the fastest, most robust out of the box database, but for a huge deployment like Google/Facebook/Twitter, even out of the box Oracle SQL won't be good enough. It's kind of an unfair comparison.

That's not to say I'm defending Oracle's bullshit, but you gotta put these things in perspective.


Google and Facebook use Oracle, not for their main product but for their back-office.

eBay also used Oracle in the past (if you dig back in the past of their architecture/design of eBay).


Oracle's entire business model is based on sales people talking to middle- / upper-management and convincing them that Oracle is the best tool for the job even if their developers don't agree. There's a lot of "Oracle has a service contract" CYA reasoning, and there may even be kick-backs for the decision-makers for choosing Oracle[1].

[1] To be fair, I think this sort of thing permeates this type of "let's talk over lunch" sales model.


They solve business problems.


Developers hate Oracle, but enterprises give them money.


I've worked with a lot of software that uses Oracle on the backend. Our company wasn't buying Oracle, but I'm sure the company we were paying for the software was giving Oracle a lot of money. However, I don't think this is the biggest reason that Oracle is the behemoth they are. I think it's the US government. I expect that everything in the federal government runs on an Oracle server. Just a guess, though. I just can't fathom how enterprise sales can float a company that everyone supposedly hates.


Java EE is a set of mostly bad libs for Java SE. Unfortunately the upper management has seen it as a "better Java SE"...


Sadest part is that it diffused into education.


Agree! Over here we're teaching it to high school kids, when I think Python will be a lot more suitable and enjoyable.


Please introduce value oriented recursion (not just pretty printing). Like powerset, or countdown functions. Link them to Pascal triangle and then recursively defined series. Combinatorics, factorials, (1+x/a)^n .. etc etc. Tell them it looks fucked up dull and alien, for now.


The author's recommendations are:

> 1. Drop the profiles. They are useless and pointless waste of time.

This is true, but profiles exist mostly for the benefit of vendors, not developers. Developers only care about modularity, see #2.

> 2. Make Java EE a conglomeration of technologies that are known to work together (i.e. JPA, JTA, JMS), but don't force their full installation. Let the use pick and choose what they want. Just be sure that they work together in pieces or in totality.

You can do this today, if you use good implementations for those APIs (JMS, JPA)

> 3. Make it modular. Start with zero and let people add what they want to use.

Same as #2, plus Jigsaw.

> 4. Get rid of the tree class loader. You need it matrix based. OSGi is fine. Jigsaw is fine. But it needs to have classes that can be loaded and unloaded without an impact on the container. > 5. The container itself should be a thin shell with remote capabilities (again OSGi/Karaf looks really good here)

The OSGi spec gets a bad rep for complexity, but it actually solves a hard problem. Karaf's default UI, on the other hand, is terrible.

> 6. Make it cloud friendly. Microservices needs to be core functionality, lightweight, and run in the cloud.

Uhh, it's pretty cloud friendly now. Not sure what the author wants here.

Ultimately the author says, if you're invested in the Java EE ecosystem, you can't rely on Oracle to move it forward, but you shouldn't let their inaction lead to your inaction. However, due to IP reasons and a perceived past overengineering, the community has nearly given up on Java EE and focuses on Java SE instead. This means that they've adopted points #1, #2, #3 and #6, and are actually moving the ecosystem forward, just piecewise and no longer under the 'Java EE' name.


The wait is over, here is Oracle's official response to the rumors: http://arstechnica.com/information-technology/2016/07/not-de...


What are the current best bets for writing web apps in Java? Play! is convenient, but how does it compare to Spring Boot?


If you simply want to serve a web ui, Play and Spring Boot are good. Play is a bit more self-contained. It provides a lot but doing something a bit out of the ordinary can be challenging. Spring Boot is more agnostic in that respect but relies (obviously) on Spring for dependency handling.

As well as those 2, Dropwizard is excellent if you're writing REST apis and provides many enterprise-friendly features out of the box.

SparkJava (don't confuse with Apache Spark) is a very lightweight Sinatra/Flask-like framework using Java 8 features, and good for REST apis too.

2 more to consider IMHO: Vert.x, and Comsat from Parallel Universe. Parallel Universe have one of the most interesting technologies in Java-land IMO. They provide a library called Quasar that adds suspendable green threads (similar to Erlang processes) to your code using bytecode instrumentation. This allows a single server to handled a huge number (think 00,000s) of concurrent connections. Vert.x has support for Quasar too.

I'm sure others have favourites too.

https://www.playframework.com/

http://projects.spring.io/spring-boot/

http://www.dropwizard.io/0.9.3/docs/

http://sparkjava.com/

http://vertx.io/

http://docs.paralleluniverse.co/comsat/




Just completed evaluating the two above. Been using Play for a year and a half and Spring Boot for a few months.

Play is incredibly convenient and has some very sane, intuitive defaults which makes getting something going very, very simple. Play Authenticate and Deadbolt for instance are excellent and give near out the box authentication and security for your Play app.

Persistence in Play is very easy to get going, automatic database evolutions are super cool, routes are easy to setup and all reside in one place. On top of that its got some useful asset management processes for integrating Javascript, CSS and image assets.

Where Play fell down for me was:

1. Dependency management. SBT felt so damn impenetrable. On top of that any Scala or Java libraries were coupled to the binary version of Scala which meant updating and checking every dependency anytime I upgraded to a Play version which used a newer version of Scala.

2. Play breaks a lot of things between versions. Considering it came out in 2007 it's kinda concerning that so much changes between versions and can be a real pain point.

3. In Play Scala is a first class citizen and Java a second class citizen. I started out using Play Java, but it felt like every time I needed to do anything with it I had to consult both Play's Java and Scala docs.

Spring Boot is a real breath of fresh air for a Java dev. Sane defaults, no need to use XML configs, cool stuff like CrudRepository to make persistence an absolute piece of cake to setup.

I do miss database evolutions and the ease of Play Authenticate/Deadbolt and the great asset management utilities which Play provided but Spring Boot can do all that with a little bit of tweaking and then some - Spring Security, DropWizard Metrics, support for Jersey and just lots and lots more make SB super powerful.

Spring Boot also has a lot more tutorials and quality paid for courses so getting skilled up is more straightforward.

Finally from a project manager point of view finding competent Spring Boot developers is a LOT easier than finding competent Play/Scala devs.

Regarding the other Java web frameworks, Dropwizard's dev community seemed liked it had less momentum than SB or Vert.X. It also seemed less up to date.

Vert.X was the most compelling alternative to SB for me and I spent a fortnight messing around with it - lots of fun. It provides an excellent asynchronous event engine and if you like Lambda expressions you'll love coding in it. Very enjoyable to use and the community is fantastic. It has a lot of momentum and you can also integrate it with SB to give you the best of both worlds.


> I do miss database evolutions

Spring Boot has integration with Flyway which works pretty smoothly, if that's any use:

http://docs.spring.io/spring-boot/docs/current/reference/htm...


I'm very happy with Dropwizard (http://www.dropwizard.io/) which is great for building REST services. I think it is quite similar to Spring boot (haven't used that).


Old school + super stable (requires less upgrade type of maintenance): plain-old Servlet, Spring MVC

Slightly newer: Spring Boot (uses Spring MVC as well)

Cutting Edge + keep-up with upgrade mill: Play, everything else not on the list above


https://jhipster.github.io

It's actually based on Spring Boot.


I understand the viewpoint put forth here, but I think the big issue is making sure Java EE continues even as Oracle decides it's no longer worth the investment. I don't know how easily a group or organization (like Apache) can take charge of it given trademarks, patents, and the like.


I think that as with many things, you need to follow the money:

Someone has to pay for the talented and expensive people needed to develop, maintain and extend a language/ecosystem ("community" does not == free of cost).

It isn't obvious to me what the underlying motivation would be to drive the investment required. For Swift/C#/Golang it seems to be roughly "Platform Entrenchment" or perhaps "if not this then we're owned by $otherbigco". Oracle doesn't really have a platform to entrench these days.


Wildfly Swarm (http://wildfly-swarm.io/) seems like the exact adaptation the author is looking for. "Swarm offers an innovative approach to packaging and running JavaEE applications by packaging them with just enough of the server runtime to "java -jar" your application."


Nice post! I have the same opinion.

I guess, most people who make a scene about Oracle's stance think that Java EE is the same as the JCP. The JCP will go on and JSRs that are part of EE will continue to evolve. Its just a question of which JSRs still have value in a world of fast changing cloud / compute infrastructures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: