Feature #403
Check if explicit Typeinfo representation is necessary
| Status: | Resolved | Start date: | 07/04/2011 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | S. Wrede | % Done: | 100% | |
| Category: | Java | |||
| Target version: | 0.4 |
Description
Stringlified encoding of types in Events and Converters feels broken in Java.
Probably, we can just remove it?
History
#1 Updated by J. Wienke almost 13 years ago
If there always was an IDL, we could resolve a name automatically from the definition of the IDL. But what would be the solution for hand-crafted protocols?
#2 Updated by S. Wrede almost 13 years ago
This ticket is about the client-side API and the converter selection within Java. So, if a user writes a converter, he writes this for a programming language type within Java that can be easily accessed with Class.getName(). However, until now all the Java type names are passed around as strings where we could better use Class objects. That is basically the whole proposal.
For the ProtoBuf converter, this is already done as the actual conversion for the serialization is done based on the type of the class.
#3 Updated by S. Wrede almost 13 years ago
- Target version changed from rsb-0.10 to 0.4
#4 Updated by S. Wrede over 12 years ago
- Tracker changed from Tasks to Feature
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
Initial implementation available with r2242. At client-level and internally now class objects are used for designating Java types.
Please note, that this also leads to an API break between 0.3 and 0.4 as the Event contructor changed from Event(String content) to Event(Class type).