Even then Oracle tools were horrible for developers and still are. The only reason they had that many databases was Oracle's business is licensing, massive, expensive licenses, and their sales pushed them sold through upper management. Those days are almost over, developers choose the tech, the cloud is here. Without Tom [1], Oracle was basically not even a great developer community, all documentation was bad and the Java interfaces on the tools / management studio were horrendous. Oracle is fast but for most things on the web caching comes into play heavily and other databases are good enough. Oracle is good for large datasets/reporting, cursors are extremely fast when Oracle is tuned, the problem is it is like vehicle that needs tuning and optimization all the time or it drives bad. The cost and upkeep make Oracle mostly overkill and too painful.
Ellison laughed at the cloud like Ballmer laughed at the iPhone. That was a major error. But ultimately Ellison is an engineer that forgot to make sure developers like to use the product. That will ultimately be their fatal flaw as now the developers choose the tools not what is sold in above them.
All other platforms are developer centric and cloud first now. Oracle the all seeing one says the end is nigh for Oracle the database. No new projects will be using it without force. Too bad Oracle also owns MySQL, Java etc. I really wish someone else had bought Sun.
The OpenJDK (not 'OpenJVM', that's not a thing) is literally 100% the same build as Oracle JDK now. There can't be any technical reason.
This said, the likes of RedHat, Amazon and Azul are pretty happy to offer those guarantees, and I bet their prices are lower than Big Red O.
And there are other concerted efforts to keep control from Oracle in releases and the validity of the JDK.
As long as a sufficiently large majority (and AWS is helping here a lot, admittedly) maintain such regimented discipline, the JDK will be ok.
Oracle mostly wanted it to sue google for billions. That suit is basically dead, and Oracle knows the JVM isn't worth any large scale revenue.
Guess which One Rich Asshole company has this practice.
This is just personal abuse.
Purge every oracle product slowly but surely
Yeah. Say no more... If only you would have looked. Anyhow, Oracle does the following:
- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;
- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;
- Starts providing a free OpenJDK build (which includes all these donated technologies);
- Provides uncountable man hours of maintaining and innovating the Java platform;
- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;
And how does the community react, you wonder? Yep, that’s right. “Oracle is the Devil”, “This is a bait and switch operation” etc. Ad nauseum.
ONCE AGAIN. You do not need to use OracleJDK. Just use OpenJDK from AdoptOpenJDK.
The long short of it is we aren't a booming industry and we do it for the money so one less vendor we have to send a 7 figure check to will only increase the bonus pool.
The Dynamo part of it, the pure application server part, had a few genuinely decent features. I've never seen a dependency injection framework like Nucleus, despite the fact that it makes an awful lot of sense. And you got /dyn/admin!
The whole publishing thing - derive a versioned dual of your database schema, edit data in it using a reflective CMS, then automatically publish changes to your production database - is kind of amazing. Source control for databases. I haven't seen anything else like that. Apart from just putting databases in source control, i guess. It occasionally got absolutely screwed up, but the idea was cool!
But a lot of it was absolute garbage. Repositories, where database entities are mapped to these crappy dictionary things that you need to either wrap or go mad trying to customise to actually use. Form handlers, whole classes for what would be a single handler method in a modern framework. The wacky build and packaging stuff.
And then whole commerce layer of it. Pipelines where the majority of the steps are about doing cleanup and normalisation that's only necessary because of how weak ATG's data model is, and the real commerce value could have been a single 20-line function, and adding your own stages becomes and exercise in boilerplate-smithing. Catalogue maintenance, which you have to run sometimes, because apparently it's too hard to just keep the database consistent. Scenarios, the businessperson-usable customisation tool that isn't, in practice, usable by businesspeople!
However, publishing has always been a dumpster fire for me, from the very first time I've used it (around 2004-2005 IIRC) to 2015 when I stopped working with ATG. Deploying changes never worked reliably, full deployments could take days, if not weeks, and relying on RMI made for a very fragile system anywhere multiple network interfaces were involved.
Nucleus and /dyn/admin are incredible features, not only for development but for having near total control of your application in production. I can't count how many production incidents I've solved with curl and /dyn/admin alone.
Fun fact: Java (Apache) Struts 2 [2] is a vulnerability mess. It was used by Equifax on the breach:
> Struts 2 has a history of critical security bugs, many tied to its use of OGNL technology; some vulnerabilities can lead to arbitrary code execution. In October 2017, it was reported that failure by Equifax to address a Struts 2 vulnerability advised in March 2017 was later exploited in the data breach that was disclosed by Equifax in September 2017. [2]
They probably went with Java EE because it was "secure", little did they know Struts would enter the game. Equifax I am sure treats their developers good by how often their software was updated /s.
1) they have significant investment in the human capital side of Oracle, which is to say, Oracle DBAs on staff who are highly capable at keeping the lights on for their Oracle databases, but have little or no familiarity with alternatives 2) enterprise architects are required to get approval from their DBAs for the design of new systems, who won't approve non-Oracle databases that they can't support, so new systems get built with new Oracle databases 3) the financial cost of the additional databases is organizationally far enough removed from the design phase that Finance has no real power to say no, and anyway such enterprises have other areas of the business that are far more bloated grabbing Finance's attention, where the cost of additional Oracle licenses is a rounding error by comparison 4) Anybody at a high enough level to see why this is a problem has far bigger problems to deal with and so the situation persists.
I doubt that apathetic enterprises are enough to make Oracle database a growth center overall when nobody in their right mind adopts it for new companies, but I doubt that all of their customers are looking for a migration exit.
I still love Java, but I won’t be surprised if that language becomes a business risk because of Oracle’s behavior in other spaces.
To be clear the licensing appears to be open enough so that this shouldn’t be a real threat, but IANAL.
Yes, maybe there will be built in automatic fail over in a few years so you don't have to hack it together using a bunch of scripts.
Of course there's overlap in functionality and most companies should probably chose PG over Oracle. But PG is a joke in some areas like the above mentioned.
thanks microsoft !!
Yeahh I guess not. Let me know when I don't have to hack it together with a bunch of scripts and the PG team takes availability seriously.
Having said that, Oracle is probably the COBOL of databases, in that it will still be around (collecting good $$) from its existing customers for a long, long time.
Last company was very reliant on Oracle, we ran the entire business on a single Oracle instance for a couple of decades.
We had our share of adventures, but over the years never lost a minute's worth of data despite server, hard drive and other issues. We've also had a few scary performance problems, but have always been able to tune the DB to get past them. And once or twice, we've been in a dark place where you are googling for cryptic error codes, and we've always come through. That's a lot of business and millions of dollars earned through having a very reliable database underneath.
For us, the cost equation is whether it's worth learning a new DB. It's not. If you can run your business on a single instance, then on AWS, it's cheaper to stick with what you know than to try and move to a new DB for a few K of saved licence fees.
What's more, using Oracle is a good answer when the PHBs at our customers ask about our stack. No one ever got fired for using Oracle.
So yes, it certainly makes sense to use Oracle for new projects if you are already Oracle experts.
Java is somewhat the same equation as well ;)
Yet.
> Like many other open-source communities, the OpenJDK Community requires Contributors to jointly assign their copyright on contributed code. If you haven't yet signed the Oracle Contributor Agreement (OCA) then please do so, scan it and e-mail the result to oracle-ca_us(at)oracle.com. Please make sure to specify OpenJDK as the project you'd like to contribute to so that we can process and store your OCA. Allow at least two weeks for processing. If your request is urgent contact the appropriate Project Lead.
It seems to me that they actually own OpenJDK. I'm not a lawyer, but I think that they have the power to make all code proprietary if they want.
they cant pull the this licence from already published code, which means that they cant forcefully monetize it anymore. if they tried, someone else would fork it and continue its maintenance.
- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;
- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;
- Starts providing a free OpenJDK build (which includes all these donated technologies);
- Provides uncountable man hours of maintaining and innovating the Java platform;
- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;
Some bits do not even make sense: >OpenJDK might survive as permanently stuck in version 8
??? Wat?
They do own it. They own the copyright on the source code (all of it - even if Google or Intel wrote it). They own the trademarks. They own the specifications.
At that point, someone else could attempt a hard fork. Same as what AWS did for Elastic search and MongoDB. The existing release code is still under open source license and so would allow for that. But whoever's attempts that fork, unlike Oracle, would not be allowed to change the license terms beyond what the current open source license allows.
And, someone could also choose to not re-use any code, and re-imement from scratch the spec, like what Google did for Android. That said... the open lawsuit against Google is still deciding of the legalities of that one.
The large Accounting firms handle 80% of the financial audits of Fortune 500 corporations. They are used to walking up to Oracle DBs and extracting the reports needed for compliance and reporting.
If they have to learn a new ERP or proprietary Accounting system, then the T&M costs can mount.