FWD

Yes.

The conversion process creates the DDL to create the tables and indexes for the database. This can be run with only a simple hello world 4GL program (the conversion process needs at least 1 program specified). It will also create the Data Model Objects (DMOs) which are Java classes that represent the permanent tables of your database.

The database import can then be run on its own to import the .d files from a Progress OpenEdge DB instance. You can do this for as many instances as needed to migrate all your databases.

But doing this does not result in a database that the original 4GL code can use unless the 4GL code is converted and run using FWD. In other words, OpenEdge cannot access PostgreSQL or H2. The full FWD conversion of the 4GL source code is needed for that.

The "DB only" approach will miss all of the temp-tables which are converted only when you include all the 4GL application code in the conversion run. A full conversion of the source code will result in DMOs that represent all temp-tables in the application.

Hi Greg.
Is the DMOs in form of POJOs with anotations？
Can the DMOs be utilised in some MDD
Java RAD web frameworks such as Openxava. Apache Isis？

Is the DMOs in form of POJOs with anotations？

Yes, the DMOs are POJOs. We use Hibernate as the ORM layer. We do store some legacy 4GL schema information as annotations in these classes, but the core Hibernate configuration is in a separate .hbm.xml file.

Can the DMOs be utilised in some MDD

It will work fine if your tools are able to handle regular Java code and/or are compatible for using Hibernate for ORM.

Java RAD web frameworks such as Openxava. Apache Isis？

I have not used either of these. They both seem to be a complete framework for development. It is not clear how well they integrate with other technologies. Can they use Hibernate for data access?

If they can't use Hibernate, can they provide their own ORM layer using those POJOs? In that case, you would have to do some kind of mapping similar to how we do it using the .hbm.xml Hibernate configuration files.

A question for you: do you really want to throw away all of your 4GL code? Is there no value in the 4GL application itself?

Starting from scratch is a very expensive proposition, no matter what tools you use. Leveraging your existing code and evolving using the tooling/libraries/frameworks available for Java has proven to be a more successful approach in practice. It carries less cost and less risk.

Hi Greg,

Thanks for your detail explanation.

Openxava uses Hibernate and Apache Isis uses DataNucleus for data access.

FWD Code conversion's drop-in replacement is surely a very attractive solution for transforming our existing legacy 4GL applications.

However, it is not easy to obtain a rapid "error-free" converted result when the Progress 4GL application contains a lot of programs/modules after I tried the FWD Code conversion. Of course I will keep on trying to convert some programs/modules to see the result.

Besides, the system development and maintenance approaches after the conversion are important issues. Even though the conversion is success, our developers need to study the FWD run-time and related libraries to maintain the converted modules and build new modules respectively.

Therefore, I am looking for a way to reduce the coding from scratch and leverage the existing codes by combining FWD Code Conversion tool and different RAD Java Web frameworks.

Two more questions: can FWD tool convert the 4GL procedures/functions only and the converted business logic classes can be utilized in other Java frameworks?

Hi Greg,

I tried to convert DB only according to your hints and the results are fine.

Then I tried to convert some simple procedures with checking logic related to the DB. The procedure can be also converted.

Finally, I want to build the result codes to test them and the build is failed as below. Please help.

[javac] Compiling 1512 source files to C:\FWD\pprog\build\classes
    [javac] C:\FWD\pprog\src\test\pprog\dmo\uat9ampf3\impl\BocipMsSchrgEdateImpl.java:223: error: not a statement
    [javac]       secPayDate;
    [javac]       ^
    [javac] C:\FWD\pprog\src\test\pprog\dmo\uat9ampf3\impl\BocipSurchrgDtlImpl.java:221: error: not a statement
    [javac]       secPayDate;
    [javac]       ^
    [javac] 2 errors

BUILD FAILED

C:\FWD\pprog\build.xml:344: Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1416)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:1121)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:857)
at org.apache.tools.ant.Main.startAnt(Main.java:236)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:113)

The code in the default constructor for the sec-pay-date field in both the bocip-surchrg-dtl and bocip-ms-schrg-edate tables is somehow being generated incorrectly by the M0 portion of the conversion process. The strange thing is that the first-pay-date doesn't have the same issues even though it looks quite similar. There is probably something in the schema for the sec-pay-date fields that is causing us an issue.

Can you please post both ADD FIELD "sec-pay-date" portion of the .df file for these tables?

Also, please post your conversion cvt*.log from the run where you converted this schema and code.

However, it is not easy to obtain a rapid "error-free" converted result when the Progress 4GL application contains a lot of programs/modules after I tried the FWD Code conversion. Of course I will keep on trying to convert some programs/modules to see the result.

I'm guessing that the issue is you may be trying to convert some features that are not yet supported by FWD.

A key step in the process is to do a "gap analysis" of the code using the FWD Code Analytics tools. The idea is to just use the parsing and reporting portions of FWD to identify any code or schema elements that will cause a problem for the conversion (or for the runtime). Any missing support for 4GL features can be added to FWD during a project to convert the application. Alternatively, in some cases the usage of those features can be dropped if they are not really needed, or replaced if there are alternate approaches that are already supported. You can also temporarily exclude those files that have "4GL feature gaps" while support is being added to FWD. Golden Code can help you with the assessment and planning.

Not Yet Supported ABL Features
Gap Analysis
Code Analytics

At this point FWD contains so much of the 4GL feature set, that nearly all remaining features can be added in quite modest amounts of time. There are some bigger items like OO and ProDataSets, which will take some months for us to add, but there is nothing that would take years of work. For this reason, planning to add features to FWD to fill the gaps is a quite workable strategy. Manually rewriting a large 4GL application can take a decade or more. Spending 3 to 6 months improving FWD to fill gaps is much less expensive and also less risky.

Besides, the system development and maintenance approaches after the conversion are important issues.

Absolutely true.

Even though the conversion is success, our developers need to study the FWD run-time and related libraries to maintain the converted modules and build new modules respectively.

To the degree that the converted Java code is edited by your developers, this is true. However, this is not the only option.

FWD has two attributes that make it possible to continue to develop in the 4GL while using FWD as a deployment platform to run the result. This is enabled by the fully automated conversion process which can be re-run at any time, picking up the latest 4GL code changes each time. Combined with the runtime environment that provides compatibility this means that as long as you keep 4GL development within the supported 4GL features list of FWD (which is always growing over time anyway), you can continue developing in the 4GL for as long as makes sense. It is quite easy to add a FWD conversion run in to an automated build system or build process. You can think about it as a modified form of compiling/packaging your application.

You can develop new modules in either 4GL or pure Java code. From a UI perspective there are even really interesting capabilities to write pure Javascript code and make calls up to the converted code (basically it is like a Javascript Appserver client). There are a range of tools and techniques to integrate pure Java code functionality into the rest of the converted application. It is common for our customers to do some development in Java and some in the 4GL, depending on what makes the most sense for their application, their developers, their technical objectives and their business requirements. The choice is completely up to you:

• All development in 4GL; OR
• Mixture of 4GL and Java development; OR
• All development in Java.

This decision does not need to be made now, or even when you start deploying FWD. You can change the mix of development approaches over time to match your changing needs. As long as you have 4GL development going on, some or all of your code will be converted as often as it changes. Although there is great value in leveraging the Java capabilities, there is also great value in your 4GL development team. FWD allows you to maximize that value and evolve over time as makes sense.

For this reason, you don't necessarily need to have all the Java development answers up front. And over time, those answers may change.

Therefore, I am looking for a way to reduce the coding from scratch and leverage the existing codes by combining FWD Code Conversion tool and different RAD Java Web frameworks.

FWD is being deliberately enhanced to provide new 4GL features that don't exist in OpenEdge. An early list of the ones that are available now can be seen in FWD-Unique 4GL Language Enhancements.

We already are providing the ability to implement a 4GL UI as a web client. Our embedded web client mode (https://www.beyondabl.com/features-fwd.html#direct-to-web) shows the currently available capabilities. The current code is focused on supporting a compatible 4GL widget implementation.

But our objective here is to make FWD an environment in which a 4GL developer can write normal 4GL UI code and achieve a first class web and mobile result. The idea is to eliminate the need to integrate a separate web RAD framework and instead to continue to use the 4GL for direct web UI usage. This will require a range of improvements:

• Enhanced versions of existing 4GL widgets. The first one that we are working on is an enhanced browse. It is probably the most important widget and you can see our improvements in process in task #3261. Some or all of these features will be released in FWD v3.2 (which is going to be released shortly).
• Add new 4GL widgets (tree, tabs, calendar, data visualization...). These will be programmed using enhanced syntax for the 4GL
• Implement dynamic layout for all widget types, frames and windows. No more fixed positioning of the 1990s style 4GL GUI.
• Implement layout hints as a 4GL syntax extension. This will allow the developer to associate a layout pattern with each window and frame. The idea is that this will allow the same 4GL UI to implement a responsive design. For example, if you mark a frame as having a stacked, multi-column layout then on a wide desktop or tablet screen the widgets will be formed into multiple columns but on a narrow tall screen (e.g. a phone) only a single column would be used.
• Modernize the color and font processing.
• Full control over the look and feel through theming. This is already available in FWD v3.1.
• Add capabilities for direct 4GL output/reports for the full range of complexity including 2D graphics primitives, images, fonts, colors, barcodes without output to PDF, XLS and other common types. We already have some of these features implemented. The reporting engine we have put in place uses JasperReports and the 4GL code to leverage it is very clean and simple. See #3342 for details. This will also be available in FWD v3.2.
• FWD client for Android and iOS. The idea here is that there will be a native client on phones and tablets that can run pure 4GL UI code in a first class way.

See this presentation, pages 18 and 25 through 27.

In the 1990s, Progress did something very smart. They provided an evolutionary path from character mode (ChUI) to GUI. The same code would work in both, but the ChUI code would need some tweaking to make it look like a first class 1990s Windows GUI. You didn't throw away your investment and it was a reasonable effort to modernize.

In the GUI to web/mobile transition, Progress has made the decision that 4GL GUI is not strategic. They say you must drop that code and rewrite a new front end using native web and mobile technologies. But we disagree. FWD is the way to evolve your 4GL GUI code into a first class web/mobile result.

can FWD tool convert the 4GL procedures/functions only

I'm not sure exactly what you are asking here. Any external procedure that is converted, will convert to a business logic class. If that procedure has internal procedures, functions, triggers... those will all be converted too. The business logic class will have the same logical control flow as the original code, though in a "Java way".

You can choose the exact list of programs to convert by providing an explicit conversion list. If there are parts of a program that you don't want to convert you should edit that code (to remove or comment it) before running the conversion process. You can easily use preprocessor conditionals to have different code in OpenEdge versus FWD.

and the converted business logic classes can be utilized in other Java frameworks?

Yes, it is definitely possible to call into the converted code. This is possible in many ways including an appserver client, a secure remote object protocol or from Java code (that you write) that runs in the FWD server process. Any direct calls to the converted code do require that the FWD "session" is initialized first so that the block/transaction management will work properly. Even that session setup is a very small amount of code. Once the session exists, it is quite easy to call converted code.

Hi Greg,

As I did the test in my office PC, I will post the field and send the converted log file on next Mon.

Thanks for the reply with a very detail explanation on my queries.

IMHO, FWD conversion is a very powerful tool after further testing the tool.

By the way, I will see your attached links to learn more new FWD features.

According to your suggestion, 4GL can be used for system development and FWD conversion can be used for system deployment and maintenance.

This suggestion is feasible but 2 constraints I need to consider. 1. test the business logic in existing 4GL environment and then test the converted business logic in FWD to ensure both results are the same. 2. how to keep the data synchronization between the new DB and old DB when a portion of existing programs cannot be converted due to the complexities.

Actually I am studying the feasibility to convert some enquiry screens and reporting functions by using FWD and shift some users to use these in new FWD environment.

"But our objective here is to make FWD an environment in which a 4GL developer can write normal 4GL UI code and achieve a first class web and mobile result." This triggers me to come across a development tool (i.e. B4X) which helps the VB6 developers to write VB6 code to achieve web and mobile results.

Finally, I will study the related documents(i.e. conversion handbook and developer guide) more in depth.

Hi Greg,

Please find the attached files for reference.

I suspect that the use of INITIAL "Second pay end date" as the initial value for the date type is the cause of the problem. As the 4GL allows this, we will have to be more tolerant of it.

I've created task #3495 for this issue.

As a workaround, please edit the .df file and for those two fields, please use INITIAL ?. Then reconvert and compile the result.

4GL can be used for system development and FWD conversion can be used for system deployment and maintenance.

Yes.

2. how to keep the data synchronization between the new DB and old DB when a portion of existing programs cannot be converted due to the complexities.

Traditionally, we have focused on filling the gaps in FWD to allow entire applications to be converted rather than trying the data synchronization approach.

This triggers me to come across a development tool (i.e. B4X) which helps the VB6 developers to write VB6 code to achieve web and mobile results.

We have been thinking about a visual builder. Something along those lines may be an important part of the solution.

Hi Greg,

As per your advice, modified the .df file and the problem is solved. Thanks.

For the data synchronization issue, can the converted program do CRUD to the new DB and CUD to the old DB during the mixture of 4GL and Java development mode?

For the visual builder issue, will it be a plug-in in Eclipse or a new RAD IDE as B4X?

For the data synchronization issue, can the converted program do CRUD to the new DB and CUD to the old DB during the mixture of 4GL and Java development mode?

We don't currently support the Progress DB as a database that can be accessed from converted 4GL code. This means that code which is written in 4GL and then converted, would use the new DB, not the old DB. Although there is some possibility that we could add support for Progress DB, we also know there are some definite issues to investigate and resolve (see #3319). At a minimum, the effort to implement this would be non-trivial. For now, it is best to assume that the converted code doesn't use the Progress DB.

On the other hand, one could manually write pure Java code to push changes into the Progress DB using JDBC access and the Progress SQLEngine support. We have a variety of techniques that can be used to call this Java code from converted 4GL code.

For the visual builder issue, will it be a plug-in in Eclipse or a new RAD IDE as B4X?

We don't know about this yet. One idea we have is to take the open-source (Possenet) Appbuilder (which was written in the 4GL) and convert that to run in FWD. We would have to replace quite a number of native dependencies that are deeply built into the Appbuilder 4GL code, but the core of it is there and could be converted and executed. We would need to update it to support the new controls. We would also need to add better control over layout (enabling the dynamic layout features in a clean way). This approach would have the advantage of being quite familiar to many existing 4GL developers, but we haven't made any specific decisions yet.

Hi Greg,

I tried to convert the log screen only and ran convert.front without error. Then I ran deploy.all but the build is failed. Please help

------------------------------------------------------------------------------
     [java] Code Conversion Annotations
     [java] ------------------------------------------------------------------------------
     [java] 
     [java] Optional rule set [customer_specific_annotations_prep] not found.
     [java] .\abl\license\lcal05.p
     [java] Elapsed job time:  00:00:02.605
     [java] EXPRESSION EXECUTION ERROR:
     [java] ---------------------------
     [java] javaname = p2o.javaPropertyName(getNoteString("schemaname"), false)
     [java]                ^  { java.lang.NullPointerException }
     [java] ---------------------------
     [java] ERROR:
     [java] com.goldencode.p2j.pattern.TreeWalkException: ERROR!  Active Rule:
     [java] -----------------------
     [java]       RULE REPORT      
     [java] -----------------------
     [java] Rule Type :   WALK
     [java] Source AST:  [ _connect._connect-type ] BLOCK/PROCEDURE/BLOCK/INNER_BLOCK/KW_FOR/RECORD_PHRASE/KW_WHERE/EXPRESSION/KW_AND/LPARENS/KW_OR/EQUALS/FIELD_CHAR/ @108:8 {25769804785}
     [java] Copy AST  :  [ _connect._connect-type ] BLOCK/PROCEDURE/BLOCK/INNER_BLOCK/KW_FOR/RECORD_PHRASE/KW_WHERE/EXPRESSION/KW_AND/LPARENS/KW_OR/EQUALS/FIELD_CHAR/ @108:8 {25769804785}
     [java] Condition :  javaname = p2o.javaPropertyName(getNoteString("schemaname"), false)
     [java] Loop      :  false
     [java] --- END RULE REPORT ---
     [java] 
     [java] 
     [java] 
     [java]     at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:1068)
     [java]     at com.goldencode.p2j.convert.ConversionDriver.processTrees(ConversionDriver.java:1128)
     [java]     at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:978)
     [java]     at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:2017)
     [java] Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:16 [FIELD_CHAR id=25769804785]
     [java]     at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:274)
     [java]     at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:209)
     [java]     at com.goldencode.p2j.pattern.PatternEngine.apply(PatternEngine.java:1631)
     [java]     at com.goldencode.p2j.pattern.PatternEngine.processAst(PatternEngine.java:1529)
     [java]     at com.goldencode.p2j.pattern.PatternEngine.processAst(PatternEngine.java:1477)
     [java]     at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:1032)
     [java]     ... 3 more
     [java] Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:16
     [java]     at com.goldencode.expr.Expression.execute(Expression.java:484)
     [java]     at com.goldencode.p2j.pattern.Rule.apply(Rule.java:491)
     [java]     at com.goldencode.p2j.pattern.Rule.executeActions(Rule.java:738)
     [java]     at com.goldencode.p2j.pattern.Rule.coreProcessing(Rule.java:707)
     [java]     at com.goldencode.p2j.pattern.Rule.apply(Rule.java:530)
     [java]     at com.goldencode.p2j.pattern.RuleContainer.apply(RuleContainer.java:583)
     [java]     at com.goldencode.p2j.pattern.RuleSet.apply(RuleSet.java:98)
     [java]     at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:261)
     [java]     ... 8 more
     [java] Caused by: java.lang.NullPointerException
     [java]     at com.goldencode.p2j.schema.P2OLookup.getJavaName(P2OLookup.java:982)
     [java]     at com.goldencode.p2j.schema.P2OLookup.javaName(P2OLookup.java:579)
     [java]     at com.goldencode.p2j.schema.P2OLookup.javaPropertyName(P2OLookup.java:683)
     [java]     at com.goldencode.p2j.schema.P2OLookup.javaPropertyName(P2OLookup.java:650)
     [java]     at com.goldencode.p2j.schema.P2OAccessWorker$Library.javaPropertyName(P2OAccessWorker.java:263)
     [java]     at com.goldencode.expr.CE6943.execute(Unknown Source)
     [java]     at com.goldencode.expr.Expression.execute(Expression.java:391)
     [java]     ... 15 more

BUILD FAILED

C:\FWD\pprog\build.xml:213: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:113)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:857)
at org.apache.tools.ant.Main.startAnt(Main.java:236)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:113)

Hi Kenny,

Since the internal implementation of FWD is necessarily very different than that of the AVM and the Progress database, we don't automatically support all of the metadata/VST tables. We do support some of those most commonly used (e.g., _file, _field, _index, etc.). The state of support for any metadata in use in your application would be something we would evaluate in an assessment/gap analysis phase, using the code analytics tool set.

To enable support for metadata, one has to explicitly configure the conversion project to know which metadata tables are in use. This is done in the configuration file cfg/p2j.cfg.xml.

Please add the _connect table to your cfg/p2j.cfg.xml file. Right now, support for the _connect table is mixed. It should convert, but runtime support is spotty/untested. I don't think we currently have runtime support for the _connect._connect-type field you're using, for example. We would add this in the course of any conversion project that needed it, however.

In cfg/p2j.cfg.xml, under the schema/metadata section, add _connect. So, for instance, depending on which tables you were using, that section might read:

<metadata name="standard">
   <table name="_db" />
   <table name="_file" />
   <table name="_field" />
   <table name="_index" />
   <table name="_index-field" />
   <table name="_user" />
   <table name="_connect" />
</metadata>

That configuration change should get you past this conversion error, but like I said, the runtime support for the _connect table isn't fully there yet.

I suspect you already have this setup otherwise the code would not have parsed.

Just in case, I will mention how the metadata schema definition is handled. Make sure you have the exported metadata schema included in your configuration. We typically name this standard.df and place it in the data/ subdirectory with the other schemata.

cfg/p2j.cfg.xml must then have something to load it:

      <namespace
         name="standard" 
         importFile="data/standard.df" 
         xmlFile="data/namespace/standard.dict" />

Hi Eric,

Fixed issue as per your advice. Then tried to add some related .w files and ran convert.front and result is fine. Then, ran deploy.all. The build is failed. Please help.

[javac] Compiling 1556 source files to C:\FWD\pprog\build\classes
    [javac] C:\FWD\pprog\src\test\pprog\ui\sys\WMmstMenuMainMenu.java:10: error: cannot find symbol
    [javac]    public WMmstMMasterFileMZSubMenu mMasterFileMZ = SubMenuWidget.createStaticSubMenu(WMmstMMasterFileMZSubMenu.class, "mMasterFileMZ");
    [javac]           ^
    [javac]   symbol:   class WMmstMMasterFileMZSubMenu
    [javac]   location: class WMmstMenuMainMenu
    [javac] C:\FWD\pprog\src\test\pprog\ui\sys\WMmstMenuMainMenu.java:10: error: cannot find symbol
    [javac]    public WMmstMMasterFileMZSubMenu mMasterFileMZ = SubMenuWidget.createStaticSubMenu(WMmstMMasterFileMZSubMenu.class, "mMasterFileMZ");
    [javac]                                                                                       ^
    [javac]   symbol:   class WMmstMMasterFileMZSubMenu
    [javac]   location: class WMmstMenuMainMenu
    [javac] 2 errors

BUILD FAILED

C:\FWD\pprog\build.xml:344: Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1416)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:1121)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:857)
at org.apache.tools.ant.Main.startAnt(Main.java:236)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:113)

Eric spotted a potential cause. In the conversion log, it says:

[java] .\abl\sys\WMmstMMasterFileMzSubMenu

In the compiler error message, the class name is:

   WMmstMMasterFileMZSubMenu

Notice the former has a lowercase "z"; the latter has an uppercase "Z".

FWD must have a bug in dealing with the upper/lowercase in these menu/sub-menu names.

Can you please post a little of the 4GL code related to this menu/sub-menu definition (e.g. DEFINE MENU and DEFINE-SUBMENU) and the usage of it (e.g. if it is included in a menubar or popup menu...)?

The issue can be duplicated with a name like def sub-menu nop-i-i - note the two - chars - which generates MenuNopIISubMenu for Java class references in the generated code, while the actual class name (and file) is MenuNopIiSubMenu.

Kenny, task #3503 tracks the problem with the menu conversion; the patches which work with FWD v3.1 are in #3503-2 - please test and let us know of any other issues.

Hi Constantin,

As I am new to use FWD conversion, would you provide some hints on how to apply the patches?

Kenny Chan wrote:

Hi Constantin,

As I am new to use FWD conversion, would you provide some hints on how to apply the patches?

Please see #3503-3 - I've added a zip file which needs to be extracted in your p2j/ folder (there will be two files overwritten by this update), as is easier than using the patches. No rebuild is needed.

Hi Constantin,

Thanks for your reply. The build is successful after using the patch.