Develop Reference

Sharing POJOs between Java backend and an Android application

I am developing an Android application with my friend. I am currently responsible for the backend while she is working on the Android part. The backend is developed in Java using Lambda functions running in AWS Amazon Cloud‎. The frontend and the backend are totally decoupled (Lambda functions are exposed via REST APIs) except for the POJOs used on both sides. POJOs are serialized by the application into JSON when calling an API and deserialized again into POJOs (very same ones) by the backend when handling API requests.
We want to keep POJOs on both sides exactly the same for obvious reasons but we are wondering what the proper way to do it is. We see the following two options:
1) Simply copy code on both sides. This has the disadvantage of changing common code independently which, sooner or later, will lead to a misallignment.
2) Move POJOs out to a separate library and include it as a dependency on both sides. This seems like a more proper way to solve this issue but how do we ensure that both me and my friend know that a POJO has been changed? Let's say I remove one field from a POJO and create a new version of the shared library. I push changes to our repository and then... tell my friend that I made some changes so she should pull them, build the new version and include it in her project?
Is there a different (better) way to address this issue? Currently the backend is built with Maven but I can switch to Gradle if this would help automate things and make our code consistent (Android Studio forces Gradle builds).
I found similar questions of other people but they were either a bit different or remained unanswered:
Sharing POJOs between Android project and java backend project
Sharing one java library between Android and Java backend (gradle)
Sharing code between Java backend and Android app

There are certainly lots of other ways of doing this and better or not; I will leave that to you to consider.
But before going to sharing the POJOs, I ask you to take a step backwards and take a look at your architecture. You have essentially got:
a Java Backend with REST APIs, supporting JSON payload
an Android Application, capable of making REST calls and deserialising the JSON payloads.
If you note, above, the tech stack does not involve POJO on any level.
You see what I mean? POJO is an implementation detail for you and it is not wise to share it among your components.
How about looking into the future where you add more components to your architecture, say:
iOS application
Kotlin support for Android application
Will your inclination to share POJO code still be intact? Perhaps not.
From what I see, you should design and develop for a REST backend and a REST capable client. Thats all. That should be the bottomline.
So with that, coming back to your requirements of sharing the updates between the backend and the client, you can share the JSON schema between the two, instead of sharing the POJOs. And thereafter, employ an automated system (say, a simple script) to generate POJOs in the backend and the client.
This approach can have certain benefits. For instance:
You will be able to share updates now and in the future, as per your requirements.
This makes your modularity (or decoupling) better too because the backend and the client is not bound by the requirements to use POJOs. For instance, you can use Data class if you decide to use Kotlin in your client.
You can use versioned schema for future, for the times where the client cannot keep up with the backend, or the backend needs to update independently.
and more

Adding to the answer above, I would take advantage of the fact that both languages use Java compilers and apis. Whether the front end uses Java or Kotlin, you can call any of these api libraries directly from your code.
One api in particular, Json-B, provides methods for transforming your Java (or Kotlin) objects into Json for transport, then transforming the Json response back into Java/ Kotlin on the other end.
One caveat: I recently heard that at least parts of the javax.* package were scheduled for deprecation. They should work on Java 14 or lower, but if you are planning on updating in the future, this is something that you will want to consider.
For Java versions 9 or newer, you should also read this first. It will save you some time.
EDIT: Json-B is, in fact, disabled by default in newer Java versions (the package is included but 'hidden'), but the last article linked in the paragraph above talks about acceptable workarounds. IMO it is still the preferred option for working with Json in Java.

Can I generate a C/C++ client for a JAX-RS JSON API?

Suppose I have a remote JAX-RS JSON API from a server running Tomcat. I want to access this API from a C/C++ client. Are there any tools available to make life easier for the C/C++ client, e.g. code generators? Or does anybody have a suggestion for an alternative?

I have never heard of such a tool. More to the point, I suspect that such a tool (a C / C++ generator for JSON) is impractical.
There are a number of reasons why. Some of the most significant ones are:
A key problem is that JSON doesn't have schemas. This means that an API generator would have to resort to looking at example messages and try to infer what fields to expect and what their types are. This can be difficult and even theoretically impossible in some cases.
In languages like Java and C#, there are straight-forward "right ways" to generate object APIs; e.g. the JavaBeans conventions. In C++ and especially C, the conventions are not there, and there are complicating issues like container protocols and memory management to deal with.
In languages like Java and C# are runtime type-safe, and have various language level mechanisms are provided that allow you to use dynamic programming to deal with the JSON's schema-less nature. For example, in Java you have reflection, proxy classes, dynamic code generation and dynamic code loading, all of which can help in dealing with JSON. In C and C++, these mechanisms are generally unavailable.
In short, if you are using C or C++, JSON libraries are as good as it will get.
FOLLOWUP
As a comment points out, this may be feasible to implement in the context of a specific JAX-RS-based server implementation. You'd need to get hold of the internal metadata, apply the JSON mapping to it, and generate C / C++ APIs from that. The problems are:
The generator implementation would be platform specific.
The C / C++ based client would not be able to cope with changes to the effective schema without regeneration of the APIs and corresponding client code changes. (By contrast, a JSON library-based solution can in theory be coded to deal with unexpected new attributes, etc)
You still have the container / memory management problem to deal with.

What you need is your choice of library for sending and receiving http requests, and a json parser. Nothing is going to generate code to make it easier for you because the idea of such an API is that it spits out JSON. The point of JSON is to go across language and transport barriers in a consistent way. A bit like XML, but simpler.
This question might interest you: what's the best json parser? JSON Spirit Looks like a particularly good article.
Now, as you're using REST, all you need is to communicate to the right urls. Done.
The final thing you want to decide is what libary to use for network communication. Boost would be many people's recommendation, I'm sure.

JSON or YAML encoding in GWT/Java on both client and server

I'm looking for a super simple JSON or YAML library (not particularly bothered which one) written in Java, and can be used in both GWT on the client, and in its original Java form on the server.
What I'm trying to do is this: I have my models, which are shared between the client and the server, and these are the primary source of data interchange. I want to design the web service in between to be as simple as possible, and decided to take the RESTful approach.
My problem is that I know our application will grow substantially in the future, and writing all the getters, setters, serialization, factories, etc. by hand fills me with absolute dread. So in order to avoid it, I decided to implement annotations to keep track of attributes on the models.
The reason I can't just serialize everything directly, using GWT's own one, or one which works through reflection, is because we need a certain amount of logic going on in the serialization process. I.e. whether references to other models get serialized during the serialization of the original model, or whether an ID is just passed, and general simple things like that. I've then written an annotation processor to preprocess my shared models and generate an implementing class with all the getters, setters, serialization, lazy-loading, etc.
To make a long story short, I need some type of simple YAML or JSON library, which allows me to encode and decode manually, so I can generate this code through my annotation processor. I have had a look around the interwebs, but every single one I ran into supported some reflection which, while all fine and dandy, make it pretty much useless for GWT. And in the case of GWT's own JSON library, it uses JSNI for speed purposes, making it useless server side.
One solution I did think about involved writing writing two sets of serialization methods on the models, one for the client and one for the server, but I'd rather not do that.
Also, I'm pretty new to GWT, and even though I have done a lot of Java, it was back in the 1.2 days, so it's a bit rusty. So if you think I'm going about this problem completely the wrong way, I'm open to suggestions.

Have you looked into itemscript? Some excerpts from the description on the webpage:
A cross-platform GWT & standard Java JSON library, with convenient classes, parsers, and utilities.
A RESTful connector API for retrieval of data (JSON, text & small binary files) over a variety of protocols.
The same JSON API can be used in both standard Java and in GWT Java.

Is there an efficient tool to convert the .Net C# webservice to java webservice?

Is there an efficient tool to convert the .Net C# webservice to java webservice. Is there any open source tool that can help?

Don't waste your time looking for a transition tool. If you were working with Java 1.4 and maybe C# 1.x, there was a beta utility from Microsoft that did on-par conversion between the two. But that was a long time ago, and they don't publish the utility any longer. Even then, the utility would only convert source code at the language level, as opposed to dealing with the separate languages' implementation, i.e. in a Windows service, web service, console app, etc.
Having ported applications in both directions (C#->Java and Java->C#), the manual effort IS your shortest path. Any tool that suggests otherwise is likely a poor implementation. You're making modifications in either case. Convert-and-update is slower than writing-from-scratch.
Not to suggest this, but if the basis for your approach is not time-savings but rather a lack of understanding C#, then a conversion tool is only going to cause you more problems because it will hide the true intention of the source code.
Basically, take your lumps and roll your own. Follow #Padmarag's suggestion and stick with simplicity. The closest agreement between your two options (C# and Java) is a generated WSDL. This is a great way to get started with your base objects and operations.

I have never tried this, but maybe you could try to make a contract first web service in java with the wsdl of the c# web service.

A simple option would be to -
create Web - Service in .Net
Generate the WSDL
Copy the WSDL to Java Project (possibly in Netbeans/ Eclipse)
Implement the WSDL using reverse engineering - also called as "Start with WSDL" approach.
Implement the generated methods.

Check this out:
http://www.cs2j.com/

Guaranteeing that a .NET WCF Service can be consumed by a Java client

I am creating a WCF Service that will be consumed by both .NET and Java client applications.
We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.
Are our worries well-founded? If so, what should we be wary of?
Edit
One example of a concern is whether a .NET DateTime value is represented in the service interface in a manner that can be correctly understood by a Java client.
Edit2
A second example of a concern is the use of any nullable value types (bool?, int? etc).
Edit3
At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.
The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.
The downside is that this adds a development burden and also precludes us from documenting these classes using <summary> tags (.NET equivalent of javadoc comments).

The recommendation to start with XSD is a good one. That will not guarantee compatibility on each side, as XML Schema is really big and no web services stack supports all of it. (Example: lists).
So, start with XSD, but confine yourself to mainstream types. Primitives, complextypes composed of primitives, arrays of same. You can safely nest complextypes and arrays. (arrays of complextypes, complextypes that contain arrays or complextypes, etc).
Stay away from restrictions, substitution groups, lists, derivations, and any other XSD esoterica. Even XSD enumerations should be avoided.
About dateTime:
It's not enough to use a nullable datetime. There are formatting concerns as well. The .NET DateTime is a higher resolution quantity than a Java Calendar and as a result, shipping a .NET time to Java can result in de-serialization exceptions on the Java side. (EDIT: using the DataType="dateTime" decorator in the XmlElement attribute on the .NET side can make sure you serialize properly)
Some old advice on that.
Finally, it is not true that you cannot use in-code XML doc on the classes that get generated. With C#'s partial classes, you can write separate code from the generated classes with the in-code doc you want. Even if you re-gen the code, your partial class code will remain unchanged. EDIT: When you compile, the doc will appear on the classes.
EDIT: Someone asked, if using XSD-first is not enough to guarantee interop, why use it? My answer: it is not a guarantee but it is a good step, it helps. It keeps you away from designing interfaces in code (either Java or C# or VB, etc) that expose platform-specific things like .NET DataSets, generic Dictionaries, Java ResultSets, etc, all of which present interop problems. There are still pitfalls in the more marginal parts of XSD, but you can usually avoid those with thoughtful design.
I should have mentioned in my original answer that you can apply an iterative process to the development of the interface. Design in XSD, then generate (client) stub and (server) skeleton code from the XSD+WSDL, then adjust and do it again.

Using basicHttpBinding endpoint will guarantee that any SOAP 1.1 compatible client will be able to consume your service.

Use DateTime?, i.e. a nullable struct. Java does not have the notional of complex value types (i.e. structs). I believe there are ways to specify in the WSDL not to allow nulls, but I think WCF doesn't do it out of the box.
Use arrays instead of collections. If I recall correctly, the collection types do not translate very well over SOAP, but array types do quite well.
You should get a copy of Eclispe or Netbeans. After you create a prototype WCF service, run the web service wizard to create your proxies. Examine the object model for any major defects with particular emphasis on complex objects or non-primitive types (treat string as a primitive).
The learning curve to do that with Netbeans or Eclipse is pretty flat, so it's not a huge burden.
Edit: The other potential problems are with the bindings. If you stick with HTTP(S), you should be good... start going to the alternatives like TCP or MSMQ, you'll have to do a lot of work in Java. Also, some of the security features don't interop in all cases, such as using NTLM tokens... Take an iterative approach. Start with a simple HTTP w/SOAP binding with no security and go from there.

Does WCF provide standard SOAP interfaces? If it does, getting Java to talk to it should be a doddle.
Re: Edit1: The WSDL / XSD will use a standard date time format (Calendar at the Java end, a formatted datetime string in the SOAP, DateTime in .NET), or you could force it into a string format of your own choosing.
Read up on the Apache Axis (1.4 and 2.0) documentation for Java web services. It's very easy to use to get a Java web service client set up from the wsdl/xsd that your web service will provide.
Edit3: In Java you would define a Java model (with all your favoured documentation), then run Java2WSDL (preferably as an ANT/Maven task) to create your WSDL (however I have found you need to hand-reorder the fields in it). Axis 2 supports Collections and Enums just fine, Axis 1.4 likes Arrays and hand-rolled Java 1.4 style enumerations. From this WSDL you would create a server-side skeleton using WSDL2Java in which the only thing you need to do is implement your business logic.