How to assert that assert works in Rational Application Developer
Written by Chintan Rajyaguru
Saturday, 09 September 2006 17:34
JDK 1.4 added a keyword called
assert. You can use assert on a boolean expression that you believe will be
true. If the expression is not true, the program throws an error. Using assert
(and not receiving any errors) increases your confidence in your code. You can
use assert (as opposed to System.out) to debug your code. Visit this link to
learn more about assert: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
So far so good but I wouldn't be
writing this blog entry if assert was this simple. Since assert was NOT a
keyword prior to jdk 1.4, you could use it as an identifier as in
private String assert;
Obviously, jdk 1.4 would give you
an error because assert is a keyword in jdk 1.4 and the statement above isn't
the legal use of assert. To avoid this problem, jdk 1.4 compiler was designed
to be 1.3 compatible by default. So, if you write code in jdk 1.4 using assert
as an identifier and compile it, you will simply get a warning because for
.class files, it uses jdk 1.3 compatibility.
The so called 'feature' described
above caused me some trouble when I recently switched my IDE. My code was using
assert in jdk 1.4 way (as in)
assert idao != null;
When I compiled my code, RAD
compiled it against jdk 1.3, thought assert was an identifier and gave me an
error. The link above explains that you must use -source 1.4 flag to correctly
recognize assert statements.
To fix this,
I went to Window > Preferences > expand Java > select Compiler > Compiler and Classfiles
tab
Unchecked Use default compliance settings
Selected 1.4 in both source and .class files compatibility
This may not remove all the
compilation errors however. RAD (and eclipse for that matter) by default uses
compiler settings at project level so Window > Preferences settings may not have any effect.
This makes sense because not all the projects in a workspace may belong to a
single application. You may have some projects in an old application that you
might want to compile against an older version of jdk.
To fix this,
Right click the project and go to Properties
Select Java Compiler
Either set source and .class files compatibility to
1.4 OR choose workspace settings
The only pain point is, if you are
migrating an application with many projects to a new RAD or WAS 6.1 toolkit,
you may have to do this for all the projects.
Most
application that allows multiple windows allow you to switch between them using
ctrl+tab key. Not eclipse. It uses ctrl+F6 and so does RAD etc. But this can be
changed. To change the key that switches between classes (small windows within
eclipse),
go to Window
> Preferences > expand Workbench > select Keys
In the Category
dropdown, select Window
In the Name
dropdown, select Next Editor
Put the cursor
in the Name field in the Key Sequence section and press ctrl+tab. Do not
type ctrl+tab, press those keys
Click Add, the
key assignment is added to Assignments section
Optionally,
remove the ctrl+F6 assignment by selecting it and clicking Remove button
Click Apply and
then OK buttons to close the dialog box
If
you are using eclipse 3.1.2 OR WebSphere Application Server toolkit v6.1, the
procedure is similar but the buttons are little different:
go to Window
> Preferences > expand General > select Keys
In the Category
dropdown, select Window
In the Name
dropdown, select Next Editor
Put the cursor
in the Name field in the Key Sequence section and press ctrl+tab. Do not
type ctrl+tab, press those keys
Click Add, the
key assignment is added to Assignments section
Optionally,
remove the ctrl+F6 assignment by selecting it and clicking Remove button
Click Apply and
then OK buttons to close the dialog box
There
are all kinds of considerations when migrating an application from WAS 5.x to
6.x. But I want to talk about moving projects from WAS 5.x to WAS 6.x within
Rational Application Developer. This change could come in two flavors:
Moving from
WSAD to RAD
Moving from
RAD using WAS 5.1 to WAS 6.0
Before
we talk about specific steps to follow, it must be noted that every J2EE
project in WSAD or RAD uses at least 2 variables. Both of these variables are
predefined in the IDE and point to specific set of jar files:
JRE System
Library variable, which can be configured to point to any valid JRE. While
you have the option to use the eclipse JRE that comes with the IDE, I
recommend against it. The JRE System Library variable should point to
WebSphere JRE because the code is ultimately going to run in WAS runtime
environment.
WebSphere v5.1
runtime, which is added by WSAD or RAD when the project was created for
WAS 5.x server. This variable includes all the J2EE and WebSphere
libraries needed to build the project
In
any case you can follow these steps to move the project:
If the project
doesn't exist in RAD already, import it using File > Import >
Existing Project into Workspace, select the directory that contains the
.project file and click Finish
Upon
successful import, one or more of the following could happen:
If you are
using RAD and if you have installed WAS 5.x test environment, you should
not get any errors. To use WAS 6.x runtime in this case,
Right click
the project, select Properties > Java Build Path > Libraries tab
Select JRE
System Library variable and click Edit button
Click
Alternate JRE radio button, select WebSphere v6 JRE from the dropdown
and click Finish
Go to the
Server section in the Properties dialog box and select WebSphere
Application Server v6.0 in the Target runtime dropdown
Click OK to
close the Properties dialog box, the project should rebuild itself
If you
haven't installed WAS 5.x test environment, you will get errors upon
importing a project that has WAS 5.x entries in its classpath. In that
case,
Right click
the project, select Properties > Java Build Path > Libraries tab
If the JRE
System Library variable has an error, remove it
Click Add
Library button, select JRE System Library click Next
Click
Alternate JRE radio button, select WebSphere v6 JRE from the dropdown
and click Finish
Remove the
WebSphere v5.1 runtime entry
Go to the
Server section in the Properties dialog box and select WebSphere
Application Server v6.0 in the Target runtime dropdown
Click OK to
close the Properties dialog box, the project should rebuild itself
If
any of your projects had generated EJB code, you will get a number of
compilation errors that won't make much sense, just delete all the generated
code and do a clean build. If you will start using JDK 1.4 with this move and
have assert statements in your code, there are some other considerations but I
will write about that later.
WebSphere
v6.1 is out
for a while now. I recently got an opportunity to use it in the development
environment and wanted to list my quick thoughts here:
First off,
there is no production release of Rational Application Developer (RAD) for
WebSphere v6.1 yet. WAS 6.1 ships with a so called Application Server
Toolkit (AST). In my personal opinion, toolkit is a misleading word as it
makes customers think it's some sort of beta tool and not suitable for
serious development. This perceived lack of development tools may even
cause a delay in WAS 6.1 adoption. While I believe IBM should have
released RAD 6.1 with WAS 6.1 (more on this in some other post), I also
believe the toolkit has all the coding features an average development
project needs. Some RAD features e.g. UML modeling are missing. If you are
still not clear what AST offers, think of AST as WSAD for WAS 6.1
Second, you
cannot install the toolkit with WAS 6.1 test environment. You must install
WAS 6.1 and toolkit separately and then point the toolkit to WAS 6.1
installation directory to use the server. I am not sure whether this is
how RAD 7.0 (which is supposed to be the IDE for WAS 6.1) will work or RAD
7.0 will continue to have WAS install within its runtimes directory.
Personally, I like the ability to use separate installation of WAS. This
gives the flexibility to run the server outside the IDE and deploy and run
applications on it.
Third, the
toolkit appears to support export and import of server profiles. Thank you
IBM! In WSAD, an experienced developer could configure all the server
parameters and distribute the server profile to the rest of the team. In
RAD, this feature disappeared forcing every developer to go through the
painful steps of configuring the server. But, looks like now this feature
is back. At least it's back in the toolkit. I haven't personally used it
yet (may be I will use it next week)
Forth, Since I
am using a separate server installation, I have to rely on the log files
created within the server. In other words, not everything is printed on
the old friend console within the IDE. This may not be true for RAD 7.0
but it's true for the toolkit. Also, if you are using WAS 5.x, the log
files are at
<app_server_home>/logs/<server_name>/<log_file_name>.log
but WAS 6.x uses the concept of cell, node and profile. The new location
for the log files is, <app_server_home>/profiles/<profile_name>/logs/<server_name>/<log_file_name>.log
Listed
above are all the WAS 6.1/toolkit features related observations. Here are some
miscellaneous observations. It's possible that some of these were implemented
in WAS 6.0; consequently, the list below is more useful to some one migrating
from WAS 5.x:
By default WAS
6.1 installs as a windows service. I wish I could choose against it
Security on WAS
installation is turned on by default
I
absolutely love the format and formatKey attributes of bean:write tag in Struts
framework. You can use these attributes to format the display of your form bean
properties. This works pretty well in displaying currency and date/time values.
For example, you can display 1234.567 as $1,234.57 and 08/12/2006 as Aug 12,
2006. Here is how it works:
myapp.currency.format=$#,000.00
(in resource bundle)
The
preferred way is to use the second format because it makes the code portable.
Plus, if you want to change the format, you can make the change in resource
bundle without having to worry about changing all your JSPs.
So
far so good. When I tried to use this feature in one of my recent projects, it
didn't work! Why? Because the type of the property being formatted cannot be
String. The format attribute simply uses default format (display the property
as is) when the property is of type java.lang.String. In other words,
private
double amount; // will be formatted correctly
private
String amount; // will NOT be formatted at all
This
could be a feature or a limitation but I haven't been able to figure out why
String shouldn't work! Why
do I expect the format attribute to do the type conversion? Because the
framework automatically does the type conversion on form submission. Here is
what I mean by that:
//
action form code
public
class MyForm extends ActionForm{
private double amount;
}
//
jsp code
<html:text
name="myForm" property="amount" />
Even
though request.getParameter("amount") returns a String, the framework
happily converts the String to double. If this conversion is automatic, why
can't it convert String to double and try to display the value in currency
format in the format attribute? I am sure this has been
raised/discussed/considered somewhere but I can't find it. If some one knows
let me know.
There
is another problem (not really a Struts problem though). There is no way to
format phone numbers. If you get a String 8001234567 from the database and
would like to convert to (800) 123-4567 OR 800-123-4567, currently there is no
tag or attribute to do that (or I don't know about it). I was hoping, since
it's so easy to format currency and date objects, it would be easy to format
phone numbers but looks like it's my challenge to write something like that.
