Home » Eclipse Projects » UOMo » Re: Interim collaboration area @Google Code
| Re: Interim collaboration area @Google Code [message #546798] |
Wed, 14 July 2010 09:11  |
 Werner Keil
Messages: 1087
Registered: July 2009 |
Senior Member |
|
|
Glad to help.
I am not sure, if there's anything going to happen at OFMP, but it is not
directly related to us ar UOMo.
Frederic said, they'll migrate to Eclipse Labs, let's see if that attracts
new committers...?
>
> Regarding UOMo... well... this is a pretty tiny subject when we think
> about the wide subject of trading systems. Even JQuantLib, which is
> considered by many as a large library, can be treated small (or even
> tiny) given the very wide subject of trading systems.
>
It is a building block like EMF, most likely to even support it in some way.
If you find a way to use ICU4J (Measure/Currency) in JQuantLib, that'll be
fine, and compatible with both some of Google's projects and Eclipse UOMo or
its extensions towards financial use cases.
The most I'd imagine to see in UOMo itself is probably a more sophisticated
Currency class than ICU4J has and basic currency exchange on top of that.
Probably sets of rules or interfaces to use exchange rates in time and
context, but no concrete implementations. That's up to either you, OFMP or
custom projects.
> I think that collaboration should happen for the benefit of all
> participants but we need to have something, maybe a draft or manifesto.
> This kind of document is necessary in order to guide people interested
> on contributing. Not even a quick document like this can be found in the
> wiki hosted at GoogleCode. :(
>
> So, my sad and hard conclusion is that this project does not exist. :(
> Again, I'm really sorry for my harsh words but you can be sure that I
> will be delighted when someone proves I'm wrong and I will be delighted
> when the day comes I commit something to the repository.
>
Kind Regards,
Werner
|
|
|
| Re: Interim collaboration area @Google Code [message #547453 is a reply to message #546798] |
Fri, 16 July 2010 22:42  |
Richard Gomes
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
On 14/07/10 10:11, Werner Keil wrote:
>>
>> Regarding UOMo... well... this is a pretty tiny subject when we think
>> about the wide subject of trading systems. Even JQuantLib, which is
>> considered by many as a large library, can be treated small (or even
>> tiny) given the very wide subject of trading systems.
>>
>
> It is a building block like EMF, most likely to even support it in some
> way. If you find a way to use ICU4J (Measure/Currency) in JQuantLib,
> that'll be fine, and compatible with both some of Google's projects and
> Eclipse UOMo or its extensions towards financial use cases.
>
> The most I'd imagine to see in UOMo itself is probably a more
> sophisticated Currency class than ICU4J has and basic currency exchange
> on top of that. Probably sets of rules or interfaces to use exchange
> rates in time and context, but no concrete implementations. That's up to
> either you, OFMP or custom projects.
>
I will have a look at ICU4J and evaluate how it impacts performance.
IMHO, performance is 'the' critical issue when we talk about financial
applications written in Java. This issue must be considered and
addressed from the day one, every day, otherwise performance will be
poor when compared to C++.
In particular, I believe that enterprise class, low latency financial
applications need RTSJ or something better. GC must be removed from the
equation every time it is possible. Better than trying to solve the
problem of unpredictable performance due to GC, we'd better get rid of
GC whatsoever.
Unfortunately, it's difficult to obtain the best from both worlds at the
same time: (1) elegant programming language and (2) good performance.
>
> Kind Regards,
> Werner
Let's keep the ball rolling :)
Kind Regards
Richard Gomes
|
|
| |
| Re: Interim collaboration area @Google Code [message #566866 is a reply to message #546798] |
Fri, 16 July 2010 22:42 |
Richard Gomes
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
On 14/07/10 10:11, Werner Keil wrote:
>>
>> Regarding UOMo... well... this is a pretty tiny subject when we think
>> about the wide subject of trading systems. Even JQuantLib, which is
>> considered by many as a large library, can be treated small (or even
>> tiny) given the very wide subject of trading systems.
>>
>
> It is a building block like EMF, most likely to even support it in some
> way. If you find a way to use ICU4J (Measure/Currency) in JQuantLib,
> that'll be fine, and compatible with both some of Google's projects and
> Eclipse UOMo or its extensions towards financial use cases.
>
> The most I'd imagine to see in UOMo itself is probably a more
> sophisticated Currency class than ICU4J has and basic currency exchange
> on top of that. Probably sets of rules or interfaces to use exchange
> rates in time and context, but no concrete implementations. That's up to
> either you, OFMP or custom projects.
>
I will have a look at ICU4J and evaluate how it impacts performance.
IMHO, performance is 'the' critical issue when we talk about financial
applications written in Java. This issue must be considered and
addressed from the day one, every day, otherwise performance will be
poor when compared to C++.
In particular, I believe that enterprise class, low latency financial
applications need RTSJ or something better. GC must be removed from the
equation every time it is possible. Better than trying to solve the
problem of unpredictable performance due to GC, we'd better get rid of
GC whatsoever.
Unfortunately, it's difficult to obtain the best from both worlds at the
same time: (1) elegant programming language and (2) good performance.
>
> Kind Regards,
> Werner
Let's keep the ball rolling :)
Kind Regards
Richard Gomes
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 22:40:04 GMT 2024
Powered by FUDForum. Page generated in 0.03045 seconds |
] 
Search
Help
Register
Login
Home
