New Article: J2EE Platform Independence, Have We Regressed?

Discussions

News: New Article: J2EE Platform Independence, Have We Regressed?

  1. In this article, Robert Simmons takes us through the evolution of Java's promise of cross platform, vendor independent solutions. Simmons proclaims a recent regression back to the old platform war days among EJB platforms and a regression in programmer thinking. Has the dream really turned into a nightmare?

    Read J2EE Platform Independence, Have We Regressed?

    Threaded Messages (52)

  2. There are some interesting points. The dream of cross platform is definately not there yet.

    I do think that some IDE's DO allow you to work with different vendors. For example, I have used JBuilder on WebLogic projects just fine. Together supports a lot of the big guys too. A large problem is when a new app server version comes out, it takes awhile for the tools to catch up. Since new app servers come out so frequently it is hard for the tools to keep to pace. Maybe as we are in a maturing technology, this pace will slow down, allowing for better support.

  3. Hello,
        This article is good feedback for the people managing development of the IDEs. I agree with the essence of the article given the perspective. I also appreciate the vendor neutrality.
        From a business point of view, the picture does not look as gloom as the article points out. I have witnessed two different large applications that have migrated from one AppServer vendor to another. The cost and time was an drastically less than in previous generation applications. While there definitely is a cost in learning the new systems, which do have proprietary tools and administration settings, the advantages of this new paradigm are still vast. Imagine migrating from a Java to .net to get a comparison with what used to be and what exists today.
                    GS
  4. Robert,

    Frankly, I'm surprised that it surprises you. I think the answer to your question is very simple: companies are here to make money. If a customer can reach the same objective using a cheap solution or an expensive one, which one do you think the companies are going to promote ? For them, J2EE is just one mean to make money. For you, it seems to be a philosophy hence your deception. But this is not only a valid argument for J2EE, it is also applicable for cars, food, tooth paste, in short, to anything that is for sale.

    The argument is always the same whichever the product may be: minimize the risk associated with the technology. Some customers associate risk minimisation with IDEs and integrated solutions. That is one solution. The overall costs are not so huge compared with the development and maintenance costs and consumer feels reassured.

    On the developer's side, laziness is the reason why so much effort is being put into frameworks aimed at enhancing reusability. People do not want to code the same things again and again. And people hate to spend time developing GUIs. When I write a servlet, I don't want to mind too much about HTTP. I want to use documented and tested black boxes. Because I'm lazy. And I'm not surprised if other developers are.

    Don't you thing it's a bit up to the buyer too to be clever enough to gather as much information as possible in order to detect that a salesman is trying to sell tools that are unneeded ?

                    Yann
  5. I totally agree with Yann about the company that just want their profits. If we would all focus on the things we excell in and would not compete, but just use other companies products and solutions, we would end up in a situation were everybody wouldn't be earning anything anymore. Competition is what drives the industry going (look at the theories about basic economy, you'll see).

    Furthermore, I don't really agree with Robert about the fact that one would not be able to develop a solution for a certain application server without the IDE that the vendor promotes. Using a decent build and test process implemented with tools like Ant, JUnit you can perfectly design, implement, test and release your products for multiple servers, using the IDE you like. Especially for component developers (as we are) this is something you really have to care about and my experiences have been that it's perfectly possible. It takes some time and thinking, but it's worth a shot and definitely something you need if you want to be a decent, quality-oriented and flexible software development organization.

    Besides all this, what's wrong with developing an application just for one application server? If it's a project a customer initiated, it would be fine with me. There's a big difference between organizations developing reusable software (those need to be vendor independent) and teams that develop tailor made software, on demand (for instance web applications).

    What Yann says about black boxes and laziness is partly correct in my opinion. Black boxes are perfect, but it should be well-designed, well-implemented, well-tested black boxes that have been thought over really long. Reusability is not something that just comes in one day. In my opinion reusable software cannot be developped without a decent, but basic IDE. Part of me says 'Use that JavaDOC, auto-completion: please NOOO', but since I use an IDE that has usage-tracking, refactoring support (ok, I'm using Idea) I think that's nice as well...

    The world isn't perfect, and if it would be, we would all be out of a job, take a look at the past, it's always been this way in the traditional branches, it's only a little new for the IT industry.

               Alef Arendsen
  6. This article strikes me as being more interested in sensationalism than real hard facts. I can totally understand that an article titled "J2EE made us regress" sounds more enticing than "J2EE is doing good", but come on...

    <quote>
    Currently, if you take a look at the market, you will see BEA with Visual Cafe, ...
    </quote>

    Robert asserts that all the major players are shipping with IDE's that lock developers in. Of the four examples that come up to my mind (three of which are cited in the article), only one really is accurate:

    - BEA with VisualCafe
    - IBM with VisualAge
    - Borland with JBuilder
    - Oracle with JDeveloper

    The only vendor pursuing both the appserver + IDE route is IBM. For the rest, everybody uses a mix and match of appserver with various build environments. And I have see those: WebLogic developers using VisualAge and/or JBuilder, etc... (dunno of everyone using JDeveloper, though ;-))

    <quote>
    "if you would only use our IDE" is frankly disturbing
    </quote>

    Welcome to capitalism.

    <quote>
    We are being pushed out of our independent development tools and funnelled down cattle shoots
    </quote>

    Sensationalism again. Here is a hint: if a vendor offers a solution that doesn't match the customers' needs, they won't be picked. End of story.

    <quote>
    all of us console, vi and emacs 'freaks' are left out in the cold.
    </quote>

    Uh? My perception is that most of the development in appserver market, on both sides of the fence (including here, at WebLogic) is made using emacs and shells, not IDE's. I certainly don't feel left in the cold.

    <quote>
    It's actually a historical irony that no one has, as of yet, come up with an editor better for programmers than emacs or vi.
    </quote>

    Oh please.

    <quote>
    the vi and emacs camps are being driven out into the cold.
    </quote>

    Again? I think Robert should move to California, it's nice and warm here.

    [About code generated by wizards]
    <quote>
    The LSD argument seems to be winning with PCP running a close second.
    </quote>

    Everybody who has used GUI builders for a production application knows the limits of such tools. They are great for prototyping but usually fall short when you need to share code, because you need to understand what's going on under the covers, being able to resolve conflicts and understand diff as you check in new code, use object-oriented techniques to reuse your graphic components, etc...

    Robert seems to see everything in black and white. GUI builders are neither good nor evil, they are tools that you need to use with an open mind and an awareness of their limits.

    <quote>
    There is a Borland camp and an IBM camp and a BEA one. We seem to have forgotten that the whole dream was about integrating multiple platforms
    </quote>

    I don't get it. First, Robert bashes Microsoft for their software and their monopoly, and now he complains that there are several camps. Which one is it?

    <quote>
    We choose the best IDE and the best UML tool and the best language and roll them into a smoothly functioning development environment attuned to our needs
    </quote>

    This is *exactly* what is happening. I have seen and talked to dozens of customers, and they are doing exactly that: mixing and matching. Environments, operating systems, application servers, virtual machines, hardware, tools, you name it. They are not dumb.

    Overall, the article seems very condescending and elitist to me. Robert criticizes developers and customers altogether and complains about the current state of the industry which, in my perception, is not anywhere near what he depicts.

    --
    Cedric









  7. I agree with Cedric,

    my team on my current projects are definitely mixing and matching. We've got various people using JBuilder 6, Intellij, Forte, VI, rational enterprise development suite, and we're testing and running on 3 or 4 different app servers.

    It all seems pretty simple to me.

    -Newt
  8. oh yeah, and we're using different JVM's and OS's in some cases as well.

    We haven't had any problems yet (knock on wood, man I'm getting superstitious).

  9. Yep, I've got to agree with Cedric as well.

    Why does it matter if one IDE matches up with a particular application server better than another? When did it become so difficult to build/deploy to an application server anyways?

    We do builds for multiple versions of WebLogic using Ant without any interaction in the IDE (unless its within IDEA). Our teams use a large mix of tools for development including everything from JEdit to IDEA. I even think we have a few holdouts using an old version of Kawa.

    We develop on Windows 2000 boxes, then integrate, QA and deploy on Solaris boxes.

    I don't see the vendors of IDEs and application servers having any real power to lock us in to their tools.

    Now, if you want to see vendor lock-in and abuse, I think the writer should talk more about Oracle's recent licensing changes (I suppose Larry needs another 500 ft yacht).
  10. Even IBM plays fairer these days.
    I can use many tools to deploy to WebFear (Together, JBuilder, etc).

    They even give us the great Eclipse! :)
  11. I find it funny that Robert writes this article when he has blasted people in the past for being so dense as to not use Together. So he is pissed that IDEs cost $3K but he is absolutely fine with Together costing $10K? Sounds kind of hypocritical to me.

    Call me crazy, but I like JBuilder Personal or IntelliJ IDEA for development and MagicDraw for UML. When combined with tools like EJBGen (thanks Cedric), XDoclet, and Ant I can be just as productive at 5% of the cost.
  12. Of the 20 odd J2EE/EJB projects I'm aware of in 4 different banks I would put money on the fact that about 30-40% use Emacs. Emacs with ANT, the odd println and you've still got a development environment that even the likes of IDEA and Together can't touch for efficiency. True there is an increasing amount of ex-VB programmers converting to Java and not managing without their IDEs but I don?t really include these as ?real? quiche eating Java programmers, they are wizard users or prototypers, not programmers.

    I?ve tried most IDEs, non of them got more than an hour or two?s attention until I got onto IDEA. I still found myself slipping back to Emacs though. There are still many features I have in Emacs that I just can?t seem to do without when using IDEA and if IDEA doesn?t have it you can rest assured the other IDEs won?t. Emacs was J2SE 1.4 compliant the day the first beta version came out, IDEA still doesn?t support it nor does WSAD, JBuilder or any of the others I know.

    I use Together for modelling; it?s a really superb tool that I fortunately have a license for. If I didn?t I certainly couldn?t afford one personally so I?d no doubt be using one of the other well know 0-$200 ones. Together doesn?t restrict me at all for the App Server, it deploys to JBoss, WebLogic, WebSphere and several others. Both JBuilder and WSAD also deploy to more then the obvious ones so where are the restrictions?

    We?ve had Borland in, we?ve already got all the IBM products paid for, we?ve seen TogetherSoft and BEA. They all obviously try to sell us their own tools; they?d be pretty strange if they didn?t. If you write to the J2EE spec then you can port from App Server to App Server with few problems (we?ve done it several times with several large banking applications). If you use something like ANT you can use pretty much any editor or ANT compliant IDE you like (JBuilder is not one of these although they promise it soon).

    The only way I can see lock-in is if you?re too damned stupid to believe the sales man, perhaps Mr. Simmons still thinks Salesmen tell the truth? My train is firmly on the track.
  13. I have created a poll to see what how people on the server-side view java and J2EE, please try this link:

    Go to the poll

    to place your vote.

    Send suggestions on other questions to me.
  14. "There are still many features I have in Emacs that I just can?t seem to do without when using IDEA"

    Could you give me any examples? I can think of several
    things that IDEA does (apart from refactoring), that vi/emacs doesn't (I may be wrong on this, since it has
    been several years I last used emacs):
    * Find all usages of a specific method.
    * Show a quick Javadoc popup for a method or class (Ctrl+Q).
    * Detect all checked exceptions thrown in a block of code
      and wrap the block in the appropriate try { ... } catch
      (E1) ... catch (E2) ... statement.
    * Optimize import statements (eliminating uneeded ones, for
      example).
    * Show tooltips with variable values during debugging.

    "Emacs was J2SE 1.4 compliant the day the first beta version came out, IDEA still doesn?t support it nor does WSAD, JBuilder or any of the others I know."

    Both IDEA and JBuilder allow you to use any version of the
    JDK to develop your code. I am currently using IDEA 2.5 in
    a project that targets JDK 1.4.0. What you cannot do with
    the current versions of these IDEs is to run them on JDK 1.4, because of incompatibilities. But this is completely
    different from the project's JDK.


  15. <rant>
    Part of the reason why some Emacs/Vi fanatics stick to their old tools is some peverse pride that they do things the "hard" way - therefore they are "hard" developers - masters of their craft - still using the old-school tools of the trade... none of this namby-pamby making-things-easier malarky.
    Other reasons are perhaps laziness or a reluctance to learn a new tool.
    More annoying, is that some really enjoy writing those little add-ons to personalise their version of Emacs so that it can automate some 5min task in 30 seconds (forget the fact that it took them 2 hours to find it on the net, and yet another hour to get it working). Some of these old-school tools are real time wasters in the wrong hands - I know - I have had to work with a couple of these (which sadly make up 40% of the emacs users I know).
    </rant>

    The other *valid* reasons why these simple tools are popular are because:
    a) They dont take 60 seconds to start up
    b) They dont consume over 150Meg of RAM
    c) They are not as slow as cold molasses
    d) They dont cost a months wage
    e) They are simple - and dont require a 16-week training course.

    However, to say that IDE's are for VB programmers is a bit of an inductive leap.

    In summary:

    An IDE != wizard generated code.
    ====
    While it is true that a LOT of IDE's boast huge wizard feature lists - it is not necessary that they be used. Sometimes, these evil wizards are useful for quick slap-up prototyping or the learning developer.
    Some IDE's, like IntelliJ, dont have any wizards - they are just really useful.

    System.out.println != debugger
    ====
    It really bothers me when developers waste time *guessing* where a problem might be and pepper the code with println's to flush it out. You often see them, motionless with concentration, executing the code in their head...
    Rather than guess, why not step through the code in a debugger - its much quicker.
    The reason is usually laziness - "its quicker for me to do a couple of pintlns and re-deploy than set up the debugger" is the usual excuse.
    It takes about 15 minutes at most to set up your debugger for the first time, so that it can debug locally or connect remotely - and once you have done it once, it will take about 20 seconds thereafter.
    Also, dont forget the amount of company time again wasted repeatedly *removing* this debugging output from the code (where it usually manages to survive several check-ins and invariably some makes its way into a production system).
    This is further evidence that a debugger is a good investment.

    ---

    IDE's, in general, should make your life easier and adapt to the way you work. Some dont, and force you to work according to their notion of development. Simply dont buy these tools.

    Support for refactoring, *smart* code generation, integrated JavaDoc viewing, code hints and code navigation like that found in IDEA, well and truly beats a text editor for productivity:price ratio. In fact, of all the IDE's, this is the only one that I have seen attract the interest of the emacs devotee (100% success rate so far...).

    A lot of the tools are now following IDEA's direction and are paying careful attention to what the developer really wants. Here, contrary to the opinion of the author of the original article, there is evidence that there is competition at work.


  16. Personally I think editors are for the chemise's of girls with alternative body image. I prefer to burn my code direct to HD with a magnetic beam (based on my pencil and paper binary design of course).

    Seriously though I think the original article had a point more about diversity of choice than anything, until it went off into tangential 'rant' land (all the more surprising given Roberts's profound declarations of love for the vastly expensive Together tool in recent postings on this site).

    Its a matter of choice what you use but childish in the extreme to denigrate the ability of others based on their editor/IDE. At the end of the day is the architect/developer who signs off on the code and thats where the responsibility rests. I agree with Yann, Cedric and Nick (nice rant, brought back memories :)) that a decent IDE/editor has its place in this commercially driven arena.

    Most vendors want to own the entire customer experience now, hence the recent rush to vertical integration of development tools with app servers. Its not necessarily a bad thing, just financial reality for the vendors that theres a possibility of increasing revenue stream if they can provide one stop shopping for an organisation. Some are good, some bad and some just crap, its a matter of experience/opinion. I think most of us in the enterprise arena are mature enough to decide for ourselves.

    On of the central tenets of the JAVA paradigm is choice, choice of strategy, choice of tool, choice of vendor. This will always lead to diversification, how you get there is up to you.
  17. <quote>
    It really bothers me when developers waste time *guessing* where a problem might be and pepper the code with println's to flush it out. You often see them, motionless with concentration, executing the code in their head...
    </quote>

    Well, I'm often one of these guys, "executing the code in my head...". Quite often, in server/distributed environments, conventional debugger is no help at all vs code instrumentation. I'm not trying to say that debuggers are useless, but in some cases they are simply not applicable.

    <quote>
    Also, dont forget the amount of company time again wasted repeatedly *removing* this debugging output from the code (where it usually manages to survive several check-ins and invariably some makes its way into a production system).
    </quote>

    That's what log4j or 1.4 logging API's are for. System.out.println is not the right way to instrument your code.

    --
    Dimitri
  18. I thought the article was somewhat interesting but I think it over-values the impact of IDEs on the decision processes the IT organizations make. The production side of most organizations are considered cost centers. Sometimes developers get lucky and are bundled in with a revenue line and excape being a pure cost center. Since the selection of products have to meet operational requirements as well as developer requirements, developer voices can be dilutedby two other factors:

    (1) minimize procurement costs (# of vendors)
    (2) minimize operational / support costs (products and people)

    I think there is promise in some of the standardization in the 2.0 specification that may make operational transitions more cost effective. But, I believe there will alway be a training incentive (both perceived and real) to stay with one product. Considering IT shops never have just one project going on, companies will not change anything without a strong reason.

    Every time a shop decides to change, there are training, deployment, migration, and internal support issues that have to be resolved. There is a population that believes that vendor relationships are key to project success and relationships are the hardest to estabilish and maintain. Current technology really doesn't have very good answers for these problems. The problems go away the easiest when people are removed from the equation. Hence, crappy IDEs from primary vendors for untrained developers. (There are a lot of places that believe in the 100 monkeys are better than a well-trained small team. Then again, if this actually was properly addressed, there would be a lot of unemployed people in the software industry.)

    The issues above insure that single vendor solutions will get some share of the market because it increases the size of the initial sale, hopefully builds both dependancy and if the product is good loyalty to the vendor. Best of breed solutions are used when there is a productivity or control advantage for the organization or the development groups skill level is high-enough to evaluate, select and use alternative solutions.

    I personally like hybrids ability to move the industry but there are a lot of cases this is beyond the risk profile of of a company.

  19. While this article does have some good points, it comes off as just a hacker who all of a sudden has to vent his frustration with everything. As far as his statement, "We are being pushed out of our independent development tools and funnelled down cattle shoots" is concerned, please - have you been living under a rock all this time. Go get free JBoss for your app server and there are any number of open source IDEs with which you can integrate JBoss with.
  20. I feel that the author is right. Provided I use Ant tasks, XDoclets, I can to a great extent build portable components. Lately I had the misfortune of of integrating Weblogic 5.1 ejb components with Tomcat 4.1. For reasons I wont go into, I ended up using Websphere Application Developer Studio 4.2 to do my Struts based Client layer and JBuilder to build my EJB layer. It does work but it took me a while to get the development setup stable.

    Ideally, I wish the IDEs would just support the J2EE reference implementation. With plugins to support the various vendor extensions on top of it that a developer could slap on. The one extension tht I really like are OR mapping tools for Entity beans. I have been using VisualAge Persistence Builder tool, unfortunately, I have not quite figured out how to make the runtime libraries work with Websphere.

    The point I am trying to make is that to a great extent, the ejb jars I produce with Vajava, or WSSAD or JBuilder (sorry not much experience with webgain) is reasonably portable across app servers. Its mainly when I use OR mapping tools for my entity layer that portability becomes an issue and IDE seem to lock my implementation into a sereve implementation. However this I think is to be expected as the actuall OR mapping is not really specified by the EJB spec. The deeper question is would JDO as the key adapter layer between my component and persistence layer solve this issue? Looking at the spec, it might be the solution..

    just my 2.5 eurocent
    Suhail
  21. I agree with the author. VB programmer are usually ex teacher or english major who need more money to make end meet :). I doubt most VB programmer understand the underlining technology well.

    If you want a great and simple IDE, try visual slick edit. It supports vi and emacs emulation.
  22. I still have to see an IDE that does the job as simply and elegantly as Emacs.
  23. <quote>
    I still have to see an IDE that does the job as simply and elegantly as Emacs.
    </quote>

    Easy, but first, you need to open your eyes.

    --
    Cedric

  24. To all the vi & emacs heads, why use <quote> when we got "?
  25. Anybody notice that a 'GUI text-editor' is an oxymoron, in the sense that you are using a <b>Graphical</b> UI on <b>text</b>, so that editing is not graphical at all?

    I use a 21 inch monitor, and yet can see less text on a screen today (using a GUI editor) than I did in a 15 inch monitor using Microsoft's text-mode Programmer's WorkBench 10 years ago.

    None of the editors I use nowadays are any quicker or anywhere near as ergonomically efficient as PWB 10 years ago (that includes Visual SlickEdit, which is the only one that gets even close).

    (I mention PWB because it was what I happened to be using as an OS/2 developer at the time, it might equally be any other text-mode editor)

    I wouldn't mind if:

    a) These GUI editors supported <b>any</b> enhanced graphical functionality (such as the ability to overlay handdrawn diagrams next to the code, or the like). But they don't. It's just still text!

    b) The old text editors for Windows (like PWB and Brief) were still around. Borland bought Brief and alledgedly broke the code-base permanently while trying to upgrade it. MS 'upgraded' PWB to VisualStudio, loosing huge chunks of ergonomic efficiency.

    Sorry for the rant, but sometimes I get really fed up with being forced to accept 'progress' that is really a retrograde step.

    More on-topic, I feel that plug-ins for Forte and Eclipse will help match some of the vendor-specific IDE features, and judicious use of the likes of Ant can make a big difference.

    /david
  26. <quote>
    I use a 21 inch monitor, and yet can see less text on a screen today (using a GUI editor) than I did in a 15 inch monitor using Microsoft's text-mode Programmer's WorkBench 10 years ago.
    </quote>

    Use a better software, one that lets you change the font size.

    --
    Cedric
  27. Use a better software, one that lets you change the font size.


    Better than Forte, Eclipse, VisualAge, VisualCafe, or Visual SlickEdit? Go on, I'm game...

    Actually, I bought SlickEdit (with my own money) because all of the IDEs sucked so badly.

    a) As I'm sure you well know, the text mode fonts (because there was no choice) were designed for clarity and legibility. Most of the fonts on my system (and I'm sure yours) are designed to be pretty, rather than legible.

    b) The point I was making was that GUI editors habitually steal large chunks of screen 'real-estate'. As I speak, Forte loses 8 lines to title area, and 13 or so lines to file lists and status bars, leaving me with a 44 line editing area. I had (IIRC) 56 lines to play with PWB.

    c) My main drive was ergonomics. In most editing you are swapping between 2 or 3 files during any chunk of programming. PWB had an MRU list, so Alt-1 through Alt-6 always swapped to the six most recently viewed buffers.

    Nowadays (thanks to the wonders of graphics), I have to
    1 - find my mouse (no useable keyboard shortcut)
    2 - remember what that other file was called
    3 - find it in all of those buffer tabs in front of me
    4 - click the tab
    5 - Try to remember what the change was that I was intending to make before I started poking around with the dratted IDE.

    /david

    PS If you were accusing me of overstating my case, note that my point is that ergonomics and usability have apparently taken a very low priority over the last few years. I contend that the 'standards' for working with files (MDI and other L&F initiatives) have precious little relevance to the requirements on a programmer.
  28. I've use Visual SlickEdit since version 1.0 which was only for Windows NT 3.1. I've since used it on several Unixes as well - it works identically, and I can bring my preferences with me.

    I just fired it up on my 21" monitor. I get 60 lines vertically and 95 columns horizontally - far more than I got when I used PWB (under OS/2 also :), unless I wanted to run in 132 column mode (which I didn't). I was unwilling to switch to a GUI editor until VSE, at which time I was forced to because it was the only editor for NT which supported long file names and had a reasonable feature set (since text-mode SlickEdit had been out for a while).

    I have my personal install of it burned on a CD so I can take it to the client sites at which I work. I pretty much can't live without it. :(

    Of all the things I've seen people post in this thread about features of IDEs & other editors, the only thing I've seen mentioned that VSE doesn't do is auto-create the try/catch blocks based on detecting throws declarations of called methods - that's pretty cool. Oh, and debugging... ;)

    Donnie
  29. Donnie,

    I usually don't get into these posts, but that is one of the most ridiculous posts I've seen in a long time (and closed-minded). You seem to be implying that people who use IDE's aren't worthy. I know lots of people of whom I'd say "I'm not worthy," who use IDE's.

    On of my closest friends made full academic faculty at a major west cost university by age 25, and he's a senior system architect for distributed object architectures at one of the top engineering R&D firms, also on the west coast. He regularly uses JBuilder. Have you done anything like that?

    How absurd. I wouldn't hire a guy like you on my team simply because you're one of those people who obviously believes that your way is the only way to do something right. Choosing the right tool for the job usually delivers better results than choosing the wrong tool, even if the person is the best in the world at using the wrong tool.
  30. I do not think there is one and only one right way of developing systems. IDE:s have their own place while Emacs/VI has their own. For example i do not think that installing a IDE on the test/production system is a good idea...

    I think that it all comes down to what the developers individual needs / skills / mindset are. The most important thing in my opinion is to be open minded and objective. The over all goal is to produce a working system as efficiently as possible, and to do this you shold not try to hinder the developers by imposing artificial constraints in the form of a mandatory IDE that the developer does not want to use. The degree of control executed needs to be balanced in order to allow developers to be productive and happy while the organisational interoperability is maintained.

    Also the policy in the organisation affect the mindsets, and they may even contradict the over all goal. Often the price of a tool is considered by management as expensive, while the time (and hence money) that possibly could be saved by using a tool is usually not considered at all. On the other hand new tools tend to end up as shelfeware.

    Getting IDE:s working out of the box with application servers is not always trivial. I think it is essential to have one or more developers act as "local support" or "trouble shooters" that can help set up the development environment and tools. Standardisation and support for "defacto standard tools" like Ant helps in the long run for sure, but i doubt the world will ever be perfect...

    There has by the way been some efforts to enable emacs/vi in IDE:s. At least NetBeans has a module that lets you plug in among others XEmacs as an editor, but i have not had the time to try it out. More info is available at http://externaleditor.netbeans.org/

    Regards, A. Aspnäs...
  31. Don't agree with this article.

    The IBM v BEA war had been extremely useful for developers. The app servers are now 100% better than even a year ago in stability, performance etc. Having competition between camps is a good things. I do try to avoid certain vendor lock ins that they offer as enhancements.

    In reference to IDE's, my general complaint is most vendors tools are behind their appservers capability. Current version of Visual Cafe does not support ejb2.0. Two years ago I asked some BEA developers how they cope with their tools constantly being behind. They replied Emacs and println.

    I personally use the combination of JBuilder and Weblogic (with JUnit and Ant) and it seems to work well for me. I started to use Visual Cafe and I hated it. A friend of mine in Atlanta uses Oracle JDeveloper to work with BEA and has no issues. Net Beans and Eclipse are also gaining ground to provide a more open developer framework.

      





  32. PS.

    CORBA is far to complex for most things and its integration with EJB is far from easy.
  33. I think the one of the article's premises is that IDEs are "required" and "a good thing" but that they shouldn't be bound to a particular app server / platform.
    <p>
    I question that premise. While on my most recent project, everyone used JBuilder except for me. I stuck w/ my Visual SlickEdit and ant-based build scripts. I used JBuilder solely for debugging. Just the responsiveness alone of a non-Java-based UI was worth the productivity benefits, let alone that of using a real programmer's editor.
    <p>
    I recall having other developers in my cubicle watching me do something in Visual SlickEdit and being amazed at what I could do with it - stuff I completely took for granted and essentially didn't even think about.
    <p>
    Another benefit to avoiding the IDEs is that it forces you to have a significantly better understanding of the technologies you're using. The wizards and stuff are great right up until what they product doesn't work. Then you have to dive in and figure out why not. Also, the wizards frequently make it very easy to get functional code with which is very poorly designed.
    <p>
    Ant and a good programmer's editor are all that's needed - trust me... :)
  34. <quote>
    Another benefit to avoiding the IDEs is that it forces you to have a significantly better understanding of the technologies you're using.
    </quote>

    Yes and no. I think you are referring to a very small subset of an IDE: wizards and code generation. I agree that one needs to be careful about using those, but for all the rest, trust me, a lot of very good developers use IDE's, and they are extremely productive with them. Much more than "old school tools" offer you.

    <quote>
    Ant and a good programmer's editor are all that's needed - trust me... :)
    </quote>

    Smiley notwithstanding, IDE's do bring a lot of features that developers should not thumb their nose at. I always get a little aggressive when I hear someone say "Who needs debuggers? We have println". I would certainly not hire someone with such a mindset.

    The first generation of IDE's brought with them debugging and type system assistance. The current crop of IDE's (which started with IDEA and now Eclipse) brings along a wealth of features, such as refactoring, and more generally, making it easy for developers to make "sweeping changes" (such as renaming a public method). The alternative with emacs/ant/vi/whatever just doesn't cut it.

    --
    Cedric

  35. Agreed. One of the "great leaps forward" with IDEs is that they are getting closer to the code - to the point where they actually understand it. Refactoring in most of the IDEs isn't just search/replace in the text - which is the only way to do it with vi (I guess you could write something in LISP that would understand Java bytecode, but I doubt it would be worth it).
    Regards,
    Vlad
  36. All the stuff that you're pointing out about IDEs, Visual SlickEdit does. I can hit Ctrl-Space just about anywhere and it auto-completes and/or pops up a list of variables of the correct type, methods, etc. I can navigate through my classes just like with an IDE, but about 10^6 times faster.

    I've yet to meet a developer that causes me to say, "I'm not worthy!" that uses an IDE. One man's opinion...

    Donnie
  37. I couldn't agree more. Myself a VI(M) freak as he calls it I find it amazing that many are willing to let the "IDE" generate everything and then when it comes time to really deal with cross platform issues like moving something generated by one IDE into someone else's AppServer they come right back to us VI/EMACS freaks to tell us what is really happening behind the covers.
    Most wouldn't know that deep down all the hype about JSP Servlets is really developed from CGI.
  38. <quote>
    I find it amazing that many are willing to let the "IDE"
    generate everything and then when it comes time to really deal with cross platform issues like moving something generated by one IDE into someone else's AppServer they come right back to us VI/EMACS freaks to tell us what is really happening behind the covers.
    </quote>

    IDEs do geenrate generic standard archives. If both the app servers (the original and the 'someone elses') are J2EE compliant, then there wouldnt be much of a problem deployingthsi archive on the latter (the probability of this happening is higher if the same archive was tested on atleast 2 servers).

    Now if one really has to see what is happening under the covers, all you need isd an editor. All IDEs do have editors

    Cheers,
    Ramesh
    - Pramati
  39. Hi,

    I agree that it is necessary for developers to understand what is going on underneath the covers but I don't believe this is a reason just to use vi/emacs. IDEs do provide needed debugging capabilities and some help with deployment (I generally use ANT for deployment).

    David
  40. "no one has, as of yet, come up with an editor better for programmers than emacs or vi"

    This is simply untrue. This comment puts the author's views in perspective for me. Fine, if you like emacs and vi, use them. But, I think you're nuts. Nothing comes close to IDEA.
  41. <quote>
        I think you're nuts.
    </quote>

    We need something like this to settle this issue. Next year at the Thirsty Bear ;-)

    --
    Dimitri
  42. As a former SilverStream employee - I tought this was a good article !
    And for those of you calling yourselfes lazy in this thread - I hope your bosses doesn't read this and that your salary is in line with your lazyness !
    Of course the capitalism and 'the market' will choose its way - but it doesn't stop us programmers from focusing in important issues like our quality of code , computing ethics etc.

    </knut erik>
  43. Knut,

    "And for those of you calling yourselfes lazy in this thread - I hope your bosses doesn't read this and that your salary is in line with your lazyness !"

    Is this for me ? Don't worry. My bosses read this and they know what I mean. By the way, my salary is not in line with my skills, so boss, if you read this... :))

    Knut, read between the lines, you got me wrong. When I'm given a task to complete, I don't want to spend energy reinventing the wheel so if a tool allows me to do it easily, I'll use the tool. If no such tool exists, then I'll be happy to invent the wheel. That's how lazy I am. But I am not lazy in the sense that I don't want to do the job and prefer a nap instead. On the contrary... I use TextPad for most of my Java coding but I just can't imagine writing a CMP 2.0 entity bean deployment descriptor with it. I'd much prefer JBuilder or TopLink Workbench to do it for me.

                    Yann
  44. Yann
    I didn't got you wrong :-) - as regarding to lazyness - instead of a nap - you can learn something else :-)

    Well - as regarding to writing CMP deployment descriptors with textpad - I understand your argumentation - but I'm really not sure if all those wizards which is now available really help us write better code. I would really like to read some research in this area. As for my self - I'm also used to wizards (since I was an silverstream empoloyee) but I'm really not sure if those are helping me or making me "dumb".
    As for my deployment descriptors - I'm writing them in a text editor - a wizard or a gui upon those doesn't help me understand what I'm doing. I preferr to read some lines in a book and understand what the heck I'm doing. And in the total timeframe this doesn't take more time than having GUI upon it. Well - that's me.
    My point is - Let every developer choos whatever tool he/she want to use as long as they understand what they do and the code they produce is of good 'quality' (whatever that is) and thet they are effective in their work.
    I'm grown up with VisualBasic v1 -> PB etc, but the more years I'm in this industry the more I'm sure that we have to learn from the old timers back in the 60-70's which didn't have all the fancy stuff we have today... well - enough from me.

    </knut erik>
  45. I think that what's really the issue is an amount of control you get. An inexperienced programmer doesn't want control (as he would not know what to do with it), while an experienced one does.
    I do not enjoy copy/pasting my ejb interfaces around - I would much prefer something that would keep them in sync automatically.
    Neither would I want to go and do build/try/fix approach with vi and building an UI interface, where you have to get your real estate just right - and if someone tells me they can do it better in vi than I in JBuilder, I won't believe them until I see it.
    On the other hand, having something generate all the code for me (all those stub/skeleton ejbc compilers for example), isn't something I like either, as I loose the control over the generated code - especially if something goes wrong (i.e. if the wizard doesn't handle something very well).
    So, as long as the IDE gives me an option to take full control myself, all's well :).
    (EMACS is a prime example of that, giving you a language to do all that you want, Eclipse having a bit more conservative approach).
    And as for what I use? JBuilder, IDEA, vi, notepad, emacs - whatever's around and can do the job.
    Regards,
    Vlad
  46. "On the other hand, having something generate all the code for me (all those stub/skeleton ejbc compilers for example), isn't something I like either, as I loose the control over the generated code"

    Stubs, proxies, skeleton code is often product/implementation sensitive. You're pretty much stuck with it. And that's a good thing.
  47. You're right about product sensitivity and generation being a good thing there. With one caveat - if it works properly, which they sometimes don't.
    An example:
    a stub generator for the product we were using had/has following problems (to name few)
     - incorrect exception handling
        - exception class compared on the name strings (because of classloaders) so in this place it could not deal with inheritance.
     - could not deal with constants on interfaces (trying to find a bean method for <clinit>)
    and some other minor ones.
    So instead of tweaking the generated code to handle things properly, we had to modify our code - and that's what I don't like.
  48. I personally think that although many IDEs automate certain targeted tasks very well, they still do a terrible job of tying all of these tasks together.

    I think the IDEs of the future will be much smarter at helping you actually *design* your software with the appropriate implementations. And notice I said help you, not do it all for you. An ideal tool would get input along the way, and after you are finished accepting its help/advice, it would be transparent enough to let you muck with the code. The transparency part is key.

    But it doesn't end there. The tool would then validate your changes in a passive way and point out inconsistencies, many of which it should be able to help you resolve. This is critically important for pattern-driven designs. Indeed, I think the driving force behind this new breed of smart tools will be patterns.

    I also think current and future tools should stick to open standards wherever possible. It is okay to generate, say, app server specific code/descriptors, but that shouldn't be at the expense of the standards they "extend." Product companies that do not do this will ultimately limit their pool of potential customers.

    Regards,
    Bill
  49. Bill,

    Take a look at my post on this thread. I agree with what you say and think this is the only way for tools to evolve. MDA is promising a lot in this area, although the driving factor is not patterns, per se, but an architectural modelling style = "designing" your IT architecture. A lot of what you've described is then catered for and is an explicit part of any tools or platform supporting/implementing MDA. ArcStyler is basically the only one which provides this level of functionality already, while many other tools are providing code visualisation or stub generation capabilities (which don't really help)... It also "ties the tasks together" in the sense that it supports complete fan-out of generated models. Things are moving fast in the direction you've described.

    Robert
  50. It's only natural that different vendors will build in different proprietary features which go beyond or around J2EE standards. How else can they differentiate and win customers from other "J2EE Vendors"? You won't, however, easily solve the problem at the code level... and I wouldn't recommend you do:

    MDA (www.omg.org/mda) already solves this problem, with the pleasant side effect that you get automatic evolution/migration as well as automatic refactoring and documentation of your system. By modelling and testing at higher levels (platform independent) of abstraction and then generating platform-dependent implementations of your architecture, you'll achieve the platform independence that you want. It makes migration and vendor changes so much easier as well.

    The most highly-recommended platform (Architectural IDE) for implementing MDA is ArcStyler - www.arcstyler.com. Platform (J2EE app. server) support is extremely comprehensive and it offers complete MDA support.

  51. <QUOTE>
    Some of them barely have the ability to find a matching brace and none of them have the power to do regular expression search and replace
    </QUOTE>

    What a crock. Sounds like this person has *only* used EMACS or VI and never bothered to seriously evaluate another editor. For example, humble TextPad supports both these features.

    I really wish people wouldn't write rubbish like this. They do themselves no favours at all.
  52. This is less of an article on the lack of portability offered by J2EE and more of a rant. This is one pissed off guy! Here are the major points:

    1. He's mad that major IDEs don't support regular expression search and replace. I do this outside the IDE (I use Netbeans) using Cygwin whenever I need to.

    2. He hates the today's GUI builders and is somehow convinced they are all written by ex-Microsoft MFC guys. ???

    3. Web developers can do a little without knowing a lot and are dangerous. I actually strongly agree with this point. They should be hunted down and destroyed.

    4. That there are camps. Dude, as long as there are businesses, they are going to try and sell their wares. That's capitalism.

    5. Why, oh, why can't the leading vendors stop trying to make money and just make our jobs easier? Hmmm. A naive question at best.

    What has any of that got to do with J2EE portability? Talk about straying from the subject!

    My company is enjoying a good amount of success (not as much as we'd like, of course :-)) in porting from one app server to another and actually make that part of our development process. It's not all doom and gloom!

    Based on the near-palpable venom I could feel coming from the last few paragraphs, I don't think the author takes criticism nearly as well as he likes regular expression searches. So, um, just kidding...
  53. Yes, Vendors are in the business to make money. However,
    I think they are pushing their proprietary solutions
    on many naive, or confused developers. Let's face it,
    J2EE can take a while to get a grip on what is standard
    and what is proprietary.

    I sincerely believe that the vendors are pushing themselves
    out of business with this tactic. I think that if the
    vendors were pushing J2EE development, and not proprietary
    quick results, lock-in solutions, we wouldn't be having this
    discussion. The amount of work required to port? to another
    J2EE certified App server can quickly make the move an
    unacceptable one, when there shouldn't be any port work
    involved other than using a different deployment tool.
    The perception to this tactic, is that J2EE is too complex
    to be implemented as portable, when it is all the vendor
    lock-in extensions that are confounding and confusing a
    much simpler architecture.

    I am referring to a vertical slice of the J2EE architecture,
    not a servlet mod 1 architecture.

    It seems many are confused that the J2EE strategy is that
    the vendors will provide value added (lock-in)extensions, when, in
    fact, the strategy is for vendors to compete by their
    implementation of the Standard J2EE APIs, in areas of performance and reliability.

    Now if I put on my vendor hat, their response would be;
    J2EE can't go out of business, we have too many customers
    locked in. Maybe, for old business, but kiss your new
    business goodbye. If people are being "led" into a
    proprietary architecture by J2EE vendors, they will soon
    realize that .net, at least doesn't lie about being
    proprietary.

    I would hate to see the immediate future go that way. Any
    future for that matter. A word to the wise to all the
    vendors;

    "stop speaking with forked tongue". Kick off new
    business with offers to help do standard, portable J2EE,
    and explain it at the same time.