[Epic] Improvements to Java Runtime avoid com.sun.*, support MANIFEST main and other runtime image optimizations

[kameshsampath]

The following are list of tasks that we need to work to improve the OW Java Action runtime:

1. 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

2. Right now we rely on the --main parameter passed to run Java Aciton, instead we can make the Loader to infer it via MANIFEST.mf Main-class or add custom attribute for OW apps

3. It would be great to have making OW Java Action use standard Java main method signature with just String[] args and 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 ??

[rabbah]

On 3, did you consider an openwhisk java FDK which provides a standard wrapper instead for local development?

[csantanapr]

What’s an FDK?

[csantanapr]

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]

Title says “performance” not all 3 items are about performance

[rabbah]

Function Development Kit - FDK is the new SDK, haven't you heard? :D

[kameshsampath]

@csantanapr - I mentioned the title as Improvements ;)

[kameshsampath]

@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]

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]

+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]

Yes they are related and we should start using epics and child’s with zenhub

[csantanapr]

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]

One zenhub board for all repos

[kameshsampath]

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.

can you please share more details not sure I got what you mean here

[csantanapr]

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]

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