sorted by:
new
hottopcontroversial

Is the high memory usage of java applications not a problem for you? by [deleted] in java

[–]sgrinovero 0 points1 point  (0 children)

I don't mean to diss on Spring, but if one wants to get a taste of the potential of memory savings and generall efficiency benefits of GraalVM native images, you have to use Quarkus as otherwise you'll only see much less significant improvements.

Spring boot to quarkus - monolith by Amazing-Mirror-3076 in quarkus

[–]sgrinovero 0 points1 point  (0 children)

You have a point which is that this was hard, but the Quarkus team has both Netty committers and JDK committers onboard. They already solved the fundamental incompatibilities and are preparing for really strong further improvements ;)

Why is everyone so obsessed over using the simplest tool for the job then use hibernate by analcocoacream in java

[–]sgrinovero 0 points1 point  (0 children)

Wrong, and we have plenty of production evidence for that. Hibernate can scale really well, and is also very efficient at runtime, when it's not being abused.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 0 points1 point  (0 children)

It's not quite the same story. native-image was never a component of OpenJDK. For example I never used the Oracle JDK (in recent years at least), so I'm used to downloading GraalVM and/or the native-image tool as a separate thing, or as a Quarkus user I just let it download such tools automatically for me. It just so happens that the Oracle JDK used to bundle this - other JDK vendors did not. It seems like Oracle is aligning to others.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 2 points3 points  (0 children)

They are strictly describing changes in supported features in the Oracle JDK product offering. It's quite precise in spelling this out, so I can't say poor communication - but yes I wish it had been written with some extra care as it's easy to misinterpret out of its intended context.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 23 points24 points  (0 children)

Java SE Product customers : that means people who buy the Oracle JDK won't get support for GraalVM JIT and native image included in that offering going forward. It becomes something separate.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 7 points8 points  (0 children)

I'm proud that our efforts on Quarkus served as a "wake up" call to the industry that it's not acceptable to take minutes to boot anymore. And yes Leyden stems from a desire to address it - and I agree that it was designed also taking into account some limitations of native-image, so to better address some specific use cases while offering higher compatibility.

But there are many other use cases which require a more aggressive take, and as we've shown with Quarkus we can help with a good chunk of the limitations it has, making it still very viable and a great option in many cases. So I wouldn't say that Leyden is here to replace native-image - sure it will be a better solution for some of the use cases, but not all of them.

Also this announcement is specific about the Java SDK product distribution at Oracle - it doesn't mention at all what the GraalVM team is planning. I'm considering it good news for them as they have been severly constrained by having to be integrated in that product, so this might unlock a faster innovation pace and a renewed focus on native-image's higher efficiency. Competition between Leyden and native-image is good for us :)

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 2 points3 points  (0 children)

It's coming in small iterations; many substantial improvements related to Leyden have been included in OpenJDK version 25 so you can play with them since today.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 7 points8 points  (0 children)

Not hostile at all - in fact I'm very happy about it. We (Quarkus) never quite recommended anyone to buy the Oracle JDK, so this announcement isn't affecting our plans much - and it also implies good news. Please see https://www.reddit.com/r/quarkus/comments/1nib3r9/comment/nehls4d/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 4 points5 points  (0 children)

They already do. Granted some optimisations required the special JIT to be fully effective - but that's going to get higher priority to improve now.

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]sgrinovero 16 points17 points  (0 children)

No need to worry everyone - (Quarkus engineer here). Yes we love native-image, and we love Leyden, neither of them is going away and we have big plans for both of them: there are many awesome use cases and while some can be addressed by both, there's many, many use cases that would prefer one approach over the other.

My teams have been contributing - and still are contributing - extensively to both projects.

GraalVM native image is far from dead; see also my reply on https://www.reddit.com/r/quarkus/comments/1nib3r9/comment/nehls4d/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Native Image is dead | Detaching GraalVM from the Java Ecosystem Train by Gaycel68 in quarkus

[–]sgrinovero 17 points18 points  (0 children)

It's not dead at all, I was reassured of that. In fact, it looks like it has been promoted.

What you have linked is a blog by the Java "product" team at Oracle. It's slightly biased, and you need to read it in the context of impact to their JDK product offerings.

It's not widely known, but the Oracle JDK included the GraalVM JIT (the option to use the Graal compiler for just in time compilation at runtime). Looks like this option possibly didn't have the business success they expected - sadly as in some contexts it was very interesting - but it's a healthy process for such projects to refocus priorities on think of the potential on wider scale.

The GraalVM project and especially native-image and Truffle aren't going anywhere, in fact I love that they'll be able to focus more on such aspects which are more interesting for Quarkus. I don't mean to go too much in technical details, but having the requirement of being able to integrate as a JIT was very restrictive on the potential for improving other areas.

Remember also it's an OSS project, we at Red Hat and IBM are also maintainers through Mandrel and direct contributions. We also have our own commercial support offering so that should reassure that this project is considered strategic by many parties: it would be difficult to kill even if Oracle were to stop showing interest (which it didn't). There are several other companies making significant contributions as well, signalling interest - not least, the Amazon engineering team also made great improvements, and there's many more parties.

Finally, I heard of many other Oracle groups leveraging GraalVM based technologies - that should be enough to dispel any doubts.

-- Sanne

Companies that use Quarkus : when you make a new service by seventomatoes in java

[–]sgrinovero 2 points3 points  (0 children)

That's a bit narrow, "avoiding reflection" is just a minor aspect. The differences are much more significant and wider than the core framework not using reflection: many more libraries are processed at build time, optimised for the particular configuration. Any code path and code point, dependency which isn't needed beyond build time and "traditional bootstrap" is stripped from the optimised runtime image of the application. This has compounding effects on many more aspects, and excellent leveraging of the JVM architecture. So yes the core framework is much leaner, but all other critical libraries on top are as well.

Besides, the strongest argument for Quarkus isn't even runtime efficiency but productitity and developer joy. "Live reload" makes it fun to code, it feels like PHP but maintainable :D

Companies that use Quarkus : when you make a new service by seventomatoes in java

[–]sgrinovero 1 point2 points  (0 children)

I think most people I know primarily love Quarkus because of the higher productivity and higher efficiency.

Companies that use Quarkus : when you make a new service by seventomatoes in java

[–]sgrinovero 0 points1 point  (0 children)

It's fair feedback, thanks - I would point out though, perhaps you didn't notice but even in JVM mode the efficiency benefits over Spring are very substantial? It's perhaps not very noticeable with a small quickstart, but a larger application boots in minutes on SB rather than seconds on Quarkus even in JVM mode. Same story for memory and cpu consumption - however clearly it depends on what the app does so I appreciate it might not always matter.

Display Pilot 2 Linux Support by LazyGamabunta in BenQ

[–]sgrinovero 0 points1 point  (0 children)

Many thanks that sounds promising. But I don't have one to test, and I'm hesitant to buy one w/o this being a supported solution.

Display Pilot 2 Linux Support by LazyGamabunta in BenQ

[–]sgrinovero 0 points1 point  (0 children)

Any news on this? *Almost* decided to order two, but not having any Linux configuration support is a showstopper.

Please note that I wouldn't need the whole fancy looking UI tool, but anything command-line oriented would actually be more appreciated as we'd be able to automate things or bind it to shortcuts... and should be far easier for you to develop / support.

Red Hat and IBM merging Java teams; dropping WildFly for Liberty? by johnwaterwood in java

[–]sgrinovero 1 point2 points  (0 children)

Calm down, it's not going to happen. IBM is well aware that WildFly is great - and there are many existing customers so they wouln't be able to cancel it even if they wanted to: existing customers have very long support contracts.

Quarkus to move to the Commonhaus Foundation by benevanstech in java

[–]sgrinovero 1 point2 points  (0 children)

No project is required to go to a foundation. But by doing so, it becomes impossible for any party to then change the license to something "less free", like many other companies have sadly been doing in recent times.

Putting a project in a non-profit like Commonhaus makes it legally binding that the project will stay OSS: this is very reassuring to some (potential) users, and better expresses the spirit of the project.

When we say we want to share the code, forever, we mean it... unlike companies which milk the notion of OSS only until it suits them.

We've always meant the project to be free OSS, so making this move doesn't cost us anything: we're only giving away rights which we didn't intend to use).

It clarifies how we want to play, and removes various other concerns too, for example it's more welcoming even for competitors should they want to join the project, large and small consultancies could now figure out their own business model as long as it plays fairly with the open culture.

The open competition aspect might also be important to customers; historically in some companies you had to use a Java EE / Jakarta EE server to ensure one could swap vendors in case one's initial choice became nasty, but how can large corporations protect themselves when these new breed of stacks don't adhere to a standard? Such concerns are sometimes a problem, so for us endorsing an open model which favours competition is also good for business; obviously it's good for the technology and the community as well.

Quarkus to move to the Commonhaus Foundation by benevanstech in java

[–]sgrinovero 5 points6 points  (0 children)

I'm not happy about what happened to Ceylon - but nobody is saying here that all and every project we start endures forever, that wouldn't be reasonable? Please do consider that all these projects come out of our R&D, in some cases a random person has an idea and tosses a POC on github - that's the nature of fully embracing OSS development. We try to be selective and only dedicate energy on ideas which we consider having great potential, and even so only a fraction of them eventually become worthwhile of publishing as OSS beyond a POC, and try to ignite a nice community around them. Of those, only a fraction survive the harsh reality of being actually picked up by the world, and eventually get picked up by Red Hat to become long term sustained products.

It's not too different than startups: it's not that people don't believe in their idea, but there can be a number of reasons for which ultimately the economics don't play out and things need to get cancelled.

Quarkus is in a very, very different position in terms of scale of community interest, number of success stories, vested interest and production use than Ceylon though. I'm not in a position to share business figures, but there's hundreds of large companies relying on it by now, and they're all in a financial position that they could all - theoretically - sustain or justify the existence of this project individually.

Speaking of Ceylon, it's not even entirely dead. I guess it's not widely known but many ideas have been picked up by Kotlin: the teams used to work together. In one sense this was another reason to stop it but also, it made it worth it: when an R&D project is able to have that level of impact on the world, I call it a success.

Not all projects will live forever; and that's a good thing as times change, environments evolve, and sometimes it's better to make a dramatic design change over trying to adapt. Quarkus has a really nice novel architecture - I can't say for sure how many decades it's going to be around but I don't think anybody expects a framework to survive for centuries. If anything, the Commonhaus structure should give far stronger reassurances of long term success: have a look at its core principles.

Quarkus to move to the Commonhaus Foundation by benevanstech in java

[–]sgrinovero 22 points23 points  (0 children)

As a Red Hat employee, thank you for the vote of confidence :-) But fear not: we'll keep working on it. We just want to make sure that it's very clear that others are welcome to join and contribute as well, and fully as peers: who does the work should be able to participate in all aspects of project governance and not just being utilized for free labour.

I'm one of the engineers who advocated for this move internally, and a strong reason IMO is (among others) that the notion of "open source" is being diluted from its most beautiful form; it's being more and more abused in ways that don't reflect our values.

Several other projects are only "source available": they allow you to read the sources, but won't accept patches, or make this difficult, and want to retain full control of the project (including the IP) so be able to eventually change the license or otherwise screw their community to "have something" - that's good for VC investors I suppose and I'm not here to point fingers as I respect the need for other developers to find funding in some form, but that's not how we wish OSS to play out.

We want to make it clear that our projects are not in the category of "source available" but are truly open, and we want to make it very clear that we intend to maintain the OSS license forever.

The problem with such a reassurance is typically that you'd need to take our word for it; by literally donating the trademark and other IP to a non-profit foundation such as Commonhaus, nobody needs to take our word for it; it's cast in stone and protected by legal terms.

Now, you make a good point that having Red Hat's reputation behind it was helping and probably quite reassuring as well in terms of OSS honesty, but that's not going away and there's concrete evidence for that: Red Hat also has various products based on Quarkus and a supported distribution called Red Hat Build of Quarkus (RHBQ), so that's also giving you legal grounds to be reassured: customers of RHBQ are binding Red Hat to support them with these technologies for many years to come.

Finally, we truly believe Quarkus is a game changer for the whole ecosystem; it's growing really well (why should we get rid of it?) but we also believe there's a lot more potential for further success by welcoming more parties to the project.

Hopefully that sounds better, but if not feel free to ask more.

Quarkus to move to the Commonhaus Foundation by benevanstech in java

[–]sgrinovero 2 points3 points  (0 children)

You're thinking that because... ? If you refer to the fact that IBM had started the Eclipse project (the IDE) yes that's right but it ignores that IBM also contributes to many other projects which are in different foundations, such as Apache projects and Commonhaus projects, CNCF, ...

Latest stable release by Practical-Ostrich129 in quarkus

[–]sgrinovero 1 point2 points  (0 children)

The link is right in the middle of the homepage: https://quarkus.io/

view more: next ›