3 ms·

One might argue that Oracle also made this model work. Not sure about their revenue between different divisions, but they finished open-sourcing even the last

by kaba0 4y ago

One might argue that Oracle also made this model work. Not sure about their revenue between different divisions, but they finished open-sourcing even the last proprietary part of their JDK, making OpenJDK the reference implementation, plus they finance 90+% of all its commits. They make some revenue from selling OracleJDK licenses (and even most of those are free if you stay on the latest version) which includes support. Many of their customers are on older Java versions though, for example their Java 8 support is valid for something like 2030, so mostly government, big enterprises. (For some reason though, there is just endless bullshit around Java, even though the exact same model/license is true for the Linux kernel)

pjmlp 4y ago
The funny thing about Oracle haters is how they ignore that Oracle and IBM stand by Java since the early days, they collaborated with Sun on the Network Computer project, were one of the first SQL vendors to include the JRE on the database engine, provide a GUI based on Swing, JSF framework, JVM implementation, IDE, and so on. They also ignore the fact that Sun also charged money for support, JDK was only available as free beer with source on request, the whole Apache drama with the TCK, and access to legacy versions required a Sun developer account with license. Or that they were the ones introducing the separation of having UNIX for users, and an additional license for an UNIX SDK, which is what made people rush to improve GCC, until then mostly ignored project.
- Kwpolska 4y ago
  I think that most Oracle haters hate them for their obscenely expensive and often idiosyncratic database product, as well as their legal division being larger than their engineering division. And speaking of databases, the idea of running custom Java code inside the database seems like an abuse of the database. How many people actually use this feature, and how many of them like it (as opposed to having made a bad technical decision 20 years ago)?
  - pjmlp 4y ago
    Plenty, this is no different from running C and Perl, which Oracle did before, what PostgreSQL allows for (which Rust stable support being cheered over here last week), or running .NET on SQL Server. When performance matters, stored procedures are the way to go, not wasting network traffic and CPU cycles on the client, As it so happens, these additional runtimes are great and safer way to extend PL/SQL, pg/SQL, T-SQL,... than writing C extensions.
    - KronisLV 4y ago
      > When performance matters, stored procedures are the way to go, not wasting network traffic and CPU cycles on the client, As it so happens, these additional runtimes are great and safer way to extend PL/SQL, pg/SQL, T-SQL,... than writing C extensions. While I agree in principle, in practice to me it feels like the tooling just isn't there. Testing and debugging is a bit more difficult than with other languages (e.g. even using breakpoints and stepping through code), things like logging typically don't have pleasant implementations (e.g. log shipping), the discoverability and even version control of the code also tend to be worse, among other things. That's even before you get into building around the particular runtime that you're provided with, trying to get a grip on dependency/package management, automated CI deploys, rollbacks, monitoring/health checks, local development environments and so on. My experiences might be the opposite of some folks, but I recall working on a system where most of the logic was implemented in the database packages and something like Java was used just as a glorified templating solution to serve a webapp. The performance was great, but actually working with the codebase was an utter nightmare, so it's not worth it in my opinion. That's like choosing to write a webapp in Assembly just because it's faster. For example, look at the JetBrains survey, where they asked some questions about databases: https://www.jetbrains.com/lp/devecosystem-2021/databases/ https://www.jetbrains.com/lp/devecosystem-2021/databases/ Do you debug stored procedures? 47% Never 44% Rarely 9% Frequently Do you have tests in your database? 70% No 15% I don't know 14% Yes Do you keep your database scripts in a version control system? 54% Yes 37% No 9% I don't know Do you write comments for the database objects? 49% No 27% Yes, for many types of objects 24% Yes, only for tables If half the people don't debug their code, three quarters don't test their code, almost half don't use version control and about half don't bother writing comments of any sort, that's the kind of code that I don't want to be working with and would advise others against going for that approach. While we can talk about the fact that these things can be done, the fact that they're not, is evidence enough that the community just isn't there yet. Use databases for what they're good at (including some in-database processing, like reporting), but don't try to do everything in them.

by kaba0 4y ago

pjmlp 4y ago

The funny thing about Oracle haters is how they ignore that Oracle and IBM stand by Java since the early days, they collaborated with Sun on the Network Computer project, were one of the first SQL vendors to include the JRE on the database engine, provide a GUI based on Swing, JSF framework, JVM implementation, IDE, and so on. They also ignore the fact that Sun also charged money for support, JDK was only available as free beer with source on request, the whole Apache drama with the TCK, and access to legacy versions required a Sun developer account with license. Or that they were the ones introducing the separation of having UNIX for users, and an additional license for an UNIX SDK, which is what made people rush to improve GCC, until then mostly ignored project.

Kwpolska 4y ago
I think that most Oracle haters hate them for their obscenely expensive and often idiosyncratic database product, as well as their legal division being larger than their engineering division. And speaking of databases, the idea of running custom Java code inside the database seems like an abuse of the database. How many people actually use this feature, and how many of them like it (as opposed to having made a bad technical decision 20 years ago)?
- pjmlp 4y ago
  Plenty, this is no different from running C and Perl, which Oracle did before, what PostgreSQL allows for (which Rust stable support being cheered over here last week), or running .NET on SQL Server. When performance matters, stored procedures are the way to go, not wasting network traffic and CPU cycles on the client, As it so happens, these additional runtimes are great and safer way to extend PL/SQL, pg/SQL, T-SQL,... than writing C extensions.
  - KronisLV 4y ago
    > When performance matters, stored procedures are the way to go, not wasting network traffic and CPU cycles on the client, As it so happens, these additional runtimes are great and safer way to extend PL/SQL, pg/SQL, T-SQL,... than writing C extensions. While I agree in principle, in practice to me it feels like the tooling just isn't there. Testing and debugging is a bit more difficult than with other languages (e.g. even using breakpoints and stepping through code), things like logging typically don't have pleasant implementations (e.g. log shipping), the discoverability and even version control of the code also tend to be worse, among other things. That's even before you get into building around the particular runtime that you're provided with, trying to get a grip on dependency/package management, automated CI deploys, rollbacks, monitoring/health checks, local development environments and so on. My experiences might be the opposite of some folks, but I recall working on a system where most of the logic was implemented in the database packages and something like Java was used just as a glorified templating solution to serve a webapp. The performance was great, but actually working with the codebase was an utter nightmare, so it's not worth it in my opinion. That's like choosing to write a webapp in Assembly just because it's faster. For example, look at the JetBrains survey, where they asked some questions about databases: https://www.jetbrains.com/lp/devecosystem-2021/databases/ https://www.jetbrains.com/lp/devecosystem-2021/databases/ Do you debug stored procedures? 47% Never 44% Rarely 9% Frequently Do you have tests in your database? 70% No 15% I don't know 14% Yes Do you keep your database scripts in a version control system? 54% Yes 37% No 9% I don't know Do you write comments for the database objects? 49% No 27% Yes, for many types of objects 24% Yes, only for tables If half the people don't debug their code, three quarters don't test their code, almost half don't use version control and about half don't bother writing comments of any sort, that's the kind of code that I don't want to be working with and would advise others against going for that approach. While we can talk about the fact that these things can be done, the fact that they're not, is evidence enough that the community just isn't there yet. Use databases for what they're good at (including some in-database processing, like reporting), but don't try to do everything in them.