JVMCI 0.57 released

[Gilles Duboscq]

Hi David,

I think the more interesting question here is around the things you are using (e.g., `GraalFeature`) that in turn make you need to depend on JVMCI.
The reason why it's not easy to consume at the moment is that none of this (classes in `com.oracle.svm.core` and others) is API.

The only APIs available at the moment for interaction with SVM are the classes in `org.graalvm.nativeimage` which are part of the the Graal SDK.
This is available on maven as `org.graalvm.sdk:graal-sdk`.

Since you are using things from `com.oracle.svm.core.graal`, i'm guessing you didn't find the APIs you need in the SDK.
Could you describe your use-case in more detail? Maybe then we could then see if there is a way we can improve/extend the API in the SDK to fit your use-case.

  Gilles

PS: we(I) was rather hesitant to publish any of the Graal and SVM jars on maven since this gives the false impression that any of this is an API with some kind of stability while this is not the case.
The only things we try to keep stable as APIs are the Graal SDK and the Truffle API.
On the other hand, we consider all the rest (graal compiler, SVM, truffle languages implementations...) as implementation code that can happily be refactored, where things can be removed without any deprecation notice etc. Even in minor releases!

On 25/03/2019 18:28, David Lloyd wrote:
> On Mon, Mar 25, 2019 at 12:25 PM Paul Wögerer <paul.woegerer at oracle.com> wrote:
>> On 3/25/19 6:00 PM, David Lloyd wrote:
>>> The question is - which one of these artifacts actually contains the
>>> JVMCI classes?
>>
>> Hmmm ... None because JVMCI is defined within the JVMCI JDK.
>>
>> Specifically the jvmci-api is in <path to your JVMCI-enabled
>> JDK>/jre/lib/jvmci/jvmci-api.jar
> 
> Exactly.  So, if you need to build an artifact which can optionally
> consume these APIs - you can't, unless you require a JDK to be used
> with JVMCI in it, which is exactly what I wish to avoid, because it
> makes it considerably harder to contribute to the project.  Having a
> separate published version of these APIs (even stubs) would be very
> helpful in this regard.
>