Macromedia JRun 4 Gets J2EE 1.3 Certification


News: Macromedia JRun 4 Gets J2EE 1.3 Certification

  1. Macromedia JRun 4 Gets J2EE 1.3 Certification (31 messages)

    Macromedia today announced that Macromedia JRun, has successfully passed Suns J2EE 1.3 test suite.

    Playing with the beta, it looks pretty different from their old product which I always had a soft spot for. Stuff like JINI clustering is in there and JMX admin and what seems to be totally new EJB code look cool and deployment is way cool, and there's an app that seems to let Flash Movies talk to EJBs and JMX and other Java on the server. It seems definitely beta stuff though and macromedia site has nothing about it. Cool to see another vendor beat some of the bigger guns to certification.

    A technology preview of the next version of Macromedia JRun can be downloaded at

    Press Release
    SAN FRANCISCO, Jan. 28 /PRNewswire-FirstCall/ -- Macromedia, Inc. (Nasdaq: MACR - news) today announced that Macromedia JRun, the company's Java(TM) technology based application server, has successfully passed Sun Microsystems' comprehensive Java(TM) 2 Platform, Enterprise Edition (J2EE(TM)) 1.3 test suite to achieve Sun's J2EE 1.3 compatible brand. Focused on the needs of developers building server-side Java technology based applications built on open industry standards, Macromedia JRun makes the advanced capabilities of the J2EE 1.3 platform broadly accessible to the entire Java development community. The J2EE 1.3 compatibility program helps JRun developers deliver superior applications to market quickly, while leveraging Java technology's value proposition of simplified business integration, simplicity of development, and freedom of choice. Further, by achieving compatibility, Macromedia provides JRun customers with the knowledge that their J2EE 1.3 technology based application will run predictably and reliably.

    ''Macromedia JRun has gained incredible momentum in the Java application server space due to its unmatched performance, reliability, flexibility, and aggressive price-point,'' said Jeremy Allaire, chief technology officer, Macromedia. ''By gaining J2EE 1.3 compatibility, we're further validating our belief in the value of supporting leading-edge open Internet standards. Sun's J2EE 1.3 compatible branding of JRun enables Macromedia to provide the most affordable, J2EE 1.3 compatible Java application server for companies of all sizes, and offers customers greater flexibility and developer productivity gains.''

    Macromedia JRun delivers the powerful capabilities of the J2EE 1.3 specification in a single integrated server, providing companies the ability to build advanced business systems that take advantage of distributed transactions and messaging for enterprise-class reliability. Macromedia JRun supports all J2EE 1.3 APIs, including Enterprise JavaBeans (EJB 2.0), JavaServer Pages (JSP 1.2), Java Servlets (2.3), Java Naming and Directory Interface (JNDI), Java Transaction API (JTA), and Java Database Connectivity 2.0 technology (JDBC). A technology preview of the next version of Macromedia JRun can be downloaded at

    ''As Java technology continues to evolve and help shape enterprise systems, the support and advancement of long-time partners such as Macromedia is critical,'' said Ralph Galantine, product marketing line manager, J2EE, Sun Microsystems, Inc. ''Given its rapid move to gain J2EE v 1.3 compatibility, Macromedia JRun offers developers the opportunity to leverage the new innovative features of the latest version of enterprise Java. The new specification promotes further options for interoperability which JRun users can leverage to gain the benefit of simplified system integration.''

    Recently, Macromedia was elected to the Executive Committee of the Java Community Process(SM) (JCP), the open process that Sun has been using since 1995 to develop and revise Java technology specifications in cooperation with the international Java community. In addition, Macromedia participates in several other special Expert Groups that drive the creation or revision of leading edge Java specifications.

    Macromedia is also a Platinum sponsor at JavaOne, Sun's premier Java industry event, scheduled for March 25-29, 2002.

    About Macromedia JRun

    Macromedia JRun is a Java(TM) 2 Platform, Enterprise Edition (J2EE(TM)) compatible Java application server and integrated development environment for building and deploying server-side Java technology based applications. Focused on ease-of-use, JRun 3.0 provides a 100% Java technology based J2EE implementation, founded on a clean design that avoids the overhead of legacy technologies. Development components, including EJB 1.1, JTA 1.0, JMS 1.0, JSP 1.1, have been built from the ground up to meet Sun Microsystems' J2EE specifications, to deliver advanced performance and reliability. Winner of Internet World Magazine's ''Best of Show'' at Internet World Fall 2000, JRun pricing and upgrade information can be found at


    Macromedia is passionate about what the Web can be. Its award-winning products empower designers and developers to efficiently create and deliver the most engaging experiences on the Web, and enable innovative Internet business solutions. Headquartered in San Francisco, Macromedia has more than 1,400 employees worldwide and is available on the Internet at .

    Copyright 2001 Macromedia, Inc. All rights reserved. Macromedia, the Macromedia logo, and JRun are trademarks or registered trademarks of Macromedia, Inc., which may be registered in the United States and internationally. Sun, Sun Microsystems, the Sun logo, Java and J2EE are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Other product or service names mentioned herein are the trademarks of their respective owners.

    Threaded Messages (31)

  2. Greetings,

    I could not find anything on Macromedia's web site about JRun 4, maybe it is JRun 3.1?

    Thanks in advance,

  3. This is at :

    This is mentioned in the press release.
  4. Hi'

    I would certainly prefer if Macromedia seriously did try to make their buggy (oracle) JDBC Connection Pool mechanism work before releasing any more more of their marketing crap.

    Kind regards

  5. Well done for JRun...
    But SUN J2EE seems seems largely irrelevant and unrepresentative now, when one considers that Sun refuses to certify the most popular J2EE server on the planet (JBoss)
  6. <quote>
    But SUN J2EE seems seems largely irrelevant and unrepresentative now, when one considers that Sun refuses to certify the most popular J2EE server on the planet (JBoss)
    How does that have anything to do with JRun? And in case you haven't noticed, J2EE is hardly irrelevant. I like JBoss, but that seems like a very ignorant remark.
  7. What?! Can you please give me facts supporting your statement that J2EE is irrelevant? Just because one app. server that you happen to like is not certified does not mean that the platform it is based on is dead.

    I won't get into it here since this is an article about JRun, not JBoss. Besides, Sun certifies vendors that COME TO THEM. Sun does not go out and say "Hey, let's try certifying this product." The certification costs a lot of money, and since JBoss is an open source product without a lot of funding (if any), they cannot really afford to go out and get the app. certified by Sun.

    Don't get me wrong, I like JBoss a lot, but your comments are inaccurate and invalid, and I would suggest you reconsider them.

    - John
  8. <quote>
    What?! Can you please give me facts supporting your statement that J2EE is irrelevant? Just because one app. server that you happen to like is not certified does not mean that the platform it is based on is dead.

    I think the point is not that the platform is irrelevent, but that the Sun certification mark is irrelevent. JBoss is not just another app server, it's arguably the de-facto standard implementation if you believe the Sourceforge download numbers.
  9. <quote>
    JBoss is not just another app server, it's arguably the de-facto standard implementation if you believe the Sourceforge download numbers.
    That might be a bit of a stretch. The number of downloads does not equal the number of servers in production use.
    Nothing against JBoss...
  10. Ooops!

    I seem to have caused so much confusion by an innocent typo (or ommission of word anyway).

    What I meant was that Sun "J2EE *certification* seems largely irrelevant" rather than "J2EE seems largely irrelevant" - I certainly don't think J2EE is irrelevant - apologies for any confusion caused!!!

    My reasoning is if the most popular J2EE server is excluded by nature of not having the cash to give Sun, then how representative / useful can the measure be to any prospective user when evaluating which J2EE server to use?

  11. To me, J2EE certification is important, regardless of external issues such as Can The Company Pay For The Cert. JBoss is certainly an excellent product, but that has nothing to do with the importance and legitimacy of obtaining a J2EE certification.

    Yes, SUN has made a standard that J2EE products need to pay money to claim compliance with. Yes, in JBoss's case, this is a hinderence because the JBoss team's approach to open source development involves little financial compensation, certainly not enough to go for the J2EE cert.

    Regardless, it is important that JBoss certify themselves so that they can dig their heels in, so to speak. If money is an issue, why doesn't JBoss organize a funding drive? How about setting up a "Donations Section" on their website that will accept contributions for J2EE certification costs from the JBoss faithful? With all the tens of thousands of committed JBoss users( judging from their download statistics ), it shouldn't cost more than a buck or two for each person( How much is certification anyway? ).

  12. The Sun J2EE certification mark isn't irrelevant, it just isn't the only factor to consider. J2EE certification gives you some confidence about certain facts. Just because a given vendor doesn't have that mark doesn't mean they're useless, it just means you have to do some of that verification for yourself.

    And JBoss' download numbers are certainly impressive, as are aspects of their application server, but download numbers and production deployments are very different things. Until I see real numbers about production deployments of JBoss vs. other application servers, I don't think there's any chance of arguing that JBoss is the defacto standard. A popular download, I'll grant.

  13. <quote>
    But SUN J2EE seems seems largely irrelevant and unrepresentative now, when one considers that Sun refuses to certify the most popular J2EE server on the planet (JBoss)

    That sounds like a bitter and irrelevant remark, but since you mention it: JBoss doesn't support (and doesn't intend to) RMI-IIOP, so they wouldn't qualify for J2EE 1.3 anyway.


  14. Why no support[ Go to top ]

    Cedric( and others too ),

      At the risk of going off on too much of a tangeant, why is it that you believe JBoss will not support RMI/IIOP? Did BEA not hold the same position with regards to this topic in the past? That is to say, BEA did not exactly "lead the charge" towards RMI/IIOP did they? I just want to understand this issue more clearly -- what is the rationale behind choices like this?

    Thanx in advance,

  15. Why no support[ Go to top ]

    At the risk of going off on too much of a tangeant, why is it that you believe JBoss will not support RMI/IIOP?

    Posts on jboss-dev (one of which from yesterday actually).


  16. Why no support[ Go to top ]

    At the risk of going off on too much of a tangeant, why is it that you believe JBoss will not support RMI/IIOP?

    Posts on jboss-dev (one of which from yesterday actually). </quote>

    Amusing to learn that the lead BEA developers hang out on JBoss-dev :)

    Actually JRun has a lot more to do with JBoss than most people know. Rumor has it that Allaire liberally inspired themselves from JBoss code for their container and verifier(with the ironic result of producing an inferior, for-pay product).

    Last time I checked there was RMI/IIOP support in JBoss.
  17. Why no support[ Go to top ]

    Actually JRun has a lot more to do with JBoss than most people know. Rumor has it that Allaire liberally inspired themselves from JBoss code for their container and verifier(with the ironic result of producing an inferior, for-pay product).

    Actually, if I remember correctly, Allaire purchased an early implementer of the the EJB Spec (Vanto Systems, I believe?) and their product, Ejipt. This is the source of what is now known as JRun, if I'm not mistaken.
  18. Why no support[ Go to top ]

    Right, Jason, that was Ejipt that Allaire acquired, but from Valto (rather than Vanto) Systems. Yet it wouldn't be right to say it was "the source of what's known as JRun". Rather, it's the EJB part that was then integrated into the existing JRun (which, for the sake of completeness, had itself been acquired by Allaire much earlier from Live Software).

  19. Why no support[ Go to top ]

    RMI/IIOP support should be available in JBoss 3.0.

    This info also comes from the jboss-dev list.

    -- jason

  20. So...

    indicates a lack of intention to support IIOP?
  21. Greetings,

    By the way, it looks like after Macromedia took JRun under control, they stopped supporting FREE DEVELOPMENT LICENSE as it was with Allaire. If it is true, then I think it will decrease number of JRun sites, since there are a lot other Java App Servers that free for development and have same price for deployment.

    Best regards,

  22. Ok, I'll bite.

    Jorgen: I'm not sure what you are referring to. We OEM our jdbc drivers. Updates can be found on the web site, if you're having a problem with the shipped version.

    Taras: There is definitely still a developer's edition. Check this page:

    tim: I don't think the 14000 tests we passed are completely irrelevant...

    Pierre: Let me guess, Mark told you this? Not true, if you're wondering.

    Just another engineer working on JRun, these answers don't reflect Macromedia's opinion, etc etc etc

  23. Greetings,

    Brian, does trial license covers developers needs? Can I develop Web Application(s) on trial version for unlimited time?

    Thanks in advance,

  24. Brian, you may wonder why Taras has to ask that question (and the original one as well). The comments rais an interesting point.

    The trial download page you offered (and I was about to before you did) doesn't really explain the availability of the developer edition or what it entails. Instead, it lists a drop-down of ALL the available editions on all OS's. One is more likely to select either the enterprise, advanced or pro editions (full copies with 30 day time limit but no user limit) rather than notice the availability of the developer edition (no time limit, 3 user limit) in that long list.

    The problem is that the site design seems to presume one has already visited the products page to know about the alternate editions. Perhaps if nothing else, the page could add a link to that page, if not also specifically indicate that the developer edition is available as a non-expiring, 3 user limit trial.

    The problem's exacerbated by the fact that choosing any of the editions on that page leads to a login/registration form, which not only might stop some people from proceeding but also doesn't indicate anything about the edition they've chosen (further reason why the previous page really needs a little more explanation).

    Even the product overview page ( doesn't describe the developer edition. Indeed, I looked all over for the info, which seems to have become hard to find in the macromedia site redesign. The only mention I could find was the FAQ (

    BTW, for those interested, the developer edition is a full enterprise edition (servlets, JSP, EJB, JMS, etc.) and the 3 user limit means that 3 ip addresses may hit the server as users--after that, any others get a message indicating that the server is running the limited dev edition. (The FAQ doesn't indicate this, saying it's for a single developer, but I recall reading this in the licensing, which I cannot now find anywhere.)

    Brian, if you could bring this to someone's attention there and have them look at the site from this perspective, I'm sure it would be great for everyone.

  25. Macromedia and JBoss[ Go to top ]

    Pierre: Let me guess, Mark told you this? Not true, if you're wondering.

    Are you so sure? Marc alluded to this on JBoss dev sometime back. He even claimed that a manager at Allaire had tried to offer him $10K in guilt money to license the parts they effectively ripped off.
  26. Hi'

    Brian: I think your trying to sidestep my statement by claiming that your not suring what I am referring to. To help you understand my statement I thus strongly recommend that you take a look at your support forums. To save you the time and trouble I have listed the relevant links regarding the JRun JDBC connection problems below (... and yes, I did post these issues to the Database connectvity forum) :

    I have never received an official Macromedia explanation regarding these issues and I am thus still waiting for the answers ... after all we did pay an awfull lot of money for our JRun v 3.1 server license!.

    Kind regards

  27. I feel like I opened a can of worms...

    charles, thanks for the comments, I'll send them to someone in the loop.

    Jorgen, I really wasn't trying to sidestep anything. Remember I'm just another engineer, and I've never worked on our jdbc pooling mechanism. I see from the posts that there is a solution, even if you don't enjoy it-- using the database's pooling mechanism. In any event, I asked around and found out that the next version will have new pooling code and that this problem is fixed in it.
  28. Hi,

    There were many inspirations for the re-design of JRun 4. These included our 3.x codebase, exchanges with individuals, and of course analysis of both commercial and open source products. Brilliant folks like Jonathan Wheedon, Cedric, Rickard, Mark Hapner, Richard Monson-Haefel, Martin Fowler, Floyd, and countless others in JSR expert groups, community lists and gatherings, here on TSS, and in private exchanges played a part, whether they know it or not. We also have very strong, tight team of internal dev and QA engineers for this release who proved at least as brilliant, even though names like Karl Moss, Edwin Smith, and the Reilly Brothers (Tom and Paul) won't be as well-recognized as the others I mentioned.

    As far as EJB is concerned our own 1.2-certified Ejipt server acquired from Valto was an influence, of course, but it is true that the EJB subsystem (along with much of the rest of the server, except for the classic servlet engine) was redesigned and contains only certain nuggets of Ejipt now. Most of the server -- from remote invocations to DTP to JMS to interoperability and CSIV2 to the web management console -- is new.

    I came to Allaire/Macromedia as a heavy Tengah/WebLogic user, and its behavior and use cases probably bore the heaviest influence on our EJB design. I also carry a VisiBroker background that likely surfaces in the design here and there. And we've followed the forums and lists of most other J2EE application servers at one time or another, including JBoss. While I personally have not used it or followed its lists in some time, I am sure that it remains a very strong server, and those folks deserve a public tip of the hat. I have great respect for the JBoss developers, and Rickard in particular has been an inspiration to me and I value our friendship. In hearing secondhand from Rickard about updates JBoss has made, it sounds like they've taken their JMX-based service infrastructure to a whole new level, and their original version influenced so many product designs. Certification or lack of it doesn't take away from such great features, so cheers to them. Earnestly, I continue to wish JBoss the very best.

    I once suffered through a PR training course in which I was told never to mention competing products in public. I suppose I'm not very competitive: In addition to WebLogic and JBoss, at one time or another I've followed Orion, Borland AppServer, WebSphere, HP/Bluestone, we've spoken to some smart folks at Pramati, I participated on the Jonas lists for a while, etc. I think engineers often filch the better ideas of their peers -- that is, if they respect those peers at all -- in the hope and sheer enjoyment of creating clean-room implementations of those ideas that might be "better." I'm not privy to business dealings, so I'm (sometimes frustratingly) not in the know about any potential partnerships or other dealings with these folks; I'm speaking about them only from an engineering perspective.

    And open source projects were definitely an influence, no doubt about it. Again, I'm not involved in the business side of the product, but it's my understanding that our J2EE licensing agreement allows usage of Apache/BSD-style products. So we've tapped XDoclet, and allowed folks to use it as a JRun service integrated with our deployment services. Our web services engineers are leaders in the Axis (formerly known as Apache SOAP) project. I even beefed up and streamlined my own object pooling/caching open source product (called PoolMan) to create JRun's pooled/XA JDBC mechanism to wrap our embedded Merant drivers. This completely replaces the pooling mechanism in 3.x, which was the source of at least one reader's complaint in this thread.

    But as EJB and other elements of J2EE become commodities, all the territorial or competitive dialogue -- even of the generic commercial vs. open source kind -- becomes largely irrelevant. I enjoyed pulling in JINI for object clustering, I appreciate that our design is primed for eventual evolution to an AOP structure, and technical tidbits like our ability to hot deploy apps written for other servers is nice. Since I now work on a Flash product, I'm fond of our ability to pass EJBs, MBeans, and Serializable Java objects both by value and by reference to Flash movies. But what's much more important than the actual commoditized technology is how all of this can be linked to development methodologies, pattern languages, tools, and other critical technologies such as web services -- how all of this can be used to state and resolve real problems. I'm in favor of using the best tool that can support this in a given scenario, even if it proves not to be JRun.

    I should also note that I am no longer a JRun architect, as I have moved on to design our Flash-to-J2EE/ColdFusion/.NET offering. So not only do my opinions not necessarily reflect those of my company, but they may not reflect those of current JRunners like Brian -- and by the way, since Brian opened the door for this, feel free to send him any JRun beta bugs directly. ;-)

    Patrick Sean Neville
  29. Brian: I am sorry if you feel that I was picking on you it was certainly not my intension.

    However I also have to admit that it has been rather frustrating dealing with the Macormedia support team some of the solutions they did come up with are according to my opinion not serious - I mean booting the database and app. server every 4'th hour or so cannot be accepted as a plausible solution when deploying to stable production environment.

    The last mail I received from the support team stated that the forth comming version of the JRun server is expected to implement some machanism to ensure that any JDBC connection returned from the app. server to en EJB is validated BEFORE the connection is handed over to the EJB thereby solving my problems. However I have not yet received any conformation regarding the implementation of this mechanim in the new release of JRun so I am left pretty much in the dark on this matter.

    Kind regards

  30. Hi Jorgen, don't worry, I didn't feel picked on. I'm not an expert in this area, but I still think the solution is to turn off JRun's database pooling for the datasource and use the driver's pooling mechanism. Since there is a viable workaround, I would guess that's the reason that this issue wasn't raised to engineering. Sean also mentions above that your problem is fixed in JRun 4. Best, Brian
  31. Dear All,

    I could not able to login with my macromedia user id and password. Even, Im not able to register also in the Beta Site. Can u tell me where can I register else or how can I get JRun 4 to try.

    gives Error.

    Almost all the corporates have started using Flash in their sites and applications over web. Even, it downloads faster and not having any probs like Applet. Def Flash can become as the Front End for Web in near future. Also, almost all browsers invariably in all platforms are having Flash plugin installed. But, Macromedia should make Flash as a RAD Tool for Web. If this happens, Web Applications also will have a Front End.

  32. Hi Sanakar,

    Try the following link:

    The new JRun 4 looks really promising!