I'm not sure I understand how Amazon can offer something like this. IANAL, clearly, but isn't anything one or two degrees away from "java" something that Google just fought a long court battle over? Is Corretto different because it is running inside Amazon's data centers? Was the Google blunder that they supposedly used actually Oracle (acquired from Sun) JDK code inside their Android/Dalvik?
I believe this is just long-term support of the open jdk in formally managed releases. They are not modifying the JDK for anything outside of its original intended purposes and APIs.
Since oracle changed the release schedule to be a thinly veiled "pay us money or upgrade your JDK every couple months" model, there is a lot of uncertainty in javaland.
If you think that corporations would just stay up to date... well, then you clearly don't know how slow corporations are to adopt new JDKs.
This is fine. Amazon is just redistributing OpenJDK according to the terms of its license, which is indisputably legal.
The problem with Android was that it was using, Harmony, a clean-room implementation of JDK whose license is incompatible with OpenJDK. It was believed at the time that APIs were not copyrightable, and thus that clean-room implementations were not derivative works. The courts disagreed. Now Google just uses OpenJDK for Android and they are back in the clear again.
When Android started, they could have? J2ME and state of Java/JDKs was far different than their AOT and Harmony classlib, especially with licensing/freedom. If anything, being divorced from Sun/Oracle stewardship/runtime over the years helped them more than hurt them.
>Aurora is an open source database. They just it picked up and made it closed source on Amazon.
This isn't remotely true at all. As far as I'm aware most of the work inside of aurora is in the storage side which is a complete rewrite with a new architecture as per here [1].
>Who develops Aurora? That would be Oracle. It’s called MySQL.
> You know who else uses Oracle? Another company that hates us, SAP uses Oracle everywhere. SAP ten years ago said I hate Oracle, I’m getting off of Oracle, I can’t stand these guys, especially this guy that goes on TV and makes fun of us. They say we have this great new database called Hanna.
Wow! Getting it from Jassy is one thing, but hearing an engineering mind like James Hamilton sounding off like this is a surprise. I can't imagine what Oracle must have done to deserve a dressing-down like this.
> Eventually, a customer will focus on the “Oracle Problem” and do the work to leave the unhealthy relationship. When they do, the sense of relief in the room is absolutely palpable. I’m super happy to have been part of many of these migrations in my near-decade on each of IBM DB2 and Microsoft SQL Server.
If switching to IBM and DB/2 is a relief, the "Oracle Problem" must have been really painful.
We've been working on exactly this for more than a year. Well, not to Amazon PostgreSQL, but to PostgreSQL on our own linux setup. Using ora2pg makes moving the data over fairly simple (once you get all the settings right so the data flows quickly instead of taking forever). The thing that takes a long time is converting and testing all of the thousands of sql statements/triggers/procedures/etc. from Oracle syntax to Postgres syntax. Here is a partial list of things to look for:
replace nvl with coalesce
replace rownum <= 1 with LIMIT 1
replace listagg with string_agg
replace recursive hierarchy (start with/connect by/prior) with recursive
replace oracle insensitive query format with insensitive_query()
replace minus with except
replace SYSDATE with CURRENT_TIMESTAMP
replace trunc(sysdate) with CURRENT_DATE
replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date
replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date
remove dual table references
replace decode with case statements
replace unique with distinct
replace to_number with ::integer
replace mod with % operator
replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
change the default of any table using sys_guid() as a default to gen_random_uuid()
oracle pivot and unpivot do not work in postgres - use unnest
ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)
replace UNISTR( with U&’
Oracle: uses IS NULL to check for empty string; postgres uses empty string and null are different
Fix string IS NULL comparisons: field1 IS NULL becomes COALESCE(field1::text, '') = ''
Fix string IS NOT NULL comparisons: field2 IS NOT NULL becomes (field2 IS NOT NULL AND field2::text != '')
If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.
PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A
Any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="", it won't work).
Concatenating a NULL with a NOT NULL will result in a NULL.
Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For sequences, instead of table.nextval use nextval()
Recommendation: change all varchar2 columns to be not null and set the default to be ''. This fixes a lot of the issues with the difference between how oracle and postgres treat empty strings and nulls.
I led an Oracle to Postgres migration for my company's primary databases, and this is an excellent list of things to look for! It really can be done as long as you just use Oracle as a DB, and haven't invested too much into the Oracle ERP universe.
Are there techniques to write the above in compatible ways?
For example: "replace mod with % operator", can a shim "mod" function be implemented on Postgres?
Do you think it's reasonable to lint/test your way to compatibility before transition, and then remove transitional code afterwards, or do you think it needs to be a long running fork of the codebase? We did the former for our Python 2-3 migration and it worked really well.
Yeah, that's a tough problem on two counts. First, it's hard to find SP programmers for any one dialect, let alone two (e.g. PL/SQL and pgSQL). This is why architects who decide to go the SP route must realize that doing so means committing totally to that particular database platform - so you better really like the product, the vendor, and it's support.
PL/pgSQL is close enough in terms of language features to be nearly syntax compatible after some ora2pg-like transformations, aside from autonomous transactions, which apparently are now supported by Postgres 11 procedures (I haven't tried this). Your main problem will be all the DBMS_* package calls... orafce helps a bit, but not if you've gone really far into Oracle-land. Procedures you wrote for DB system maintenance may not have a meaningful translation.
I spent a few weeks converting all of ours. At first it was hard trying to figure out the differences, but pretty quickly I was able to get a handle on it and converting them went very quickly. Unfortunately, it has been about 9 months since I did so, so I don't really remember the details of how to go about it.
IMO the best practice for starting this migration is dependent upon the caller of the procs. Meaning, where you need to abstract, fork, migrate, write test cases at, etc are at that level. There are too many idiosyncrasies between vendor-dependent plsql to do much more than migrate data and calling code (after having written test cases first to confirm functionality equivalence). Often this can include bidirectional data synchronization between independent DBs during the transition. An apt comparison is a temporary bridge built to serve only during the construction phase of large road projects. Don't be tempted to improve things while migrating, one refactor purpose at a time (accuracy/compatibility, and once complete, then improvements).
I imagine a major justification, especially for Amazon, is to stop paying Oracle $$$.
I'm not sure if you consider that a technical, or a business justification, but I don't really see a distinction here.
Some more strictly technical justifications would be:
* Aurora has the potential to be a better architecture in the long run because it has something closer to an active/active redundancy, rather than Oracle's primary/secondary architecture, where fail-overs are manual and/or prone to failure.
* Aurora can also scale out to larger database sizes than Oracle.
Interesting, I don't think I've ever seen a comprehensive price list before and I've worked with Oracle for 20 years. Generally I've been somewhere with a site licence so you can use almost anything or used XE and bought standard one for production.
The main justification for some people will be getting away from Oracle's ... quirks, regarding both technology and business practices. The cloud environment for many folks will just be an added fringe benefit.
(Note also that if "cloud" is all you want, and you're comfortable with Oracle otherwise, Oracle is loudly touting their own.)
I had an exec level interviewer ask me about migrating from sql server to pg and deep down I knew it would be a nightmare but also knew that I would have to say its ok in order to continue on with the interview process, I paused and said that it was possible but would likely require a lot of work....luckily didn't get that job
I had a long chat with a senior engineer at Amazon a few days ago and this migration came up, apparently the first whispers that lead to this migration occurred back in 2010. Just goes to show how long it takes to complete these projects at scale.
The irony of being this transparent with CIOs about DB migration details is it instantly triggers an opportunity cost discussion.
"This looks like it'll cost $3M-$5M to migrate away from Oracle. But Oracle only increased our licensing costs $500K per year and I already have a team of 5 Oracle DBAs!"
Okay... but those costs compound each year.
Don't get me wrong... I'm all in the "migrate to cloud" camp. But DB migration is one of the most difficult and political conversations to have these days.
We did this with the New England Patriots, only we moved to an on-prem PostgreSQL instance. Specifically, we were on Oracle 8, so just finding the compatible drivers was half of the battle. I wrote a Python utility that carries these (nasty) migrations out from end-to-end. It works well, probably doesn't scale well, and needs tests. IT also doesn't solve the problems of Oracle-specific features, we just dropped those, which is probably not suitable for most folks, though many of these can/should be done at the application level.
Anyway, I made a promise to myself that when the project hits 300 stars I'd write tests and refactor for scalability. I need 3 more. Probably will be looking for some help if anyone's interested... https://www.github.com/seanharr11/etlalchemy
My experiences with Oracle databases back in the late 90's is partly what drove me to really strongly adopt open source. My webdev company was doing a contract for Ascend Communications who made ISDN modems, to build their whole website content management system.
I wrote an adapter that tied PHP (pre-1.0) and Java together before we had servlets and Tomcat. We used Java for the ‘backend’ and PHP for the ‘frontend’ rendering. Java talked to Oracle, pulled data out of the db and sent it to PHP for rendering the HTML. Oracle was forced on me because Ascend had a contract with them. This project was a nightmare on many levels, but Oracle was the majority of my drama.
Eventually, this project drove me to figure out servlets and Apache Jserv (first open source servlet engine)… which then led to myself and a couple random guys from Italy who had joined to work on JServ, to get Sun to open source Tomcat and create Java Apache (later renamed to Jakarta). If it wasn’t for all that, other Java stuff might not have happened at Apache (Hadoop, Lucene, etc).
56 comments
[ 3.0 ms ] story [ 107 ms ] threadhttps://aws.amazon.com/fr/corretto/
Since oracle changed the release schedule to be a thinly veiled "pay us money or upgrade your JDK every couple months" model, there is a lot of uncertainty in javaland.
If you think that corporations would just stay up to date... well, then you clearly don't know how slow corporations are to adopt new JDKs.
The problem with Android was that it was using, Harmony, a clean-room implementation of JDK whose license is incompatible with OpenJDK. It was believed at the time that APIs were not copyrightable, and thus that clean-room implementations were not derivative works. The courts disagreed. Now Google just uses OpenJDK for Android and they are back in the clear again.
[1] https://www.geekwire.com/2017/legendary-computer-scientist-j...
But they didn't
They have golang and dart to stand behind, they have no "need" to push Java.
Context: https://www.webpronews.com/larry-ellison-amazon-oracle-datab...
This isn't remotely true at all. As far as I'm aware most of the work inside of aurora is in the storage side which is a complete rewrite with a new architecture as per here [1].
>Who develops Aurora? That would be Oracle. It’s called MySQL.
Christ.
1. https://www.slideshare.net/AmazonWebServices/amazon-aurora-a...
He can't even write the name correctly.
If switching to IBM and DB/2 is a relief, the "Oracle Problem" must have been really painful.
In the CAP theorem context if you need CA you can't beat an IBM mainframe. IBM can also co-locate nodes of it's latest Power9/GPU supercomputer racks.
replace nvl with coalesce
replace rownum <= 1 with LIMIT 1
replace listagg with string_agg
replace recursive hierarchy (start with/connect by/prior) with recursive
replace oracle insensitive query format with insensitive_query()
replace minus with except
replace SYSDATE with CURRENT_TIMESTAMP
replace trunc(sysdate) with CURRENT_DATE
replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date
replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date
remove dual table references
replace decode with case statements
replace unique with distinct
replace to_number with ::integer
replace mod with % operator
replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
change the default of any table using sys_guid() as a default to gen_random_uuid()
oracle pivot and unpivot do not work in postgres - use unnest
ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)
replace UNISTR( with U&’
Oracle: uses IS NULL to check for empty string; postgres uses empty string and null are different
Fix string IS NULL comparisons: field1 IS NULL becomes COALESCE(field1::text, '') = ''
Fix string IS NOT NULL comparisons: field2 IS NOT NULL becomes (field2 IS NOT NULL AND field2::text != '')
If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.
PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A
Any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="", it won't work).
Concatenating a NULL with a NOT NULL will result in a NULL.
Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For sequences, instead of table.nextval use nextval()
Recommendation: change all varchar2 columns to be not null and set the default to be ''. This fixes a lot of the issues with the difference between how oracle and postgres treat empty strings and nulls.
>>> Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For example: "replace mod with % operator", can a shim "mod" function be implemented on Postgres?
Do you think it's reasonable to lint/test your way to compatibility before transition, and then remove transitional code afterwards, or do you think it needs to be a long running fork of the codebase? We did the former for our Python 2-3 migration and it worked really well.
For me the most annoying thing has been the (+) operator for LEFT/RIGHT (OUTER) JOIN, which does not exist in PostgreSQL.
Generally speaking, PostgreSQL’s syntax feels more logical.
https://docs.oracle.com/database/121/SQLRF/queries006.htm#SQ...
Alternatively, you could pay EnterpriseDB.
It might also be reasonable to migrate what you can into ADA, and run it outside of any database altogether.
I'm not sure if you consider that a technical, or a business justification, but I don't really see a distinction here.
Some more strictly technical justifications would be:
* Aurora has the potential to be a better architecture in the long run because it has something closer to an active/active redundancy, rather than Oracle's primary/secondary architecture, where fail-overs are manual and/or prone to failure. * Aurora can also scale out to larger database sizes than Oracle.
Now Standard Edition 2 costs $17k/core, but I believe it includes a license to use Real Application Clusters (RAC), justifying the price hike.
Not much justification if you're only running a single instance, though.
https://www.oracle.com/assets/technology-price-list-070617.p...
SE2 processor license is $17,500.
Enterprise processor license is $47,500.
So single 8 core CPU is 17500 with SE2, but 40.547500.
(Note also that if "cloud" is all you want, and you're comfortable with Oracle otherwise, Oracle is loudly touting their own.)
Oracle is also a hairy beast, kind of the perl of databases: there's always more than one way to do it.
Wow the guts of that thing are a god-awful mess.
"This looks like it'll cost $3M-$5M to migrate away from Oracle. But Oracle only increased our licensing costs $500K per year and I already have a team of 5 Oracle DBAs!"
Okay... but those costs compound each year.
Don't get me wrong... I'm all in the "migrate to cloud" camp. But DB migration is one of the most difficult and political conversations to have these days.
Anyway, I made a promise to myself that when the project hits 300 stars I'd write tests and refactor for scalability. I need 3 more. Probably will be looking for some help if anyone's interested... https://www.github.com/seanharr11/etlalchemy
I wrote an adapter that tied PHP (pre-1.0) and Java together before we had servlets and Tomcat. We used Java for the ‘backend’ and PHP for the ‘frontend’ rendering. Java talked to Oracle, pulled data out of the db and sent it to PHP for rendering the HTML. Oracle was forced on me because Ascend had a contract with them. This project was a nightmare on many levels, but Oracle was the majority of my drama.
Eventually, this project drove me to figure out servlets and Apache Jserv (first open source servlet engine)… which then led to myself and a couple random guys from Italy who had joined to work on JServ, to get Sun to open source Tomcat and create Java Apache (later renamed to Jakarta). If it wasn’t for all that, other Java stuff might not have happened at Apache (Hadoop, Lucene, etc).