[FoRK] overhead of RESTful stuff

Stephen Williams sdw at lig.net
Fri Mar 9 08:36:24 PST 2012

On 3/9/12 1:09 AM, Eugen Leitl wrote:
> On Thu, Mar 08, 2012 at 09:50:33AM -0800, Gregory Alan Bolcer wrote:
>> On 3/8/2012 9:42 AM, Stephen Williams wrote:....
>> +1 on all fronts.
>> The key takeaway is, arguing java vs c++ on hardware costs is a losing
>> argument.
> We're frequently CPU bound. Some apps could saturate SMP boxes with
> hundreds of cores with no problem -- we only don't use them for budget reasons.
> Hardware costs are considerable if you're not living heads in the cloud(s),
> and you're traditionally operating on a shoestring budget.
>> If you need to preserve a capability, ie. you've spent 5+ years building
>> up an expertise c++ team and the switching costs to some arbitrary "new
>> shiny thing" without proper knowledge as to applicability of such thing,
>> then make the capability argument.
> Porting of 25+ years of existing working stuff is not an option -- however
> I can see how there will be more Java in newer projects. I want to nip in the bud
> the anticipable debacle where Java, inappropriate use of REST and poor programming
> skills meet very weak hardware base, and poor awareness of network architecture.
If you need both, which sounds possible, you can use both.

Doing Java+C/C++ works very well, and in fact is how a lot of Java is implemented (all expensive 2D and other operations result 
in a call to a C or assembly routines).
Writing Java++ (Java & C++) is actually pretty fun with JavaGlue, my fork and improvement of another project.  Just point 
JavaGlue at C++ headers, with no real prep or restrictions, and you can start writing Java code that instantiates and works with 
C++ objects, methods, etc., including pointers and template use.  I would not recommend writing more than a few JNI calls by 
hand.  Doing so has zero type safety, only interfaces Java->C, C->Java, and is a pain to debug.

>> An organizational capability is a very valuable thing.  Replacing one
>> with another shouldn't be taken lightly.
> Sure thing.

More information about the FoRK mailing list