Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

graalvm.org

Post reply on HN
Print view View original

121–130 of 141 posts

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#121

Post by bluejekyll »

mike_hearn wrote: post #100
bluejekyll wrote: post #98

Earlier quoted context omitted.

> If Chrome and Safari shipped GraalVM accessible via tags, how many people would care about WASM? That’s a good question, and partly why I was pointing out that it’s not just benevolence for Oracle to OSS this. I don’t know if the browsers vendors could embed Graal, maybe they can, (license restrictions being some of the issues I’m sure) and then that could supplant the individual JS and WASM runtimes they support.…

Despite the wording of the announcement, Graal and Truffle have been open source under permissive licenses for a long time now. The "donation" is from one open source project run by Oracle to another. Confusing, indeed, but Oracle is a big company. So it's been possible license-wise for a long time.

In the announcement it sounds like they are planning to change the license in some manner, “Will the GraalVM license change? The plan is to align all the GraalVM technologies with Java both from a release perspective and from a licensing perspective. Additional details will follow in the coming months as we move forward through this process.”

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#122

Post by kaba0 »

mapme wrote: post #119
w10-1 wrote: post #46

GraalVM is truly great stuff. GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software. Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility. Native support for reflection (used i…

Does graal native perform better than a non-native running with JIT compilation?

In certain cases it may, but generally the JIT compiled version will perform better on most workloads (but that can also use Graal)

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#123

Post by heretoo »

mapme wrote: post #119
w10-1 wrote: post #46

GraalVM is truly great stuff. GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software. Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility. Native support for reflection (used i…

Does graal native perform better than a non-native running with JIT compilation?

Not in the community edition, but the enterprise edition appears to be quicker than JIT because of profile guided optimisations.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#124

Post by Twirrim »

mapme wrote: post #119
w10-1 wrote: post #46

GraalVM is truly great stuff. GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software. Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility. Native support for reflection (used i…

Does graal native perform better than a non-native running with JIT compilation?

if it's "long" running, you want the full JIT experience, because you essentially lose the entire "But how does my code actually run" optimisations that the JIT can do, and only have stuff that can be done ahead of time.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#125

Post by GoOnThenDoTell »

dtech wrote: post #89
mike_hearn wrote: post #62

Earlier quoted context omitted.

There isn't any way to spin it negatively. The generalized dislike of Oracle you have seen really comes from a couple of different aspects, neither of which are relevant to this specific announcement: 1. License audits suck. 2. The Google lawsuit (about matters resolved long ago and which don't apply to anyone except Google, really). A lot of ill will comes from people whose companies have been audited. The process i…

I feel like this is a bit too generous to Oracle. The DRM-free thing is indeed a feature, but they know full well that it will encourage more and more unlicensed usage which they can then "extort" additional fees out of a company once it's in place and critical, which they would probably never have gotten if beforehand a trade-off check would've been done for operational expenses or the right gates would've been need…

Who is downloading oracle and using it on a whim? Surely postgres or mysql would be the path

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#126

Post by commandar »

mike_hearn wrote: post #62
nvrspyx wrote: post #47

Earlier quoted context omitted.

I know absolutely nothing about Oracle, GraalVM, OpenJDK, or Java development in general. I haven't used Java since a CS intro class during my undergrad like 10 years ago. Despite this, I've internally adopted the general consensus that Oracle is a terrible, greedy company. Can someone play devil's advocate to explain how this news may actually favor this negative view of Oracle? The sentiment in this thread is prais…

There isn't any way to spin it negatively. The generalized dislike of Oracle you have seen really comes from a couple of different aspects, neither of which are relevant to this specific announcement: 1. License audits suck. 2. The Google lawsuit (about matters resolved long ago and which don't apply to anyone except Google, really). A lot of ill will comes from people whose companies have been audited. The process i…

I'm not worried about or bothered by audits. We put a lot of effort into license compliance and performing regular true ups with our vendors is the norm.

A large part of Oracle's bad reputation comes from a history of entering markets, gaining a captive customer base, and then engaging in blatant rent-seeking that squeezes every last penny that they can out of their customers.

As a direct example, I'm in the healthcare space and specifically work in a Cerner shop. Our quotes from Cerner for routine integration projects have gone up literally 5-10x since Oracle acquired them. An EHR migration costs well into eight figures, so Oracle is fully aware that customers aren't easily going to be able to move away from them because things that were $15-30K (and still are with other vendors) are now running into the six figures, but it certainly doesn't leave a positive taste in the mouth.

And we knew this was coming as soon as the Oracle acquisition was announced. Because Oracle has built a reputation for doing exactly this across multiple markets over multiple decades.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#127

Post by origin_path »

bluejekyll wrote: post #121
mike_hearn wrote: post #100

Earlier quoted context omitted.

Despite the wording of the announcement, Graal and Truffle have been open source under permissive licenses for a long time now. The "donation" is from one open source project run by Oracle to another. Confusing, indeed, but Oracle is a big company. So it's been possible license-wise for a long time.

In the announcement it sounds like they are planning to change the license in some manner, “Will the GraalVM license change? The plan is to align all the GraalVM technologies with Java both from a release perspective and from a licensing perspective. Additional details will follow in the coming months as we move forward through this process.”

They're both open source licenses just slightly different ones (gpl2+CPE and upl I guess). Sun liked to use odd licenses.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#128

Post by mike_hearn »

GoOnThenDoTell wrote: post #125
dtech wrote: post #89

Earlier quoted context omitted.

I feel like this is a bit too generous to Oracle. The DRM-free thing is indeed a feature, but they know full well that it will encourage more and more unlicensed usage which they can then "extort" additional fees out of a company once it's in place and critical, which they would probably never have gotten if beforehand a trade-off check would've been done for operational expenses or the right gates would've been need…

Who is downloading oracle and using it on a whim? Surely postgres or mysql would be the path

It's more like your company already uses it, so people just copy the binaries from one server to another and start it up. Oracle DB has massively more features than postgres or mysql so there are good reasons to use it.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#129

Post by bionsystem »

mike_hearn wrote: post #96
dtech wrote: post #89

Earlier quoted context omitted.

I feel like this is a bit too generous to Oracle. The DRM-free thing is indeed a feature, but they know full well that it will encourage more and more unlicensed usage which they can then "extort" additional fees out of a company once it's in place and critical, which they would probably never have gotten if beforehand a trade-off check would've been done for operational expenses or the right gates would've been need…

My point is this: what alternative would you prefer? Oracle can't implement trade-off checks or process gates inside other companies.

Alternative : open source it and charge for support.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#130

Post by quelltext »

chrisseaton wrote: post #40
quelltext wrote: post #39

Earlier quoted context omitted.

Digging through that code might be a bit challenging. Do you happen to have a link to a paper/documentation on this? Or maybe some rough explanation how it works (that goes beyond the short summary you provided) Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a sit…

Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference. But you might find this interesting as a specific example - this is where it actually obtains memory from the OS. https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use withi…

I think that's the piece that got me and grand-GP maybe confused.

You are writing a GC in Java, yes but have access to low-level memory abstractions/interfaces, right?

Whereas I was initially wondering how to write a GC in "pure Java" that doesn't have access to low-level memory interfaces.

Does it make sense why I was asking, now? Or am I still not getting it?

To be clear, Java the language is Java, I'm not going to argue that it's not Java because of special primitives / interfaces available to write the GC here, but it is not what most people would think of when considering the limitations of the runtime everyone's using.

Post reply on HN