Java EE
github.com
github.com
I run into this issue often enough that I've been tempted to write a userscript to translate the java.net links automatically... doesn't do anything about all the broken documentation links though :(
>Oracle said this week it plans to transfer management of the Java EE project to an open-source foundation, such as Apache or Eclipse. (Aug 19) https://www.bleepingcomputer.com/news/technology/oracle-want...
Acquiring all the rest of the Sun stuff (SPARC, Solaris, Java, StarOffice, VirtualBox, etc) was a side-effect of the MySQL acquisition.
Time to invoke SandGorgon's law of outsourcing analogies - "As an online discussion about PROGRAMMING grows longer, the probability of a comparison involving outsourcing or Indians approaches 1, if Godwin's law has not already been satisfied"
http://www.lambdacurry.com/2010/07/sandgorgons-law-of-outsou...
J2EE became a target for offshore software projects primarily because of its userbase being organizations that are fundamentally not software companies and that are constantly trying to cut costs while being unable to migrate off these systems quickly simply due to their sheer organizational inertia. These companies culturally haven't scaled based upon much more than bodies (a typical enterprise M&A is fundamentally more bodies and access to specific customer bodies rather than a strategic technology play given how slow M&A works in practice), and these are oftentimes the companies you see in newspapers that are experiencing business difficulties - what skilled, talented developers want to stake their careers working on software used only by a community that is in a multi-decade crisis?
Even if you spend a lot though, outcomes are not necessarily great either. US DoD is a great example of tons of J2EE on their backends with unremarkable outcomes despite having spent perhaps more dollars on software engineering effort than probably Google has in the past 30 years cumulatively (where the money goes is another topic).
It's tough problems as a large company that thought they were getting ahead of the technology curve back in the 90s and are now the dinosaurs and fossils.
To me the beauty of JEE on the backend is: 1. Scalability - the application server creates as many instances as needed - until it hits either the JVM limit or the machine limit. 2. Declarative transaction management so I can write reusable code that interacts with the database without having to worry about transaction boundaries. 3. Excellent and portable Object Relationship Mapping (Java Persistence Architecture).
On the front end, with JSF webpages can be developed very quickly.
There are a lot of other things you get with JEE like Asynchronous Messaging (JMS) - built in.
There is a reason mature organizations worth billions of dollars and with highly skilled architecture teams have settled on JEE as the defacto standard for their information systems.
There is definitely a learning curve with JEE, and someone fresh out of school will need a year or two to really understand how it fits together - but when you write something in this framework, it is easy to read, maintain and rarely needs to be re-written.
Most importantly, the framework will continue to be developed for the foreseeable future - I mean multiple decades.
On the other hand, some of the newer javascript stuff - is horrible broken spaghetti code that is glued together by spit and prayer. 99% of these frameworks will fall out of fashion with the associated problems that come with falling out of fashion - the canonical example being Ruby On Rails.
A lot of what's in JPA now came after Hibernate became such an industry-wide standard and because EJB 2's EntityBeans were so awkward. For early adopters in the 90s, EJB 1.0 was really, really difficult to work with and overall a frustrating experience compared to using Spring + Hibernate. This pain was much more keenly felt for enterprise software start-ups that couldn't afford release cycles and deployments that take so much time.
JMS is not the end-all be-all of enterprise messaging either and the J2EE ecosystem made certain technology innovations more difficult due to its byzantine nature. The AMQP working group came out of their frustrations with JMS and it includes a lot of experts with JMS implementations from the usual vendors.
I challenge you to find communities of developers other than H1Bs, older, offshored, and other disadvantaged (and in no way technically deficient either!) workers that are writing anything with EJBs for their jobs these days. Look at the career possibilities for these places as an engineer - do you imagine IT outsourcing and banking backends is something highly motivated and talented engineers would find fulfilling when there's other options? Furthermore, I challenge you to find operations teams that enjoy supporting these systems compared to architectures built around microservices / SOA using lightweight containers using, say, Kubernetes. J2EE architecture is simply not easy to maintain in production with typical enterprise sysadmins despite the billions spent on improving them over multiple decades now (and due to the hostile atmosphere of enterprise software vendor-client relationships impeding technical progress since time immemorial), and this is a deal-breaker for large organizations that are trying to reduce operations costs.
Even though ultimately we as an industry seem to be reinventing the wheel constantly probably to keep ourselves busy rather than to build highly maintainable software, this is preferable to millions of developers around the world in a monoculture writing constantly refactored and improved COBOL and Fortran if we approached the world of software with the JEE vision. It's been shown academically that for software reliability and maintainability, if you need to rewrite more than a certain percentage (I believe it was around only 30%) of the software, it is more economical and practical to rewrite it all. It is the rigidity of the JEE vision and competing enterprise standards that made interoperability and thus freedom for motivated, creative developers difficult that pushed them away from both larger companies and toward smaller companies united by open and probably less stable ecosystems. Moreover, it is really difficult to argue that the MIT Approach [1] fits everywhere in the software world and also that there is no merit to Worse is Better.
It's funny that you mention RoR in that there's been some concern by the community that it's becoming more like J2EE. It's a bit sad in a way because if everyone writing mature software winds up ultimately implementing J2EE, it has shown how little progress we've made as a software community despite so many different software design philosophies gaining market traction.
[1] https://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approa...
Once you get out of toy frameworks that won't scale, refactor or "age well" - you end up with a JEE style framework.
It's like that famous cliche about unix - "Those who do not understand Unix are condemned to reinvent it, poorly."
You are right about older versions of JEE being a pain in the ass to use - but that critique hasn't been valid since 2004 when EJB 3.0 was released - 13 years ago. JSF is really slick for front end development.
But even prior to the release of EJB 3, can you name any EJB equivalent (from the pain in the ass xml era) that is still used, supported and actively developed?
We literally still have 15 year old EJB's - that "just work". People just inject them into the new EJB's they write and they work!
You might think rewriting services to keep up with the latest and greatest fad is a productive use of your developers time - but I prefer to have my developers focus on solving new - revenue generating problems, with building blocks that have already been written instead of constantly reinventing the wheel.
We have a mix of American developers (junior, mid-level and senior), offshore developers in 6 countries, and H1-B developers - all of whom are paid at or above market rate for their work (150K+ for the State side workers). I don't think any one of them considers themselves "disadvantaged" in any way because of the technology stack.
They understand that they have problems to solve and JEE are a tool to solve their problems and I am sure they grateful we aren't making them re-write 15 year old code to keep up with the latest fad.
What multi-decade crisis are you talking about? Not everyone is hipster afraid to learn abstractions or unable to comprehend them. There is learning curve to J2EE and especially early versions were hard to learn, but willingness or ability to learn is not exactly mark of no-talented developer. Low skilled untalented developers go for easy to learn technologies.
Integration projects are difficult for many reasons, technology choice is not one of them.
From my years doing integration projects for a lot of the F500 I've confirmed your assertion that technology hardly matters for them, but this makes it very difficult to grow as a developer because you're not solving technical problems anymore as much as business level ones. The "learning" involved at technical levels tends to become more about trivial (API inconsistencies from implementation, names of properties) or specific, proprietary knowledge gained from basically reverse engineering other parties' code. This also does not require any skill or much training either. Combined with mostly straightforward coding requirements, this drives down the skill level necessary to be successful in a usual J2EE software shop and thus the labor pool drives toward commoditization.
I don't see "bad" mentioned anywhere
Also DropWizard is pretty quick and offers a good combo of features.
Spring is the most feature complete, it's a shame it's so slow in comparison
What's going on?
Do you think it was anything but the most incredible terror and desperation that drove them to add a Linux subsystem to Windows? To open source their "crown jewel" of .NET? To support Linux on Azure? To make Visual Studio almost entirely free? To adopt Electron as the base for VS Code? To ditch TFS for GitHub?
Edit: Corrected to be more precise Chromium vs. Electron.
In the real world, companies are made up of lots of individuals, all with strong, differing opinions. Some people at Microsoft undoubtedly hate open source. Some of them undoubtedly love it. Many of them are probably, like most developers, somewhere in-between. They have no ideological investment, they just make use of it when it's useful.
Having actually worked in the Microsoft ecosystem in past, I know that there have been people there for years who like open source, and who have pushed to make Microsoft a more open company. There's no doubt that competitive concerns have driven some of Microsoft's embrace of particular open source technologies, but to characterise their entire approach to open source as being: 1) entirely recent, and 2) completely fearful and reactive, has no basis in recorded fact, and does an appalling disservice to the many people who have spent many years (successfully) trying to change Microsoft's internal culture and make it more friendly to open source.
If you're not already familiar with the "Halloween Documents" (https://en.wikipedia.org/wiki/Halloween_documents) then you should take a look. They were pretty much the definition of "fearful and reactive".
Microsoft has historically had an ideological investment in killing everything that wasn't Windows.
Microsoft has been roused in this fashion 3 times before that I can think of.
1. The internet. If you don't remember, MSFT completely misjudged the importance of the internet. A heroic effort by Bill Gates turned the company around and got them on track to seize control of the web (until Google drove them back).
2. Java. It was so successful that MSFT had to create a nearly identical tech stack that they controlled, after Sun beat them in court.
3. Linux. Open source, well supported, loved by tech people, runs on almost every conceivable hardware platform. It's been a herculean effort just to fight for market share. If it weren't for lock-in, MSFT would have gone the way of Solaris and HP-UX.
Now open source is the only way to try to get back that developer mind share that they've been losing for so long. This is a good thing in the long run, but to couch it as anything but "fearful and reactive" is to discount a lot of history.
Seems like quite a straw man argument, there probably isn't a single person that actually fits your description. And it certainly does not describe a typical developer.
As infamously documented in "The Windows Shutdown Crapfest" [1], in order for anything to be publicly observed outside of most large bureaucracies, a large number of people are involved, and their only common interest comes from very high up in the bureaucracy. So you usually do end up with a single, simple ideology presented to the public, even though there are a lot of people internally fighting for different things.
[1] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
A corporation has a power structure which necessarily is independent from any one person. It follows that there is something about corporations which is distinct from its employees. Look at a business as both having employees, who are people, and being a corporation, which is like a golem.
Nobody does risky moves out of the sheer joy of doing them, especially if you have shareholders holding the Damocles sword of share-value over your neck.
You do them, when you run out of options.
"Microsoft’s Open Source Developer Journey"
https://channel9.msdn.com/Events/Visual-Studio/Live-2017/Key...
It's funny because the new generations still use Windows to develop on and Linux to deploy to and no one is denying this. But Microsoft somehow is accepting this shift and is trying to bring its stack on Linux and also Linux on Windows.
I think Microsoft is smart,they really realized unlike Oracle and others that sometimes you cannot people force to use or do whatever you think is the best (looking at you Oracle,IBM,Apple) and literally giving people what they want is the best thing you can do to turn the tides.
Ehh, using Electron to write a relatively lightweight wrapper for Monaco (the editor component that was developed for an entirely different product) was an obvious technical choice if you were no longer restricted to only using Microsoft technologies. There's not a reasonable/supported alternative to Electron within Microsoft.
F#'s compiler and tools has been Apache licensed since, what, 2005?
Even now they are being disingenuous about license changes, witness for example the leadership of this project changing license from Apache 2.0 to MIT and being obtuse about the licensing of patents or about reasoning, not explaining clearly the drawbacks of the change: https://github.com/Microsoft/visualfsharp/issues/3440
OpenJDK happened on May 8, 2007, that's 10 years ago and you've got companies like Red Hat and IBM collaborating on it. By comparison .NET Core was released 2016, so that's 9 years later.
And the JCP might be a farce as far as standardisation efforts are concerned, but at least you've got multiple companies participating.
I'm replying this because I'm getting tired of Microsoft's marketing campaigns on this forum.
UPDATE:
Btw I actually applaud Microsoft's open sourcing efforts, I see myself using .NET in the future and I'm actively using Visual Studio Code and TypeScript at the moment. They've got fine people there working on dev tools, they always had.
But then I also see them engaging in what's basically racketeering, threatening Android phone makers with patents (i.e. if you can't innovate, litigate), having potential for becoming one of the largest patent trolls ever. And I also see them breaking user privacy in Windows 10. Therefore my view of them is balanced, as a large organization the left hand doesn't know what the right does, etc.
I cannot love them and even though I may have forgiven them for their past attacks on Linux and the open web, I can't forget their past that easily. And before you mention Google, Apple, Facebook, or other media darlings, check my history to see that I'm consistently ranting about all of them and the malevolence of one does not excuse the rest.
What I'm saying is that "Microsoft changed" messages make me feel nausea because it's been a clear marketing campaign and people fell for it. Let their actions speak, applaud and reward them when they do good, but don't put them on a pedestal and don't do marketing for them without getting paid for it.
You're comparing unequal things. OpenJDK was a community effort, while .NET Core is maintained primarily by Microsoft themselves. The correct comparison would be to .NET's community based alternative, which is Mono. Mono in turn had it's initial release in June 30, 2004, which is _13 years ago_, and 3 years before OpenJDK itself.
Further, note that Oracle only open sourced Java a year after Microsoft did .NET Core. One might even argue that Oracle only did so _because_ of .NET Core.
I'll note that I'm replying because I'm getting tired of Oracle's marketing campaigns on this forum.
> The correct comparison would be to .NET's community based alternative, which is Mono.
This is disingenuous at best. OpenJDK was started with a huge codebase from the existing Sun JDK at the time, similar to how .Net core was started with with a Microsoft codebase.
Meanwhile Mono had to be written from scratch and was a far cry from being somewhat compatible for years after it started (e.g. capable of running a Visual Studio compiled .NET GUI program)
> Further, note that Oracle only open sourced Java a year after Microsoft did .NET Core
I'm not sure what you mean by "open source Java" in this context. The Java Community Process was started in 1998, and as said OpenJDK started in 2007. Java EE being open sourced like now would be much more comparable to Microsoft releasing something like Windows Presentation Foundation as open source, as it's a oft-used part of .NET but not part of the language per se.
You can read it all here: https://en.wikipedia.org/wiki/OpenJDK
Mono is owned by Ximian, which is now a subsidiary of...Microsoft. This creates the rather odd situation where there are three implementations of .NET, but Microsoft controls all of them.
I just think you're simply underestimating how many people actually like .net and spreads the love by free will. :)
Can you substantiate that claim?
For some reason Java people have a near allergic reaction to it though.
I cringe a little when I need to write the occasional `def foo[T](list: List[T])(implicit tag: ClassTag[T])` in Scala.
It's such a shame that Microsoft until recently kept it so tightly controlled and Windows only. If that hadn't been the case the ecosystem (libraries and languages) might have been a lot more up to par when compared to the JVM ecosystem.
Make no mistake: Microsoft knows very well what its business model is. Sun was very confused in that respect.
It kind of worked for a small slice of .Net programs (e.g., those that didn't rely on WinForms or any other non-implemented part of the stack). That's about all you could say for it for quite some time.
Don't take me wrong I am not saying that Windows / MS stack is better. It's just as good! And that's the beauty of it. I am glad microsoft is embracing other platforms so lets see how other people will react :-)
Oracle has improved it quite a bit and all those features are being worked on for Java 10.
So it is not like everything is better on the other side.
Note that I do enjoy using both of them since their early versions.
The only problema with Swing (JavaFX not so much) is developers coding away withouth bothering to learn how to use them.
Yes, out of the box they are harder to use than Windows Forms, but anyone that bothers to read books like "Filthy Rich Clients" is able to tame Swing.
When .NET Core starts supporting a standard GUI (eventually Xamarin.Forms) than runs in all platforms that Java GUIs run today, then you can complain.
This post is just about JavaEE - a set of libraries for Java - being moved to GitHub.
Don't forget the business community. To a first order approximation, most programmers who get paid to write code work in either C#/.NET or Java. Everything else is a relatively small minority of paid development work.