Jigsaw

Jigsaw is a code name for a project that implements module system for Java and NetBeans were asked to be its first supporters. The NetBeans IDE would like to be the ultimate UI for developing projects using Jigsaw.

NetBeans IDE has a long tradition of reusing command lines tools internally to guarantee the result of internal processing is 100% same as in case of doing a headless build. This is not something people are used to when using other editors or IDEs, but it is something NetBeans IDE is proud of. It is part of NetBeans identity. We want to keep this approach when supporting Jigsaw.

In the light of the above identity vision, it is essential to properly understand the command line tools that Jigsaw offers and their intended orchestration when supporting key software development use-cases. List of them is discussed below...

Contents

Ultimate Information about Sources

Prior to Jigsaw the set of Java sources on disk could not be processed without external information. Without knowing the classpath, encoding, source level and (possibly) set of annotation processors.

Jigsaw attempts to fix the classpath problem. There is a meta file describing classpath next to the sources. However that is not enough, tools desperatelly need encoding as Jesse explained (here and here). The reply was strict no!. That is a perfect reply from a rationalistic point of view of a maintainer of the language specification. However looking at the problem with empirical real world experience, one can realize that 99% of Java projects don't use UTF-16, rather something else! Tools just need a standard way to find such information about Java sources on disk.

Before Jigsaw the JavaC was uncapable to process sources without additional command line parameters. Jigsaw's classpath specification is progress towards the right direction, but unless the information about the sources are sufficient (as proposed at JavacOptionsInSourceFiles), tools will still have to resolve to additional source of information provided by other wide spread standard.

Handling Resources

Each jmod will contain not only Java sources, but also other resources like .png, .properties, etc. How easy it is to convert this into jmod?

$ javac sourcedir -d moduledir
$ jpkg -r resourcedir -m moduledir jmod modulename

Looks like the Jigsaw team thinks that the sources should be in different directory than resources.

Central Repositories

Q: How will the module-info.java indicate which network repositories to use?

Answer: ModuleInfo does not point to remote repositories. However local repository can have references to remote ones use jmod add-repo. The module resolver does use external repositories during installation. Compiling with javac on the other hand doesn't result in downloading.

From Source to Native Package

Download sources ready for Jigsaw. Locate root folder with module-info.java. Open the project up. NetBeans IDE resolves the dependencies and downloads necessary module libraries in the right version from the central repository. All sources seem to be without any errors. Choose build distribution action. All sources are compiled, packaged into jmod modules and appripriate .rpm, .deb and something for windows is generated.

Question: Is this the right approach? What API from JDK 8 would be used to achieve the same from command line?

Answer: There is no single command to handle this. The typical steps will be:

  1. compile module with javac
  2. use jpkg to package it into a jmod or native package or maybe a JAR file.

Sources with Native Code

I have a desire to develop module that will contain some JNI code written in C++. How should I structure my Java and C++ sources? What tools to use to produce the final jmod module?

Answer: Jigsaw doesn't impose any structure on the native code. The jpkg command has an option to specify the location of any native libraries to include in the jmod package.

External Tools

Sometimes, source code or resources are generated by third-party tools during. For example, antlr may generate a parser for the given grammar. Although the third-party tool might sometimes be invoked from an annotation processor, it is not an option for antlr to jlahoda's knowledge.

Answer: External tools (unless invoked by annotation processor) are not supported in any of OpenJDK tools.

Javadoc

Projects that create publicly available libraries need to also generate javadoc for the library's APIs. How exactly is this to be handled?

Answer: Not rewritten to work with modules yet.

JUnit testing

In most places unit testing is part of the development process via special tasks run by automated continuous build systems. The testing metadata are often part of project configuration and more specifically the build scripts contain fragments related to testing. If we are providing end to end solution for the build process the unit tests invocation (and reporting) must be handled somehow.

Answer: No answer to the structure of the project. No simple way to execute tests. A comment about harnesses: test harnesses is that they will need to updated to run tests in module mode. The test runner should essentially be a container.

OpenJDK Jigsaw Projects

The NetBeans IDE should be able to open OpenJDK sources. They will be converted to Jigsaw format before release. They may actually be the only sources available in Jigsaw format at the time of release JDK8. Consuming them in the IDE will demonstrate the JDK8 build system is ready to support tooling from the IDE.

Questions: How the OpenJDK sources will be organized?

Generate Skeleton

Q: Will it be possible to generate an application skeleton?

Answer Not with the Jigsaw tools. The won't predefine any module-info.java templates.

Extensibility by Obscurity

As the argumentation in the encoding and source level case shows. The Jigsaw design is overly minimalistic and tons of important information is left for others to specify. The need for extensibility leads to obscure situations when one can after append any text after module declaration without giving it any meaning! Is this an attempt to build new Tower of Babel?

Needless to mention that this is a nightmare for tools.

More to Come...

TBD

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo