This content has been marked as final. Show 5 replies
this also reproduces with JDeveloper11. I filed an enhancement request to automat this refactoring. I'll forward this post internally in case someone knows a good practice
Thanks for your reply Frank.
Any responses to your internal post for a good practice?
The simplest way to avoid this message is:
(*) Make the attribute data type change before you've enabled the custom view row java class
(*) or if that is not possible for whatever reason, temporarily disable the view row java classes in the dependent VO's, change the datatype of the attribute, then re-enable the view row java class. Of course, if you have any custom code in the view row class that you temporarily disable, you'll want to copy it into a temporary file so you can easily add it back after re-enabling the view row java class that you temporarily disable.
Thanks for your reply Steve.
The approach to disable "Generate Java File" for the View Row classes involved works, but indeed the DepartmentsViewRowImpl.java and EmployeesViewRowImpl.java source files are removed and recreated.
While trying this I was wondering, working with ADF BC in general, if it would be possible/desirable to never touch the generated ADF BC Java source files. Maybe by writing all custom code in subclasses of the generated classes and having those subclasses instantiated at runtime. I don't know, if this would be possible, that any advantages would outweigh possible disadvantages like more artifacts (Java source files) to manage or a negative influence on the design-time experience (like in the Data Control palet).
The ideal would be that Java have a "partial classes" feature like the C# or VB compiler offers where two distinct source code files were compiled into a single class file by the compiler. However, Java doesn't offer this. We've studied ways to more cleanly separate the generated code from user-written code, but none of the ideas we've experimented with has made it into the product as a feature yet.