It happened when I was settiing them on the command line, and continues to plague me after I created CamBAfx.

Long time users of CamBA will certainly noticed that it underwent quite a few revisions. To their chagrin, I am imposing yet another redesign.

The way I see it is the parameter design was deceptively simple for the control of a very complex program. Like all academicly written programs (including my own) it does not perform rigorious check on the parameters and therefore can hide a multitude of sins if you are not careful. It is further complicated by the fact that one parameter’s behaviour is dependent on another. [For example, '-c' is dependent on '-l' and in the case of the pipeline cglm, -c is also dependent on the 'Main' and "Interaction" parameters.] This is not uncommon, but nonetheless a trap.

It is also very difficult for users to explain to me what is wrong. Take for example the case of a user which took 6 months to convince me that I have omitted a possible  ‘-c’ value when extra regressors are available, and no less then three emails to nail down the problem, followed by 8 plus emails to fully clarify the issue.

Translating this into the wizard was not an easy task either. Take for instance this latest incarnation. Three times I thought I completed it, three times the QA testing reveals that I have mistakes in the implementation.

Why? first of all, unlike other pipelines where the parameters are either independent of each other or have minimum dependencies and as you progressively down the option list, your remaining choices are narrowed down really quickly. With CGLM, there are a lot of interdependent parameters and at any steps, depending on what you had chosen, your remaining choices can explode instead of being narrowed down. That is never a good sign for a wizard designer.

One of the major CamBAfx’s wizard design aim is to guide you through the pipeline creation and ensure that you will always create a valid pipeline. Guiding you through the pipeline creation means I have to keep the promise that I do not unnecessarily restrict your choice and will communicate to you all your available option. Ensuring the pipeline is valid means I have to constantly check what you had selected/entered is valid. This  complicates the wizard’s design enormously.

Furthermore, I am one of those who wants to make sure that the wizard design reflects the parameter given to the pipeline. For example, for a pull down box, I could had shown you an option called “Main effect of variable 1″, but I choose to show you “1: Main effect of variable 1″ because the parameter in question, say ‘-c’, is expecting the value ’1′ to represent “Main effect of variable 1″. I think small little thing like option number in this case is important as it helps you (and me) to read the shell script generated by the pipelines later.

Unfortunately, all these nice things we have on the wizard translated to more work. More work means more potential trouble point. Remember that in the last reincarnation, the wizards display changes according to your response? That is part of the strategy to present you with the most appropriate UI items (dropdown box, text box etc) for the options you had chosen.

Unfortunately for me, the previous CGLM design has these major problems:

1. For 2×2, I had presented the “Interaction between factor 1 and factor 2″ as an option for the variate. Unfortunately, unless you click the “interaction” button, the “Model” file is not generated correctly. Guess what is worse? You probably do not realize that I have a check box for “interaction”. The wizard sometimes hide it.
2. You choose to add extra regressors, but you cannot use them as output variate. Apparently this is a very common operation which I missed.
3. In this design I had implemented the concept of restricting the parameter choice to those that are valid for you particular design. It appears that I was not agressive enough and did not completely eliminated the possibility of you changing the parameters to invalid one post pipeline creation. As I think this give you a false sense of security which is even worse than telling you there is no security at all, i.e., giving you all possible choices regardless of whether the pipeline created will be invalid, it has to change.
4. It was a conscious decision to exclude user-defined “interactions”, such as the interactions between factors and regressors. I did not think this will impact day-to-day work. Unfortunately, recent advancement with  users wanting to regress with more than one regressors shows that I am wrong.

So, what did I changed in the new wizard? For one, no more display change as you fill in the wizard. All sections are listed immediately. You are expected to start by specifying the pipeline name (as usual), then your analysis design (as usual). Next you decides whether you want any extra regressors and input the interactions that you want. Finally, you choose the variate to output. Note that the analysis design, extra regressors, interactions and variate to output are heavily dependent on each other. Changing one can invalidate the other. So you might have to revisit the others after changing one of them. No worry, as usual, refers to the notification area at the top of the wizard to tell you what to do; And the “Finish” button will only be enabled if you have a valid pipeline configuration. Also as usual,  the interactions terms you define will be carefully scrutinized for mistake.

As for trimming the output, you will note that you can no longer change the “Interactions” parameter after pipeline creation. Therefore, this means that the wizard is the only chance you can define the “Main” and “Interactions” parameter. If you want to know which interactions is available, have a look under the “variate” parameters. As with previous wizard, your choice of analysis is restricted to those that share the same parameter settings.

Hopefully, this wizard will be the last ever redesign.

I think the cglm pipeline is difficult to setup correctly and always advise users to NOT modify the parameters unless John Suckling or I am consulted on it. If you need to modify the analysis, create a new pipeline and let the wizard guide you. Then import the data from the old pipeline.

We just completed a big analysis project using CamBA. As with large projects, one start to find out the shortcoming of existing tools. Post project, one set out to create those tools for the next project. So, the update flurry is the results.

What do we have now?

First, Two new processing engines (PPSS and SGE) for GenericFX. One uses PPSS from http://code.google.com/p/ppss, and the other for Sun Grid Engine. As with all GenericFX processing engines, the aim was to simplify them to be easily useable by everyone. I think I more or less achieve this aim.

Then, FSL (http://www.fmrib.ox.ac.uk/fsl) processes for analyzing 3D structural brain images into its three separate components (White Matter, Gray Matter and CSF), used in the big project is coded up as a pipeline. It is now part of FSLfx which is part of BrainFX.

With CamBAfx the changes are very small. What I did was to remove the restriction on CGLM where the regressors must take the value of -1 or 1.

If you are new to NifTI and want to use NifTI with Java really quickly, then I recommend NifTI reference library, niftijlib. niftijlib’s initial learning curve is very low, and it does most of the things you want to do. If you want a nice Java Swing library that is able to display nice brain images and perhaps convert your images to jpeg/png and other format, use LONI’s ImageIO Plugins. I’m sure there are more fine NifTI libraries around and apologize for not listing an exhaustive list here.

You should consider CamBA’s NifTI library if you are interested in concentrates on manipulation of NifTI headers and not UI.
I develop CamBA’s NifTI library for the following reasons:
I want functions that reminds me about things I may have to consider to get my NifTI file to behave properly

So, I se several pieces of data together. For example, I use

nim.setBasicMetaData(dim[8], pixdim[8], NIFTI.NIFTI_TYPE_INT16, NIFTI.NIFTI_UNIT_MM, NIFTI.NIFTI_UNIT_SEC)

to individual setX() function because it reminds me that dim[], pixdim[], datatype and xyzt_units are not mutually exclusive and you should consider setting all of them if you modify one. Other examples include

nim.setCalRange(cal_min, cal_max) nim.setScaling(scl_slope, scl_inter)

I want a library that reflects my normal programming practice

1. Separation of concern: NifTI1Infoset does not know how to read/write itself. Instead, it relies on Nifti1FileStream to read/write it.
2. Rather than packing/unpacking data directly, e.g. the time and space measurement unit into xyzt_unit, I let the program API handles it. i.e., nim.setBasicMetaData(…, space_unit, time_unit), nim.getSpaceUnit() and nim.getTimeUnit()

I want a framework that reflects programming need, not file structure

Hence, Nifti1Infoset (equivalent to NifTI1Dataset in niftijlib) does not carry the fields sizeof_hdr, bitpix, voffset and magic[] as it is the job of Nifti1FileStream to insert them correctly when reading/writing to file. I let machine worry about them.

More flexible Nifti1 Container

Using storePut(key, object) and storeGet(key), Nifti1Infoset has a storage area for you to store anything if you can associate it with a key. In fact, we use NIFTI.COMPLETE_DATA_KEY is used to store the actual image data, and any key with the prefix EXTENSION_ECODE_PREFIX stores your extension value.

I need a software framework that encapsulate task I do daily:

For example:

• INifti1InfosetValidator interface allows me to call validate() to check incoming NifTI file conforms to ceratin requirement. For example, in CamBA, fMRI raw data must be single 4D NifTI file, of int16 datatype, have slice_code and sform is filled properly, not gzipped and in machine endian, standard brain template must be a 3D NifTI file etc…
• INifTIComparator interface. It allow me to compare two nifti files intelligently. For example, when comparing two files, if one detects differences in the Time component of xyzt_unit for the two files, it is not imporatnt if you are looking at 3D template file, but is definitely an error if you are looking at a 4D fMRI file. The comparator should be able to figure this out.

I need a SWT/JFace/Eclipse kit to manipulate NifTI header data

Eclipse uses SWT. I cannot find any SWT toolkit to manipulate NifTI data out there.

It also must be smart enough to adapt to different type of NifTI file, e.g., fMRI4D, template data etc.

Note:

To use this NifTI library, you have to:

Download the BrainFX->2.1.1->brainfx-2.1.1.zip package. While it is actually a collection of Eclipse plugins, it is simply a collection of directories.

The core NifTI access routine, which is pure Java code, is in directory org.brainfx.nifti/src. Please note that org.brainfx.nifti.testers and org.brainfx.nifti.helpers are older packages which are deprecated and have dependencies on genericFX package and the package net.sourceforge.nifti package. [net.sourceforge.nifti is niftijlib-0.1 packaged as an eclipse plugin]

org.brainfx.nifti.ui contains the SWT UI Package. The only dependency is the Standard Widget Toolkit (SWT) package from www.eclipse.org. You need to remove org.brainfx.nifti.ui.UiPlugin which is only useful if you are using it as an eclipse package.

The JUnit tests, in org.brainfx.nifti*tests, can only be if you use the Eclipse IDE. The reason is I used Eclipse to determine where to find the test datasets used in some of the unit tests.

What this tool do is to simply automate the tasks stated in TBSS step 1 to 5

Quick Start

From the File->New… menu item, select “Cambridge TBSS Pipeline”.

Then fill in the information on the wizard:

“FAi Target” refers to the target you used in step 2 (FMRIB58_FA in TBSS page). The “Number of EVs” and “Contrast” is used to emulate the input to GLM Wizard as described in step 5. “Number of EVs” determines the number of columns available in the Input Table, and is used in conjunction with the Input Table to generate the “design.mat”. “Contrast” is used to define the “design.con” file

On clicking “Finish”, you will get the input table:

To run this pipeline, use the standard Run->Run… dialog box and give it a output directory name.

That is all you need to do. TBSSfx will automate the whole TBSS process from step 1 to step 5.

What happens when you run it?

After you click “Run” in the standard Run->Run… dialog box, the usual scripts controlling the processing will be generated as usual.

TBSS Step 1

You will find that a suitable threshold value for “Step 1″ of TBSS will be automatically determined and all your “Input Map” in the Input Table copied to the output directory.

In the output directory, you will find that the “Input Map” are actually named “NNNN-<inputmap>” where NNNN is a number starting from 1. The number is consecutive and will list the file according to the order it is on the Input Table. In the example above we will have “01-tbss1.nii” and “02-tbss2.nii”. The precise reason will be articulated later.

Whenever possible, to save diskspace, a hard link is used instead of copying.

TBSS Step 2

Your FAi target copied and renamed to <output directory>/FAI/target.hdr just before TBSS step 2 is performed as required by the TBSS analysis process. Hard link will be preferred over copying to save disk space.

TBSS Step 3 and 4

Just as TBSS step 3 and 4. The threshold value in TBSS 4 can be set via Parameter->Threshold.

TBSS Step 5

Your “Number of EVs”, EVs column in the Input Table and “Contrasts” value will be turned into<output directory>/design.mat and <output directory>/design.con.

In the example above, design.mat looks like this:

/NumWaves 2
/NumPoints 2
/PPheights 2.0
/Matrix
1.0 2.0
-1.0 -2.0

As you can see, the /Matrix array is the array in constructed by using the EV columns

The design.con looks like this:

/ContrastName1 ev1
/ContrastName2 ev2
/ContrastName3 ev1-ev2
/NumWaves 2
/NumPoints 3
/PPheights 1.0 2.0
/Matrix
1 0
0 1
1 -1

/ContrastNameX is the name of row X in /Matrix; And both the /Matrix and /ContrastNameX is defined in the New Wizard.

Notable Fact

“design.mat” which lists the EV values, does not contain the name of the “Input Map” it refers to. Instead, it arrange all *.nii (“Input Map”) in FAI in alphabetical order and apply the first row to the first “Input Map” and so on and so for.

The Input Table, however, do not constrain you to put the “Input Map” in alphabetical order. We find this too constraining and instead let TBSSfx handle this automatically for you. There is two choices: Rearrange “design.mat” /Matrix row to fit the alphabetical order of the “Input Map” or to rename the “Input Map” name so that it is in alphabetical order in the way it it is presented on the “Input Table”. We chosen the latter and do it by prefixing the “Input Map” with four digit numbers representing its row. The reason is for easier debugging: The /Matrix row order in “design.mat” will be the same as that in “EV columns” and the order of “Input Map”, as seen by TBSS is immediately clear compare to the first approach.

FINALLY and unfortunately: An important exception

Two actually. The first is that the numbering of “Input Map”s using four digit number means TBSSfx cannot handle more than 999 “Input Maps”. Unless you use a Grid Engine, this is more than what your computer can handle. In any case, realistically speaking, one rarely have a thousand or more “Input Maps”.

The second exception is more important: Just after we released TBSSfx 1.3.2, FSL version 4.0 came out. We had used FSL3.3 in the development of TBSSfx. Therefore we do not know whether it works with FSL 4.0. The development of TBSSfx is temporary frozen as we do not expect to revisit the dataset acquired until at least 2 years later.

We created BrainFX in support of our Neuroscience research work. Increasingly, we find that we are using FSL to run the preliminary stages for structural analysis of the brain. Thus, we wants to explore whether we can run FSL inside BrainFX with the view of creating hybrid FSL and CamBA pipelines. Unfortunately, the powers-that-be is not willing to take my word for it, so a little demonstrator is in order.

After playing with FSL and BrainFX for a few hours, I managed to cook up such a demonstrator. It is a basic one, i.e., proving that BrainFX can reach out to BET. Let’s face it, BET is one of the easiest program in FSL to co-opt with BrainFX, and the demonstrator did nothing but read in a NifTI image, process it with BET then write the output, bypassing all the options you can set with BET. Nonetheless, it shows that it is possible to run BET with BrainFX.

I must stress that these work are very preliminary. It simply demonstrates that there are no-unsurmountable hurdle in getting BrainFX to work with FSL. The next plan is to get FSL programs that we need running in BrainFX, before branching into mixing FSL with CamBA. There will be a lot of decision to be made before both FSL and CamBA can coexists under BrainFX’s umbrella.

Maintaining the tradition of calling something integrated into genericFX as fx, we named the FSL integration into BrainFX FSLfx.

Please note that we are not integrating FSL and CamBA. They are integrated separately into BrainFX. In fact, it is possible to create a CamBA-like GUI for FSL in such a way that it live and breath FSL, without losing any funtionalities that makes the GUI unique. What we do plan to do is to marry FSL and CamBA to produce offsprings (pipelines) that are more powerful than their parents separately.

We will keep you informed on our progress. Right now the most important task is to get blessing from FSL team.

This is good news for GenericFX/BrainFX/CamBAfx (“GenericFX”) as it means it is we can almost cook up a copy of it using only free software. The only component that is not free software is the Eclipse Platform and it is not compatible with GPL version 2 by only a wiskle, i.e., its patent licensing requirement. When GPL version 3 arrive and if we accept and upgrade the license to GPL version 3, this incompatibility will be removed and we will finally complies with GPL technical requirements.

Well, this is as best as we can go with Free Software compliance. Using nothing but GPL or its cousin, the Lesser General Public License for GenericFX is already ruled out when we decided to use the Eclipse Platform.

End users will find this discussion rather academic. Indeed, if you are interested in using the software only and do not care about its evolution and survivability, it is an academic discussion. Having GenericFX completely on a Free Software compatible stack means that provided you have all the necessary expertises, there is nothing that can stop you from using the software.

This release reverted Movement Correction to its old, tried-and-tested version. The principle reason is that on CamBA 1.0.0, we noticed that one of the movement component was not moving the way we expected over time. Thus, we decided to revert it back to the old version pending further investigation.

On the user interface front, we reworked “Pipeline Schemes”. A description of how this works will be posted later. This rework aims to remove confusion on the existing Pipeline Scheme for Time Series Analysis Pipeline.

With the new “Pipeline Schemes” for Time Sereis Analysis Pipeline, we followed the suggestion by John Suckling: Input Table Spread Sheet’s “Pipeline Scheme” column will deal exclusively with individual subject processing, and Run Dialog will deal with whether a Group map is needed or not.
For the General Linear Model pipelines, those with uNx1 and pNx1 designation where N = [1,3] has “Variates” and “Interaction” parameters removed. This is because we release that the two parameters will always be stuck at “1″ and “No interaction” respectively. Thus, there is no need for them.

With u2x2 and p2x2 General Linear Model Pipeline, rather than requiring users to specify how the “Interaction” parameter looks like, i.e., “1 2″, we change it to a YES/NO toggle. Yet again we realized that the “Interaction” parameter can take on only two values, i.e., with/without interaction. We have yet to make a decision on “Variates”. We can see that the main logical choice for it is “1,2″. Initially, we thought that it is possible to convert any Nx2 pipelines to Nx1 pipelines. However, only after CamBA 1.1.0 is released where we realized the Nx2 pipelines does not offer this possibility and thus “Variates” should be removed. Hence, in the next release, if the General Linear Model pipelines remains in its current form, “Variates” parameter will be removed.

The reason for using GTK instead of Motif is the usability of the “File Open”/”Directory Open” dialog. I seems to have problems to set the directory/file path on Motif. This means that all users have to start navigating from home directory to their data. This is a disaster in the making.

So far, I have the CamBAfx UI displayed on Solaris under both Motif and GTK. Haven’t done the CamBA regression tests yet but I do not think we are going to have major porblem there. For CamBA C programs it will be a baptism by fire. Something we really love to put CamBA through.

Thanks to IoP for giving me access to their system to develop this version. Our own Solaris machines (circa 98) is simply too old.

CamBA’s User Interface is of course CamBAfx. The coast was clear for CamBAfx until the last few days where a frenzy of activities to beautify and clean up the User Interface, and tests that CamBA successfully integrate Eclipse Update Mechanism to permit over-the-web update.

As a developer, I am constantly being reminded of the benefit of using Eclipse as the development. Take the “Welcome” page for example, I decided to put it in the Friday before Release Candidate 2 is due. This is to stop users from seeing an “empty” screen. I used Eclipse to generate an example wizard page with RCP application, then modify this for CamBAfx. Total development time is 4 hours, with only the first hour spent understanding the “Intro” page mechanism (Eclipse jargon for the mechanics of the “Welcome” page) by looking at the example generated by Eclipse Platform, Eclipse Help pages and the trusty Google Search. The rest is spent agonizing over what to include/exclude from the “Welcome” page. In the end, simplicity rules so I have a “Read Me First” section for important information, an advert to inform users that we will be using Eclipse’s Update Mechanism to update CamBA in the future, a link to close “Welcome” page and another pointint to CamBA’s homepage. Without Eclipse’s Intro Page mechanism, the question on whether to “decorate” the start screen will not even exists.

This post is likely to be of no interest to anyone except GenericFX maintainers and people interested to see how AspectJ has been used in a project.

AspectJ

As I had said, Pipeline Schemes is something desirable, but is not an critical component of any Batch Processing/Pipelining Framework. In fact, there is the argument that Pipeline Schemes complicates the pipeline design and confuse the users as it introduce multiple ways for the data can flow through the pipeline.

Hence, won’t it be great if, at several click of the mouse, the whole Pipeline Schemes System can be disabled, and the rest of the program behave as if it was never there, ever?

Moreover, modifying source code, especially stable source code, has the potential of introduce additional bugs. Hence, if possible, I do not want to touch the source code for the generic pipeline engine that I use to pump the data through the pipeline. They are simple, but quite flimsy and sensitive to modification. Moreover, they are stable code as the code has not gone through much changes for almost 2 years now. They are also well understood and well tested, considering the fact that it survives two major tests, the first being to add an interface to Matlab transparently, and to extend the original code to embrase script output.

Pipeline Scheme related code, because of its very extensive reach from UI to pipeline control, is also expected to be peppered all over source code. Peppering code around several files to acheive one aim is bad, as it destablize these files.

Is there an alternative? AspectJ seems to offer one. It allows selective AspectJ code to be disabled by excluding the relevent aspectj files from compilation; There is no need to modify the original Java files because aspectj works by injecting codes from an aspectj file at defined location and when some predefined conditions are met; Finally, Peppering of code for Pipeline Schemes can be avoided because the we can put a significant amount of aspectj code inside a file and get aspectj to inject codes from this files into the Java files it is suppose to “infect”.

The downside? Possible overhead with AspectJ. Roughly speaking, this translated to slower compiling and/or running. Slower code generation affects developing the software. Slower application run affects everyone. Since creating more source code always leads to slowing down of application, I need to stress that when I mean slowing down, I meant the additional delay imposed by using AspectJ to develope the functionailty required, compared to pure Java implementation of the function.

When it comes to compiling, as aspectj is addon to java compiler, we would and must expects some overhead in compiling. Compiling is something the development team do very frequently. However, this is a price worth paying for clearer source code organization. Since aspectj uses an incremental compiler (a compiler that just compile the “difference” between the previous source code and your current modification), the delay is barely noticeable, at least for this project.

Slower application on the other hand, annoys everyone. If compile-time weaving, i.e., injection of aspectj code into java files at the time of compiling, then the slowing down effect is very much negligible, at least for this project. However, as GenericFX is a collection of plugins, this project requires runtime-weaving/post-compilation-weaving, meaning aspectj code must be injected after the plugins are created, or when the plugins are loaded when the program is running. This has the potential to significant slowdown of the application.

Development Strategy

With GenericFX, we are not sure whether AspectJ is the correct way to develop Pipeline Scheme functionality. Hence, we try to hedge our bet: We writes pure Java code as much as possible, using AspectJ only as the glue code. Hence, if necessary, we can rewrite AspectJ out of the system.

Before embarking on developing Pipeline Schemes, I used AspectJ to develop the “Job Number” and “Notes” column. This give me a feel of AspectJ. Furthermore adding the two columns is taken as a trial run for Pipeline Schemes as they are smaller, significantly easier but is representative of the expected contribution of AspectJ to this project.

Results

When compared with the original application, there is a noted delay when the application launches. After clicking “Finish” to create pipeline files in any New Wizard, there is a notable delay before the Input Table SpreadSheet is shown. I think it is safe to attribute both to the overhead of AspectJ. In particular, the use of runtime-weaving where every class is examined when its class loader runs to determine whether aspectj code is to be injected.

Another notable issue is memory usage, AJEER, the aspectj runtime weaving plugin I used, needs a lot of memory. Hence I normally allocate 512MB to the JVM. I believe it will be OK with lower memory, but 40MB, the usual memory allocation for JVM, is definitely not enough.

Developer’s viewpoint

The plugin structure for GenericFX got into the way of using AspectJ. One basic requirement for Pipeline Scheme is to track track the dataset through the pipeliine, as Pipeline Schemes can be different for different dataset. It is found that this requires modification to two classes separate across the plugin boundary. The results, post-compile weaving or runtime weaving is needed. That is why AJEER come into the picture.

For most aspectj classes created, I find that they often affect one Java file only, although a significant number of them requires injection of code at different points in the Java file. This means I could have abandon AspectJ and just code the function inside the Java file itself. The advantages of using AspectJ seems to be limitted to quick disabling of “Pipeline Scheme”, offering a different “view” on the Java file as all Pipeline Scheme related functionalities are in a separate file, and that if I used the pure Java approach I might increase the already long file by a third. This create doubt in my mind on whether aspectj is really suitable for this project since may be a reorganization of the Java File will achieve the same result.

A IDE that understands AspectJ is a requirement, not an option

For beginners, it is a MUST. Beginners need the little visual cue (is the apsectj injecting code? if so, to whom? Did it inject into too many files?) the IDE comfirm their AspectJ construct is correct. To require them to compile and run a test case simply to get feedback is too cumbersome.

One of the downside of AspectJ is the Java file that it has to inject code into can be easily altered in such a way that AspectJ is no longer capable of injecting code into it. Hence, developers have to look for the (dis)appearance of little visual cue offered by AspectJ-enabled IDE. I do not think seasoned developers can escape this problem. Like dynamic-typing in Scripts (where the variable can be integer in one instance, string in another), it can be argued that this is not a problem because the Unit Test or Regression Tests should catch this problem and rigorously testing is definitely better way to ensure software function as programmed.

AspectJ reinforce the need of “Design-by-contract”

Design-by-contract basically means a programmer promise his downstream programmers that if they call so-and-so function, so-and-so job will be performed (the contract). This contractual is crucial to the smooth functioning of AspectJ, especially if aspectj’s feature where a sequence of events (cflow() statements for example) is needed to cause activation of of aspectj code is used.

Conclusion

As it is currently implemented, the advantage of using AspectJ in GenericFX is rather uncertain. It do allows “Pipeline Schemes” to be activated/deactivated almost at will. However, the expectation that without it, Pipeline Schemes code will be peppered throughout the source code does not materialize since most aspectj code affect one file only. Moreover, the significant increase in memory requirement and the “very slight but noticeable” delay at some points in the application introduced simply because I have to use runtime-weaving to allow one aspect to cross the plugin boundary might just not be worth it.

I will keep monitoring AspectJ use in GenericFX and form an opinion later whether is it worthwhile to keep AspectJ, or to work it out from GenericFX. The jury is still out.