search

apache / openwhisk-runtime-java

Apache OpenWhisk Runtime Java supports Apache OpenWhisk functions written in Java and other JVM-hosted languages
https://openwhisk.apache.org/
Apache License 2.0
46 stars 63 forks source link

Support .java source actions in some fashion #16

Open csantanapr opened 6 years ago

csantanapr commented 6 years ago

by @gorkem from https://github.com/apache/incubator-openwhisk-runtime-java/issues/12#issuecomment-368357302

We should add direct .java invocation to this epic too. I have it already implemented on the devtools repo. [1]. The only reason I did not PR it to here was the gson dependency. Since we are taking care of it with this one, I see no reason not to implement it. [1] https://github.com/apache/incubator-openwhisk-devtools/tree/master/java-local

by @csantanapr https://github.com/apache/incubator-openwhisk-runtime-java/issues/12#issuecomment-368473079

@gorkem I See no issue on adding .java also @rabbah do you recall why this was not done originally for Java actions and only .jar? Maybe the extra latency for compile step on /init too bad or takes longer than 1minute those would be the only two I see, put that’s a problem we have today with swift with single source file it’s convenient for dev/demo but for production is better to have a precompiled to the action Maybe it’s time again to bring discussion of init actions that will help with compiling and saving the compiled output to the action stamping with runtime image and maybe source on the action this way it only compiled when the source changes or the runtime image changes.

by @csantanapr https://github.com/apache/incubator-openwhisk-runtime-java/issues/12#issuecomment-368484016

Hum 🤔 What about simple one liner functions between sequences ? Meaning like to transform output parameters into input parameters in sequences Maybe there is a OW provider/operator that included libraries and frameworks into a custom runtime IBM including Watson sdk, COS SDK, Cloudant sdk, http client library RedHat including spring cloud framework and adapters Regular user extending a Java runtime with own libraries Someone offering a UI web based editor useful for demo to edit a java file in web editor assuming that runtime has some useful libraries installed like Jax-rs related ones to handle web actions input.

by @rabbah https://github.com/apache/incubator-openwhisk-runtime-java/issues/12#issuecomment-368486065

It’s nice to have - quick start, demo all good.

by @kameshsampath https://github.com/apache/incubator-openwhisk-runtime-java/issues/12#issuecomment-368492849

This has been my thinking last couple of days in these lines I am not sure where are storing the jars today when we say wsk action create foo foo.jar --main foo - is it as a blob in couchdb ?? As you mentioned that biggest stuff we need to resolve dependency resolution for Java - wondering we can deploy a Maven Repo Manager as part of the OW deployment, this could solve the above point as well,. Right now the biggest hurdle of Java Adoption is this as functions need to be quick

markusthoemmes commented 6 years ago

Hasn't there been a proposal by somebody to have "compiling-actions" where we an action is called on action creation and creates the binary outputs that we today "manually" create in the swift runtime for example.

Would be nice to have a principled approach here.

csantanapr commented 6 years ago

Hasn't there been a proposal by somebody to have "compiling-actions" where we an action is called on action creation and creates the binary outputs that we today "manually" create in the swift runtime for example.

Yes @markusthoemmes me and others have proposed this I think we keep referring them as "init-actions", "compiled-actions"

Yes it would be nice to have this approach here I agree 💯

gorkem commented 6 years ago

@csantanapr @markusthoemmes The current solution compiles a .java into .class in memory and loads it to VM. No real .class files are generated. The approach is suitable for single file and no dependecy actions but nothing else, unless we want to add some known Java libraries to the runtime by default.

I think "init-actions" can be suitable for an actualy maven/gradle build.