BEA's Tod Nielsen on the Future of J2EE

Discussions

News: BEA's Tod Nielsen on the Future of J2EE

  1. BEA's Tod Nielsen on the Future of J2EE (45 messages)

    BEA Executive VP Tod Nielsen in a recent article discusses how Java rose to power, and his opinions that Java needs to become easier to use, the commercial vendor community should innovate faster, and that J2EE should evolve not from the current standardize first and implement later model, but to an innovate, implement and then standardize model.

    Read The future of J2EE.

    I thought it encouraging to hear an exec from a major vendor identify the "speed at which J2EE innovations are made available to customers" as a "roadblock". Faster innovation will certainly keep Enterprise Java at the forefront - particularly given all the innovations that are coming out in the next versions of .NET.

    Threaded Messages (45)

  2. <quote>
    In the same way the ease of VisualBasic unleashed Windows applications development, routine J2EE development tasks need to become less elite and more mainstream.
    </quote>

    I agree that we need ease of development in Java, but only at the client tier, so the analogy goes neck to neck with VB or now WebForms. But when it comes to middleware there is no silver bullet even in the MS world. Hope Mr. Tod knows better the intricacies of COM+; it is by no way easier than EJB.

    Besides that I think Java community got too much stuck with tons of patterns and framework, and that is what making Java/J2EE more and more complex and harder to grasp. I remember a saying from a Java Guru, long time ago, that the real forte of Java is not right once and run everywhere, but learn once and apply everywhere. But unfortunately Java departs from it long time ago.

    I am amazed that industry leaders in Java market are still not paying full attention when it comes to the presentation tier, and how drastically .NET approached it. I strongly believe JSP has to come a long way to compete with ASP.NET, and that's where they should pay more and more attention.
  3. I agree with Rashid, Java needs better UI tools for both Web and Swing/AWT/SWT. For middleware development Java tools are much better then .NET tools. For example, JBuilder and IDEA are far better then VS .NET in refactoring, code formating, template support, build process, code navigation...

    Nileta
  4. |
    |Java needs better UI tools for both Web and Swing/AWT/SWT
    |

    If you mean visual UI tools, then IMO this is not too easy to achieve.
    For example, how do you _visually_ represent something as basic as Swing's resize behaviour?
    Swing is a quite powerful UI framework - but its difficult to leverage its flexibility with any kind of visual tool.

    Otherwise, to simplify both simple and complex UI layout, check out JGoodies forms.


    -Nick
  5. I think that we need to straighten out which Java we're talking about, since Java on the server and Java on a client are different. VB was (C# is) great for just whacking together a client application, and as far as threads, pools, memory, transactions, etc. - no one cared because it didn't matter! Sometimes complexity is worth it, sometimes not.

    Neither Java nor Java tools should be a one-size-fits-all, although taking different sides in that fruitless argument will keep us all from writing code...
  6. eerie dejavu[ Go to top ]

    The Java world is "stuck with tons of patterns and framework"

    Exactly. Recommended light reading in the evenings as a replacement for Woodhouse.

    Nowhere in the world today does it exist a bigger discrepancy the between "the talk" (called "Javaspeak" in some circles) and actual user experience. An eerie dejavu - the same thing happened before in the Mainframe world! After listening to multiprocessor dispatching overhead, pararell sysples, pipeline lengths, pipeline invalidations, prefetch differences, branch prediction, microcode levels etc etc you took good look at the application and got a good laugh ;).

    And after listening to Agile Methodologies, Domain-Driven Development, MDA, Interceptors, Field Driven and Model Driven Actions, the Inversion of Control pattern. Organize inter-service transfers according to use cases from known domain objects into a coarse-grained Composite..you take a look at the application and get a good laugh.

    BTW, I have heard rumors that Cameron has read a book! Can it be true?! If there is hope for Cameron "dishonest" Purdy then maybe it can be hope even for Java.

    Regards
    Rolf Tollerud
    the component market for .NET is already vibrant..
  7. eerie dejavu[ Go to top ]

    experience. An eerie dejavu - the same thing happened before in the Mainframe world! After listening to multiprocessor dispatching overhead, pararell sysples, pipeline lengths, pipeline invalidations, prefetch differences, branch prediction, microcode levels etc etc you took good look at the application and got a good laugh ;).


    Yes, and yet the bulk of the worlds large - mission-critical - business systems still run on these systems. I guess the decision makes that counts like laughing, because I havent heard to many rumours of anyone replacing their mainframe systems with .net and sql server. Have you Rolf?

    > And after listening to Agile Methodologies, Domain-Driven Development, MDA, Interceptors, Field Driven and Model Driven Actions, the Inversion of Control pattern. Organize inter-service transfers according to use cases from known domain objects into a coarse-grained Composite..you take a look at the application and get a good laugh.

    Hmm, lets hope Java continue to attract the attention of the people who counts then, perhaps they will be laughing with Java systems in 20 years - just like they are laughing with their cobol systems today.

    > BTW, I have heard rumors that Cameron has read a book! Can it be true?! If there is hope for Cameron "dishonest" Purdy then maybe it can be hope even for Java.

    Really mature argumentation there, Rolf...
  8. eerie dejavu[ Go to top ]

    Hey Rolf you never answered my question in the other thread about "Microsoft-speak" either. Sure java-speak can be dense techo-jargon. After all it is designed to lock out hordes of VB-addled "programmers" from coming near a real enterprise-level system programming task. However it just doesn't come anywhere near matching Microsoft-speak which tends to just the latest top ten platitudes from an empowering-your-business seminar's powerpoint presenation. I've heard more cogent thoughts about software systems from graphic designers. And then of course you go and look in the source code and you don't laugh -- you cry. That's if you can obtain the source code in the first place.

    Patterns and frameworks may not be the most rivetting read you've ever done but it's good engineering practice! Just ask town planners and architects. Unlike in MS "engineering" where generally you've A pattern and A framework to learn - the one size fits all approach forced on you from the vendor of the tool.
  9. eerie dejavu[ Go to top ]

    Hey! Rolf is back!
  10. There already is a Java tool that does all this. Easy to use, lots of tool support, strong GUI metaphore and yet still powerful enough to build quality enterprise applications. And you don't have to read a "yard" of specifications. Most people can get their first basic application up and running in a few days. This is open source SOFIA (http://www.salmonllc.com/sofia).

    I keep reading these articles about how enterprise Java needs to be made easier and I agree, but I also laugh because it has been for quite some time, just not from the big boys like Sun and IBM. Making tools (and just about everything else) harder then they need to be is just what they do. It is just technical snobbery with no real purpose. Why spend twice as long writing an application then you have to? Developers should be highly paid because we design great software. And we should get paid more if we can produce more, not because we've learned a bunch of arcane details about a spec a yard long.
  11. Ideally, the core business logic components should be where the true developer effort should be, to some extent it is but J2EE developers still spend an awful lot of time on framework.

    I really hope that JSF succeeds in delivering an easy, rapid way to so we can just worry about business logic and largely forget about the framework. I know that Struts, etc. can make things markedly easier but it's still harder than it has to be.

    Mike
  12. BEA has done some big innovation around UI. Check out PageFlows and NetUI in WebLogic Workshop.

    Building Web Apps with WebLogic Workshop

    Eric
  13. BEA workshor has lot of teething problems.
    > BEA has done some big innovation around UI. Check out PageFlows and NetUI in WebLogic Workshop.
    >
    > Building Web Apps with WebLogic Workshop
    >
    > Eric
  14. Ease and speed at what expense?[ Go to top ]

    While I agree that J2EE development can benefit from more straightforward approaches, I have to wonder about the idea of innovating first and standardizing later. When proprietary implementations gain momentum with a market leader, there can be an incentive to avoid standardization and seek a vendor lock-in model for large corporations. Profit is the primary motive for any for-profit corporation, no matter the public front, and vendor lock-in means profit. As a small example, remember the broken standards in IE (notice where Mr. Nielson spent 12 years of his career)? The breaks were 'innovative' and arguably hurt standards-based development in the web community. The real solution, I believe, is to standardize faster -- streamline the JCP. Don't leave the community's future in the hands of for-profit corporations that don't have the same motives and the rest of the community.
  15. <quote>
    J2EE development tasks need to become less elite and more mainstream.
    </quote>

    It's the "elite" and "non-mainstream" that keeps me in gainfull and lucrative employment. Heaven help us if it goes the way of VB!
  16. BEA's Tod Nielsen on the Future of J2EE[ Go to top ]

    BEA is the idiot bringing VB concepts into J2EE Development process by marketing their idiotic tool workshop. BEA got workshop concepts from some ex Microsoft culprits joined BEA later with their ugly business modeling in enterprise computing.

    Tod Nelsson and Eric, get a life dude, instead of teaching J2EE community about how to develop Java code using your ugly workshop tools. Java achieved its current status because it is not attached to a specific companies ugly ideas and process of development. What are your points to support your talks and bring a tool like workshop into Java community? What are the standards your tools follow so that you can sell them into Java community? You guys just want to get Java into a stage where Microsoft use VB, so that you can brainwash all Java firms and apply your ugly approach in development process and steal their money
    .
  17. <quote>

    > J2EE development tasks need to become less elite and more mainstream.
    > </quote>
    >
    > It's the "elite" and "non-mainstream" that keeps me in gainfull and lucrative employment. Heaven help us if it goes the way of VB!

    For $90K+/CPU for Platform, it seems BEA is pandering to an elite market so this drivel coming from Mr. Nielsen mouth is laughable. It seems that, with Open AppServers making leaps and bounds towards enterprise quality, it's J2EE vendors like BEA that have to be less elitist and more mainstream. The fact that BEA's market share is based on them being J2EE compliant(ie. based on standards) sort of flies in the face of this guy's statements.

    Is Mr. Nielsen saying that corporations should enter into a R&D project for critical production systems? Every CTO/CFO/CIO I've dealt with WANTS standards and are usually 1-2 releases behind the curve in their development pipelines. Standards allow them to achieve controls in operations, give them a larger resource pool to choose from and manage risks since the standards provide third party alternatives than a single vendor lock-in.

    Sounds like a M$soft strategy: "Throw it at the client, have the client help us fix it through 'feedback' and then call it a standard". This works for them because they're the only chef in the kitchen. It doesn't apply in a more open and competitive J2EE market.

    As far as the terrible Workshop product:

    This is BEA's new marketing pitch. "Capture the cheap VB market. J2EE programmers are expensive and don't provide value. With Workshop, you buy our mindtrust with the product". This from a recent workshop at a client's shop after my J2EE consulting company recommended their product. Needless to say we are going to rethink our relationship with BEA.

    What happens if the client decides that BEA is not their cup of tea and wants to go to vendor XYZ. The code is not portable since the NETUI and most of the other frameworks under Workshop are not portable including the WebServices framework.

    The problem is that the current propaganda is declaring that Software Engineering can be deconstructed like an assembly line. The idiots forget that we are ENGINEERS and there is a significant level of craft behind design and development well beyond the tools used. This is a huge difference between the statements "Put these parts together" versus "Design these parts and then put them together and make them work". This was the same garbage back in the "Powerbuilder will change the world" and the CASE is the end of developers mantras that were puked out in the past.

    More FUD from the Free Traders group of the IT gang.

    -- Frank Bolander
  18. <quote>
    The problem is that the current propaganda is declaring that Software Engineering can be deconstructed like an assembly line. The idiots forget that we are ENGINEERS and there is a significant level of craft behind design and development well beyond the tools used.
    </quote>

    100% Agreed. Writing software that can be plugged in like hardware is far-fetched dream, not possible at least in our life time:-) Only people who never have written serious code can dream of that, rest of us know it is bull crap.

    One point about standards, even right now most of the standards are hijacked by big companies, and they strive hard to make any thing a standard which they already have developed in their labs. It is quite unfair for small companies who don’t have any say in the standards. Web services is hot because IBM, MS, etc say that is the way to go, on the other hand CORBA is out of the picture because one big vendor, you all know who, says no to it, and preemt some very good small companies like IONA and ORBIX who were way ahead in the game.
  19. Rashid: 100% Agreed. Writing software that can be plugged in like hardware is far-fetched dream, not possible at least in our life time:-) Only people who never have written serious code can dream of that, rest of us know it is bull crap.

    It seems far-fetched, but even ten years ago we had VBX's which were extremely re-usable and pluggable chunks of software. In other words, it's hard to predict how re-use and componentization will evolve, but it is evolving and moving forward all the time, and when we look back, it will be obvious that it happened.

    I have to agree with Tod, or at least say that the vision is an attractive one.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  20. VBX and ActiveX components are reality in Visual Basic world. I know because I'm from there. But there seems no such components in Java world. Why? Because there are no accepted binary component architecture in Java. The nearest thing to ActiveX is Java Beans however Java Beans is not a binary component architecture like ActiveX. Maybe someone here can show me a binary component architecture for Java that has widespread acceptance.
  21. Frank

    I'm curious whether you think BEA is "pandering to an elite market" or rather pitching to "capture the cheap VB market"? BEA has a wide set of price points, not unlike other commercial products. I don't think that nullifies Tod Nielsen's opinions in any way.

    We've recently had a number of threads on TSS focused on discussing the value of open source vs commercial products. Tod Nielsen's comments instead were focused on what the Java community needs to do to make Java technology easier to use and to make Java technology more agile. Workshop and its surrounding technologies (PageFlows, NetUI, ProcessDefinition, JWS, XMLBeans, XQuery, etc.) is BEA's ease-of-use message. There is a strong concensus that J2EE needs this, and every ISV even remotely associated with Java is pushing their tools for ease-of-use. I read Tod's message as, "OK, we need ease-of-use, and we need to do it in a standard fashion. But companies shouldn't have to wait until everything is standardized to use it." The interesting debate is where to draw the line, and it's really up to companies to decide whether a "non-standard" feature or tool gives them an advantage over staying "100% standard" (if that's even possible).

    Going back to Workshop, I believe that maybe there's a misconception that developers are obligated to use Workshop to develop on WebLogic. WebLogic supports 100% of J2EE standards with very solid implementations. You can use any J2EE IDE to build components for WebLogic. If you're a J2EE expert, you will probably be frustrated with Workshop, as it focuses on programming at a J2SE level, generating J2EE code on the server. There's no UML, no hard-core refactoring and packaging tools.

    And I don't think you'll find anyone at BEA saying that J2EE programmers don't provide value. However, as everyone on this thread would agree, J2EE is difficult and not something you can learn from a textbook alone. You need real project experience to do J2EE right. The cost of buying and maintaining a staff of J2EE experts is just not feasible for most companies. Also, many companies want to standardize on J2EE for all development, not just mission-critical. Many have non-Java staff (VB, COBOL, etc.) and are looking to retool these guys to Java. What Workshop provides is a way to supplement development done by J2EE experts with developers who are new to Java and/or J2EE. Using Workshop these developers will be able to see and use your J2EE components and services (built with JBuilder, Eclipse, etc.) in building their new components and services.

    Workshop is still a fairly young tool (not unlike Eclipse). It will have to grow and standards will need to solidify in lots of areas. I'm confident that Workshop will adopt these standards as they are announced.

    Still, Tod Nielsen's comments were not about the functionality or the stability of Workshop, but rather what Java needs and (we can assume) where Workshop fits into that vision.
  22. I'm curious whether you think BEA is "pandering to an elite market" or rather pitching to "capture the cheap VB market"?

    The "cheap VB amrket" comment wasn't mine, it was the presenter's. Just to give you context, a powerpoint slide came up with two circles, one with J2EE "experts" with about 5 icons of heads inside. Next to it was a circle with "VB programmers" with many icons inside. Above both was $$J2EE >>>> $$VB Pool. The argument continued whether the premium paid for a smaller resource pool was worth it. Seemed like a question of value to me.

    Tod Nielsen's comments instead were focused on what the Java community needs to do to make Java technology easier to use and to make Java technology more agile.

    The WSAD/Eclipse, JBuilder, Intellij, Oracle JDeveloper folks would probably argue that they are already there and making strides everyday. I have no problems with components being used in an engineer's toolkit to increase productivity. However, the Workshop product's argument is that you can displace a person with J2EE skillsets with less expensive "traditional development" resources with the product. I take issue with this premise. Most people on these threads have spent a great deal of time and effort developing their craft just to have a vendor trivialize it to deflate their value as a "cost-cutting" proposition. "Cost-cutting" doesn't lead to innovation which was part of his original thesis.

    Going back to Workshop, I believe that maybe there's a misconception that developers are obligated to use Workshop to develop on WebLogic. WebLogic supports 100% of J2EE standards with very solid implementations. You can use any J2EE IDE to build components for WebLogic.

    So standards provide a client with third party alternatives to deliver a product. I think this was the point of standards being of value. Unilateral innovation is great but it can also lead to fragmentation ala Unix of the late 80's.

    If you're a J2EE expert, you will probably be frustrated with Workshop, as it focuses on programming at a J2SE level, generating J2EE code on the server. There's no UML, no hard-core refactoring and packaging tools.

    Then what value does it bring other than an "assembly line" model. You're not extracting value and engaging the COBOL and VB "non-expert" resources to improve their skillsets and provide innovation pathways for future development. You're giving them piece work.

    And I don't think you'll find anyone at BEA saying that J2EE programmers don't provide value.

    OK I agree, I'll write off the statement as poorly worded by the pitch men, but it was said. I've been dealing with Weblogic since the Tengah days (and extremely happy) and this statement floored me when I heard it. I just don't agree with the Workshop proposition.

    However, as everyone on this thread would agree, J2EE is difficult and not something you can learn from a textbook alone. You need real project experience to do J2EE right.

    I think you're making my point that Software Engineering can't be deconstructed as an assembly line analogy and "commoditized".

    The cost of buying and maintaining a staff of J2EE experts is just not feasible for most companies.

    So is buying commercial J2EE application servers in a lot of cases ;)

    Bottom line, BEA as well as the other vendors just to be fair, are pushing this "commodity developer" concept which has been tried in the past. I'm sure a lot of people on this thread have long careers or hope to in the IT industry. Why participate in a field of diminishing returns?

    I'm an old fart in this industry and I'm seeing the same drivel being regurgitated again and again. I don't see innovation through "cost-cutting" propositions, it's through R&D which requires capital, both money and intellectual. Elitism I guess is an integral part of that, to some extent, since there is a burden to keep one's skills sharp to maintain an advantage.

    - Frank Bolander
  23. Hey Frank,

    Out of curiosity have you tried using Workshop 8.1?
    The level of productivity that you can achieve with the
    tool is really outstanding. Yes there are some value
    added propositions that BEA has created but even then
    some of those are built on top of defacto standards (i.e. Struts).
    And for the things that aren't standard BEA is working
    to either make them standards or adjust the implementation
    to conform to standards. I don't think there's any
    doubt that BEA knows that customers like standards. Heck
    that's what got them to where they are today.

    But at the same time how does one innovate and comply to standards
    that don't exist or don't fit into the model of the innovation?
    At the end of the day customer's care about value and productivity too.

    You say you've been around for a very long time so that means you
    must have worked with many developers that you know would struggle
    to, or not have the desire to, master the complexities contained
    within the J2EE spec. There are many folks out there that are
    capable of writing code, less that are capable of creating a well designed
    system of software. Add in the complexity of J2EE and that number goes
    down even further.

    Assuming you agree with that premise, what would you propose that many
    companies out there do that have developers that are capable of
    writing code? Sure many are capable of mastering the complexity of J2EE
    some maybe aren't, some probably have no desire to. Why wait 6 months
    or more for these folks to come up to speed to be able to provide any kind of
    value at all? Especially when the largest part of the curve is alot of grunt
    work and needless complexity that just gets in the way of the programmer simply
    getting something done. Furthermore the folks that have no desire to learn that
    complexity will never come up to speed and that's one less person that
    is using the entire J2EE platform. Someone's going to make this work easier.

    So perhaps now is the time to give the disclaimer that I am an engineer at
    BEA and that I work on Workshop as well as having worked on WLS.
    I have been using emacs as well as other text based editors for the majority
    of my software engineering career. Emacs for writing WLS, WLS apps, anything
    code related. The WLS apps writing part in Emacs came to an end sometime
    during the course of 8.1 development. The level of productivity I realize
    when writing an app for the server with Workshop makes it a no brainer.

    For example:
    To write an EJB with emacs you have to either know all the files that need
    to be created along with the bean and create them by hand, or use xdoclet, or
    ejbgen which generates the needed files. Once you master this complexity of
    just writing the bean, compiling, descriptor creation/editing, deploying the thing you now have to write something to call the bean.
    Now you must know about webapps and what it takes to deploy a webapp.
    Go make your descriptor(s), jsp page, do your JNDI lookup or make your ref and do the lookup on that, call your bean and have it do something to indicate that it's alive.

    There's alot of steps in that entire process and many ways that a user can be
    tripped up. I'm not sure of the number of steps that it takes but I'd be
    willing to bet that Workshop cuts down those steps by a large percentage.

    The complexity is there when you're ready for it but sometimes you just
    want to get something done. Some of the productivity boost is realized by
    value added features that have been created at BEA, others are standard.
    Add to all of this the tight integration of portal and WLI and the value proposition for any customer looking to leverage the entire
    stack simply outpaces anything out there. I can write you a portal from
    nothing in 10 minutes. Enabling more people to use J2EE is a good thing
    and that's the intent with Workshop. Certainly moving "up the stack" in terms of being a J2EE guru is a good thing because the need for intelligent expert developers and architects are never going to go away. At least not until
    this whole AI thing is mastered ;-)

    -Michael

    All of these opinions are my own and may or may not be necessarily endorsed
    by my employer :-)
  24. Hmm[ Go to top ]

    <quote>
    Enabling more people to use J2EE is a good thing
    and that's the intent with Workshop
    </quote>

    But can that be achieved? You will enable more people to create EJBs,
    Webapps etc. in the first place. But unless these people *understand* what
    they have built, you are in for a surprise of the poor performance and maintainability of the created application. No classic RAD environment -
    like Workshop - can deliver that. Only application frameworks and application
    code generation (now called MDA) can take you there.
  25. re: Hmm[ Go to top ]

    <quote>
    But unless these people *understand* what
    they have built, you are in for a surprise of the poor performance and maintainability of the created application. No classic RAD environment -
    like Workshop - can deliver that. Only application frameworks and application
    code generation (now called MDA) can take you there.
    </quote>

    Does everyone who writes Java understand how the JVM works? Could they write better bytecode or assembler by hand for that matter?

    I don't agree that everyone writing a J2EE application needs to understand all of the specs and be able to write code and descriptors from scratch. If you find one that can, great but new tools like Workshop are going to lower the barriers and allow more participants who will probably eventually learn the ropes but also get work done quicker. Not build EJBs quicker, but build applications quicker.

    I been working with J2EE for a number of years, yes it can be tricky and it is easy for begineers to hose themselves. I like Workshop because it can pump out J2EE based applications based on the frameworks that you mention and prevent wasted time and bad performing applications since it can handle the implementation of an application, not just the components.

    The value to me is in the integration strategy and packaging of components - not just in building the components themselves.

    Rob
  26. re: Hmm[ Go to top ]

    I completely agree.

    J2EE provides lots of low-level specs for messaging, remote calls, asynchronous communications, data passing, data mapping, transaction mgmt, and integration with DBs, back-office apps, etc. It gives you enough rope to hang not only yourself but also your entire development team.

    MDA does not necessarily solve the problem. It can help with generating some of these low-level components, but is generally focused on DB-oriented systems. It also requires a lot of study and experience to get the models right. Finally, even with emerging standards, there are still differences among the MDA tool vendors, requiring you to learn a particular tool and hope that the generated code works, and that the developers comply with the generated comments that say things like /** PUT YOUR CODE HERE */.

    The lack of a standard framework in J2EE means that using any existing framework may create portability problems, support problems (if it is an external framework), or maintenance problems (if it is a homegrown framework).

    It would be nice to (1) standardize on a common development framework for programatically developing J2EE apps, possibly using JSF or Struts and (2) work to develop the next tier of J2EE specs that would allow developers to program using basic J2SE concepts, then translating that "procedural Java" to J2EE components at run-time. This new tier of J2EE standards would offer portability, while lowering the barrier to entry for Enterprise Java and allowing J2EE App Svr vendors to compete on the quality of implementation of these new specs, exactly what they are doing now for J2EE functionality.
  27. re: Hmm[ Go to top ]

    <quote>
    J2EE provides lots of low-level specs for messaging, remote calls, asynchronous communications, data passing, data mapping, transaction mgmt, and integration with DBs, back-office apps, etc. It gives you enough rope to hang not only yourself but also your entire development team.
    </quote>

    Monte, all the above details are quite necessary to be a middleware developer/architect, and that is why they are well paid too. That is the nature of the beast, and quite frankly most of the time it is not as complex as people brag to.

    <quote>
    The lack of a standard framework in J2EE means that using any existing framework may create portability problems, support problems (if it is an external framework), or maintenance problems (if it is a homegrown framework).
    </quote>

    100% agreed. If you ask my perosnal opinion, I don't want any thing to use outside the stadard Java/JDK, becuase not only it looses portability, but also it would be much harder to maintain. But I think every mature J2EE architect should know these things better, isn't that is why they are paid that much, and I am so underpaid:-)
  28. re: Hmm[ Go to top ]

    <quote>

    > J2EE provides lots of low-level specs for messaging, remote calls, asynchronous communications, data passing, data mapping, transaction mgmt, and integration with DBs, back-office apps, etc. It gives you enough rope to hang not only yourself but also your entire development team.
    > </quote>
    >
    > Monte, all the above details are quite necessary to be a middleware developer/architect, and that is why they are well paid too. That is the nature of the beast, and quite frankly most of the time it is not as complex as people brag to.

    They might need to know them now and for quite some time, but I don't see why most of this can't be automated by a future tool. There's nothing to stop a RAD tool from generating most of this without code from the developer, especially as long as the developer could go in and tweek it here and there. But, ideally, the generated app would suffice 90% of time.

    Applications have definetly gotten more complex in the last 5 years but I'm sure the same arguments were made prior to apps like VB automating alot that, prior to that, consumed alot of developer effort.

    I agree with a previous poster who predicted that eventually the code we'll be writing will be J2SE in nature and the rest will be generated framework. As far as RAD development for specific business logic, I'm much more skeptical.
  29. re: Hmm[ Go to top ]

    Applications have definetly gotten more complex in the last 5 years but I'm sure the same arguments were made prior to apps like VB automating alot that, prior to that, consumed alot of developer effort.

    >

    I am confused. In VB you write some code, you click a buton and you have a deployable COM object. In Java you write some code, you click a button(OK, you type soemthing in a telnet/ssh/Xwindow(preferably VNC, it is OS) session:-)))and you have a deployable jar file. I see No difference.
    Of course, if you start manipulating IUnkown(God be praised, I don't have to do this now) it's a different story. But the thread was about Java/VB.
  30. re: Hmm[ Go to top ]

    Applications have definetly gotten more complex in the last 5 years but I'm sure the same arguments were made prior to apps like VB automating alot that, prior to that, consumed alot of developer effort.

    > >
    >
    > I am confused. In VB you write some code, you click a buton and you have a deployable COM object. In Java you write some code, you click a button(OK, you type soemthing in a telnet/ssh/Xwindow(preferably VNC, it is OS) session:-)))and you have a deployable jar file. I see No difference.
    > Of course, if you start manipulating IUnkown(God be praised, I don't have to do this now) it's a different story. But the thread was about Java/VB.

    There is a very big difference, most of VB programmers do not know IUnkown and about hidden reference counting, it produces memory leaks and doe's not work for server applications. IUnkown doe's not help too, it takes too much time to count all references manualy (debugging takes more time than application development).
    COM was a very "transparent" technology a few years ago, but forget it, MS started to replace it with new experiments, JAVA clones.
    But there is no time to wait this replacement.
  31. re: Hmm[ Go to top ]

    There is a very big difference, most of VB programmers do not know IUnkown and about hidden reference counting, it produces memory leaks and doe's not work for server applications.



    Sorry, I confused you. My point was that whatever deployment advantages VB/COM provided at a click of a button, Java also provides. There is almost no relation between a VB and a C++/COM programmer(I'm stretching reality a little bit here:). Historically COM started just as a better way to deploy dlls(I might be wrong on this one, but I doubt it). And if we think about dynamic invocation, well a class loader does the same thing.
    So I don't understand from the article what VB has and Java with a good IDE doesn't.
  32. re: Hmm[ Go to top ]

    There is a very big difference, most of VB programmers do not know IUnkown and about hidden reference counting, it produces memory leaks and doe's not work for server applications.

    >
    >
    > Sorry, I confused you. My point was that whatever deployment advantages VB/COM provided at a click of a button, Java also provides. There is almost no relation between a VB and a C++/COM programmer(I'm stretching reality a little bit here:). Historically COM started just as a better way to deploy dlls(I might be wrong on this one, but I doubt it). And if we think about dynamic invocation, well a class loader does the same thing.
    >
    COM was a great technology, it solved dll deployment problem aka "dll hell" decade ago and much better than JAVA at this time. I see the most of projects at this time are web applications, web frontends for legacy systems, "online databases". COM was a good idea, but web popularity kills it, it is too dangerous for server side or web development.


    > So I don't understand from the article what VB has and Java with a good IDE doesn't.


    Mouse, IDE, drag & drop, code generators and visual tools are usefull for beginers, but I have never saw large application implemented this way and I do not think this kind of tools are usefull for expierenced developers. I have used ATL for COM development, visual tools helped me to learn and to get started, but nothing more than text editor later.
    There are a lot of this kind tools for JAVA too, but ant is more usefull, is not it ?
  33. re: Hmm[ Go to top ]

    When I used VB, I found it useful for prototyping UIs quickly. Problem was that after the protoype you needed to throw away what you did and re-write it in another language (normally C++).

    I think the opportunity here is to make a tool that lets you get quick J2EE prototypes working that you will not need to rip down later on. Instead you can keep building on to make your solution (more like "tracer bullets" as discussed in Pragmatic Programmer, rather that an actual prototype).

    I think this is another value for advanced developers.
  34. re: Hmm[ Go to top ]

    Mouse, IDE, drag & drop, code generators and visual tools are usefull for beginers, but I have never saw large application implemented this way and I do not think this kind of tools are usefull for expierenced developers. I have used ATL for COM development, visual tools helped me to learn and to get started, but nothing more than text editor later.

    > There are a lot of this kind tools for JAVA too, but ant is more usefull, is not it ?

    Well, I've seen some big projects built with an IDE. And I just don't understand why using an IDE makes a good programmer a bad programmer(you used ATL, so...). Au contraire, I think it improves speed and quality. But maybe the real answer is the one that somebody provided in a discussion about C++templates. At the moment everybody and their brother was a programmer, and the guy said that templates reduce white noise(emitted by some other programmers probably). If this is the case, you have a point. But otherwise I just don't see why a good GUI is bad.
  35. re: Hmm[ Go to top ]


    > Well, I've seen some big projects built with an IDE. And I just don't understand why using an IDE makes a good programmer a bad programmer(you used ATL, so...). Au contraire, I think it improves speed and quality. But maybe the real answer is the one that somebody provided in a discussion about C++templates. At the moment everybody and their brother was a programmer, and the guy said that templates reduce white noise(emitted by some other programmers probably). If this is the case, you have a point. But otherwise I just don't see why a good GUI is bad.
    >
    No IDE doe's not make a good programmer a bad programmer, but It doe's not make
    a good programmer better too.
    I am talking about MOP (Mouse Oriented Progamming) It improves speed for pilot project, but not a quality. Looks like you are more lucky man, but I have saw toys only implemented with MOP. IDE and MOP is not the same, ant is delopment environment too, is not it ? If you have text editor intgrated with ant you have integrated delopment environment (IDE).
  36. re: Hmm[ Go to top ]

    No IDE doe's not make a good programmer a bad programmer, but It doe's not make

    > a good programmer better too.
    > I am talking about MOP (Mouse Oriented Progamming) It improves speed for pilot project, but not a quality. Looks like you are more lucky man, but I have saw toys only implemented with MOP. IDE and MOP is not the same, ant is delopment environment too, is not it ? If you have text editor intgrated with ant you have integrated delopment environment (IDE).

    Well, since others mentioned Powerbuilder: PB wasn't bad by itself, but the people using it were some of the most amazing bad programmers I've ever seen. They all seemed to want to improve their resume and the first victim was the database, something like I have to write SQL as skill.
    Otherwise, JBuilder is a much better editor.

    From this point of view you are definitely right.

    Try to explain this to your manager:-)))
  37. I've been evaluating the Weblogic 8.1 Platform for a mid-size enterprise application prototype for a good chunk of this year, and the fact of the matter is that there are still major hurdles that often REDUCE productivity. While the Weblogic Server portion may be fairly stable (it has class-loading and resource issues), the Weblogic Integration product and Weblogic Workshop are very much in their infancy.

    I don't want to go into detailed evaluation results here, but try these out for fun:

    BEA claims to have 10x higher productivity and a stable x.1 release that allows you enterprise quality applications. Try this one out:
    Open up BEA's Configuration Wizard
    Create a new configuration
    Choose the Weblogic Integration domain template
    Choose Express setup
    Select Production Mode when prompted
    After creating your configuration, go to the domain directory and run the startWeblogic script.

    I'll let you see for yourself what happens, but this shows how the promise of ease of use is far off. This should be the simplest thing you can do with the Weblogic Platform, and look what happens.

    Another thing to try:
    Open up a large source file in Weblogic Workshop (10-15k or higher)
    Try to program

    You should notice some horrible performance. BEA's suggestion: "turn off code completion and method completion". OK, so I have to sacrifice some of the most productive features of the IDE to get acceptable performance?

    There are many other issues with BEA's promise of high developer productivity as well, but these are some blatant ones. The point I'm trying to make is that ideas like Workshop/Integration sound great with high potential, but their reality is still far off. BEA's Platform works well for small, simple applications, but try doing something real, and you'll find out for yourself.
  38. IDE's are good[ Go to top ]

    Juoazas:
    beginers, but I have never saw large application implemented this way and I do not think this kind of tools are usefull for expierenced developers. I have used ATL for COM development, visual tools helped me to learn and to get started, but nothing more than text editor later.
    There are a lot of this kind tools for JAVA too, but ant is more usefull, is not it ?

    It seems to me you are mixing up IDE's and wizards. Since you mentioned you used ATL, I can see how you would feel this way :-)

    Saying that "ant is more useful" doesn't make much sense to me. ant is as essential to the development process as an IDE is. If you think you are very productive with emacs/vi and ant right now, you need to realize you will be even more effective if you include an IDE in your arsenal.

    --
    Cedric (weblog)
  39. IDE's are good[ Go to top ]

    Juoazas:

    > beginers, but I have never saw large application implemented this way and I do not think this kind of tools are usefull for expierenced developers. I have used ATL for COM development, visual tools helped me to learn and to get started, but nothing more than text editor later.
    > There are a lot of this kind tools for JAVA too, but ant is more usefull, is not it ?
    >

    > It seems to me you are mixing up IDE's and wizards. Since you mentioned you used ATL, I can see how you would feel this way :-)
    >

    Yes, I am talking about wizards, code generators, visual data binding, ... .
    I use IDE to edit text and to navigate classes, but I use ant if I need something more. I have bad expirience with projects *dependant* on IDE, I have spend a few weeks to migrate my firt project to new IDE version ( it was almost the same as reenginiering ).

    > Saying that "ant is more useful" doesn't make much sense to me. ant is as essential to the development process as an IDE is. If you think you are very productive with emacs/vi and ant right now, you need to realize you will be even more effective if you include an IDE in your arsenal.
    >
    > --
    > Cedric (weblog)
  40. Hmm[ Go to top ]

    Karl:
    But can that be achieved? You will enable more people to create EJBs,
    Webapps etc. in the first place. But unless these people *understand* what
    they have built, you are in for a surprise of the poor performance and maintainability of the created application.

    If I judge by the size of the VB market and by the number of VB applications out there, there is historic precedent that it is indeed possible to hide complex API's behind languages and tools in order to make these technologies accessible to a broader range of developers.

    Easy? Certainly not.

    Possible? Absolutely.

    --
    Cedric
    weblog
  41. Hmm[ Go to top ]

    From the IT development perspective, I guess its a question of whether you want to spend your effort trying to hide the details - or - whether you want to spend that effort making sure you have the right people (training and/or recruiting)

    -Nick
  42. Hmm[ Go to top ]

    Hey Nick,

    Nick:
    From the IT development perspective, I guess its a question of whether you want to spend your effort trying to hide the details - or - whether you want to spend that effort making sure you have the right people (training and/or recruiting)

    You make it sound like it's a zero-sum game: for every "new" programmer that a tool like Workshop adds to the J2EE pool, an "old" system programmer like you or me has to go.

    It's not.

    It's about creating value.

    The emergence of PowerBuilder and VB hasn't made C++ and COM programmers obsolete. They are still needed. Badly. If anything, their value has increased because they now represent a tiny fraction of the overall population of programmers and the demand for the skills is at least as pressing as it was before.

    --
    Cedric (weblog)
  43. Hmm[ Go to top ]

    You make it sound like it's a zero-sum game: for every "new" programmer that a tool like Workshop adds to the J2EE pool, an "old" system programmer like you or me has to go.
     
    It's not.

    It's about creating value.


    Unfortunately, it usually is a zero-sum and sometimes less-than zero game since budgets are finite and shrinking everyday. Shops aren't adding, they're shrinking their development pools.

    As far as creating value, I'm not seeing how restricting design degrees of freedom in a tool like Workshop creates value. No matter how good a tool is at abstracting processes, it still takes time for a resource that isn't trained in a discipline to ramp up to speed(ie Object Oriented Design, Distributed Architectures,J2EE, etc...). That equates to time and training dollars which a journeyman resource already possesses.

    In the interim, the journeyman J2EE programmer finds himself in a lose-lose proposition because now he's competing against marketing hype. He finds himself in a decreasing wage market. He either does minimal work now for his decreasing wage -- not good for innovation or value , or goes on to the "next best thing" and a valuable resource leaves the J2EE pool.

    From my experience(we have to do a lot of 'mentoring' on reengineering projects), a lot of the target resources DON'T WANT TO DO JAVA. They want to do VB/COBOL/SQL/RPG or whatever. That's what they're trained for and that's what they like. You can't extract blood from a stone by throwing them in an arena which they don't want to be in. Another black mark for innovation and at least a smudge against value.


    The emergence of PowerBuilder and VB hasn't made C++ and COM programmers obsolete. They are still needed. Badly.


    Obsolutely, they were always needed from the start of a project. This was a problem with the original VB/Powerbuilder gold rush. But at the time the C++/COM guys were excluded from the picture because of marketing hype by vendors that they could be replaced with more "traditional development resources" and a GUI. There was a 4 year period of lean times for C++/COM people as shops followed the hype. Then when the tools hit the wall in terms of solving more complex problem domains, the C++/COM guys with engineering experience percolated to the top again and the guys with fortitude who could bet on this are reaping the rewards. A lot of people don't have the stomach to weather that type of storm.

    If anything, their value has increased because they now represent a tiny fraction of the overall population of programmers and the demand for the skills is at least as pressing as it was before.

    Your statement is sort of making my point. The pool of qualified people actually descreases in light of the marketing hype so you're not bringing new people to the fold -- less-than zero sum. So if you time average the value of a proposition, it doesn't look as rosy as before.

    -- Frank
  44. Hmm[ Go to top ]

    If I judge by the size of the VB market and by the number of VB applications > out there, there is historic precedent that it is indeed possible to hide

    > complex API's behind languages and tools in order to make these technologies > accessible to a broader range of developers.
    >
    > Easy? Certainly not.
    >
    > Possible? Absolutely.
    >

    Cedric,

    I do not see that the precedent works. Provision of a click-and-go middleware framework that performs satisfactory has not been demonstrated up til now, as far as I know. And VB is totally off topic, you would need to compare it with integration frameworks a la webmethods and vitria to get a closer fit. Sure a couple of good UI components with some sophisticated data binding can take you quite far - no arguing with it, that's what MS has demonstrated with VB and ASP.NET quite strikingly. And this is exactly where the greatest benefit of tools like workshop lie currently.

    If this will take you very using asynchronous messaging, catering for high data volume and generally doing things at the very core of J2EE I very much doubt.
  45. Excellent Summary Frank Bolander[ Go to top ]

    Excellent Summary Frank Bolander
  46. FUD 101 -- Perhaps a bit overblown?[ Go to top ]

    I'm a developer on the Workshop team, and I'm a little bit surprised by this. I don't think anyone on this team would agree with

    <quote>
    J2EE programmers are expensive and don't provide value.
    </quote>

    The purpose of appealing to VB level developers is not to replace J2EE developers. Its to allow J2EE developers to focus on more difficult problems, while handing easier problems to less technical developers. Our goal is to be able to make an IDE that developers in any range of experience will enjoy developing in.

    I feel that
    <quote>
    This was the same garbage back in the "Powerbuilder will change the world" and the CASE is the end of developers mantras that were puked out in the past.
    </quote>

    is a bit of building a straw man to beat down. VB is an easy tool to build quick windows programs with. Making the argument that VB and tools like VB haven't caused real developers to go away seems orthoganal to the arument that VB and tools like it are useful. I feel there is no doubt that productivity tools are useful. I also feel that productivity tools in this space have the chance of being even more useful than VB, because everyone is playing on the same language and on the same platform. One of the big problems with VB is that your prototypes are often relegated to only being prototypes. In Workshop, your app still runs on an App Server, so it still has headroom to grow.