topobyte / osm4j-pbf

PBF input/output for osm4j
17 stars 7 forks source link

update to protobuf 3.4.0 #8

Open hklarner opened 5 years ago

hklarner commented 5 years ago

I am using osm4j in a project that has a dependency to com.google.protobuf:protobuf-java:3.4.0 which causes some trouble. Could you update to version 3.4.0?

See also https://github.com/topobyte/osm4j-pbf/issues/1

sebkur commented 5 years ago

Seems like a good point to upgrade the dependencies. Are you aware of any problems with upgrading to the latest version 3.9.1?

hklarner commented 5 years ago

no, not aware of any

sebkur commented 5 years ago

I just updated the dependency (1e82b51) and also regenerated the protocol buffer source code (cc2dd12). I made some minor changes to the .proto files because the current protoc generated some warnings. Also the old style of using the lite runtime is not supported anymore. I followed the instructions from the documentation to continue using the lite runtime. Interestingly, if we proceed like this, osm4j-pbf will now depend on com.google.protobuf:protobuf-javalite instead of com.google.protobuf:protobuf-java. Not sure whether this might create problems in your project as well. It's possible that using both dependencies in one project at the same time produces errors. Also, I don't know at this time whether the files generated using protoc --java_out=lite:${OUTPUT_DIR} path/to/your/proto/file with the lite: prefix on the --java_out parameter can be used with both runtimes without problems. I'd like to look into this a bit more thoroughly before publishing a new version.

hklarner commented 5 years ago

Not sure whether this might create problems in your project as well

Not sure either, will try to find out..

I'd like to look into this a bit more thoroughly before publishing a new version.

Ok, thanks and waiting for updates.

sebkur commented 5 years ago

Seems to me as if the best option is to actually support both versions of protocol buffer runtimes in the future. If we were to decide for one version it would most likely result in dependency conflicts in some projects or, if the problem goes unnoticed and the wrong runtime is used, might result in unpredicted behavior. I prepared the project to produce two artifacts in the next version: de.topobyte:osm4j-pbf which uses the normal protocol bufferes runtime and de.topobyte:osm4j-pbf-lite which uses the lite runtime.

The lite runtime is mainly relevant for Android projects. If an Android project has de.topobyte:osm4j-pbf as a transitive dependency (for example via de.topobyte:osm4j-utils) the authors will probably need to replace the dependency manually with de.topobyte:osm4j-pbf-lite to make things work. It's not optimal, but I don't see a better way to do this without dropping support for Android.

sebkur commented 5 years ago

Okay, I went for two versions of the library (one with dependency on the lite runtime and another with dependency on the full runtime). I decided to swap the logic described in my previous post, i.e. the default artifact de.topobyte:osm4j-pbf depends on the lite runtime and de.topobyte:osm4j-pbf-full-runtime depends on the full runtime. You can try if things work for you by just upgrading to de.topobyte:osm4j-pbf:0.2.0. If you require the full runtime, use de.topobyte:osm4j-pbf-full-runtime:0.2.0.

hklarner commented 5 years ago

With de.topobyte:osm4j-pbf:0.2.0 I get the following error when I run my code:

Exception in thread "main" java.lang.NoSuchMethodError: 
com.google.protobuf.GeneratedMessageLite.registerDefaultInstance(
Ljava/lang/Class;Lcom/google/protobuf/GeneratedMessageLite;)

With osm4j-pbf-full-runtime:0.2.0 I get the following error when I run my code:

Exception in thread "main" java.lang.VerifyError: class 
de.topobyte.osm4j.pbf.protobuf.Fileformat$BlobHeader overrides final method getParserForType.
()Lcom/google/protobuf/Parser;

:/

sebkur commented 5 years ago

Interesting. I mainly tested the new version with the osm4j command line tools (topobyte/osm4j-utils) and had no problems so far. Is your project online somewhere? If not, would you try setting up a minimal test project that reproduces the buggy behavior?

sebkur commented 5 years ago

Is com.google.protobuf:protobuf-java:3.4.0 a direct dependency of your project or does it get pulled in there from another library (if yes, which one?)

sebkur commented 4 years ago

I'm archiving this repository because this module has been merged into the osm4j master repository. Please re-open the issue there if you want to continue the discussion.