Java Hair

This is the post I promised that contains a link to the source code for the FlashCard game. There is also a Web Start Launcher link so you can see what my “masterpiece” looks like for yourself.

Some things that I need to work on:

1. Commenting - only parts are commented and though the variable names are pretty self explanatory, it could use some better commenting so that a write-up does not need to accompany it.

2. Layout - I used a couple Box layouts and I’m beginning to think that I should have just gone straight to the old GridBag. I haven’t spent much time figuring out how to space the components yet, but it isn’t spaced the way I’d like it to be.

3. Integrate with Pojo’s - I’d like to use some properties files and a few plain old Java classes to read in the properties and set up the array of flashcards. Currently the array is hardcoded into the FlashApp file.

4. Sound - I want to add sound to the letters, and sound to the images so that when they are clicked on, the letter sound plays or the word sound plays. I downloaded a package to let me integrate sound, but I haven’t gotten to it yet.

If you are interested in the current code, you can find it here.

If you want to see the game in action and you have Java 1.5+ installed, click here to launch Java Web Start and the FlashCard game. No need to tell me how awful my artwork is, my daughters already let me know.

Please let me know if you find it interesting or have comments on anything I may have done blatantly wrong, this was my first attempt at a JavaFX application so I am interested in feedback.

Note: An updated version of the source code for JavaFX 1.1 is available at this post.

I’ve gotten my FlashCard game to a point that is good enough and when I get the chance I’ll post a link to a zip of the contents so you can download it and check it out. Before I do that, I thought I’d take this chance to go over some of things I’ve learned, using my FlashCard application as an example.

My Flashcard game is a simple application that displays flashcards, word side up. Clicking on the Flip Me! button flips the card to show an image of the word. Clicking on the Next button cycles through the deck of cards. Since it is primarily a graphical application, I thought JavaFX would be a good choice for it. This post will go through the files that make up the application, pointing out some of the interesting characteristics of a JavaFX application. (more…)

This is my week off.  I had a nice little vacation planned with the family, but most of the family (except me, so far) has been sick with the flu for the past few days.  We postponed our little jaunt up north but I decided to take the time away from the office anyway.  I needed to keep an eye on the kids while my wife stayed in bed most of the last few days, but I also just needed some time away to do something different.  That something different?  JavaFx, of course.

Ever since the announcement at JavaOne last year I have been curious to check it out.  I was very skeptical about it at first, from what I could tell it looked a lot like Swing but in a scripting language.  I’m still not so sure it isn’t Swing in a scripting language, my old friend, the GridBagLayout is still around after all, but taking a look at it did encourage me to try some things I never really felt like dealing with in regular old Swing.

I decided I’d spend this time on my vacation writing a flash card game for my kids.  You all remember flash cards, right?  This particular version would have words on one side, an image on the other side, and hopefully, if I have time, be slightly enhanced with sound.  I want to encourage my oldest to learn to read phonetically, and I figured a flash card game in which she could click on the individual letters to hear the sounds they make may make it interesting.

I already learned a few things about JavaFX.  One is that it is enough like Java to really confuse me at times since it really isn’t Java and has different syntax.  Another is that some really simple things, like constructors, for example, take entire articles to explain.  I learned that displaying graphics is really easy, but playing a sound file isn’t, at least not until a sound api is incorporated into it.

The coolest thing is that with the NetBeans IDE and the plugin for JavaFX, there is an actual preview window that shows what the JavaFX file will display when it runs.  It also is essential in finding some errors.  It reminds me very much of the Smalltalk workspace in the Smalltalk Visual Studio I used to progam in decades ago.

One downside, though, JavaFX files are script files and they are not compile checked so some errors to not appear until runtime.  And besides that, I don’t think it is possible to debug either, if it is, it isn’t obvious.

Okay, three downsides, number two is that NetBeans will not install on my laptop and doesn’t give a reason why not.  Number three is that the language still seems a bit buggy to me and from what I have read recently, seems that way to others also.  It’s okay, though, I’ve been doing a lot of work with the pre-release versions of ADF 11g so I’m used to dealing with lacking documentation and a plethora of bugs.

I have gotten close to a milestone at this point and if we do end up going away for a few days and my laptop still won’t run NetBeans, I won’t be working anymore on it anytime soon.  I will do my best to provide some type of update, however, before I am back in the thick of things at the office.  It may be that I throw the code up here and let someone else play with it if they are interested.  Only time will tell.

Here are some links to get you started:

JavaFX Community Home 

JavaFX API 

Introduction to JavaFX Script

SQL, at least the standard SQL and the SQL that Oracle implements does not support Boolean datatypes. In the decades that SQL has been a standard or even taking into account the liberties technology companies take with standards, I would have expected Boolean variables to appear in databases a long time ago. Since they aren’t there, typically a Boolean attribute is represented by a number in the database.

Anyway, ADF is no exception to this rule of not liking Booleans. I would have thought that you could create a Boolean in an Entity, tie it to a Number field in the database, and then create everything as normal, but, at least in Tech Preview 3, it does not appear to be as simple as that.

So I took a hint from my buddy, Andre (check out his blog in the Blogroll to the right, it is full of great examples), and on his advice, checked out an Undocumented Sample from Steve Muench’s blog.

Here are the steps I took based on Steve’s 10.1.2 example to overcome this limitation in ADF 11g. Perhaps there is a better way, but I am not aware of it yet.

To demonstrate this, I added a Number type attribute to the Employee’s table in the default HR schema. I called it OrganDonor, since it’s always a good idea for companies to know which employee’s are organ donors

Create the Entity and View as you normally would. Open the view and add a transient attribute called “OrganDonorAsBoolean”.

Click on “Java” in the sidebar of the View, then click the little pencil in the top right to bring up the “Select Java Options” dialog.

Check off “Generate View Row Class” and “Include accessors”, then click “OK”.

Open the EmployeesViewrowImpl.java file it created.

Change the getter and setter for the AsBoolean attribute:

/**Gets the attribute value for the calculated attribute OrganDonorAsBoolean.
*/
public Boolean getOrganDonorAsBoolean() {
return (Boolean) (new Number(1)).equals(getOrganDonor());
}

/**Sets <code>value</code> as the attribute value for the calculated attribute OrganDonorAsBoolean.
*/
public void setOrganDonorAsBoolean(Boolean value) {
setOrganDonor((value ? new Number(1):new Number(0)));
}

Save everything (as always).

Next, create the JSPX page, make it a JSF page.

Open the DataControl that contains the EmployeesView1 view.

Drag the view onto the JSPX page, and select Tables -> ADF Table.

Select all the attributes you want displayed in the table, do NOT select the original number-based attribute. It will not let you select a “SelectBooleanCheckbox” as component at this point, so just just “Input Text”.

After it puts the form on the page, put a Commit and Rollback button on the page.

Finally, go to the source of the JSPX page and change the input text component for “OrganDonorAsBoolean” to this:

<af:selectBooleanCheckbox value=”#{row.OrganDonorAsBoolean}” />

Now run the page to test it and your check boxes should be working fine.

If I come across an easier way to do this, particularly, one without having to create a RowImpl class, I will post it here.

So, I get this all the time “Why should I convert my perfectly good Forms?”. The answer is you should if you have a good reason to. If you don’t, by all means stay there (until, of course, one day Oracle decides you will not have Forms at all anymore; around 1213 or so, and then you’ll need to do something). I see TON’s of blog’s about the topic. Mostly these entries are on Oracle-centric sites and are not, perhaps, as objective as they could be. So, here’s my opinion on the matter (as I find myself to be a relatively objective person).

Wait, before beginning, I need to pull out a blog-shaped soap box.

These efforts aren’t “conversions”. This isn’t a translation exercise. Meaning, if you think you can change from one computing architecture to a completely different one by pushing a button, you’re nuts. It’s just not realistic. From the outset of Vgo Software (and prior to that, NEOS) we used the word “evolution” or “modernize”. To reach a stage of evolution, you have to work at it to reach the full potential of the modernized state (whoa… I’m feeling a little Zen here).

Think about this, Oracle DBA’s out there: when you upgraded from v7 to v8 of the database, did you use consider the cool new features like partitions, a better cost-based optimizer (though, in my ex-DBA opinions, still not great then) or materialized views (I’m publishing my age here)? If you did, did you get all that stuff by upgrading? NO. You had to reconsider your applications using the DB and what impact that the changes would have on them. 

I shouldn’t mention that your manager wouldn’t give you time to implement any of the good stuff as I’m sure that wasn’t/isn’t common at all.

So, back to Forms and Java.  The people that should want to convert would be those folks who want to integrate applications in a standard way.  They want to move towards service orientation and can see integration across application silo’s.  These folks may want to move away from Oracle as an application solution and move toward open-source, allowing them to use a wide community of development resources.  Of course, Oracle has been making great strides as we can attest to. 

But why is Forms evolution hard?  It’s hard because there is alot to do to create a solid JEE app.  In a code translation (of which there are a large number), an engine maps each construct to a “Java equivalent” which may, or may not, be proprietary to the translator.  What you do in those cases is create at least 2 different source files (possibly 10 times more) for every Forms program unit, trigger, etc. creating a huge mess.  Maybe it works, most likely it will not, but then your stuck with 1 million source files and no way to maintain them.

We put in a lot of effort to try to allow people to clean up and consolidate code in forms applications (we’re the only one’s who do that, BTW) and even build customized classes from existing forms components.  Our last release allows you to do this across different forms applications, creating true enterprise-class applications and services.

There is also discussion about modernizing Forms apps by putting all of the PL/SQL in the form into the database (perhaps the re-surgence of mainframe computing is making it into the distributed database market).  This approach was taken by forward thinking companies in the mid-to-late ’90’s by taking core business rules out of their forms and wrapping them in CRUD procedures in Oracle to thin out the front end.  A good approach back in the client/server days.  In fact, I did that myself with a large annuities application.  But now you have application servers that run real Java; why would you want to isolate your business logic in a single database?  What about sharing that logic with other apps (yes, I know you can do that to some degree in Oracle)?  What about exposure as a web service from different platforms?  And how many PL/SQL programmers can be found to manage really large apps that stuff all of their logic in a database?  In my opinion, fattening the database isn’t a viable architectural solution in this day and age.  If you want to thin-out your front end, that’s great, just don’t dump all of it in the database. 

So, I’ve written this over a vast amount of time, being a poor blogger (Rob may suspend my blogging privileges after this release).  Maybe it’s insightful to you; therapeutic to me.

Here is an unsorted list of 5 simple JDeveloper tips to help speed things up and prevent unexpected problems.

1. After updating your code from a repository, do a clean and a rebuild, especially if changes are made to the JPR files.

Example: We started getting a JAZN Runtime exception:

oracle.security.jazn.JAZNRuntimeException: JBO-25002: Definition com.demo.model.MyView of type View Definition not found

As it turned out, the views had been updated and JDeveloper had not picked up on all of the changes, after a clean, a rebuild and another test, everything worked as expected.

2. After changing a property in the properties panel, click on another property or press enter so that JDeveloper recognizes the change. If you just move on to another file with changing the field you are on and causing a value change event to occur, it will not register the change you made.

This problem is actually resident in many web and Java based systems mostly because the events provided by JSF and Swing never recognize value changes if you leave the component that caused the change.

3.  Use the BC Browser.  I wrote an earlier blog post about it and why it is important.  Basically it allows you easily test the ADF BC layer in your project.  Since the Model layer is the basis for the rest of the application, it’s an important tool.

4 .  Log out of the Version Control repository you are using.  JDeveloper is constantly rechecking the server to see what has changed and update the “Pending Changes” list in the project.  This can cause a lot of unnecessary overhead if you aren’t waiting around for a particular update to be made.  Logging out fo the Version Control server will prevent that from happening.

5.  Increase the memory allotted to the embedded OC4J server.  Often you will be testing your application using the embedded server and it’s default settings are not adequate for most real projects.  You can increase the default memory allocation by right-clicking on your ViewController project, select “Project Properties”, “Run/Debug/Profile”, Edit the existing profile or add a new profile to select.  In  the profile,  select “Launch Settings” and in the input box for Java Options add the options “-Xmx512m -XX:MaxPermSize=256M” or whatever you deem appropriate.

I have been chosen as a speaker at Oracle’s ODTUG Kaleidoscope Conference which will be going on in June of this year in New Orleans. My presentation is entitled “Using ADF 11g as a Platform for Oracle Client/Server Forms Conversions”.

With the introduction of ADF 11g, including both the back-end Business Components and the front-end ADF Faces Rich Components, Client/Server applications can now viably be converted to Web applications. This presentation explores some of the difficulties in recreating such applications in a Web environment and shows how ADF 11g can be used to alleviate some of those difficulties. The presentation will explore a real-life proof-of-concept project that uses ADF 11g as the target platform for a client/server migration project. Real-life problems, their solutions, and code examples will be reviewed.

If you are in town, be sure to stop by and say hi!

One of the many features that Oracle got right in JDeveloper is the Oracle Business Component Browser. This little tool is a built-in testing suite for a persistence layer that has been created in ADF BC.

Not only does it provide the ability to perform CRUD operations on the data that your Views are based on, but since some UI elements are influenced by “Hints” on the Model layer, including LOVs and validation, you can test those aspects of your Model as well.

To run it, simply right click on the Application Module that you’d like to test. When the browser starts, all of the views associated with that Application Module will be available to you to run and test. If the view requires a parameter, you will be prompted to provide it.

This is a great little feature that lets you ensure your persistence layer is up to snuff before you start worrying about the presentation. Of course, since we are all excellent programmers here we always unit test anyway, but this way your unit tests are written for you.