Putting generated code in my.application.generated is problematic

[kspangsege]

When code is generated 'on the fly' during compilation, it is not possible to write something like this in the application code:

import my.application.generated.*;

Because there is nothing inside a package of that name initially. If you try, you will get a compile time error.

This effectively forces you to use fully qualified names when referring to any of the generated classes:

my.application.generated.MyTable = new my.application.generated.MyTable();

Way too painful!

Changing the generator such that it no longer appends ".generated" to the package name works very well in my tests, so why don't we simply do that?

Here is my test code:

package my.application;

import com.tightdb.*;
import com.tightdb.lib.Table;

public class Test {

    @Table
    class hilbert {
        String fido;
    }

    @Table
    class banach {
        String type;
        String number;
    }

    public static void main(String[] args)
    {
        SharedGroup db = new SharedGroup("/tmp/test.tightdb");
        try {
            WriteTransaction transact = db.beginWrite();
            try {
                BanachTable banach = new BanachTable(transact);
                banach.add("John", "Doe");
                transact.commit();
            }
            catch (Throwable e) {
                transact.rollback();
                throw e;
            }
        }
        finally {
            db.close();
        }
    }
}

[bmunkholm]

Reason is that we don't wan't to pullute the src directory for the user. But it should of course also work initially.

Solutions:

1. Is it possible to place the generated file in the same package, but place them physically under another directory (like the javac -s option)?
2. Otherwise: Let's investigate "prior" art. Other tools must also generate - how do they do it?
3. If no better solution, let's put the generated files in the package directory.

[nmihajlovski]

I am not sure if I understand this problem, because I don't experience such problems in Eclipse.

If the main usage scenario is to generate the source code in the IDE, then when the model classes is written, the generated code will be imported automatically when used anywhere (e.g. with Shift+Ctrl+O). I think this is how usually the generated classes will be imported, the developers usually don't write the imports as "import my.application.generated.*;", right? :)

And as long as the IDE is the generator and the generated code is "treated" as a source code, the build tools don't have to generate it again, so those problems where the source code references temporary non-existing source code won't appear.

About the multiple source folders, Ant and the IDEs support it naturally, but things are more complicated (a bit hacky, but possible) with Maven.

The other tools use various folders, some (usually the Maven-based) use the "target/generated-sources" folder.

In my opinion, putting the files in the package directory and mixing the primary and generated sources won't help a lot, and will be more confusing for the developers.

But, as I mentioned, I am not sure if I understand this problem, am I missing something?

[kspangsege]

Hi Niko,

The main usage scenario may, or may not be through an IDE such as Eclipse. However, we should not think of it as the only usage scenario.

Generally speaking, we should seek to impose as few requirements as possible about the way our language binding is used.

It is particularly important that our language binding can be used in a "bare bones" situation where you only have the Java SDK (command line compiler) plus the required Java libraries (JAR files).

Further more, it is desirable (read, we want it to be such that) the code generator is invoked automatically from the compiler, or, stated differently, it is undesirable that it is a requirement that the code generator has to be invoked explicitly, and as an individual step, before the compilation proper.

As I write in my initial post, one consequence of this is that it is an error in general to write something like

import my.application.generated.*;

because that package may not exist at the time the compiler is invoked.

The only solution that we have been able to come up with so far, is to put the generated classes in the the same package as the annotated class.

Besides that, we also consider it an improvement if the customer did not have to write import statements for the generated classes.

The only problem is that the immediate result of such a change, is that the directory that contains the annotated class, will be "polluted" with numerous generated files. The expectation from our point of view, is that it is possible to order Eclipse to place the generated files in a separate directory (just like using the -s switch on the Javac command line)

IMPORTANT: Please go ahead and remove the ".generated" part of the package of the generated files, as well as any 'import' statement mentioning 'generated'. We need this change even if we cannot find a way to order Eclipse to place the generated files into a distinct directory. As it is now, the "bare bones" scenario simply does not work.

[kspangsege]

Looks good. It works for me.

[nmihajlovski]

Last update: now the generated sources can be put in any folder (e.g. any folder can be specified as "Generated source directory" in Eclipse - Annotation processing, or as "destdir" in the Ant build configuration, or as "outputDirectory" in Maven's pom.xml). You can check gen.xml and pom.xml in tightdb-example for more details.