OE10 .Net or Java

alightbo

alightbo

New Member
Hi,

I've got a client currently running CHUI Progress V9.1D on HP:UX. We are currently migrating to OE10.2 and moving to Redhat at the same time.

Once this initial upgrade has been completed the client needs a limited amount of functionality upgraded to GUI. Probably about 5% of the overall application.
I had planned to build these new GUI screens/modules in OE10 .Net (using OE Architect). However there is a new architect on the project (with no Progress experience other than google) who has seen some of the 'auto upgrade tools' out there that will move your 4GL code to Java.
Given the complex nature of the existing application, the fact that it's CHUI and has no split between the UI and business logic, this idea seems a bad one to me. I'd love to know what others think that may have been through this process before.

Kind Regards

Allan
 
From my experience:

Your biggest challenge when trying to harvest the legacy application will be to seperate out UI and business logic. After you've done that it should not make a big difference if you go for .NET or Java UI, unless your OS is Linux/Unix - then, IMHO, Java is the better decision. AFAIK, there is no "official" support for .NET on Linux and whatever you do might be perfect for a testing environment, but when it comes to the production environment I would want to have it "officially" supported.

I was in involved in several projects running Java UI against the OpenEdge AppServer and there were no major issues. Although, at his point, I have to admit, that I'm not a Java programmer.

HTH, RealHeavyDude.
 
Have you ever heard of snake oil?

IMHO you should take those "auto upgrade to Java" tools with a huge grain of salt.

You might start by asking the vendor for reference accounts and you might want to ask the references some questions like:

1) Is your conversion project finished yet?

2) How long did it take?

3) How much did it cost? (Both direct costs and indirect costs...)

4) What percentage of the conversion was actually automated?

5) How much testing and what sort of testing did you have to do?

6) How much recoding of your application did you have to do to make it "automatible"?

7) What does the resulting application look like? (IOW is it a duplicate of the original or has it been magically transformed into a modern GUI application?)

8) What does the resulting code look like? (IOW is it nice OO Java code or an ugly kludge...)

Unless you have money to burn (in which case I have lots of additional suggestions to offer) don't even think of spending any time or money on such a project until you get satisfactory answers to these questions from verifiable reference customers.
 
I completely agree with the above posts. I highly, highly, highly doubt one can effectively convert between any two sufficiently different languages. And Java vs. P4GL are very different!

I know you didn't ask this, but as to the overall Java vs. P4GL debate, well I have been doing a lot of Java+SQL lately. Here is what runs through my head constantly: "Java+SQL is so awesome! I love Java+SQL. Java+SQL is better! Everything about it is better. Oh wait a minute I need to do a bunch of database work. Agh! What is all this ORM crap! Why are these data types different? Why can't it find all these problems at compile time? Oh God, I hate Java!".
 
One more thing. Many of "us" in the Java world consider Java as a desktop GUI platform dead. Also, I personally don't know why anybody is still writing new Win32 clients when the web-based versions are so compelling. But if I had to, I would use C#. It (and Java Swing, the two are very similar for GUI development, at least compared to P4GL, which is somewhat hopeless, IMO), both compare extremely positively to P4GL. But, a lot of people will look at you like you have two heads.
 
There are three companies currently offering ABL to Java or C# translation. One is now is something like the 4th year with the first customer and still not in production. One has completed and delivered a translation, but the customer is still testing internally since it is an application which will get a real production test only when they sell a new customer. The third is working on three translations but is still at an early stage on the most advanced of these.

None of these, as advertised is directed at converting the UI only, they are stem to stern translations of the entire application and all involve some fairly major shifts. It doesn't sound like that is what you are interested in.

However, I have convinced one of these companies to be interested in ABL to ABL transformations and we are working together on that concept. See the Request for Expression of Interest on my website.

If you wanted to move all the UI to GUI, then I would definitely say that you should contact me since, in addition to the exploration just mentioned, I have also been reviewing other company's UI transformation offerings, each of which has a possible place depending on your needs. But, if all you want is a handful of screens, it is unlikely that any of these tools will work for you because of the startup cost. I.e., doing a large project they can be significantly cost effective, but that may not be true for a small one.

There are a lot of choices for the GUI, each having their own proponents, but one thing that you can say for the ABL GUI for .NET is that you get to continue to program in ABL. You will have a big learning curve to understand the .NET controls, but significant parts will leverage existing knowledge. Of course, if all of your experience to date is V6 EDITING clauses and CHOOSE statements, then there is a lot of new ABL you will need to learn too.

Let me know if I can be of any help.
 
Gents,

Thanks for your thoughts - I think in the most part that aligned with my thoughts on the subject. Unfortunately I'm dealing with some external resources that don't come from a very different background and they give me an odd look when I describe some of the issues that you have each raised.
The current app is almost totally V6 type code, and needs a major update to make use of more modern statements within the ABL.
While I'm sure there would be advantages to migrating the whole application to GUI - the client aren't asking for it, and given the size of the application I don't think they would ever get payback for it.
From my point of view there are probably 20 screens that need to be combined into 2 new GUI screens - for that .Net seems to make some sense.....
 
Check out my website for the PUG Challenge talk on Transformation and Modernization as well as the previously mentioned document. That might help get you ... and them ... thinking along a path that will help modernize the application at a pace and cost that will fit the customer's need and tolerance.

The big key here is to have a plan and goal. If you know where you want to be in five years, it is much easier to make smart decisions of what to do along the way. This is as much a business issue as it is a technology issue.

And, don't neglect the possible importance of tools. The right tools can easily cut large amounts from the cost ... and that can mean going a lot farther with the same dollars, not just saving money.
 
Thanks Thomas - I read that document last night - I was thinking of suggesting a few people have a read of it.

Allan
 
java and GUI I cringe. Personally I think .NET controls are more mature and capable then some of the funky swing stuff I've seen but then again I'm not the java expert. Go with ABL.net or a C# solution for GUI. Plus web based solutions are becoming more viable
 
Of course, .NET isn't much of an answer if one is interested in being independent of Windows.
 
In my opinion we have no choise: the we are all "google dependant"
"Java-Android-WS & Crome OS" ...
 

Attachments

  • Capture-Android Emulator (my_avd:5554).jpg
    Capture-Android Emulator (my_avd:5554).jpg
    22 KB · Views: 4
  • Capture-T-mobileAndroidKsoap2OE.jpg
    Capture-T-mobileAndroidKsoap2OE.jpg
    69.8 KB · Views: 3
In my opinion we have no choice: the we are all "google dependant"
"Java-Android-WS & Crome OS" ...
 

Attachments

  • Capture-Android Emulator (my_avd:5554).jpg
    Capture-Android Emulator (my_avd:5554).jpg
    22 KB · Views: 2
  • Capture-T-mobileAndroidKsoap2OE.jpg
    Capture-T-mobileAndroidKsoap2OE.jpg
    69.8 KB · Views: 3
You must log in or register to reply here.
Back
Top