[NTLUG:Discuss] Need some inputs on porting.

Vaidya, Harshal (Cognizant) HarshalV at pun.COGNIZANT.COM
Tue Sep 30 23:04:29 CDT 2003


Hi Stephen,

   The company has already invested heavily in the current application.
They've bought Solaris boxes, all the third party tools and have also
paid some company for the development and testing efforts. From last 4
years this application is serving them good. In fact most of the users
in the bank are now completely used to it. To move the application to
JAVA now, would involve a lot of cost. Moreover, the UI provided by JAVA
is pathetically slow. It just can't match the UI provided by C++ based
applications (I am talking about TrollTech, RogueWave etc). Since JAVA
UI is pathetic, one possible solution would be move it over the Web
rather than being a standalone App. This again brings in costs of
development of JSP/Servlets/EJB's, buying of Appication server licences.
Since the application to be ported is huge it surely dosent make sence
moving it to JAVA from a financial perspective. Porting would be a much
better and economical solution.

Thanks,
Harshal.

-----Original Message-----
From: Stephen Davidson [mailto:gorky at freenet.carleton.ca] 
Sent: Tuesday, September 30, 2003 8:26 PM
To: NTLUG Discussion List
Subject: Re: [NTLUG:Discuss] Need some inputs on porting.


Hi Harshal.

I really have to ask,
for complete platform independence (for Linux, Solaris, 32bit, 64bit,
etc), I really have to ask, why not Java? Now a days, Java is just as
fast (and in many cases is faster) than C/C++. And it has all the
features you are looking for (at least as stated so far in this email).

Just wondering.

Regards,
Steve

Vaidya, Harshal (Cognizant) wrote:
> Hi,
> 
> We are providing a solution to the following requirement:
> 
> The current scenario is like this.
> 
>  Its a complex application with a lot of GUI and business logic tuned 
> towards banking.  Its Deployed on Solaris 2.8.
>  Its completely written in C++.
>  It uses third party tools like Roguewave tools for XML processing and
> GUI.
>  Connects to a standard Oracle database.
>  The application has roughly about one million lines of code.
> 
> The application is totally at application layer. What I mean by that 
> is, it does not involve any system level stuff like device drivers and

> things alike. It's a complex application built towards providing a 
> business solution for the banking practise.
> 
> The solution needs the following things to be mandatory.
> 
> We need to make the entire code compatible to gcc 3.3.
> 
> With this I have several questions in mind. Is there anything special 
> with 3.3? According to me if the entire application is recompiled with

> gcc 3.3 over Linux and Solaris our work should be done. All we will 
> need to do is see whether the compilation on both Solaris and Linux 
> goes smoothly. Any comments?
> 
> Secondly the code now needs to be portable between Solaris 2.8 and 
> RedHat Enterprise Linux Advanced Server.
> 
> I think recompilation over GCC should do it. Comments?
> 
> Thirdly, we need to make the code 32 and 64 bit compatible!! The 
> deployment platforms are Linux and Solaris both.
> 
> Now, this is the killer one!!!
> 
> How do you think the problem of 32 to 64 bit compatibility should be 
> addressed? Of course I am reading up on this over the net. But I just 
> thought that people who have been through this already would have a 
> lot of things to talk about. And that's exactly what I want to know.
> 
> Moreover what pitfalls should we be aware of in terms of porting from 
> Solaris and Linux?
> 
> If you have anything else to say about this. It is most welcome.
> 
> Thanks,
> Harshal Vaidya.
> 
> 

-- 
Java/J2EE Developer/Integrator
Co-Chair, Dallas/FortWorth J2EE Sig
214-724-7741




_______________________________________________
https://ntlug.org/mailman/listinfo/discuss
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://ntlug.org/pipermail/discuss/attachments/20031001/8668bd99/InterScan_Disclaimer.txt


More information about the Discuss mailing list