jt808-server is a Java gateway for the Chinese JT808 vehicle telematics standard

The protocol problem this gateway solves

JT808 is a Chinese transport standard for vehicle telematics, the traffic between a vehicle tracking terminal and a platform, and jt808-server is a Java implementation of the message handling on the platform side. The project describes itself as the standard JT808 gateway, built on Netty, implementing message handling and encoding and decoding for the JT808, the 1078 protocol, the Jiangsu standard and the Guangdong standard, and offering a Web interface service built on Spring WebFlux for high concurrency. The stated advantage is that the same code handles TCP and UDP without modification, and that it can be run without Spring, which matters because the encoding and decoding side is meant to be usable on Android clients as well. The audiences are therefore two at once, a platform team running the service and a mobile team embedding the codec.

Three revisions of the standard, accepted at once

The support table is the part that determines whether the project saves you work. JT/T 808 is supported in the 2011, 2013 and 2019 versions, and the note under the table says there is no manual configuration, the implementation is compatible with the 2011, 2013 and 2019 protocol versions simultaneously, and it supports sub package requests, sub package responses and timed out sub package retransmission. That last item is the one that tends to break naive implementations. JT808 allows a terminal to split a large payload across several frames, and a gateway that ignores the sequence numbers loses data. Accepting all three revisions without configuration is convenient, and it also means your code cannot assume a fixed layout on the wire, so the parser has to be the single place where the version differences live.

The regional active safety variants

Beyond the base standard, the project supports two regional extensions. T/JSATL 12, the Jiangsu active safety standard from 2017, is listed as based on JT/T 808-2013, and T/GDRTA 002, the Guangdong active safety standard from 2019, is listed as based on JT/T 808-2019. The base table also covers JT/T 1078 from 2016, with the note that you need to build a media server yourself, and the 1078 protocol supports audio and video commands. That last constraint is the one to read twice. If your requirement includes JT1078 audio and video, the protocol parsing is here but the streaming side is not, which is a different and much larger project than the message gateway itself. The repository also carries the corresponding protocol documents, including the 2011, 2013 and 2019 revisions of 808, the 1078 document and the regional standards, plus a packet sending tool for testing.

Annotations instead of hand written packing

The extension model is where this framework earns its keep, and the README draws the analogy directly with Spring and Hibernate. The `@Message` annotation describes the message type and is equivalent to Hibernate's `@Table`, and `@Field` describes a message property and is equivalent to `@Column`, with attributes for length and description. `@Endpoint` marks a message entry point and is equivalent to SpringMVC's `@Controller`, and `@Mapping` maps a message type to a method the way `@RequestMapping` maps a request. Two annotations handle the work that usually ends up as hand written threading. `@Async` is for asynchronous message handling for time consuming operations such as file writes, and `@AsyncBatch` batches messages of the same kind for high concurrency cases such as location reporting, merging them to improve database write performance. A message class is then just a bean with fields, as the 0x0100 terminal registration example shows.

The Elucidator tool for reading a packet field by field

Parsing bugs are hard to find by reading code, so the project ships a tool for looking inside a packet. The README calls it a message interpreter for analysing the parsing process, and it lives at `org.yzh.Elucidator`, with a usage example under `src/test/java/Elucidator`. You give it a hex string, and it decodes it, printing each field with its byte offset and length, its description and its converted value, which is exactly what you need when a field is coming out wrong and you have to work out where the offset drifted. The example output in the README shows the shape of the report, listing the province ID, the city and county ID, the manufacturer ID, the terminal model, the terminal ID, the plate colour and the vehicle identifier, then the message ID, the message body properties and the phone number and serial number. The same class also re-encodes the message, so a decode and encode round trip is one command away.

The demo: a device port, a log page and API docs

The README lists the demo endpoints, and they are worth reading as a description of the deployment shape. Device access is on 127.0.0.1:7100, and the log monitoring page is at http://127.0.0.1:8100/ws.html, with the interface documentation at http://127.0.0.1:8100/doc.html. Further down, the same pages are given on port 8000 instead, with the Knife4j UI at http://127.0.0.1:8000/doc.html, the Swagger UI at http://127.0.0.1:8000/swagger-ui/index.html and the device message monitor at http://127.0.0.1:8000/ws.html. That inconsistency is a small thing but a real one, since a reader following the first pair and then the second pair will wonder which port the running instance uses. The verification flow in the README uses a Windows packet sending tool against 127.0.0.1 on port 7100, with the send and receive settings set to HEX, and the point of the warning is to select HEX before pasting the packet.

Two modules, Maven integration, and an Apache licence

The repository is a Maven project with a root `pom.xml` and two modules. `jtt808-protocol` holds the message definitions for 808, 1078 and the Jiangsu standard, the codec, the parsing tool and the unit tests, while `jtt808-server` holds the Spring Boot microservice and the 808 service configuration items, with a `commons` directory at the top level and the protocol documents in their own folder. Integration is through a published artefact rather than a copy of the source, with the README recommending Maven for Spring Boot based business systems, running the install command for the jtt808-protocol module to put it in the local repository, or deploying it to a private one:

<dependency>
    <groupId>org.yzh</groupId>
    <artifactId>jtt808-protocol</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</dependency>

The application then calls the service over HTTP, with the address configured in `application.yml`:

jt808-service:
  base-url: http://127.0.0.1:8100

The licence is Apache 2.0, and the project requires JDK 17 or later. The maintenance picture is modest. There are no GitHub releases, so the version comes from the Maven coordinates rather than a tag, and the last push was on 2026-07-23, with a QQ group and a Gitee mirror listed alongside the GitHub repository for those who prefer it.

Editorial conclusion

Adopt jt808-server when your product has to interoperate with Chinese vehicle terminals that speak JT/T 808 or one of its active safety variants, since the project already handles the standard revisions, TCP and UDP, and the sub package and reply mechanics that a from scratch implementation usually gets wrong. Do not adopt it if you need the JT/T 1078 audio and video payload end to end, because the project states that the media server must be built separately. Verify first which revision your terminals actually emit, since the framework accepts 2011, 2013 and 2019 simultaneously, and check the demo ports in the README because the device port, the log page and the API documentation are listed on different numbers.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. yezhihao/jt808-server on GitHub