Repository navigation
[Epic] Improvements to Java Runtime avoid com.sun.*, support MANIFEST main and other runtime image optimizations #12
Description
The following are list of tasks that we need to work to improve the OW Java Action runtime:
-
avoid usage of com.sun.* packages - this is used in https://github.com/apache/incubator-openwhisk-runtime-java/blob/master/core/javaAction/proxy/src/main/java/openwhisk/java/action/Proxy.java, instead we can use readily available pre-built httpservers e.g. using vert.x is one of the options for high performance
-
Right now we rely on the
--mainparameter passed to run Java Aciton, instead we can make the Loader to infer it viaMANIFEST.mfMain-class or add custom attribute for OW apps -
It would be great to have making OW Java Action use standard Java main method signature with just
String[] argsand we define custom Launcher that convert the args to JSON and delegate to OW Java Function Launcher, this way it will be easy for applications to be built and tested outside before testing in OW
Edited by @csantanapr 3 is now a new issue: More flexibility to parsing and passing JSON input/out in Java runtime #15
@csantanapr @ddragosd @gorkem - thoughts comments and feedback ??
Activity
rabbah commentedon Feb 25, 2018
On 3, did you consider an openwhisk java FDK which provides a standard wrapper instead for local development?
csantanapr commentedon Feb 25, 2018
What’s an FDK?
csantanapr commentedon Feb 25, 2018
On 3 we are thinking on doing the same for Swift to handle the epilogue cc @jthomas
User will just “import OpenWhisk” and write one of the signature main function with “main” name or given name and with argument type matching the wrapper code will know how to call it
csantanapr commentedon Feb 25, 2018
Title says “performance” not all 3 items are about performance
rabbah commentedon Feb 25, 2018
Function Development Kit - FDK is the new SDK, haven't you heard? :D
kameshsampath commentedon Feb 25, 2018
@csantanapr - I mentioned the title as
Improvements;)kameshsampath commentedon Feb 25, 2018
@csantanapr and @rabbah - I just thought to file these things across about points I thought on Java Action before I forget - please feel free to let me know if you need them to split it up or wish me to do?
csantanapr commentedon Feb 25, 2018
My bad I read performance, It must be my dislexia :-) or just brain fart
I have being workin with someone to improve Java runtime with jvm optimization flags and openj9
rabbah commentedon Feb 25, 2018
+1 for all three improvements: faster stratup is a win, and main in the manifest makes sense. My immediate concern was with your third point but think an FDK can facilitate local development and testing without changing the underlying model for functions.
@csantanapr should we link this to zenhub and track issues and epics accordingly?
csantanapr commentedon Feb 25, 2018
Yes they are related and we should start using epics and child’s with zenhub
csantanapr commentedon Feb 25, 2018
We should link all the runtime repos to main core repo, I will check if we still have the correct permissions now that we are under Apache Github org
csantanapr commentedon Feb 25, 2018
One zenhub board for all repos
kameshsampath commentedon Feb 25, 2018
can you please share more details not sure I got what you mean here
csantanapr commentedon Feb 25, 2018
Keep the abstractions to developer so they can write functions with a stable api and it doesn’t matter if the run the function locally outside whisk or they run it in a whisk container
gorkem commentedon Feb 25, 2018
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
csantanapr commentedon Feb 26, 2018
@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.
rabbah commentedon Feb 26, 2018
What’s the likelihood of writing a function is Java, with no extrnal libs? Supporting the use case is nice for parity and quick start but I’d suspect if you’re doing anything serious with functions and Java you’ll have libs and need a jar file.
csantanapr commentedon Feb 26, 2018
Hum 🤔
What about composer inline functions when Java is supported. ?
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.
rabbah commentedon Feb 26, 2018
It’s nice to have - quick start, demo all good.
For composer it’s more nuanced. The library is js based today and it’s far more work getting java syntax embedded vs using a composer library entirely in Java. I suggest taking that off the table as a use case where 2 & 3 are more viable.
kameshsampath commentedon Feb 26, 2018
@rabbah @csantanapr @gorkem
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
[-][Epic] Improvements to Java Runtime[/-][+][Epic] Improvements to Java Runtime avoud com.sun.* and support MANIFEST main[/+]csantanapr commentedon Feb 26, 2018
Hey @kameshsampath @gorkem @rabbah
I enable zenhub and pulled this repo up to core/main repo, tell me if you have issues loading zenhub (chrome plugin) here:
https://github.com/apache/incubator-openwhisk/issues#boards?repos=104973620
I tried my best to split this issue in 3 Epics and copied over discussion to new issues
Let me know how this looks, and any adjustments you can to see and can't do because of write access.
I hope you guys continue with these great contributions and can propose/nominate you for committer bits 🎉
kameshsampath commentedon Feb 27, 2018
guys,
my first target for this EPIC would be to rebase the OpenWhisk Java runtime with https://hub.docker.com/r/fabric8/java-jboss-openjdk8-jdk/ as this will solve two issues #5 and we aligning to openjdk for all community bits.
@csantanapr can you please add this #18 to the Epic ?
[-][Epic] Improvements to Java Runtime avoud com.sun.* and support MANIFEST main[/-][+][Epic] Improvements to Java Runtime avoid com.sun.*, support MANIFEST main and other runtime image optimizations[/+]