[asterisk-dev] "Digium development team" - not Asterisk dev team - Java

Timothy Rodriguez timothy.rodriguez at gmail.com
Wed Apr 21 09:52:57 CDT 2010


It would significantly complicate the architecture to bring in java
for developing channel types.  I think lua would be a better language
for extensibility. However, I think java would've worked had asterisk
been implemented entirely in it, but a functional language like erlang
might've lent itself better to the type of concurrency asterisk
requires. Btw, erlang is a vm language as well, so it has similar
properties to the jvm, but is used by a telco for implementing pbxs.
Still, much less people know erlang than java or c.

All that said, I think c was a very good choice considering it's a
Linux application, which makes it easy to leverage all sorts of *nix
Apis. Lathering another language on top will only complicate
development. Especially if it's not a "simpler" "scripting"
language.   And considering the performance requirements. I'm not sure
how well something like lua/ruby/python would work for implenting
channels.

My 2 cents,

Tim

On Apr 21, 2010, at 7:50 AM, jon pounder <jonp at inline.net> wrote:

> Nick Lewis wrote:
>>> java is great for cross platform code, but is inherently not a
>>> real time language. you can't even control garbage collection
>>> yourself so the interpreter could pick the worst possible time
>>> to do it. application maybe, channel asking for trouble.
>>>
>>
>>
>
> Shame on you for even comparing java and c in that respect.
>
> C is a compiled language and compiles down very efficiently to
> assembler
> but bridges the gap where cross cpu use is needed that assembler can
> not
> do. Java is not compiled at all, (byte code is not compiling) and does
> not come close to approximating the machine code at its high level to
> start with.
>
> Laziness is not doing your own memory cleanup and allocation,
> typecasting, and all those sorts of things. Attitudes like this are
> what
> drive the demand for higher and higher priced hardware instead of just
> doing things efficiently and getting the most from what is
> available. If
> asterisk is not real time what is ?
>
>> I don't think we should get too hung up on the real-time nature of
>> asterisk. A typical example of the real-time aspects is that rtp
>> packets
>> need to go out every 20ms with less than say 10% jitter. With modern
>> processors handling billions of lines of machine code a second this
>> is
>> not a very onerous real time requirement. Furthermore asterisk runs
>> on
>> non real-time operating systems what can switch away from asterisk
>> tasks
>> at any inopportune moment so it is unlikely that a bit of gargage
>> collection is going to be significant.
>>
>> I am not convinced that using java for channels is asking for
>> trouble.
>> These predominantly deal with signalling rather than media and
>> signalling protocols are very resistant to delays with timeouts
>> typically measured in seconds.
>>
>> I think there are two types of developer in open source - firstly,
>> those
>> that want to develop code to do cool things, to contribute, to
>> improve
>> their skills and to gain kudos and secondly those that have to
>> develop
>> code to maintain their business. Only the latter will bother with
>> c. The
>> bright young things in the former category are put off by it.
>>
>> Let me draw a historical comparison. In a former generation the
>> bright
>> young things were put off by 8051 assembler even though many realtime
>> applications were written in it at that time. They lazily wanted
>> instead
>> to use c and to offload task switching to an operating system. The
>> hardware soon became capable and cheap enough to make this
>> possible. The
>> same has now happened to java.
>>
>> -- N_L
>>
>> _____________________________________________________________________
>> This message has been checked for all known viruses by Star
>> Internet delivered through the MessageLabs Virus Control Centre.
>> _____________________________________________________________________
>> Disclaimer of Liability
>> ATL Telecom Ltd shall not be held liable for any improper or
>> incorrect use of the  information described and/or contained herein
>> and assumes no responsibility for anyones use  of the information.
>> In no event shall ATL Telecom Ltd be liable for any direct,
>> indirect,  incidental, special, exemplary, or consequential damages
>> (including, but not limited to,  procurement or substitute goods or
>> services; loss of use, data, or profits; or business  interruption)
>> however caused and on any theory of liability, whether in contract,
>> strict  liability, or tort (including negligence or otherwise)
>> arising in any way out of the use of  this system, even if advised
>> of the possibility of such damage.
>>
>> Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons
>> Cardiff, CF3 0FB
>> Registered in Wales Number 4335781
>>
>> All goods and services supplied by ATL Telecom Ltd are supplied
>> subject to ATL Telecom Ltd standard terms and conditions, available
>> upon request.
>>
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list