JHipster Domain Language (JDL)

The JDL is a JHipster specific domain language where we have added the possibility to describe all your entities and their relationships in a single file (or more than one) with a simple and user-friendly syntax.

You can use our online JDL-Studio IDE to create JDL and its UML visualization. You can create and export or share the URL of your JDL model as well.

Once you have a generated project (either existing one or generated with jhipster command line), you can generate entities from a JDL file using the import-jdl sub-generator, by running jhipster import-jdl your-jdl-file.jh (make sure to execute this command under your JHipster project). You can also generate entities and export them as a JDL file using JHipster UML, by running jhipster-uml your-xmi-file.xmi --to-jdl from the root of the generated JHipster application. To learn more about JHipster UML, and install it, go to the JHipster UML documentation.

This can be used as a replacement to using the entity sub-generator. The idea is that it is much easier to manage relationships using a visual tool than with the classical Yeoman questions and answers.

The JDL project is available on GitHub, it is an Open Source project like JHipster (Apache 2.0 License). It can also be used as a node library to do JDL parsing.

If you like the JHipster Domain Language, don’t forget to give the project a star on GitHub!If you like the JDL Studio don’t forget to give the project a star on GitHub!

If you work in a team, perhaps you would like to have multiple files instead of one. We added this option so that you don’t manually
concatenate all the files into one, you just have to run jhipster import-jdl my_file1.jh my_file2.jh or jhipster-uml my_file1.jh my_file2.jh.

If you do not want to regenerate your entities, while importing a JDL, you can use the --json-only flag to skip entity creation part and create only the json files in .jhipster folder.

jhipster import-jdl ./my-jdl-file.jdl --json-only

By default import-jdl regenerates only entities which have changed, if you want all your entities to be regenerated then pass in the --force flag. Please note that this will overwrite all your local changes to the entity files

jhipster import-jdl ./my-jdl-file.jdl --force

If you want to use it in your project, you can add do so by doing npm install jhipster-core --save to install it locally, and save it in your package.json file.

The language

We tried to keep the syntax as friendly as we can for developers.
You can do three things with it:

Declare entities with their attributes,

Declare the relationships between them,

And declare some JHipster specific options.

Entity declaration

The entity declaration is done as follows:

entity <entity name> {
<field name> <type> [<validation>*]
}

<entity name> is the name of the entity,

<field name> the name of one field of the entity,

<type> the JHipster supported type of the field,

and as an option <validation> the validations for the field.

The possible types and validations are those described here, if the validation requires a value, simply add (<value>) right after the name of the validation.

Blob (byte[])

JHipster gives a great choice as one can choose between an image type or any binary type. JDL lets you do the same: just create a custom type (see DataType) with the editor, name it according to these conventions:

AnyBlob or just Blob to create a field of the “any” binary type;

ImageBlob to create a field meant to be an image.

TextBlob to create a field for a CLOB (long text).

And you can create as many DataTypes as you like.

Option declaration

In JHipster, you can specify options for your entities such as pagination or DTO.
You can do the same with the JDL:

entity A {
name String required
}
entity B {}
entity C {}
dto A, B with mapstruct
paginate A with infinite-scroll
paginate B with pagination
paginate C with pager // pager is only available in AngularJS
service A with serviceClass
service C with serviceImpl

The keywords dto, paginate, service and with were added to the grammar to support these changes.
If a wrong option is specified, JDL will inform you of that with a nice, red message and will just ignore it so as not to corrupt JHipster’s JSON files.

Service option

No services specified will create a resource class which will call the repository interface directly. This is the default and simplest option, see A.
Service with serviceClass (see B) will make the resource call the service class which will call the repository interface. Service with serviceImpl (see C) will make a service interface which will be used by the resource class. The interface is implemented by an impl class which will call the repository interface.

Use no service if not sure it’s the simplest option and good for CRUD. Use service with a Class if you will have a lot of business logic which will use multiple repositories making it ideal for a service class. Jhipster’s are not a fan of unnecessary Interfaces but if you like them go for service with impl.

entity A {}
entity B {}
entity C {}
// no service for A
service B with serviceClass
service C with serviceImpl

JDL also supports mass-option setting. it is possible to do:

entity A
entity B
...
entity Z
dto * with mapstruct
service all with serviceImpl
paginate C with pagination

Note that * and all are equivalent.
Latest version introduces exclusions (which is quite a powerful option when setting options for every entity):

With JHipster, you can also tell whether you don’t want any client code, or server code. Even if you want to add a suffix to Angular-related files, you can do that in JHipster.
In your JDL file, simply add these lines to do the same:

entity A
entity B
entity C
skipClient for A
skipServer for B
angularSuffix * with mySuperEntities

Finally, table names can also be specified (the entity’s name will be used by default):

entity A // A is the table's name here
entity B (the_best_entity) // the_best_entity is the table's name

Microservice-related options

As of JHipster v3, microservices can be created. You can specify some options to generate your entities in the JDL: the microservice’s name and the search engine.

Here is how you can specify your microservice’s name (the JHipster app’s name):

Here A’s name will be commented with My super field, B with My other super field.
Yes, commas are not mandatory but it’s wiser to have them so as not to make mistakes in the code.
If you want to mix commas and following comments, beware!

entity A {
name String, /** My comment */
count Integer
}

A’s name won’t have the comment, because the count will.

All the relationships

Explanation on how to create relationships with JDL.

One-to-One

A bidirectional relationship where the Car has a Driver, and the Driver has a Car.