my recent reads..

Atomic Accidents: A History of Nuclear Meltdowns and Disasters; From the Ozark Mountains to Fukushima
Power Sources and Supplies: World Class Designs
Red Storm Rising
Locked On
Analog Circuits Cookbook
The Teeth Of The Tiger
Sharpe's Gold
Without Remorse
Practical Oscillator Handbook
Red Rabbit
Showing posts with label JDeveloper. Show all posts
Showing posts with label JDeveloper. Show all posts

Thursday, January 31, 2008

JDeveloper Filter Add-in Now on Sourceforge

I introduced the JDeveloper IDE External Filter Add-in project last weekend. Happy to announce that the project's registration on sourceforge is complete, so full source and downloads are now available from the sourceforge jdevfilter project page.

Saturday, January 26, 2008

JDeveloper Filter Add-in

I hinted at a project to develop a simple filter add-in in my last post on Code Generation with JDeveloper. So that turned into my latest weekend project;-)

I'm registering the project on sourceforge, but in the meantime you can get the full source kit here, or if you prefer just the add-in jar here (which just needs to be dropped into your ${jdev.home}/jdev/extensions folder). [30-Jan-2008: the project is now available on sourceforge]

What does it do?
It is a simple idea. Allow you to invoke an external program to filter any text you have selected in the JDeveloper Editor. Of course, it is up to you to define what filter means - limited by your imagination only. And by externalizing the filter process, it means you can use the tool or scripting language of your choice to implement and make on-the-fly changes to your filter.

To be precise, the filter operates like operating system pipes:
  • Selected text is sent to the standard-input of the filter process.
  • The standard-output of the filter process is written back to replace the selected text.

Configuring the Filter
Configuration is done via the JDeveloper Tools | Preferences menu, and is very simple at present. It only supports a single filter process definition. As you can see in the screenshot, you just need to enter a valid command line to invoke the filter. A nice enhancement would be the support for multiple filter definitions.


This is where the flexibility comes in. As an example, I've provided a rot13 encoder written in ruby [samples/myrot13filter.rb in the source kit].
puts $stdin.readlines.to_s.tr("A-Za-z", "N-ZA-Mn-za-m")

Ruby, Perl, php, vbscript/WSH, bash ... use whatever you prefer. Rather than needing to develop and deploy an add-in in Java, you can just script the filter.

Applying the filter is simply a matter of selecting some text in the IDE, and choose the Custom Text Filter item from the right-click pop-up menu

The Development View
The truth is that I developed this add-in as more an investigation of the Extensions SDK, and the filter idea appeared to be unexplored territory.

As Brian Duff writes, there are some major improvements in the support for JDeveloper Extensions in 11g. Since it is still in preview, I decided to stick with Extension SDK 10.1.3 however.

There are four classes of significance. since this was an educational exercise, I spent a bit of time to make sure I really understood how it all worked, and tried to reflect that with liberal comments in the source.
  • CodePaneAddin - implements the pop-up menu hook and applies the filter
  • ExecShell - wraps the invocation of the filter process iwth stdin/out handling. It is independent of the extension API and may be of interest in its own right
  • ConfigPanelData - handles preferences panel configuration
  • ConfigData - bean to wrap the configuration data


The source kit comes with a JDeveloper project and also ant build file. If you want to build and deploy the add-in to JDeveloper, simplest is to first check the environment-specific settings in build.properties and then simply run
C:\MyDocs\MyDev2\JDevFilter>ant deploy
Buildfile: build.xml

init:

prepare:

compile:

jar:

deploy:
[copy] Copying 1 file to C:\oracle\jdevstudio10131\jdev\extensions

BUILD SUCCESSFUL
Total time: 0 seconds

Interested? Head on over to sourceforge to download the kit.

Sunday, January 13, 2008

Code Generation with JDeveloper

I've written about Jack Herrington's Code Generation in Action before; it is a great book for stimulating your thinking on how you go about producing code.

JDeveloper has evolved into one of the strongest IDEs when it comes to code generation. It's not explicitly mentioned in the book however. That's not a criticism of the book, but it does beg a review of how JDeveloper stacks up against the concepts covered.

Integrating code generation into your IDE


Writing a code generator can be difficult-but convincing your fellow engineers to use [it] can be even more difficult. The key .. is to make it as simple as possible to use.
IDE integration is one approach to address this problem, and the common techniques supported are external tool invocation and filtering.

JDeveloper only directly supports external tool invocation (see the Tools menu). For instance, you can call simple Ruby scripts like the following to perform file-level processing (this example simply comments each line of the file that is currently open in the editor pane).
fh = File.open( ARGV[0] )
text = fh.read()
fh.close
text.gsub!( /^/, "// " )
File.open( ARGV[0], "w" ).write( text )


NB: in the 11.1 preview, it seems the "Availability" conditions are still a little broken and it is not possible to make commands available only when a file (or certain type of file) is open.

Filters are not directly supported by JDeveloper, however implementing a filter is a fairly straight-forward project using the JDeveloper Extension API.

JDeveloper Extension API


Herrington does not directly address the topic of IDE APIs, which is understandable given the scope of his book. However if you are looking to implement complex and very specific code generation approaches you will probably want to look into this topic further.

JDeveloper comes with a comprehensive Java-based extension API which was significantly revamped in (I think) 10.1.3 to bring it into line with the standardisation efforts of JSR-198.

I must say documentation of the extension development process is a little thin. And it is only in 11.1 that JDeveloper has explicit project support for extension development (although I find it a little broken and mysterious in the preview edition). The best approach at present seems to be good ol' copy-and-modify the extensive set of samples provided by Oracle at the Extensions Exchange. There is a growing number of 3rd party open source extensions that are even available through the JDeveloper Check for updates menu.

Still, no filter add-in is available, and you are of course stuck with developing in Java. It of course puts me in mind of a little project: a simple filter add-in that then allows you to invoke a filter process developed in the language of your choice such as perl, ruby or python. Maybe I'll be able to follow-up this post with an example;-) PS: yes I did; you can read about it here.

JDeveloper's Generation Credentials


I've been hedging around the fact that JDeveloper is very significantly geared towards code generation itself. It is one of the main drawcards for why you would use it over your favourite text editor.

In the back cover of the book, Herrington includes a very illustrative Generator Tree which provides a taxonomy of generators, with of course references back to what is covered in the book. I thought I'd experiement with mapping JDeveloper into the taxonomy. I doubt if I'll manage to cover all of JDeveloper's features (or get it all right), but here goes:

ClassPlatformTechnologyHerringtonJDeveloper
Database AccessMSASPASP Generatorn/a
ASP.NETASP.NET Generatorn/a
JavaEJBEJB GeneratorEJB Entities from Tables
JDBCJDBC GeneratorADF Business Components
JDBCn/aToplink O-R Mapping
PHPPHPPHP Generatorn/a
PerlDBIPerl DBI Generatorn/a
User InterfaceJavaJSPJSP GeneratorJSP/struts/JSF wizards
SwingSwing GeneratorSwing wizards; ADF Swing wizards
MSMFCMFC Generatorn/a
DocumentationSQLSQLSQL Documentation Generatorn/a
JavaJavaJavaDocJavaDoc
Unit TestsCTestsAugmented C Unit Test Generatorn/a
Ordered TestsOrdered Test Generatorn/a
Test Datan/aTest data generatorn/a
Test Robotsn/aTest robot generatorn/a
File FormatsJavaCSVCSV file Reading Java GeneratorFile Adapter
JavaData AdapterData Adapter Generator(arguably) File Adapter; Toplink
JavaBinaryBinary File Reader Generatorn/a
Web ServicesJavaXML-RPCXML-RPC Generatorn/a?
JavaSOAPSOAP GeneratorJava Web Service from WSDL
PL/SQLn/aPL/SQL Web Service
JMSn/aJMS Web Service
Variousn/aTechnology Adapters
Business LogicJavaMathEquation Generatorn/a
JavaReportsReport Logic and Interface Generatorn/a
External Libraries*C++DLLDLL Wrapper Generatorn/a
Scripting LanguagesC++External Language Wrapper Generatorn/a
Configuration*FirewallanyFirewall Configuration Generatorn/a
Reference Data*anyLookup Function Generatorn/a
anyMacro Lookup Table Generatorn/a

*I've reclassified these items from the original table in the book.
NB: I generated the table above using an OpenOffice Calc spreadsheet [generator-taxonomy.ods]. Good example of dog-fooding perhaps;-) I've always found Excel/Calc to be really useful tools for rapidly generating scripts, SQL or HTML fragments like this.

With so much capability in JDeveloper, you might expect instant adoption. But there are of course two classic issues still to be addressed:
  1. There's quite a steep learning curve until you get comfortable with what features are available, and when they are appropriate to use. The rapid enhancement of JDeveloper and all the technology over the past few years means that your average dev shop probably doesn't have the luxury of many gurus who can coach the team either
  2. It seems to be an inherent trait of developers (arguably a good one), that generators and wizards are not fully trusted and accepted until you've had the chance to dig down under the covers. That's simply a lot of work for all of JDeveloper's features, and there isn't a great deal of information available to help your short-cut the process.
The natural conclusion is that to optimise adoption, I'd exhort the JDev team (and the community of users) to put as much effort as possible into producing resources for JDeveloper's code generation (wizards etc) and extension SDK. Importantly, to put the stress on explaining the how and why these things work (not just step-by-step tutorials).

Postscript: