Oracle 9i JDeveloper - What's Hot? What's Not?
Dr. Paul Dorsey, Dulcian, Inc.
Oracle 9i
JDeveloper represents a leap forward towards creating a true integrated
development environment (IDE). JDeveloper can be used to design, develop, debug
and deploy all types of 3GL Java and other related files that are part of the
Java 2 Platform, Enterprise Edition (J2EE) strategy. It can also connect easily
to an Oracle database. JDeveloper contains many wizards and code generators
that make the internal mechanisms of Java easier, enabling developers to
concentrate on solving business problems.
In addition, this latest release helps to better organize and
encapsulate code and includes some configuration management functionality as
well.
JDeveloper History
JDeveloper’s roots go back to its license of Java-based tools from Borland in 1997. Using JBuilder source code as a foundation helped to speed Oracle’s entry into the Java development environment. The first 1.0 release (called “AppBuilder for Java”) in 1998 was still similar to its JBuilder roots. The renamed JDeveloper product’s next few releases demonstrated the tool’s maturation in the Java environment; however, they provided little support for building applications that would interact with an Oracle database. To build Oracle applications using JDeveloper required a great deal of effort, even on the part of a skilled programmer. For this reason, many of the early JDeveloper adopters were primarily Java developers looking for ways to make their applications interact with Oracle databases.
Traditional Oracle developers were frustrated by the poor efficiency of building applications in early versions of JDeveloper. It was not until the 3.0 release that Oracle’s direction for building Java applications to access an Oracle database became clearer through its introduction of Business Components for Java (BC4J).
Business Components for Java (BC4J)
JDeveloper's main advantage over other Java development tools is its Business Components for Java (BC4J) framework and associated code generators. BC4J is the heart of the JDeveloper product that sets it apart as the tool of choice for Oracle developers building Java or web-based applications. BC4J hides most of the work required to make Java code interact with relational database tables from the user. Prior to BC4J, building Java applications for a relational database was a challenging experience. Using an Oracle-supplied Java library, the JDeveloper wizards automatically generate almost all of the code necessary to allow Java applications to interact safely and efficiently with the database, solving the security, locking, and performance problems of the past. Swing components can be attached directly to BC4J objects.
With the 9i
release, BC4J now works with the J2EE framework. This includes new
functionality including:
·
Support of J2EE security standards
·
ExplainPlan for View Objects and View Links
·
Audit history attribute types
·
Easier debugging for EJB session beans
At its roots, BC4J is supported by a programming protocol or
standard that describes how to build classes that will interact with a
relational database. JDeveloper uses BC4J as the primary way of handling
database DML operations (queries, inserts, updates, and deletes).
JClient
In addition to BC4J,
JDeveloper offers a feature called JClient that facilitates connection to a
Java application Swing component to a database object (through BC4J) with a
single property setting. This feature is found only in JDeveloper and is
extremely useful and highly productive. JClient has a counterpart in the BC4J
Data Tags Library that provides the same easy-to-use connection for JavaServer
Pages HTML-based applications.
JavaServer Pages (JSPs)
JDeveloper’s JClient architecture allows developers to build Java applications or JavaServer Pages to access an Oracle database with much more confidence. A JSP produces an HTML page that is sent to the client. It is compiled into a servlet, which is a pure Java program. Though most of the business logic can be written in Java, the UI portion is usually created in HTML.
Future Improvements
The redesign of the 9i release did not change the basic ways
in which developers work with the tool. However, the new interface is more
intuitive, often faster, and more consistent than previous releases. For those
accustomed to working with earlier releases, this release requires some changes
in the operations used. The 9i
release offers more consistency in the IDE work areas.
In the short term, Oracle is justifiably satisfied with the core architecture of the product. Now they are working to improve the product’s application development efficiency. Future JDeveloper improvements may eventually deliver improved wizards to help automate many of the tasks currently required to develop applications and to help close the gap between JDeveloper and Forms Developer for intra-company application development.
A second short-term improvement will focus on JDeveloper as a modeling and design tool. The current Class Modeler reflects Oracle’s interest in using UML to design databases. By the end of 2003, JDeveloper may be competing with Designer as a data modeling tool. Other parts of the UML will also be incorporated into JDeveloper to support more of the software development lifecycle.
Over the long term, JDeveloper should become a completely integrated design and development environment including full UML integration and improved JSP development capability.
Moving to a Java Development Environment
There are many competing Java development tools on the market including Visual Café, JBuilder and Forte. However, for working with an Oracle database, JDeveloper has no real competition. It is by far the best tool for building Oracle-based Java applications and an almost complete JSP solution.
For the 9i release, JDeveloper's IDE was completely rewritten in Java. The
choice of Java means that JDeveloper may be run in the Java Virtual Machines
(JVMs) of different operating systems with few, if any, changes. This makes
JDeveloper extremely portable.
However, moving from a traditional client/server environment to a Java/Web environment is not a simple task. In the “good old days,” only one or two products and languages were needed to develop applications. Table 1 illustrates the tools and languages needed to develop different types of applications in a Java environment.
|
|
Oracle Developer Client/Server |
Java Applications |
Java Applets |
JavaServer Pages (JSPs) |
|
Tools |
Oracle Form Builder SQL*Server or TOAD |
JDeveloper SQL*Server or TOAD |
Oracle Form Builder SQL*Server or TOAD Apache or IAS |
Oracle Form Builder SQL*Server or TOAD Apache or IAS DreamWeaver or FrontPage |
|
Languages |
SQL PL/SQL |
SQL PL/SQL Java XML JDBC SQLJ |
SQL PL/SQL Java XML JDBC SQLJ |
SQL PL/SQL Java XML JDBC SQLJ HTML JavaScript |
|
Security Issues |
|
|
Firewalls Secure Sockets Encryption Keys |
Firewalls Secure Sockets Encryption Keys |
Table 1: Products and
Languages needed for Application Development
The number of tools that a developer needs to master in a Java environment has increased dramatically when compared to the traditional client/server environment. For JSPs in particular, the number of tools and technologies that need to be mastered is quite daunting. JDeveloper will have to mature as a product or the underlying architecture will have to change before JSP development becomes popular in the Oracle environment. There has even been a recent surge in discussions about resurrecting the idea of client/server-style architecture for the Web. The author is currently working on a project to investigate the idea of a thick client for the web (termed “thicknet”). Anyone interested in further details is welcome to contact the author.
In JDeveloper projects, BC4J components will have both XML and Java files associated with them. The XML file holds the metadata that defines the business component, and the Java file holds the methods that implement the business component. The .java file contains get( ) and set( ) methods, which dynamically generate insert, update, and delete statements at runtime.
BC4J Structure
The BC4J wizards read the Oracle system views to obtain metadata representing the database structure. Using this metadata, the wizards generate XML and Java code that provides a customizable framework to which data validation or other business logic can be added.
BC4J enables Java applications to easily communicate with a relational database. By interacting with the BC4J wizards, XML files and Java classes can be generated. Application developers can then write Java code, which will interact with the BC4J-generated classes that handle communication with the database. These generated classes function because of an Oracle-supplied Java library containing all of the complex database interaction routines.
BC4J Components
The BC4J components
allow for the conceptual division of applications into user interface/client
logic and database interface/business logic portions.
The BC4J components fit into three major areas:
1. Entity objects and associations
2. View objects and view link objects
3. Data model
Entity objects are based on database tables, views, snapshots, or synonyms and include the database storage requirements. Entity objects can be generated from existing database objects, or they can be manually defined and used to create new database tables. Entity objects contain attribute (column) definitions.
An association defines the relationship between pairs of entity objects. Typically, associations represent a foreign key constraint from the database, but they may be defined for any pair of entity object attribute components. It is also possible to specify more than one attribute on each side of the association, as long as the same number of attributes are present on each side. The association is bidirectional.
View objects use SQL queries to specify and filter data that is defined in the entity objects. Client applications can navigate, update, insert, and delete data using the view object's get()and set() methods.
View links are used to express the relationships between view objects. These relationships are only implemented in one direction. Thus, in a master-detail relationship (the master being the source and the detail being the destination), only the source objects have get/set accessor methods defined. View links provide the filtered rows for the detail table, for the current row selected in the master table.
The data model consists of a collection of views. It is the element with which the UI applications interact.
The BC4J components provide a number of benefits:
·
Logical code organization.
·
Code maintainability can be improved by moving
shared code into the BC4J layer.
·
BC4J classes are easily portable and can be
deployed on the database server, application server, or locally on the client.
·
BC4J classes can implement complex validation.
· Development time is reduced.
· Data can be cached to improve performance.
Application Modules
Application modules instantiate the BC4J view objects and view links with which the client applications will interact. It is possible to have multiple application modules within the same BC4J layer. It is also possible to nest application modules within other application modules. Multiple application modules may be needed to implement the business logic for a particular application screen or task, giving each logical part its own module. Typically, an application module would contain three to four view objects and links, though it might contain many more. A large application could have 20 or more application modules, each containing the appropriate view objects and view links for a given task.
BC4J Capabilities
Application-specific BC4J entails building a set of Java classes that wrap the DML commands and that reference an XML document that stores the data structure definition. These Java classes extend the base BC4J library classes that make the JDBC calls to the database that take over all of the insert, update, delete, and lock functions required to make the applications run. This enables complete encapsulation of the logic associated with database access. It also provides developers an ease of application development similar to that of basing blocks on tables in Oracle Forms Developer.
BC4J classes can cache data to be shared among multiple users, providing performance benefits since no access to the database is required.
BC4J also has the
advantage of being “deployment-configuration independent.” A single BC4J layer
can be deployed as local Java classes or as an Enterprise JavaBean (EJB), with
no rewriting of code necessary. Programmers using business components, unlike
those creating Enterprise JavaBeans from scratch, do not need to design
applications around their deployment architecture; they can concentrate on
their business logic rather than on deployment requirements.
Complex Validation
Frequently, complex validation is placed in database locations such as triggers on tables, or views with INSTEAD OF triggers. INSTEAD OF trigger views are Oracle views that replace the default insert, update, and delete behavior with user-supplied triggers. Using JDeveloper, several options are available. One strategy is to place complex validation in the database tier but this may impact performance. A second option is to place it in the middle tier (application or web server). Finally, validation can be placed locally in the client, usually leading to faster performance, easier debugging and maintenance as long as the code is not duplicated elsewhere. The factors that should be taken into account when determining the placement of the complex validation are as follows:
·
Hardware configuration
·
Deployment strategy
·
Number of and types of clients
· Ease of debugging and maintenance
Complex data validation can also be implemented within BC4J classes. Despite this additional option, it is still difficult to set guidelines for the circumstances under which data validation logic should be placed in the database as opposed to placing it in the BC4J components. In an environment that is not 100 percent Java, placing validation in BC4J components may be dangerous. Some applications will access the validation through BC4J, while other applications written in different products may be unable to access the validation logic through BC4J. In a completely Java-based environment, JDeveloper makes the creation and manipulation of BC4J components easy enough to choose to use BC4J over server-side validation because reduced development time means lower costs. However, this is only appropriate when all data-modifying DML operations will use the BC4J components.
The advantages of
using the BC4J layer for complex validation are as follows:
· Performance improvements can be achieved by placing validation in the BC4J layer. In some applications, it may be possible to achieve dramatic improvements because code is applied at the business logic level instead of at the database level, which requires network messaging.
· Support for overloaded tables is possible since multiple entity objects may point to the same table. This can be useful for developers trying to support abstract data models containing overloaded tables. For example, in the classic single table implementation of an Employee supertype with Salaried and Hourly subtypes, there is a single Employee table with a Type column. Both hourly and salaried employees are stored in the same table. Using the BC4J layer allows for the creation of independent entity objects for salaried and hourly employees with attributes pointing to the appropriate columns in each. However, the same functionality can be achieved just as easily with views in the database.
Approaches for Using BC4J
With Oracle9i JDeveloper and J2EE, an application can be built in many ways. System business rules may now reside in any of the following places:
·
Core database procedures and triggers
·
Database views with INSTEAD OF triggers
·
BC4J entity objects and associations that
interact with tables
·
BC4J view objects and view links
·
Application logic
There are several schools of thought about how to use BC4J in applications. Business rules should not be placed in application logic or view objects. They are only listed here because it is possible to place the logic in those locations.
Some assert that the opposite is true, and that all business logic should reside in the database, with subsets used as needed for applications. Others say that virtually all business logic should be stored in the BC4J layer, with the database used as nothing more than a place to hold persistent copies of the data in the classes. The proponents of each strategy adhere to their development style with great tenacity.
This section discusses the pros and cons of these two approaches. Keep in mind that these approaches depend on JDeveloper’s ability to support them. As JDeveloper’s capabilities expand and evolve, the advantages and disadvantages may shift, and approaches that are barely workable now may become much more viable in future releases.
Database-Centric Approach
The database-centric approach assumes starting with a complete, functioning Oracle database. While logically designing applications, it will be evident that they can be built more easily with database views corresponding to the user interface elements. These views can be built using INSTEAD OF triggers to support insert, update, and delete functionality.
All fields to be displayed in the view objects are columns of the database views. For each program, build a small BC4J project including entity objects and associations that have a one-to-one relationship with the tables, views, and foreign key references necessary to build that program. Next, create a default view object and view link for each entity object and association. These are then assembled into an application module to support the front-end program.
Validation logic is added to the entity objects only for the purpose of enhancing performance, since all business logic is already validated within the database. Only rarely are additional attributes added to entity objects or view objects since these attributes are already included in the foundation views located in the database.
Each program has its own BC4J project. BC4J projects are not shared by other programs. Application modules are kept relatively small, encompassing more or less the same scope as an Oracle Forms Developer file.
Advantages of a Database-Centric Approach
Using a database-centric approach to creating applications has the following advantages:
·
This approach is the most comfortable for
existing Oracle developers. It uses basically the same philosophy as creating
any front-end application for an Oracle database.
·
The system is not closely tied to JDeveloper and
BC4J. Most of the non-UI code resides in the database. For example, programs
that do not access the BC4J layer will still use the code in the database,
because all of the business rules reside in the database.
·
Almost all BC4J work can be supported through
the JDeveloper wizards. Little hand-coding is required. The BC4J project for an
application module can be built in a few hours or less because only one default
entity object definition for each database view is being used.
Disadvantages of a Database-Centric Approach
The following are some of the disadvantages of creating applications using a database-centric approach:
·
This approach ignores all of the power and
flexibility of BC4J. With entity objects and view objects, two new layers of
abstraction are sitting on top of the database that are not used by this
development strategy.
·
This
approach does not support BC4J reuse. One of the key elements of the
BC4J architecture is the ability to build and reuse BC4J projects.
·
This approach does not take advantage of the BC4J
cache. This is one of the main strengths of BC4J, because it offloads database
activity to another location and thus saves the CPU cycles of the database
server to fulfill its primary purpose—to manage data. The BC4J layer can cache
rows and maintain consistency with the database. This reduces the number of
network messages and the amount of database activity required to serve data
that has already been served.
·
This approach does not take advantage of BC4J’s
support of Web Tier and Business Tier servers. BC4J supports the J2EE notion
that there is a benefit in splitting out some of the application code to
another server. If the database is called upon to handle application code, its
efficiency to fulfill the primary directive will be compromised by having to
handle complex business logic.
·
The application is heavily tied to the Oracle
DBMS idea of views with INSTEAD OF triggers. This approach cannot be used to
build cross-database applications unless the other database provides a
structure similar to views with INSTEAD OF triggers.
·
It is necessary to have talented PL/SQL
developers. If your organization is primarily a Java shop, this approach makes
little sense.
Business-Logic Tier Approach
The business-logic tier approach also assumes starting with a complete, functioning Oracle database. The main difference with this approach is that the business logic is contained in Java class files that reside outside of the database. Carried to extremes, this approach would mean creating only one BC4J package, containing entity objects and associations, to support an entire enterprise data model. One entity object is created for each table in the database. Separate projects containing view objects, view links, and application modules can then be built to correspond to the structures that the program requires. A BC4J application module is then built for each program. Business rules are added to the entity objects, possibly backed up by redundant rules in the database for added robustness.
In the case of a large enterprise data model, it can make sense to partition the entity objects and associations created from the database into smaller subsets, to make handling them at design time easier. For example, the 300 entity objects corresponding to a 300-table system could be partitioned into approximately 10 application modules of 30 tables each. Sets of tables with many relationships between them should be placed in a single package together with associations representing those relationships. Cross-package relationships should be represented by associations in the same package as the view objects, view links, and application modules that use them. One entity project will then be shared.
As mentioned earlier, view objects are not simply default images of the entity objects, but often gather information from multiple entity objects simultaneously. In fact, view objects need not be based on entity objects at all, but can instead cache database data directly themselves. One entity object and association will then be shared by many (5–20) different packages containing extra associations, view objects, view links, and application modules. Simple programs usually have one application module for each program, but it is not uncommon for a program to have more than one application module, or for two programs that accomplish similar tasks to use the same application module.
Using this approach, validation resides in the BC4J layer, and possibly redundantly in the database.
Advantages of the Business-Logic Tier Approach
The following advantages can be gained using this approach:
·
BC4J caching, project reuse, and independence
from the database are useful aspects of this approach.
·
This approach, if used correctly, will afford
the greatest development efficiencies because of the increased modularity of
the persistence/business logic layer.
·
This approach takes advantage of BC4J’s ability
to offload activity from the database server as mentioned in the disadvantages
of the previous approach.
Disadvantages of the Business-Logic Tier Approach
The following are some of the disadvantages of this approach:
It is a conceptually difficult approach because business
rules of the system may reside in different places. For example, the rules may
reside in tables, entity objects, or view objects. Standards and guidelines for
the use of the different code locations must be developed and enforced.
Organizations embracing this strategy should be careful to
formalize the rules. The rules apply to the database, entity objects, and view
objects. They need to answer questions such as “How will objects be constructed
and how will they interact?”
Without careful planning, the additional flexibility afforded
by BC4J can result in systems where bugs are difficult to track down. This is
because the logic error may reside in many places. Well-designed error messages
can assist in reducing this problem.
JDeveloper Application Architecture
JDeveloper applications are organized into workspaces and projects. A workspace is equivalent to a directory that holds the projects (files) that make up the program. A separate connection file is required in order to connect to the database. The following diagram shows a typical JDeveloper application structure:
Workspace
BC4J Project
Entities and associations
Views and view links
Module (based on client data model)
UI Project
Class (.java files)
Items
Client data model (.cpx)
Connection (used by BC4J project)
Workspaces
Workspaces are the highest level container in JDeveloper and consist of a logical grouping of files. A workspace can include multiple projects, all of which make up an entire application. When working with JDeveloper, more than one workspace can be open at one time. Physically, workspaces contain names and locations of other files with a (.jws) extension as shown in Figure 1.
Figure 1: JDeveloper Navigator Interface showing Workspaces
Usually, there will be one workspace per application or logical portion of an application.
Projects
JDeveloper projects can contain a single file or many files belonging to different application tiers. Physically, projects are files (with a .jpr extension) that are pointers to other files. Projects reside in one package (directory). Many applications require at least two projects: one for the business components and one for the user interface or JSP.
Packages
JDeveloper packages are equivalent to directories. They hold all of the entities, associations, views and view links needed by the projects in a particular workspace. For example, Figure 2 shows the locdept package for a BC4J project containing location and department information.
Figure 2: JDeveloper package
If everything is not placed in the same package, it will be necessary to refer to objects in other packages as package_name.object_name.
New and Improved Features
Since the release of JDeveloper 9i in the spring of 2002, Oracle has been working continuously to improve the product. The 9.0.3 release includes several new or enhanced features that can help make development easier and more efficient. A few are mentioned here.
Class Modeler
JDeveloper’s Class Modeler supports the modeling of Java classes very nicely. Currently, it only supports modeling BC4J entity objects. The 9.0.3 release also allows development of Enterprise JavaBeans and interfaces in the UML class diagrams created in the Class Modeler. Much effort is being placed into improving and expanding this portion of the tool for the 9.0.4 release in 2003. An example of a simple Departments/Locations class diagram is shown in Figure 3.
Figure 3: Example of a diagram using the JDeveloper Class Modeler
Software Configuration Management (SCM)
JDeveloper includes a way to link to the Oracle Software Configuration Management (SCM) repository. Formerly known as the Designer Repository, this feature can be used for version control and configuration management including Check-in and Check-Out, Compare and Merge functionality.
Oracle SCM provides
isolated working areas, controlled access to software configuration management
functions, and allows for:
·
Object
version control using check-in and check-out procedures
·
Parallel
development through branching
·
Comparison
and merging of object versions
·
Creation
of coherent sets of selected object versions
Workareas, configurations, branches, versioning, and access control
provide this functionality in Oracle SCM.
Other SCM options
within the JDeveloper IDE include listing checked-out and non-versioned files
and synchronization between the file system and the SCM repository.
Enhanced JSP support
BC4J support for JavaServer Page technology has been enhanced. The JDeveloper wizards can generate starter JSP pages. An expanded BC4J Data Tag Library and struts support allows for easily adding tags and struts to JSP projects.
Code Insight
JDeveloper offers the Code
Insight feature to help write code for Java, JSP, XML, XSL, UIX, and HTML
source files. Using Code Insight accesses context-sensitive lists of elements that
are appropriate to the type of file being edited. The list appears in the Code
Editor after typing a period and pause or press ctrl-spacebar. For example, for
Java class files, Code Insight displays lists of methods, constants, imports,
and method parameters.
After a selection is made from the list, press Enter to fill in the selected text. Alternatively, you can keep typing and navigate to a match in the list. Clicking outside the pulldown list (or pressing esc) will dismiss the list. This style of Code Insight is called completion insight because it completes the code being written.
Another style of Code Insight,
called parameter insight, displays a list of valid parameters. A list of valid arguments for a method will automatically appear when an opening
parenthesis character is typed or if ctrl-shift-spacebar is pressed. It can be used as a reminder of the types of
objects or variables that can act as parameters to the method.
Code Coach
If running in a Windows environment, CodeCoach is a
JDeveloper feature that provides hints about how to optimize your code. When
CodeCoach is activated, programs will run as usual but after exiting, a list of
suggestions for improving the code will be shown in the Log window. CodeCoach can
be used on Java code if it runs within the Oracle JVM, is executed locally, and
has been compiled with the Oracle Java Compiler. (JDeveloper uses this compiler
automatically.)
Why Use JDeveloper?
Oracle has seemingly decided to pursue JDeveloper as its primary development platform. Oracle9i JDeveloper is built upon the Java 2 Platform, Enterprise Edition (J2EE) and therefore sits on a stronger foundation than any other product in Oracle’s history. This new technology has a great deal of support from other vendors and the backing of recognized standards.
JDeveloper is still not the complete web application development solution for a traditional Oracle developer who is used to the simple “one product development environment” of Forms Developer. Support for the visual design of the HTML page is still quite limited compared with a tool such as Microsoft FrontPage. Developers currently using Forms Developer and PL/SQL cannot simply replace those with JDeveloper and Java to create complex client/server–style applications deployed over the Web.
JDeveloper can be used very effectively for developing Java applications. JSPs require a slightly steeper learning curve but they can be well supported with JDeveloper. Is JDeveloper a replacement for Designer? Not yet; but Oracle seems to be moving in the direction of making JDeveloper its one unified development environment in the future.
High-Level and Low-Level Wizards
JDeveloper includes many different wizards to make development easier and faster as well as allowing less experienced developers to be productive in the tool fairly quickly. Some of these wizards build substantial portions of an application. Others build single components such as a class or entity object. Wizards that are broader in scope and that build multiple components forming a significant portion of a project (such as a BC4J project containing many objects) can be referred to as “high-level” wizards. So-called “low-level wizards” only build single components such as an entity object.
When learning to use JDeveloper' the high-level wizards can help build working applications quickly. However, these high-level wizards frequently do not build applications as desired. For many production applications, the low-level wizards and dialogs will be needed to set more specific preferences and functionality, or modify the code that the high-level wizards create. The flexibility to use both types of wizards is another one of JDeveloper’s strengths.
Three Tips
JDeveloper is solid product, but it still has its quirks. Here are some tips that will help avoid hours or days of frustration.
1.
Use single object (low-level wizards) for
development. Do not use the high-level
wizards that build a large part of an application in a single step. The high-level wizards make too many
decisions at once and do not always create what is really needed in the
application. It takes a little more time
to use the wizards that build one component at a time but then there is better
control over each component. The high-level
wizards are fine for sales demos, but developers would do well to avoid them.
2.
Do not rename components after they have been
created. This is a 3GL environment. Renaming
an object means that every reference to the renamed object in the application
must be changed. For complex programs, JDeveloper sometimes misses one or more
references that need to be changed.
Sometimes the non-renamed element still has code generated that is
associated with it, so it may be weeks until it is discovered that the renaming
operation was not totally successful. To
rename a component, delete it and recreate it.
3.
Use the Windows look-and-feel. There are still
some inconsistent bugs in some of the other look-and-feel options.
More Information
As products evolve more and more rapidly, it is particularly
important to stay abreast of the changes as they occur. In addition to Oracle
Support Services, the Oracle Technology Network (otn.oracle.com) products area
contains lots of useful information as well as a very active JDeveloper
discussion forum. The ODTUG list servs and
Conclusions
In the Oracle environment, JDeveloper has numerous strengths and a few weaknesses. Its main advantages over other development products include:
·
A good integrated development environment (IDE)
·
Easy-to-use interfaces including wizards,
property inspectors, toolbars, code generators.
·
Excellent Oracle database connectivity
· Support for all Java development
· Good user interface
Oracle9i JDeveloper is built upon Java 2 Platform, Enterprise Edition, which is a stronger foundation than any other product in Oracle's history. In the past, with Oracle's earlier products, compromises had to be made based upon existing technologies, as well as backward compatibility, and internal Oracle politics. JDeveloper is based upon a technology that has vast support from other vendors in addition to well recognized standards.
JDeveloper’s weaknesses include a steep learning curve and some inefficiencies for application development because of additional tools and languages required to create complete systems. The ultimate goal is a single, integrated development environment for all Oracle systems. Design, creation, and maintenance of both database and applications will all be handled using one product. JDeveloper will probably eventually include the functionality of other products such as Oracle Designer and Oracle Forms Developer as well as third-party products such as Quest Software’s TOADÒ or SQL NavigatorÒ. The realization of this vision is still a few years away. When Oracle brings this vision to fruition, Oracle professionals will have the integrated design and development environment they have dreamed of for so long.
About the Author
Dr.