Porting C# types to Java using auto-generated code

Question

3.00/5 (1 vote)

See more:

, +

Hey everybody,

Lately, I've been trying to do something which I find very cool to improve my project's productivity (at least I find it cool... ;) ).

Anyway, What I'm trying to do is to regenerate my server side's protocol classes, which is written in C# in my application's client languages, which are Java and Objective-C. (I think you see where I'm going with that...)

My main goals are:
a. Minimization of synchronization overheads. The client developers should not have to re-write server code. Also, an automatic process would hopefully reduce bugs (wrong serialization configuration, etc...).
b. Separation of client object logic and the serialization parameters. I would like to have the auto-generated code to be recreated before any version is compiled without affecting client's logic. (Partial classes, Y U NO EXIST IN JAVA?)
c. My requests form a really neat class tree. Where every node in the tree adds its own essential parameters to the request. I would like it to remain like that.

I'm here to discuss alternative solutions for Java. As partial classes do not exist. It seems like it would be necessary to do some ugly things, such as ProtocolRequest extends ProtocolRequestParameters, or maybe it would contain the parameters struct as a member. The closest method that fits my desires would be an auto-generated section within a class, and embedding changes within it.

My main concern is that it would be impossible to send a request to server properly, while my current design is trying to be very accurate and object-oriented (in other words awesome). I'm afraid that limitations imposed by Java will ruin my efforts.

I would appreciate some good advice and suggestions on how to auto-generate my classes. I would be really grateful if you guys find some good methods / maybe references to existing solutions to fit my needs.

Thank you very much!

Posted 14-Feb-13 11:17am

ShacharK

Add a Solution

Comments

TRK3 14-Feb-13 18:28pm

"Awesome" is often extremely counter-productive.

While your approach sounds like it could be a lot of fun to play with, I am skeptical that it would actually increase productivity.

You might be attacking the wrong problem.

If you are constantly changing the interface between your server and client, there is something drastically wrong with your design, or your serialization methods.

The interface between client and server should be extremely well defined and actually fairly simple.

If you think you need to transfer huge, often changing classes between client and server, maybe you have the devision of labor between client and server wrong.

Move all those clever dynamic classes all the way into the client and have your server just serve raw data, or move them all the way into the server, and have your client just display results.

It will make serialization and synchronization of server and client a lot easier, and should cut down on bandwidth.

Sergey Alexandrovich Kryukov 14-Feb-13 18:55pm

A agree! "Awesome" and "cool" are very indicative, in practice.
If you wish to post it as a Solution, I would gladly up-vote it.
—SA

Sergey Alexandrovich Kryukov 14-Feb-13 18:57pm

However, I should admit that the question itself is valid, and pretty well formulated.
—SA

TRK3 14-Feb-13 19:01pm

That's why I didn't post my answer as a solution.

It is a good question, and a fun one to solve.

If the OP was building a framework and had no control of the client/server interface, and the framework was going to be used for hundreds of projects, then it would actually be extremely productive to solve the problem.

If he's got time and wants to work on the problem for fun, then more power to him, he'll learn a lot. Or if he really is solving a problem for lots of other developers, then great.

But if he's getting paid to get a working solution out the door, then he might want to scale back his ambitions, as fun as they might be.

Sergey Alexandrovich Kryukov 14-Feb-13 19:20pm

Whatever. Again, I agree with your points...
—SA

ShacharK 14-Feb-13 19:44pm

Actually, I am building a framework. My intentions are obviously minimizing the amount of boring repetitive code the developer has to write (even worse! duplicate :S). This is extremely error-prone, and might be annoying. Especially, when different people are working on every code base.

As you've mentioned, The client-server interface should be consistent. I obviously agree. I don't see any good reason why a user of my framework would have to change that. Especially when I'm offering many useful abstract base classes whose handling procedures do much of the validations and verification procedures needed by the average server. Anyhow, This is a cool feature to have, and if it works properly, along with some basic target-language communication framework that I can supply. An application's SDK can be created in a really short time.

I don't see why creating a copy of the request parameters on both side of the protocol is not a good solution.
Somebody who uses this framework feature would have synchronized enums, synchronized requests parameters. It ensures that the communication will be stable, as long as the client compiles properly. Serialization methods (Binary, JSON, XML, Protobuf, ...) are all configurable and the settings could be exported as well if I wanted them to. For example I could translate C# attributes to Java Annotations which would contain serialization relevant parameters (i.e JSON Keys)

TRK3 & Sergey, I think you've misunderstood my intentions. According to my design, the server is responsible to export an SDK, which one could simply assimilate into a layered protocol manager which is capable of fixing some issues without annoying the client side developers.

I don't think that I should be concerned about the division of labor. As my design is very "oniony" and every layer has a matching layer on the other side.

Thank you for your time, I really appreciate your efforts to help.

TRK3 15-Feb-13 13:44pm

OK. Other than the fact that the world has too many frameworks already, I am tracking with what you are saying.

The first thought that comes to mind would be to define the interface in some declarative syntax that you create and then have a "compiler" generate declarations in both "C#" and Java (or any other target language).

That way you get equivalent declarations in both languages automatically.

By using your own declarative language, you can limit what can be defined to only those things that you can reasonably be represented in both languages.

I'm not sure I see a need for partial class definitions -- am I missing something?

I think your interface classes should be complete definitions and the developer can inherit or extend those with whatever inheritance/extension paradigm the language supports.

ShacharK 15-Feb-13 13:55pm

The idea of using partial classes by auto-code generators is very common (Visual Studio Code Designers often use them). All I'm doing is translating data contracts from one language to another to enforce that no dumb mistakes are done.

TRK3 15-Feb-13 14:50pm

Yeah. Totally get that, but if one of your target languages doesn't support partial classes, then it seems like you are stuck with full classes.

Coming from a predominantly C++ background, and being heavily influenced by Liskov's emphasis on encapsulation, I don't see what you gain from partial classes that you don't get from inheritance or composition.

What am I missing that makes partial classes intersting/useful?

ShacharK 15-Feb-13 15:19pm

The way I see it, Composition changes the way my requests are serialized.
I'll try to simplify what's on my mind by an example:

Imagine 3 layers of inheritance, I would expect my data structure to contain the parameters of all the layers, lets say the expected serialized object is (123).
If I use composition, I have 3 Parameters Structures, one for each layer, making it look like (1)(2)(3). It is possible to work like that, but not very comfortable in my opinion... In this case, assuming the serialization works properly. Errors and Exceptions can be handled in the same layer, utilizing the fact that the requests can still inherit from one another.

If the Inheritance is used, It is impossible to use the layered error handling, as every Request is inheriting a Parameters class. and although serialization works perfectly fine, lower-level exceptions are being handled in multiple requests.

I guess that Partial classes are just wishful thinking, and that if I ever decide to write such utility, I would choose the composition method before I would choose the Request Inheriting from Parameters class.

TRK3 15-Feb-13 16:10pm

Yeah, practical solutions are too often a compromise with what's elegant -- but they have the advantage that they can be implemented.

Good luck.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Espen Harlinn · Answer 1 · 2013-02-14T13:43:00

It's possible that you would be interested in the Stab[^] programming language:

class C 
{    
 // Manually implemented property    
 private int myProperty;    
 public int MyProperty 
 {        
  get 
  {            
    return myProperty;
  }        
  set 
  {            
    myProperty = value;        
  }    
 }    
 // Indexer    
 private int[] array;    
 public int this[int i] 
 {        
   get 
   {            
    return array[i];        
   }        
   set 
   {            
    array[i] = value;        
   }    
  }    
 // Automatically implemented property    
 public int MyProperty2 
 {
   get; 
   set;    
 }
}

Best regards
Espen Harlinn