If NMR spectroscopy were as simple as UV, IR or most other spectroscopies the life of an
NMR spectroscopist would be much less interesting. Fortunately, the physics of NMR is such
that the spectroscopist can perform an almost limitless variety of experiments. Different
experiments can be used to tease out different sorts of information from the molecular
system which can ultimately be used to understand both the structure and dynamics of a
molecular system. A downside of this flexibility is the tremendous amount of data that may
need to be interpreted. A series of experiments on a reasonably complicated molecule like a
protein or nucleic acid can generate literally gigabytes of data. Furthermore, to interpret
these data requires correlating the information from the multitude of different experiments.
NMRView exists to help the spectroscopist manage and use this vast quantity of information.
Other excellent programs, with similar goals, exist. Why use NMRView instead of these?
Useful NMRView is developed by and for NMR spectroscopists. The
features are those needed by practicing NMR spectroscopists in their day-to-day work. Of
course that doesn't mean that the features we need coincide exactly with features that every
other NMR spectroscopist needs. On the other hand, many of the features we have added are
likely to be of use to others. We do listen to requests for new features, and we try to
incorporate them as time allows.
Scriptable One of the first features requested after the basic version
of NMRView was completed was the ability to automate frequently used operations. The logical
way to accomplish this was by incorporating the ability to write scripts: lists of
instructions for NMRView to carry out. The best decision made in the development of NMRView
was to not develop a new scripting language. Instead, NMRView incorporates the scripting
language Tcl (Tool Command Language) into NMRView.
With Tcl, NMRView gained not just the ability to automate simple tasks, but the ability
to write complex programs that could be used to carry out novel analyses. Thus the end-user
was to a large extent freed from the limitations placed on NMRView by the author’s limited
time. They could extend it in entirely new directions.
Starting with version 3.0, NMRView incorporated not just the Tcl language, but its
amazing companion, Tk. Tk is a library of Tcl commands that can be used to create graphical
user interfaces (GUIs). With this version of NMRView, the entire GUI is created using Tk.
Thus, not only can the end-user write new analysis techniques or simple scripts to automate
actions, they could add a GUI to these extensions.
While the compiled NMRView executables are still developed solely by the author, a
worldwide community of spectroscopists now contributes to the Tcl scripts, such as the
enhanced CSI facility. In 2000, a group of NMRView developers gathered in Utrecht, NL to
bring together a variety of extensions to NMRView and unite them into what became version
5.0.
Free Finally, NMRView is free software, available to anyone who
wishes to use it. This is one way that the developers can contribute to the overall growth
of the technique of NMR.
A recent event in the history of NMRView has been the development of a version written in
the Java programming language (http://www.java.com). The promise of Java being a portable
language is realized quite well in NMRViewJ. The identical Java bytecode file executes
successfully on Windows NT and XP, Macintosh MacOS X, SGI Irix, Linux, Solaris and probably
other Java implementations. In the case of NMRViewJ, the end user need only download a
single file. This file in the Java ?jar? format contains all the resource files (Tcl,
documentation, etc.) and the Java binary file. A key feature of the Java version of NMRView
is the ability for end users to extend it not only with new Tcl scripts, but with new Java
classes.
The transition of NMRView to NMRViewJ (J for Java) has raised a number of questions in the
user community. These questions are addressed below.
- 1.1. Why not keep developing NMRViewC?
- 1.2. Are there advantages to developing NMRView in Java?
- 1.3. How long will it take me to learn NMRViewJ?
- 1.4. Will my Tcl scripts still run?
- 1.5. How is the GUI made with NMRViewJ?
- 1.6. Will it be much slower?
- 1.7. Now that NMRViewJ is the focus of development will you release the source to
NMRViewC?
- 1.8. Will NMRViewJ be more or less stable (prone to crash) than NMRViewC?
- 1.9. Will NMRViewJ be more or less extensible?
- 1.10. Do users need to know Java to extend the code?
- 1.11. Will my STAR files and other files of data (peaks etc.) still load?
- 1.12. What platforms will NMRViewJ run on?
- 1.13. Will you keep fixing bugs in NMRViewC?
- 1.14. Will new Tcl scripts for NMRViewJ continue to work with NMRViewC?
- 1.15. What about all the third party extensions to NMRViewC?
1.1. | Why not keep developing NMRViewC? |
| The code base of NMRViewC, though very functional, is not very well
engineered. This makes it hard to debug, extend, and understand. NMRViewC
incorporates two third party libraries that are no longer maintained. While
functional, I?d rather incorporate code that is itself supported and whose
license is consistent with my distribution of NMRView. The NMRViewC code needs
to be ported and compiled on each platform I support. The time and expense of
porting it limits the number of platforms that are supported. My personal
experience is that I have more errors in my C code than in my Java code. I
really dislike the whole ?configure? concept of current C development where you
have a program that is thousands of lines long to figure out the idiosyncrasies
of the platform you are developing on. |
1.2. | Are there advantages to developing NMRView in Java? |
| While you can still write bad code in Java, the object oriented nature of
Java aids one in developing more understandable and reusable code. The same Java
code will run on many platforms meaning that I only need to make one version of
the ?binaries? available and that will run on any system with the Java virtual
machine installed. In particular, this means that NMRViewJ will run on Windows
computers. Many of the errors that have occurred in NMRView over the years are
simply not possible in Java. Because of this, NMRViewJ should be more robust
(less likely to crash) than NMRViewC. Java has intrinsic support for threading.
This means it is possible to write code that can perform certain operations in a
separate thread of execution, essentially allowing ?multitasking? within a
single application. On multiprocessor computers each thread can operate on a
separate processor. NMRViewJ already does its contouring of NMR datasets in a
separate thread. Because of this NMRViewJ can simultaneously draw multiple
spectra. The design of NMRViewJ makes it very easy to incorporate Java
libraries. This will allow the addition of many new features to NMRViewJ.
|
1.3. | How long will it take me to learn NMRViewJ? |
| The basic interface to NMRViewJ is very similar to that of NMRViewC so users
should be able to learn it quickly. There are a few areas such as the new
spectrum attributes panel that are new and hopefully improved. These should be
easy to understand. |
1.4. | Will my Tcl scripts still run? |
| NMRViewJ incorporates Jacl (Java Command Language) which is a Java version of
Tcl so most basic Tcl scripts run exactly the same. The majority of the Tcl
scripts (those found in the directory nvtcl) are the same in both NMRViewC and
NMRViewJ. |
1.5. | How is the GUI made with NMRViewJ? |
| NMRViewJ uses Swank to create its GUI. Swank is a GUI toolkit written in Java
(by me) that implements the same interface and widgets as Tk. Because of this,
the code that implements the interface in NMRViewJ and NMRViewC are nearly
identical. A primary difference between using Tk and Swank in NMRView is that
while Swank supports scrollbars the implementation is not great. On the other
hand, Swank can embed widgets within a scrollpane which is simple and gives
excellent behavior. |
1.6. | Will it be much slower? |
| Java code as executed by a good Java runtime environment is not much slower
than C code. The validity of this statement is dependent on exactly what the
code is doing, and how it?s implemented in both the C and Java programs. As a
real world example consider contouring datasets in NMRView. Here are some
timings in NMRViewC and NMRViewJ: i. PowerBook G4 (17?) 1.33 Ghz, Mac OS 10.3.2
ii. 3D Dataset 512x256x64 iii. Time to draw entire spectrum (including noise
band near water). NMRViewC: 60s NMRViewJ: 10s Yes, NMRViewJ performed 6x faster!
(disclaimer: differential may be different on other computers) The area where
NMRViewJ can be significantly slower than NMRViewC is when executing Tcl code.
The C Tcl interpreter converts Tcl procedures to ?byte codes? which can be
executed much faster (up to 10x) than interpreting the original Tcl source. At
present Jacl doesn?t have a compiler so execution of scripts can be slower in
Jacl than Tcl. For many scripts the speed difference is not apparent, but
complex routines can take noticeably longer to execute. Multithreading in
NMRViewJ can make it seem faster than NMRViewC in some areas. For example, when
peak picking runs in its own thread the user will be free to continue doing
other things while the peaks are picked. Is there any hope that NMRViewJ script
execution will become faster? Yes. I?ve done some prototype work on developing a
compiler that compiles Tcl scripts to Java bytecodes. Procedures compiled this
way are executed the same way Java code is. There is a lot of work to be done to
implement this, however, so I don?t know if I will be able to accomplish it
unless I get some expert Java programmers (preferably with compiler experience)
to help. I plan on porting some of the scripting code from Tcl to Java. In this
case it may run faster than the Tcl code in NMRViewC. The Tcl code that performs
peak matching in the cbca module is one example of code that would benefit from
translation into Java. |
1.7. | Now that NMRViewJ is the focus of development will you release the source to
NMRViewC? |
| No. There are a variety of reasons for this, but the primary one is that I?d
rather get the energy of users and contributors focused on NMRViewJ and not have
a split of development efforts between NMRViewC and NMRViewJ. Will you release
the source to NMRViewJ? This is very likely to happen in 2008. |
1.8. | Will NMRViewJ be more or less stable (prone to crash) than NMRViewC? |
| My experience so far is that it is more stable. Certain programming errors
that one can make in C programming are not possible in Java. Also, when errors
happen one often sees an error message (about an ?Exception?) but the program
doesn?t crash. On the other hand making NMRView into a multithreaded program
makes some new error conditions possible. On balance I think NMRViewJ will be
more robust than NMRViewC. |
1.9. | Will NMRViewJ be more or less extensible? |
| One reason for the widespread adoption of NMRView has been the ease with
which users can extend it with their own code so this question is very important
to me. I intend that NMRViewJ will be even more extensible than NMRViewC.
|
1.10. | Do users need to know Java to extend the code? |
| No, they can extend it with Tcl (Jacl) code just like NMRViewC. But knowing
Java is a key to extending NMRViewJ in ways that were not possible with
NMRViewC. Tcl had lots of C based extensions that could be loaded into NMRViewC.
What about those? Those extensions will not work. On the other hand, there are
many Java based tools that can be loaded into NMRViewJ. Because Jacl can call
any public method in Java code these tools do not have to be written explicitly
to work with Jacl. |
1.11. | Will my STAR files and other files of data (peaks etc.) still load? |
| Yes. NMRViewJ and NMRViewC read and write the same data formats. |
1.12. | What platforms will NMRViewJ run on? |
| I?ve run it on Mac OS X (my primary development platform), Windows XP,
Solaris, and Linux. It should run on any platform that has a suitable
version of Java (version 1.5 is best). Some NMRView versions, like NvAqua for
Mac OS X had some platform specific specializations. Will NMRViewJ be optimized
for different platforms? Yes, though this may seem inconsistent with the idea of
having one set of code that runs on all platforms. The basic code will be
exactly the same on all platforms, but it is possible to enhance the user
experience by taking advantage of some platform specific code. This is
especially likely on the Macintosh where Apple provides some nice Java related
tools for interacting with Mac OS. Expect to see such features as
double-clicking on dataset icons to open them in NMRViewJ. |
1.13. | Will you keep fixing bugs in NMRViewC? |
| This depends on the nature of the bug. The more time I spend with NMRViewC
the slower the transition to NMRViewJ (and the new features it offers) will be.
I?ll probably continue to fix bugs for some period of time (a year?) that are
particularly important, or easy to fix. Of course if the bug is in Tcl code that
is common to both NMRViewC and NMRViewJ it will be fixed. |
1.14. | Will new Tcl scripts for NMRViewJ continue to work with NMRViewC? |
| This is an important question, the answer to which will depend on feedback
from users. If scripts are developed with backwards compatibility to NMRViewC
then progress in adding new features to NMRViewJ will be slower. A clean break
with NMRViewC in the development of new scripts and reengineering of old scripts
will speed the way to a better NMRViewJ. On the other hand, users that continue
with NMRViewC will probably prefer to see a high degree of compatibility.
|
1.15. | What about all the third party extensions to NMRViewC? |
| Some of these extensions will work in NMRViewJ without any changes. For those
that don?t work, I?ll be happy to work with the developers to convert them to
work with NMRViewJ. In some cases I can port them myself, in others I?ll provide
guidance on what needs to be done. |