Home

News: JSR 277: Replace JARS with Java modules and a repository

  1. Java Archives (JARs) date back to the mid-1990s. However, JAR files are hard to distribute, hard to version, and hard to reference in general. Sun has submitted JSR 277: Java Module System, which defines a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime.

    Explaining the need for a new module system:
    There is no built-in versioning support in the JAR format. There is no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR upon another. Referencing a JAR, moreover, involves specifying it in the classpath. Since the path of a JAR may change during deployment, developers are forced to fix up all the references to the deployed JARs as part of the deployment process.

    Developers also find it quite difficult to deploy installed Java extensions (a.k.a optional packages) because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations.

    The Java Module System intends to correct these problems by including:
    o A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.

    o A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.

    o A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.

    o Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.

    o A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

    The JSR has just been submitted and is due for it's review ballot/voting by June 27th, before continuing further development. Should it pass, the intention is to have it be a part of J2SE 7.

    Threaded Messages (51)

  2. Great - if they make right[ Go to top ]

    This is a highly needed addition to Java.

    I just hope they'll keep it simple.
    Hate to see that it is not going to be available sooner than Java 7.

    Regards,
    Edmon
  3. Great - if they make right[ Go to top ]

    Note that they're also concerned about backporting availability. However, that's not likely to be a high priority.
  4. Add more features if it is possible.

    Regards,
    Uvarasan K
  5. JVM should be enhanced like Apache Maven, it can download dependencies automatically from preconfigured module repository acordding to the dependency, then this new spec will be very usefull, isn't it?
  6. JVM should be enhanced like Apache Maven

    I so do hope that Hani Suleyman sees your post... ;)
  7. JVM should be enhanced like Apache Maven, it can download dependencies automatically from preconfigured module repository acordding to the dependency, then this new spec will be very usefull, isn't it?
    If correctly done, this would enable a huge decrease in JRE size, where people would install just a very small core base and the system would download necessary libs on demand, further helping Java adoption on the client side. Together with MVM, I'd say it could revolutionize Desktop Java, as (IMO) memory footprint, startup delay and JRE size are the top items which block java adoption on client size.

    Regards,
    Henrique Steckelberg
  8. If correctly done, this would enable a huge decrease in JRE size

    Is this really important? 100 Mo is almost nothing actually, when you can buy a 300 Gb disk for 150$. Even on older computers, 20Gb disks is really enough.
    ...where people would install just a very small core base and the system would download necessary libs on demand, further helping Java adoption on the client side.

    Sorry, but I don't see what difference that make with the way a JVM is actually working, except that jars are downloaded instead of read localy.
    Together with MVM, I'd say it could revolutionize Desktop Java, as (IMO) memory footprint,

    Any clue how memory footprint could be reduced? As you still have to classload the classes you need, it won't change.
    ... startup delay and JRE size are the top items which block java adoption on client size.

    The startup delay will be much longer if you have to download all the classes you need...

    IMHO, the only advantage you'll have is that you will have a very small loader on the client side and a lot of time spend downloading many many classes.

    I may be totally wrong, but if JSR277 could be really interesting when you deal with jars that change really often (apache commons-xxx, for instance), it won't reduce the JRE size, and I don't see the JRE size as something that slows the adoption of Java on the client side. There are so many other reasons (thanks to M$) !
  9. If correctly done, this would enable a huge decrease in JRE size
    Is this really important? 100 Mo is almost nothing actually, when you can buy a 300 Gb disk for 150$. Even on older computers, 20Gb disks is really enough.
    A smaller JRE would reduce download time and improve startup time a bit.
    ...where people would install just a very small core base and the system would download necessary libs on demand, further helping Java adoption on the client side.
    Sorry, but I don't see what difference that make with the way a JVM is actually working, except that jars are downloaded instead of read localy.
    Not everyone has breadband at home (yet), so it would be possible to "spread" JRE into smaller packages, improving the response perception.
    Together with MVM, I'd say it could revolutionize Desktop Java, as (IMO) memory footprint,
    Any clue how memory footprint could be reduced? As you still have to classload the classes you need, it won't change.
    MVM reduces memory footprint by using one JRE process to run all your java programs, maximizing resource sharing. Further, it improves startup time hugely. But it is effective only when more than one java app is run at the same time, which happens more often nowadays, take IDEs for example, where you have the IDE itself, Ant, Tomcat, and other apps running at the same time on the computer.
    ... startup delay and JRE size are the top items which block java adoption on client size.
    The startup delay will be much longer if you have to download all the classes you need... IMHO, the only advantage you'll have is that you will have a very small loader on the client side and a lot of time spend downloading many many classes. I may be totally wrong, but if JSR277 could be really interesting when you deal with jars that change really often (apache commons-xxx, for instance), it won't reduce the JRE size, and I don't see the JRE size as something that slows the adoption of Java on the client side. There are so many other reasons (thanks to M$) !
    The classes you need would be downloaded only once, and it would be much smaller than the whole JRE. The next time you use a downloaded app, all its jar would be already installed locally, similar to how WebStart apps work.

    Regards,
    Henrique Steckelberg
  10. I think that Henrique explained very well. As JRE is getting bigger and bigger, most of our programs may use less than 5% of core library, why should our end user need to download 30 MB of JRE. If Java is just trying to mimic .NET, Java will be always behind the .NET. To be more useful, Java (JVM level)design should be stay ahead of Microsoft, be a pioneer, not a follower. The idea of Maven/Maven 2 like function, it really can speed up rapid deployment process. Let's say, you have a new version release, which depends on some new version open source libraries, you can drop those libraries to your repository, specify it in your module manifest file, in this case as developer, you can focus on your own package only, those third party libraries will be managed by JVM. On the other hand, you can break your own module to a even smaller, it also help you to distribute patch update quicker and easier.

    Also many of our programs share the same open source libraries, such as Xalan, Xerces etc. why should our user need to download it again and again, if it is already in user's machine?

    In modern days Hard drive is no longer a problem, but network bandwidth still is.
  11. As JRE is getting bigger and bigger, most of our programs may use less than 5% of core library

    I perfectly agree with this assertion.
    ...why should our end user need to download 30 MB of JRE.

    Make it 100 Mb actually. Whatever, this is not something you do on a daily basis. Usually, you download a new version every three month, and it's not a big deal. So the answer is : because you can download once, install many. This is the way it works in big companies.
    ...The idea of Maven/Maven 2 like function, it really can speed up rapid deployment process

    I don't know how. I agree that it eases the development process, as you have a common repository, if this was what you intended to write (deployment -> development)
    Also many of our programs share the same open source libraries, such as Xalan, Xerces etc. why should our user need to download it again and again, if it is already in user's machine?

    The point is that when you package a product, you are supposed to deliver a standalone application. If you have to rely on external jars, except the ones that are on a specific version of the JRE, you are entering in a kind of 'DLL/JAR hell'. On the other side, when you are getting used with a tool like synaptic on Linux, this is obviously something valuable if java offer such a mechanism.
  12. I don't really think the original suggestion was worried about disk space as much as how long it takes grandpa to download a JRE and any associated application level JARs over a dialup line, yes they really do still exist. We do want Java to become more widely accepted right? Making it a smaller and simpler download would help.

    IMO, he was also talking about a dynamic download of necessary libs during "first use", not each and every time they are used. The first use of a library would be slow, but things should be considerably faster after that once it is on disk to stay. A versioning mechanism with perhaps levels of severity/functionality and let the user decide what to accept... as much as I hate to say it, like Windows Update with critical updates versus feature updates.

    I agree though that the memory footprint would not be affected, you need the libs you need... they use memory.
  13. JVM should be enhanced like Apache Maven, it can download dependencies automatically from preconfigured module repository acordding to the dependency, then this new spec will be very usefull, isn't it?

    I dont use Maven, but i use the maven2 tasks, and have also added support for it in our SmartFrog deployment framework. It really works well if multiple apps all share the same central (versioned) repository.

    I do fear that the same people that gave us classpath-in-manifest and the ear.xml configuration docs will provide yet-another-XML format to describe dependencies, one that, by being included in the JAR, is too early. Development time dependency metadata should be taken as a hint, not as the absolute truth.
  14. Add Maven.... Your kidding right? It is not that I hate Maven, but it should not be part of VM!
  15. JVM should be enhanced like Apache Maven, it can download dependencies automatically from preconfigured module repository acordding to the dependency, then this new spec will be very usefull, isn't it?

    From the bottom of the JSR page:
    In addition, the expert group will seek to learn from this existing initiative for its repository feature:

    [1] Maven: http://maven.apache.org/
  16. Cool :-)[ Go to top ]

    +1
  17. new visibility keyword[ Go to top ]

    In addition to 'public', 'protected' and 'private', maybe we could get 'module' keyword with this too. It could mean something like "visible to anything within this package or its sub-packages".
  18. This is needed, but not for visibility to current package and subpackages. I don't really see the value of package and subpackage visibility, as Java packages have never been hierarchical that way. This would require, or at least really encourage, that there be a one-one relationship between namespace and module.

    Ever since the introduction of Java, the concept of "package" has fused two concepts, "namespace" and "component" (or "module" in this JSR's terminology). .NET, for example, distinguishes between these: see .NET's "namespace" keyword and its "protected internal" access modifier.

    A namespace is just something that allows you to avoid name collisions across space and time. There is nothing preventing you from using the same namespace in one place that's used in another.

    .NET's "protected internal" is what we need in Java, and could be made possible by this proposed JSR: visibility includes the current class, subclasses (which may not be in the defining module at all), and all other classes found within the module. This allows you to avoid having to promote to public methods that are not really supposed to be callable by the public. I don't really care what the keyword is, but it would be really nice to have this.

    This has been discussed before (by me, of course):
    http://www.theserverside.com/news/thread.tss?thread_id=27524#132481

    I welcome this effort, however. It wouldn't be bad to see a native platform launcher as part of it as well, but I haven't really thought that through much...

    --matthew
  19. I agree with your post. You've put more thought into it than I, I was just spouting what came to mind when I read the article :-), and because I have a habit of organizing my packages hierarchically such that classes at the top layers don't know about classes deeper down, but deeper class often know about classes 'above' them.
  20. Can we release a pacth for Java Module. For example I have modified one java class and wants to update the java module with that class alone. Because it is not possible in the current scenario of JAR. Entire JAR file has to be shipped if any changes are there.
  21. Microsoft's Java VM[ Go to top ]

    fyi

    In 1998, Microsoft's Java VM had a Java package repository. Microsoft called it the "Java Package Manager". It supported versioning and namespaces.
  22. VAJava[ Go to top ]

    The VM in IBM VisualAge for Java also had a repository containing all source _and_ compiled code (third party jars etc). I once posted a question on the vajava newsgroup if having this VM + repo as a separate product would not make sense, at the time noone seemed interested (nil replies).

    Luc.
  23. I'm a fresh Ubuntu convert, and i greatly enjoy their package management system. You have a default repository, with trusted and well tested applications and libraries, and you can add other non-supported repositories, with more cutting-edge and potentially unsafe applications, but at least you have been warned. Package dependencies are handled automatically, and when the system starts it checks for the latest versions of your installed components, and you have only to click on the red upgrade icon on your desktop to have your system up-to-date. And you can easily search for new applications to install or remove.

    This can hardly be more user-friendly. I wish that Sun will take ideas from Linux as well, and also find a way to integrate their update system with the OS update mecanism.
  24. I'm a fresh Ubuntu convert, and i greatly enjoy their package management system. You have a default repository, [..]
    The major drawback with these type of repositories is that it has to be managed centrally. I think you would rather give module vendors they ability to set up there own repositories.

    For such systems to work the new versions of the modules should be fully backwards compatible (unless stated otherwise and a client might deside to use on previous version). So I think annotations can come in to play here. Define the pre- en post conditions of a method to be sure that new versions of a module always live up to there previous contracts.
  25. One problem that maven and jpackage have is that neither of them can properly redist all the many sun jars, because lots of them require click-through acceptance.

    how can you do automated download to 200 machines on a site if clickthrough is needed on each one? If sun embrace this spec, they need to publish all the jars of their many little Java libraries on a public server for all automated tools to retrieve on demand. If they dont, then only OSS products can be redistributed, and frankly Maven2 owns that problem already.
  26. Basically, for some module that requires license agreements, those modules have to tell JVM where is the license agreement within the module. At the runtime, JVM will prompt user to accept or decline it; in case of automation, this should be handled by answer/response file.
  27. Jar level dependencies...[ Go to top ]

    I think the only way to pull this off is to put the dependencies within the Jar files (an extended manifest, perhaps).

    I don't think we'll be seeing:

    import com.xyz.package.Things(1.2+);

    First, I would think that the source code is, sorta, the wrong place to place these dependencies. I mean, it's kind of a hard question, isn't it?

    I mean, I don't want to enumerate Jar files in my source code, but I may want to notate specific class version requirements.

    Because, to me, Jars are nothing more than directories, and, ideally, save for STUPID things like COM.rsa (which will happily break on Windows), you can stuff gobs of jars into a single directory and then jar them all into one super uber jar (weblogic.jar anyone?).

    So, there's a difference between a JAR and a Package, IMHO, and I hope that they continue with that distinction.
  28. However, JAR files are hard to distribute, hard to version, and hard to reference in general.

    "Versioning , resolving dependency,namespace " . Isn't it the job of META-INF file, available within a JAR ?

    Distribution, unloading , loading is not an issue with JAR file , per se. ClassLoaders should be enhanced to achieve this.

    Regards
    Surajeet
  29. JSR 277 vs. OSGi[ Go to top ]

    Is there something new in JSR 277 that is not already achieved by the OSGi?
     
    * http://www.osgi.org/osgi_technology/index.asp?section=2
    * http://www.knopflerfish.org/
  30. JSR 277 vs. OSGi[ Go to top ]

    My immediate first thought also. Plus, the OSGi is already being used or at least very mature.


    J. Betancourt
  31. While we are at it, wouldn't it be useful to express relations between version, such as "replaces", "compatible"?

    And versions of what? If I change the implementation without changing the interface, it certainly is different version.

    If I only add to a "module", that is a new version of the module but I did only extend it.

    I hope you see my point here. It is not only that there are new version in a straight line that may or may be not compatible.

    Sure, you could rely on a numbering scheme but that feels a bit limited and unsafe, I think.
  32. While we are at it, wouldn't it be useful to express relations between version, such as "replaces", "compatible"?And versions of what? If I change the implementation without changing the interface, it certainly is different version. If I only add to a "module", that is a new version of the module but I did only extend it.I hope you see my point here. It is not only that there are new version in a straight line that may or may be not compatible.Sure, you could rely on a numbering scheme but that feels a bit limited and unsafe, I think.

    Sounds like the COM compatibility mechanism. Back in my VB days, managing the type of comptibility required at build time was a major headache. I seem to remember that either you fixed your interfaces early, which is probably not a bad thing but development is never that cut & dried, or else everything was given a new version each time, which kind of made the whole "flexible" versioning thing redundant.

    Kit
  33. I've once really learned to hate COM and I agree that if you look at it that way, it sure is not much of a point.

    But I see it more like that you have released a module that others are using and you need to be able to say: "This is a patch - low risk of breaking your code", "This is a major update but we only added stuff - also low risk of breaking your code" or "New architecture - your code will most likely break".

    I am not inventing this from thin air, it goes back to work I did at a telco company which needed an extensive scheme to keep track of which version was compatible with another.
    While we are at it, wouldn't it be useful to express relations between version, such as "replaces", "compatible"?And versions of what? If I change the implementation without changing the interface, it certainly is different version. If I only add to a "module", that is a new version of the module but I did only extend it.I hope you see my point here. It is not only that there are new version in a straight line that may or may be not compatible.Sure, you could rely on a numbering scheme but that feels a bit limited and unsafe, I think.
    Sounds like the COM compatibility mechanism. Back in my VB days, managing the type of comptibility required at build time was a major headache. I seem to remember that either you fixed your interfaces early, which is probably not a bad thing but development is never that cut & dried, or else everything was given a new version each time, which kind of made the whole "flexible" versioning thing redundant.Kit
  34. I've once really learned to hate COM and I agree that if you look at it that way, it sure is not much of a point. But I see it more like that you have released a module that others are using and you need to be able to say: "This is a patch - low risk of breaking your code", "This is a major update but we only added stuff - also low risk of breaking your code" or "New architecture - your code will most likely break". I am not inventing this from thin air, it goes back to work I did at a telco company which needed an extensive scheme to keep track of which version was compatible with another.

    I guess experiences are always going to differ. I agree that, when well organized, it worked well. But I found the effort to organize it distracted from the coding and made it prone to error. I remember we had several occasions when coders built their components accidentally as a full new version, and everything else had to be rebuilt as a result. It seemed that the effort you had to put into using it outweighed the benefit. It was a relief to move to Java with its unversioned jars.

    If the proposed mechanism for Java could do the same but try and avoid repeating the same errors, I'll be happy (and impressed) with it.

    Kit
  35. I guess experiences are always going to differ. I agree that, when well organized, it worked well. But I found the effort to organize it distracted from the coding and made it prone to error. I remember we had several occasions when coders built their components accidentally as a full new version, and everything else had to be rebuilt as a result. It seemed that the effort you had to put into using it outweighed the benefit. It was a relief to move to Java with its unversioned jars.If the proposed mechanism for Java could do the same but try and avoid repeating the same errors, I'll be happy (and impressed) with it. Kit

    Impressed is surely the word for me too. You and Vikrant points at DLL-hell which is a lesson to learn.

    First, to avoid distracting coding, it should not be part of it. It should be part of your delivery process and thus you would have to be able to switch of version checking by some means, e.g. by accepting anything.

    During coding, you shouldn't have to worry because you want to change things fast and often.

    When you deliver outside your project, it is a different song. Now your decisions will impact others. But you can't decide for them, they must make their decisions based on their product.

    If we have automatic download or not, we still need ways of determine if we should rely on new third party software. And I don't mean the company - I mean the software.

    I believe it is a matter of risk. Given that you have an application out there and there is a new version of the third party software out. How should you react to that? Test your software against it and then deliver a new version of your software? Or somehow remotley signal your installations out there to download a new version of the third party software?

    Or should that happen automatically when the third party delivers? I would like that to happen to anything mission critical!

    Why are people so reluctant to download SP2 of Windows XP? It is a risk they don't want to take, is my guess.

    I believe that a scheme for expressing dependencies and changes between versions of software would be benefical to risk assement in this case. It doesn't need to be complicated.
  36. +1[ Go to top ]

    I think this is a more reasonable and powerful way for versioning and dependency management of JAR files.
  37. Global Assembly Cache (GAC)[ Go to top ]

    looks like Global Assembly Cache concept of Microsoft .NET assemblies!!
  38. Ivy repository sounds similar[ Go to top ]

    This 'module' definition sounds like what Ivy (http://www.jayasoft.org/ivy) is trying to acheive. It uses xml files that describe dependencies for your project and flexible 'resolution stragtegies' that allow you to specify versions, such as "3.8+". It can then use a maven jar repository like ibiblio for the actual jars.

    The only real issue is keeping the Ivy Repository of these xml documents up to date.

    _________________
    Kim Pepper
  39. The Eclipse community is aiming at the same direction and has the same goals as this JSR, the lack of this functionality has been hurting the Java community long time ago, the old Windows DLL hell disease mutated into a JAR hell.

    Currently they have a better mechanism in place (plugin.xml) and in the future it will be possible to just drop a jar that contains the metadata without unzipping anything.
  40. The Eclipse community is aiming at the same direction and has the same goals as this JSR, the lack of this functionality has been hurting the Java community long time ago, the old Windows DLL hell disease mutated into a JAR hell.Currently they have a better mechanism in place (plugin.xml) and in the future it will be possible to just drop a jar that contains the metadata without unzipping anything.

    I think Sun is one more time late on this subject. The Eclipse RCP platform address this issue perfectly well (dependencies between plugins and features, update framework, versioning) that make this discussion pointless
  41. .NET Assemblies and GAC[ Go to top ]

    Looks like I am reading the description of .NET Assemblies and the Global Assembly Cache (GAC)
  42. .NET Assemblies and GAC[ Go to top ]

    Yep, .NET learned from Java's mistakes (this being one of them) and now it's time to reverse the learning process. ;) Having lived in JAR hell for a long time, I just wonder what took them so long...
  43. ahh, but look at .NET 2.0[ Go to top ]

    .NET 1.0 had a really strict binding mechanism; you could bind to something in the GAC by giving its SHA1 key, it was impossible for a new version to stamp on you as it would have a new key, etc, etc.


    But it turns out they boxed themselves in a bit, because when they turned to the problem of running .NET code on a 2.0 (specifically longhorn) system, they encountered the problem that the old libraries werent the right ones. Sometimes, on the target machine, you need to upgrade the libraries an app links against, without rebuilding the application.

    This is exactly the problem that putting hard dependency info into the manifest would have -just because someone built against a product/version does not mean you want to run it against the same verson, or indeed the same product. Example: I shouldnt have to care which XML parser other apps are built against, as long as my one implements the JAXP api.
  44. Example: I shouldnt have to care which XML parser other apps are built against, as long as my one implements the JAXP api.

    A good example where you would express that you depend on any version of a jar as long as it is compatible with the JAXP API.

    Wouldn't that be useful? Is it so hard to accomplish?
  45. Java *needs* this[ Go to top ]

    What java needs is a way of managing dependencies, not as part of the jvm, but a new tool that acts like apt on debian for example. There should be a single method on a system like sources.list for specifying repositories with Sun's repository included by default, but you could add additional urls for apache, codehaus etc.

    The jars would be installed in a directory like lib/ext, but would be subject to security constraints unlike the current implementation. The you could apt-get install clogging-1.3 and it would be available system wide.

    They need to look at tools like apt, ruby's gems and perl's cpan and implement something similar because the current situation is rediculous
  46. Re: Java *needs* this[ Go to top ]

    I totally disagree, as stated before you don't want single repository. In my opinion sources.list doesn't solve this problem since you manually describe the sources you trust.

    I, as a developer, rather specify which modules I need for my application. For instance:
    <module source="http://module.apache.org/xerces" compatible-with-version="1.0" />
    Leaving the maintenance to the vendor

    I, as a user, only want to get (atmost) notified of the fact that this application uses third-party modules and if I agree to use them.
  47. Re: Java *needs* this[ Go to top ]

    the original entries in the list would be trusted, like security updates in a debian sources.list and you shouldn't have to add the location of every jar, there needs to be a central repository for common jars with the ability to add custom locations (like an internal repository) too.

    By not using a single (or very few) well trusted resources, you may find that your xerces-1.0.jar will actually just contain the contents of a 404 page when someone moves the file on you! You need to get jars, with an md5 checksum, from people you trust and you shouldn't have to negotiate an agreement with every 3rd party jar provider.

    Using ibiblio works well, many libraries from many vendors in one place. Now we need a common place on the system to put them so your application and ide can access them without having to include the jars in multiple locations. It would be good to improve ibiblio to include a mechanism to notify the user if they are downloading jars with either restricted or viral licenses.
  48. Re:Re:Re: Java *needs* this[ Go to top ]

    This still means that the client should update itself in order to get the right dependencies. This behaviour should be avoided. Therefore such systems with sources.list simply won't do the job (good enough).

    Why would it throw a 404? There are several options to avoid this problem:
    - let the base url of a version source be updatable
    - supply your dependency with multiple resources (localized?)
    - connect to somesort of resolve servers (like dns)
  49. Mustang ?[ Go to top ]

    Is this targetted towards Mustang ?
    Since Mustang is focusing(http://java.sun.com/developer/technicalArticles/J2SE/Desktop/Mustang_build39.html) on desktop improvements, if this can also make it into Mustang, that will be great for desktop java.

    The rate of adoption of new Technologies, if they happen inbetween 2 JDK releases take more time than if a technology gets introduced with a NEW JDK.

    I hope that the JDK team keeps this in mind.

    BR,
    ~A
  50. In fact the point of worry is while trying to improve hope we don't end up making it similar to DLL in MS technologies, always getting those incompatible version problems, which make life a hell.
  51. +1.
  52. Seems a useful spec. sudhir jYog