As Java does not support unsigned integer types, the value types
are "rounded up" (an uint32 is represented as a long) but persisted
correctly (an uint32 is persisted as 4 bytes).
This CL makes a cast operation explicit so that the compiler
does not throw warning messages.
Co-authored-by: Dominic Battre <battre@chromium.org>
Co-authored-by: Derek Bailey <derekbailey@google.com>
The MyGame/Example/LongEnum.java class did not compile because
Java expects an "L" suffix for literals of type long.
This CL fixes the code generation to include such a suffix.
Co-authored-by: Dominic Battre <battre@chromium.org>
* Start of mvn-ification of the test
* move to right locations
* Update the IO done in the test to read from resources / write to temp folders
* Add github workflow attempt to mvn test it instead of JavaTest.sh
* Pin the Kotlin benchmark's symlink for /java to the right location
* Inline equality assertions and format JavaTest.java
* fix android gradle source directory
Co-authored-by: Derek Bailey <derekbailey@google.com>
This avoid to put the pom.xml file into the source directory. Normally the pom file is in a parent (/parent) folder and it is not mixed with the java source code.
An other thing is: this will make import of the project more easy from a IDE.
The side effect is that the target folder where maven build artifacts will move from the <flatbuffers>/java/target to <flatbuffers>/target therefore the gitignore file has been updated in consequences.
Java developer are mostly comfortable with maven project structure. One one the main concept behind maven is convention. If you follow the maven project convention then your development team will get more effective as they now this project structure and can easily find the production code versus the test code.
In this pull request I have structured the java project around 2 main parts:
* the `flatbuffers` project. This project is the api / lib project and contains the test code structure + an example of code generation for testing. This avoid to commit generated code. Pre-configure JUnit for test driven development and make this project OSGi compliant.
* the `jmh` project. This project aims to provide a placeholder for micro-benchmarking. JMH is a 'de facto' standard for micro benchmarking you can find more details here: http://openjdk.java.net/projects/code-tools/jmh/
For now I didn't move the JavaTest class but it could be a next step with a migration to the JUnit framework.
The only impacts are the move of the class and the project structure => no code change.
https://github.com/google/protobuf/blob/master/java/pom.xml
This isn't good enough to publish to Maven Central but will at
least allow users to publish to their local maven repository
using 'mvn install'
Change-Id: I91ea146cf7c5263fcf5d9823f70bb1ef0158f9a6
Tested: 'mvn install' runs succesfully and produces a .jar
RishabhDeep Singh