search

cberio / google-api-java-client

Automatically exported from code.google.com/p/google-api-java-client
0 stars 0 forks source link

The Java classes generated by Google Cloud Endpoints should not be final #802

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Version of google-api-java-client = 1.15.0-rc.

Java environment (e.g. Java 6, Android 2.3, App Engine)?
GAE/J SDK 1.8.1.1 with Eclipse 4.2.2 and Android SDK 4.2.2.  GPE for Eclipse 
4.2 is 3.2.4.v201306061638-rel-r42.  Windows 7 32bit.

Describe the problem.
The Java classes generated by the "Generate Cloud Endpoint Client Library" 
wizard of GPE are final and have private members (regardless of how the 
developer declared them in the server code).  This makes it awkward for the 
developer to add functionality to the generated code.

(This issue may apply to the code generated for other platforms as well.)

How would you expect it to be fixed?

I believe that the keyword 'final' should not be included in the declaration of 
the generated classes.  Also, the access level of the generated member 
attributes should be determined by one of these means (rather than always 
setting it to private):

1. The access level of the generated attributes should reflect that of the 
server code they were generated from.
2. The access level could be specified in the @ApiMethod annotation,
3. The access level could always be 'protected'.

My preference is #1.

This defect report follows from:
https://code.google.com/p/google-plugin-for-eclipse/issues/detail?id=216
http://stackoverflow.com/questions/17180690/json-deserializing-issues-when-using
-both-gae-endpoints-and-gcm-on-android

Original issue reported on code.google.com by t...@malcolmson.ca on 19 Jun 2013 at 9:46

GoogleCodeExporter commented 9 years ago 
Then let's make them not final.  That seems like an easy fix.

Note that the getters and setters for the fields are public.  Why would you 
need to access the field directly?

Original comment by yan...@google.com on 20 Jun 2013 at 12:58

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 20 Jun 2013 at 12:59

GoogleCodeExporter commented 9 years ago 
Regarding the access level...

Yes, the members can be accessed via the getter/setters, but then my subclass 
would be more like an external class.  I'm hoping to create subclasses that are 
fairly natural and simple.

I guess my perspective is that, since you have plain setters (ones that do 
nothing else but change the value and are not synchronized), why not let a 
subclass have direct access.  It is functionally no different than my subclass 
using the getter/setters but makes for a more natural subclass.

More importantly, why not reflect the access level that I specify in the server 
class (where possible)?  If I make the attribute protected, or even public, why 
override the programmers' own decision when generating the client class?  

I realize that you have to worry about mappings between languages, so it is not 
as simple as I make it sound, but I still think it could work.

Original comment by t...@malcolmson.ca on 20 Jun 2013 at 4:14

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 21 Jun 2013 at 2:08

GoogleCodeExporter commented 9 years ago

Original comment by ngmic...@google.com on 3 Sep 2013 at 8:07

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 27 Sep 2013 at 12:05