Discussions

News: Opinion: Jini IDE. Is it the future?

  1. Opinion: Jini IDE. Is it the future? (28 messages)

    Vincent Massol is at it again. His blog really is a Think Tank :) His latest idea is to have an IDE use technology such as Jini for its modules. The core IDE itself would be a small microkernel, with Jini leases to individual modules, which could work locally, remotely, or a bit of both. Is this a good idea?

    Excerpt

    "Here are some ideas about this Jini IDE:

    - Each module would be a Jini service. Examples of modules are: javac compiler module, RMI compiler module, java editor module, source repository module, java execution module, junit execution module, etc.
    - It would be lightweight. It would be able to bootstrap with a minimal jar containing only the "microkernel" (+ possibly a module cache manager). Thus you could move from one machine to another easily. To install it, simply click on a browser link and download this minimal core. The rest will be downloaded as need be when you need the modules.
    - As each module is a Jini module, there would be 3 possibilities to implement a module:
    . The Proxy contains only local methods and there are no communication between the proxy and the back-end service,
    . The Proxy is a “smart proxy”, i.e. there are both local and remote methods which communicate with the back-end service,
    . The Proxy is only a client stub, all the methods are remote
    - It would be completely distributed. For example, the compile menu of the IDE would list all compiler module implementations the IDE has been able to discover when contacting the different Jini lookup services.
    - It would be self-healing: if a module is no longer available on a given server, another replacement will be automatically discovered (by the magic of Jini leases).
    - By using Jini leases, the IDE would support hot-patching/uninterrupted services
    - It would be secure using Jini security for modules. This will allow to support both open source modules and commercial modules.
    - What would be nice would be to have a repository service which would automatically save edited code on the server side (in a user-private zone). This would enable remote building. Developers on the move would be able to get their environment set up rapidly on any machine. Same if you wish to share environment with someone else, etc.
    - It would be completely modular with caching done on the client side to improve performances. The modularity should allow the creation of module repositories on the web. It would also allow creating IDE "a la carte"."


    Read Vincent Massol in Jini IDE. Is it the future?

    Threaded Messages (28)

  2. Sounds good for "distributed projects"[ Go to top ]

    Sounds good for "distributed projects".

    I guess you know Inca X ( http://www.incax.com/ ), it is (as far as I can see) a Pure Java IDE for Jini.

    Regards, Rob.
  3. Sounds good for "distributed projects"[ Go to top ]

    I think you've missed the point, it's a Jini based IDE not IDE for Jini.

    -John-
  4. I think Eclipse has many of the features of this Jini IDE.
      Modules are plugins.
      And with Eclipse 3.0 will be possible download and install modules on the fly too.
      But I am not a Jini expert so I do not know why it would be usefull.
      Another idea can be build a IDE using a small IoC framework, like NanoContainer.
  5. WADR, I think you've also missed the point, Jini is closer to a distributed Java OS or shared memory. While you can obviously do this in Eclipse or IntelliJ the idea (no pun intended) of using a Jini based IDE is that your IDE will essentially be running across the network across using all of your computers, similar to the way SETI works. When you launch a compile or JUnit test, it will (could/might) run on one or several other computers. Jini has leasing of Entrys [sic] (services or data), this means that you could have modules in the "Space" (i.e. distributed shared memory) that have a lifetime. Of course you can do all of this on a single machine, the advantage of using Jini is that you get a nice simple API and it will automatically run across your network (local or wide).

    Jini is the future so it's worth reading about it, it's about 10 years ahead of Microsoft's WebService crap, vastly more powerful and orders of magnitude faster. The only problem is that it doesn't support Microsofts virus platform.

    -John Davies-
    C24
  6. With Jini you also have lots of other options, for instance, you could also use mobile agents.
    In effect, the IDE attaches it's core modules through Jini lookup and discovery, and when actions require capabilities not available in the IDE, the system launches a mobile agent to a grid which can then do it's processing wherever it is most capable of doing so, before returning, thus stopping the IDE creating loads of connections. I've mostly developed a system like this at the moment, using Jini, mainly because I've never really 'got into' J2EE. Neon uses a message bus and router idea to allow activation of server side function and collaboration between agents, but this function is fairly fluid, in that it can move around the network as required.

    The concepts that vincent is talking about naturally begins to lead to using Grids for terminal client type work.

    Calum
  7. With Jini you also have lots of other options, for instance, you could also use mobile agents.

    > In effect, the IDE attaches it's core modules through Jini lookup and discovery, and when actions require capabilities not available in the IDE, the system launches a mobile agent to a grid which can then do it's processing wherever it is most capable of doing so, before returning, thus stopping the IDE creating loads of connections. I've mostly developed a system like this at the moment, using Jini, mainly because I've never really 'got into' J2EE. Neon uses a message bus and router idea to allow activation of server side function and collaboration between agents, but this function is fairly fluid, in that it can move around the network as required.
    >
    > The concepts that vincent is talking about naturally begins to lead to using Grids for terminal client type work.
    >
    > Calum

    Think this is a little closer to how it might all work. I kinda like the idea of an IDE that can make use of services offered elsewhere on other machines. Trivial examples might be a distributed compilation ability or maybe a remote service to generate JavaDoc etc. So, a new "developer service" comes along and your IDE can then offer it to you. In this way, you don't need to upgrade your IDE - it'll gain functionality over time (and dynamically) as more services/modules become available.

    However, whilst this is potentially an interesting use of JINI and begins to demonstrate some of it's abilities, I think there are other areas which JINI/JavaSpaces fit better and can provide greater benefits.
  8. Now that I come to think about it, before I started writing Neon (i.e. my Jini Application Server), I was dabbling with framework but for clients called Callisto, which Neon's message routing was evolved from and subsequently backported into. Callisto allowed a small platform core, to contact a web server and download a number of server side jars specific for the user (or user's department/role), if they had been updated since the local copy (yes I know kinda like webstart) and bind them into the core framework at runtime, to provide a personalised rich client application. To extend this into using serviceUI for Jini wouldn't be that great a job, and indeed I might even dust off my JavaSpace VFS scribblings......... The combination of using a completely dynamic frontend with a fluid agent backbone seems pretty cool......


    Calum
  9. As far as dynamic services becoming available to the IDE goes, I really like the idea. Jini started off as a "plug and play" technology that claimed pain-free configuration of new devices/services that become available on the network. The promise of Jini, to my knowledge, never delivered. A strikingly similar technology called Rendezvous (Apple's name for ZeroConf), however, did deliver.

    Today, Rendezvous allows to be automatically discover:

    1) Machines that are available for a distributed compile (via XCode-Apple's IDE).
    2) Printers, scanners, and other networke-enabled hardware devices
    3) Intranet/LAN Websites
    4) Shareable music on the LAN

    I think using Rendezvous to build a network-based IDE service framework would be great! Rendezvous is gaining a lot of steam outside of Apple platform. There is an open source Rendezvous library available for Java.

    - Shoaib
  10. Opinion: Jini IDE. Is it the future?[ Go to top ]

    I haven't yet seen any development which will require a complex, weird solution like Jini IDE. if i develop someday a killer app like space engine with hundreds of agents working in parallel on different hosts then i might(?) need a Jini IDE but not yet. Jini is better for other things... I think Vincent Massol is kidding, or having fun with Jini users or challenging his brain to see how complicated he can make a simple thing or how to use misuse a technology like Jini.. please get real. we have more important issues to handle. Jini might be the future but not the Jini IDE. such crappy IDEa.

    -talip (a JavaSpaces freak).
  11. Opinion: Jini IDE. Is it the future?[ Go to top ]

    While I agree with Vincent in every way about Jini I'm not sure an IDE is the best way to kick off the WebServices take-over. Still it's a great idea and I'm sure we'll see something like it in the not too distant future.

    -John-
    C24
  12. Opinion: Jini IDE. Is it the future?[ Go to top ]

    The future seems to be "services". So I can see it at least being part of the future. Dealing with the usual proxy/firewall issues will induce some variation.

    I think (wish I could know) that all clients could be this way. Not just IDEs. (kinda like Eclipse isn't an IDE anymore but a foundation for Rich Clients).
  13. Performance[ Go to top ]

    Nice idea, but I think it will be horrible in practice. I scrapped JBuilder for its long startup time. All Java IDEs suffer from GC which is frustrating. I can only imagine what it would be like to wait for 10 Jini modules to load remotely at startup time. Gave up all IDEs for emacs, but found the features in IDEA worth the GC annoyance so I am using that now.

    Remote builds and distributed unit testing is definitely worth looking into anyway as separate Jini services. I guess using Jini for specific plugins can still be useful in an IDE not entirely based on Jini.

    /Håkan
  14. Bewitched[ Go to top ]

    While this Jini technology sounds great, I don't see any major benefits for an IDE per se. Lets face it, who cares what the IDE is made of, it could be made of cobol as long as it provides me with a nice visual environment that automates lots of the dull tasks I hate.

    The eclipse platform is moving towards a universal IDE with containers etc. This is the only reason to write the ide in a particular languages/framework. For ease of maintenance.

    Whils't this Jini ide sounds like it would be easy to install I am worried about deployment of code and version control.

    The world does not need another IDE at the moment. Especially one that is concerned with the underlying architecture. What the worlds need is to enance the development paradigms for us bog standard programmers so that I can declarativley generate 70% of my program. I see IDES like Sybase Integration Orchestrator, WebLogic Workshop and others moving this way.

    As a development techology Jini sounds great (although I know little about it). However to get people interested it might be better to pick an application that really needs this sort of lightweight distributed architecture. There's no inherant benefits to the end user of having a Jini IDE over for example Eclipse. However something like this for ewallets , now that would make a lot more sense. As a thought excercise though it is interesting.

    J
  15. Opinion: Jini IDE. Is it the future?[ Go to top ]

    This is realy funny, at the first reading I tought it is a joke. Then I relaised that the author was serious!

    Wow, distributed IDE! Arent entity EJBs enough?!
    People should realy read latest Martin Fawler's book and learn about distribution in software.

    MC
  16. Opinion: Jini IDE. Is it the future?[ Go to top ]

    Arent entity EJBs enough?


    I think you've lost the plot now or were you just joking?

    We can wrap the EJBs with Web Services access the Entrys [sic] with SOAP!

    Wait for Moore's law to catch up and it may be usable by 2050.

    -John-
  17. Opinion: Jini IDE. Is it the future?[ Go to top ]

    We can wrap the EJBs with Web Services access the Entrys [sic] with SOAP!

    >> Wait for Moore's law to catch up and it may be usable by 2050.

    John,
    maybe you are too optimistic, :), 2050 is too early for this!
  18. Sounds like a very interesting idea. May be we can finally have truly rich internet clients when this becomes feasible.
  19. Doh![ Go to top ]

    Will it work offline?
  20. Doh![ Go to top ]

    Will it work offline?


    No, of course not, JavaSpaces only work on remote machines so you will need one web server to run the lookup service, another to act as an interface and at least two other machines to actually run your objects from, that should be all.

    Only joking, I forgot to mention that all the machines need to be clustered.

    :-)

    -John-
  21. Parallel Development[ Go to top ]

    Any medium to large application involves a team working parallely on code. Java Spaces could be used in conjunction with a version control system and IDE to help in situations where two or more people are working on a single artifact.

    Since there are only a few operations in JS, like:

    read,
    read wait,
    write,
    take

    If user 1 is working on a Class A, his IDE could read-wait for others to listen to changes being made by others on class A. In this case, while user 1 is working on class A, he is able to see annotations on the side-bars in Eclipse or IDEA. When user 1 slides his mouse he is able to view the changes being made in class A in a non model window.

    The essential idea is that distributed data structures open up possibilities for two way communication like this enabling team work and avoid lost effort.

    For example, in an XP oriented environment two developers don't have to sit together, they could work together while sitting in their own cubicles.

    As far as non IDE solutions using Java Spaces are concerned, it could easily be used for load shared remote services without the complexities of J2EE.

    The possibilities of many such advances are there with JS.
  22. too confusing[ Go to top ]

    I have enough problem sitting there getting my own work done, let alone see someone else do theres through my desktop.

    Role based Async is the way to go for teamworking.

    J
  23. Opinion: Jini IDE. Is it the future?[ Go to top ]

    A solution to a problem that doesn't exist? Do we really need a distributed IDE? Well, I like to see some sort of elegant distributed pair programming IDE, but a distributed IDE with on the fly service downloading and such things is overcomplication imho.

    Ara.
  24. Shame on you!!!!!!!![ Go to top ]

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet.asp?frame=true

    "Microsoft® .NET Pet Shop is a series of application benchmarks comparing the performance and scalability of this .NET Web application to the performance of an equivalent, revised, and fully optimized J2EE™ application developed by the Middleware Company."

    Geez!!!! Shame on you!!! Equivalent?? revised?? fully optimized??? !!!!!!!!!!

    After selling your soul for some bucks you opened a .NET site. It's just business... (anyways, shame on you!) !!!!!!!!!!!!!!!
  25. ah?[ Go to top ]

    I can see how JINI will be useful to write business applications and servers. For example, spread the load across multiple machines to save the time, number crunching etc etc.

    But for an IDE? it beats me. Why an IDE needs to be distributed?
    Say,I like Eclipse but i am frustrated when it takes so much of time to load.
    And its annoying when i press a control stroke and the IDE is frozen for few seconds because of GC kicked in.

    And now, say a distributed Eclipse..., how long it will take time to load the modules/widgets/plugins which are distributed across the network? err, my IDE gone complex than my application. I spend more time for my IDE to start rather than just write my app, and go for a fag!!!

    dont know how others will see it, but this is my view anyway!
  26. ah?[ Go to top ]

    The best compromise is to provide a standard IDE (or any other client-type app) with the capability to hook in 'views' of distributed function and allow the delegation of certain functions of the IDE to the server.
    after all CVS or any other remote VCS is a distributed function allowed by many IDE's but rather than download having to find the plugin for your VCS, when you connect to it, the plugin is physically downloaded (at least the first time you connect anyways) and is hooked into your IDE and already preconfigured for that VCS system.

    This kind of things is alwasy good for administration and management purposes, and a complete end-to-end IDE, although a worthy goal, is unlikely to provide fantastic advantages, but for automatic hooking oif distributed components, it could be worth a look.


    Calum
  27. JXTA seems more interested to me[ Go to top ]

    I had created a very simple Java IDE to demo Jini technology back in 1999 or 2000. It was a really good demo for getting developers to understand Jini technology, but I learned some things in the process.

    Jini shines when the IDE is always connected to the network (duh), but a problem does arise when disconnected (which another thread touched on). Jini is great for dynamically adding functionality to an IDE but I find that many developers do both online and offline development. That means any of the dynamic functionality leveraged during on-network network development cannot be leveraged offline. Of course it is just a matter of coding a framework to deal with this but I am not sure this is a "natural" fit.

    When JXTA came out, I had thought of leveraging that technology for collaborative development by writing a netbeans module. The thought being you can get class libraries and javadocs off of peers instead of searching the web and downloading them. I also think that leveraging JXTA for version control would be an interesting concept (who else is modifiying the same file as I am right now???). JXTA, IMHO, is a more interesting and natural technology for enhancing the value of an IDE.

    Just my 2 cents worth.

    Sitting back, I think JXTA is a more natural fit
  28. Opinion: Jini IDE. Is it the future?[ Go to top ]

    One of thing not mentioned above is Jini's ServiceUI which makes it different from similar distributed technologies such as JXTA or JMX(Did anyone think of that?) sinco an IDE is basically a GUI applicaition, not a server-side one.

    Well, NetBeans have a very dynamic architecture that allows loading and unloading any plug-in at runtime, but I believe lot of us including myself turned to embrace Eclipse when it came out later. Why? As a programmer, the user of IDE is very sensitive to what funcitons an IDE can provide to make him/her program happily rather than what technology it is based on. Anyway, IMO, Jini may help today's IDEs more collaborative over the net.
  29. Jini is the future, and always wil be?[ Go to top ]

    One of the problems with Jini is that no one outside of a group of hardcore enthusiasts is able to understand the value of the technology. The Jini community has failed to communicate that understanding to a wider audience. J2EE and Web Services have become better technologies than Jini, because they have become healthy and properous markets. I do not see many Jini proponents behaving as champions of the technology in a manner that can make the technology successful to the wider software community, not just between the Jini elite. It is this behavior that would lead to certain failure for Jini, if it continues.