manual memory management

[Paulo Pinto]

On Wednesday, 9 January 2013 at 20:00:28 UTC, Dan wrote:
> On Tuesday, 8 January 2013 at 23:04:48 UTC, Paulo Pinto wrote:
>>
>> Besides Web applications, I also took part in projects that 
>> ported high
>> performance C++ daemons to Java.
>>
> Curious as to why? What was to be gained/overcome?

The architects decided it was cool to replace server code done in
a mixture of C++/CORBA/SNMP/Perl by simple Java based servers.

>
>> These were servers doing millions of data processing 
>> manipulations per
>> second of telecommunication data used in mobile networks.
>>
>
> Did it prove a worthwhile move?

It was a lengthy process with quite some victims along the way,
but it did improve the overall quality in the end.

- Way shorter build times;
- Better tooling infrastructure;
- Thanks to the JVM, the application monitoring improved
- Unit tests, code coverage and static analysis tools are much
better
- Better support of the operating systems in use without #ifdefs 
everywhere

To be honest, it would have been better to refactor the C++ code 
to improve the overall quality, but there was another issue 
related with the language change, as you can read in the next 
answer.

> Did the move relieve any issues with C++?

Yes, because in 300+ team projects not everyone is a C++ guru and 
you end up chasing language issues and pointer problems all the 
time. Not fun when you get a mobile operator complaining that 
their customers cannot do proper calls.

So moving to Java allowed to improve overall code quality at the 
time, although I must say it also allowed them to easily 
outsource parts of the applications to replaceable developers a 
few years later.

> Was GC an issue in the end?

In the beginning, yes. Most developers did not understand that in 
GC aware languages you need to change the way you code. So that 
was a learning process for many of them.

But the JVM has lots of nice monitoring tools to help you track 
down the issues, which allowed us to refactor the places that 
were giving problems.

Just some small parts were later also written in C, for 
deployment into network elements that were not capable to run a 
JVM with the desired hardware requirements.

So depending on where in the globe you're located, your phone 
calls data might be processed by those applications.

>
> Thanks,
> Dan