New Java launcher

[mizdebsk]

Currently used %jpackage_script has many issues. It would be nice to replace it with a new launcher and corresponding RPM macro.

Some of requirements for new %java_launcher:

• it should invoke:
  • JVM directly, or
  • upstream launcher script/binary
• support for two kinds of classpaths:
  • static - generated during package build
  • dynamic - transitive, geterated during runtime
  • global classpath stored in /var, updated with file triggers
  • user-specific classpath in ~/.cache, generated on first app run, regenerated when config changes
  • classpath generation done by sub-process (Python/Java)
• ABRT integration
• SCL support
• wrapper itself written in C, file triggers can be in any language (preferably Python or Java)
• configuration:
  • simple text (key=val) or INI
  • XDG directory structure
  • inheritance:
  • global (default system settings, like jvm)
  • per-app (main class, classpath etc.)
  • per-user
  • per-user-app
  • system config read from both /usr and /etc - packages install unmodifiable config in /usr, /etc is empty by default, but files in /etc can override corresponding config files in /usr
  • config specifies:
  • JVM (alternatives are not used)
  • JVM options
  • default arguments
  • main class
  • ABRT flag
  • "stop further config processing" flag; launchers for services (eg. invoked by systemd, xinetd etc.) can ignore user-specific config by setting this flag in per-app config
• rpm macro %java_launcher
  • generates per-app config
  • installs symlink in /usr/bin pointing to launcher
  • has a sane way of supplying arguments
• logging
  • debugging output
  • warnings
• documentation for both packagers and users

[msimacek]

I can see some cons of implementing it in C:

• more problematic from packaging POV - not portable, would need rebuilds for new arches, gcc
• would be quite opaque and harder to debug for users. For example, if something doesn't work, I'm used to just open the file in vim and see, what it does. I think a lot of people might do the same, especially if they are ordinary users not familiar with packaging.
• users will lose some of the flexibility that shell provided
• we still need API for shell for applications that ship their own scripts (like maven), so we don't get rid of shell entirely

What are the pros of implementing it in C?

[msimacek]

For the configuration format: YAML is getting more and more used everywhere and should be quite intuitive even for people who don't know it. It offers more flexibility than INI - for example, one thing that is quite common with %jpackage_script is conditionalizing arguments based on env variables. IMO, this would be easier to express with YAML.

[rvais]

I will wait for some statement for msimacek's points, but I personally would like to try to implement that as a new project.

[mizdebsk]

more problematic from packaging POV - not portable, would need rebuilds for new arches, gcc

What do you mean by "not portable"? C code can definitely be portable. Why rebuilds would be a problem?

would be quite opaque and harder to debug for users. For example, if something doesn't work, I'm used to just open the file in vim and see, what it does. I think a lot of people might do the same, especially if they are ordinary users not familiar with packaging.

You could say that about any software. The launcher would be very lightweight - it would just read a few config files and call execve(). It could log what it does.

we still need API for shell for applications that ship their own scripts (like maven), so we don't get rid of shell entirely

For applications with existing shell scripts, the launcher would read config files, set JAVA_HOME and run the script. No additional shell API would be required.

What are the pros of implementing it in C?

Compared to what? Bourne shell, Bash, Python, Lua?

[mizdebsk]

What about writing initial PoC in any language (eg. bash) and then, once we know what features will be needed, consider pros and cons of rewriting it in C?

[msimacek]

What do you mean by "not portable"? C code can definitely be portable. Why rebuilds would be a problem?

I meant binary portability (for stuff like importing RPMs across arches). Rebuilds are not a problem, but it's another thing we will have to deal with.

Compared to what? Bourne shell, Bash, Python, Lua?

Shell.

What about writing initial PoC in any language (eg. bash) and then, once we know what features will be needed, consider pros and cons of rewriting it in C?

Agreed.

[mizdebsk]

Rebuilds are not a problem, but it's another thing we will have to deal with.

Why? In Fedora, these rebuilds would be done by release engineering or secondary architectures developers, package maintainers are not involved with them.

[rvais]

@mizdebsk Could you please comment here some sort of pseudo code for POC launcher as we agreed on today's meeting ? I have some notes, but just to be sure I haven't forgot anything. Thank you in advance.

[kjn]

main(argc, argv):
  app_id = strrchr(argv[0], '/') ? strrchr(argv[0], '/') + 1 : argv[0];
  setup_logging(enable_debug=getenv(JAVAPACKAGES_DEBUG) != None)
  conf = get_effective_config(app_id)
  validate_conf(conf)
  if conf.is_classpath_dynamic:
    cp = cache.get(app_id)
    if cp is None or cp.is_expired():
      cp = exec_subprocess('/path/to/generator', stdin=conf.dynamic_classpath_args).get_stdout()
      cache.put(app_id, cp)
    conf.classpath = cp
  exec_jvm(conf)

get_effective_config(app_id):
  generic_system_conf = get_single_conf('generic', XDG_CONFIG_DIRS, XDG_DATA_DIRS)
  app_system_conf = get_single_conf(app_id, XDG_CONFIG_DIRS, XDG_DATA_DIRS)
  generic_user_conf = get_single_conf('generic', XDG_CONFIG_HOME, XDG_DATA_HOME)
  app_user_conf = get_single_conf(app_id, XDG_CONFIG_HOME, XDG_DATA_HOME)
  effective_conf = {}
  for file in [generic_system_conf, app_system_conf, generic_user_conf, app_user_conf]:
    conf = read_conf(file)
    effective_conf = merge_conf(effective_conf, conf)
    if effective_conf.stop_further_processing:
      break
  return effective_conf

get_single_config(id, config_dirs, data_dirs):
  for dir in [config_dirs, data_dirs]:
    if exists(dir/java-launcher/id.conf):
      return dir/java-launcher/id.conf

[mizdebsk]

I'm not planning on implementing this any time soon. If you are interested in this feature please let me know.