[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

[csantanapr]

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

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]

Hum 🤔

1. What about composer inline functions when Java is supported. ?
   Meaning like to transform output parameters into input parameters in sequences

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

3. 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]

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]

@rabbah @csantanapr @gorkem

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.

This has been my thinking last couple of days in these lines

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

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

[csantanapr]

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

• This one [Epic] Improvements to Java Runtime avoid com.sun.*, support MANIFEST main and other runtime image optimizations #12 rename to: Improvements to Java Runtime avoud com.sun.* and support MANIFEST main
  • Covers 1,2 original comment
  • Feel free better title 🤧
• New More flexibility to parsing and passing JSON input/out in Java runtime #15 : More flexibility to parsing and passing JSON input/out in Java runtime
  • Feel free better title 🤧
• New Support .java source actions in some fashion #16 : Support .java source actions in some fashion
  • Feel free better title 🤧

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]

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 ?