A Tale of Four JVMs and One App Server

Discussions

News: A Tale of Four JVMs and One App Server

  1. A Tale of Four JVMs and One App Server (14 messages)

    A user has recently reported in the JBoss issue tracker that JBoss AS 5.0.0 GA fails to start on the IBM JRE. One may say: So what? Didn't you hear that the IBM JRE "fits better" for another app server? Independently, our QA team has encountered the same problem when testing JBoss 5.0 on a new version of Excelsior JET JVM. A quick check confirmed that the problem manifests itself on Oracle JRockit as well. At the same time, on the Sun JRE everything worked like a charm... Continued in this Excelsior's blog post
  2. We see that kind of behavior quite often. Luckily less an less in production grade code, but e.g. Spring test suite will fail on any other JVM, but Sun. Generally it would have been much better if Java API wouldn't return those members sorted to begin with. And as is pointed out in the blog, this order can change at any moment even on Sub JVM leaving you with extremely weird bugs to track. Jevgeni Kabanov http://www.zeroturnaround.com/
  3. We see that kind of behavior quite often. Luckily less an less in production grade code, but e.g. Spring test suite will fail on any other JVM, but Sun. Generally it would have been much better if Java API wouldn't return those members sorted to begin with.
    The output should be randomized just in case someone doesn't bother to read the documentation? That's just silly. The Sun engineer went out of his/her way to specifically point out that the output was not sorted. It's ridiculous to ask for more than that. This kind of apparent sorting happens all the time. Hash tables often appear to return things in a stable order until something new is added. The JBoss devs (and I think you are saying Spring too) didn't RTFM. That's not Sun's problem.
  4. Is it news? Not if you've not run into the problem before. I first found out about it from the JRockit team; it was interesting if not earth-shatteringly important at the time, but the real value is that I knew about it. Now, if I am ever reflecting through a set of methods, I know to be really careful about matching arguments - I might not have known before, but I darn sure do now. (Hopefully I would have done the right thing anyway, but who knows?) I think it's worth pointing out.
  5. Is it news? Not if you've not run into the problem before. I first found out about it from the JRockit team; it was interesting if not earth-shatteringly important at the time, but the real value is that I knew about it.

    Now, if I am ever reflecting through a set of methods, I know to be really careful about matching arguments - I might not have known before, but I darn sure do now. (Hopefully I would have done the right thing anyway, but who knows?)

    I think it's worth pointing out.
    I don't think you got my point. Bluntly, if a developer have been professionally employed in that capacity for more than a year (I'm being generous here) and he/she doesn't already know that he/she (in general) should not depend on things that are not part of an API's contract or a specification or whatever, then there's a problem and it's that developer. I'm not saying that if you ever get caught by this, you are a bad developer. Everyone is going to make this mistake at one point or another, or at least be hurt by someone else doing it. What I don't understand is the idea that this is some great revelation. What do we think the API documentation is for, exactly, if not to tell us what we can depend on? What's interesting news is that JBoss is apparently no JVM independent. That actually useful bit of information is obscured by ruminations on what the documentation of API is for.
  6. James, I understand your point, but IMO you need to grade on a curve. Lots of developers read things into an API's contract, even when they shouldn't; it doesn't make them "bad developers" but simply "busy developers" in a lot of cases.
  7. James, I understand your point, but IMO you need to grade on a curve. Lots of developers read things into an API's contract, even when they shouldn't; it doesn't make them "bad developers" but simply "busy developers" in a lot of cases.
    But in this case, the API actually says that you can't rely on the order. The author went above and beyond in this case to point out what wasn't supported. And again, please don't misunderstand. Everyone will make this kind of mistake. I know I have. But the difference is that when I make this mistake, I don't blame Sun for me not bothering to read their documentation or write a blog suggesting that I've discovered fire because I realized that it's important to read the spec and not just rely on observed behavior. Maybe it's just because we are in the age of twitter twits and I'm a curmudgeon but I don't understand why everyone thinks other people care about when they blow their nose.
  8. This one was to damn funny:
    The output should be randomized just in case someone doesn't bother to read the documentation? That's just silly.
    I've introduced some silly bugs too but I wouldn't blame anyone saying Set classes are broken and don’t actually contain unique items because I used mutable objects as set elements.
  9. The lesson learned: Java applications may not rely on JVM features that are not enforced by the Java specification.
    It's not safe to depend on behaviors that are not specified as part of the API. In this case the application is depending on something that is specifically listed as not part of the contract. How is this news? Were you under the impression that it's OK to depend on undocumented behaviors prior to this?
  10. Agreed It's an easy trap to fall in to, depending on JVM specific behavior. You need to explicitly test on different JVMs to make sure the code is really portable OR know what the spec doesn't say is as important as what it does say. Billy Video podcasts on IBM WebSphere eXtreme Scale
  11. While Java is good at insulating developers from portability concerns - it's not perfect and likely never will be. This is why certifying against multiple JVMs (on multiple OSes) continues to be essential; and like all other vendors is precisely what Red Hat does for its subscription platforms. eg. currently certified platforms for JBoss EAP 4.3 : http://tinyurl.com/cm75k8 to save you having to read the JIRA - this was a known issue and has already been fixed in the JBoss AS 5.0.1 and AS 5.1.0 branches Rich Sharples JBoss, a division of Red Hat http://blog.softwhere.org
  12. Rich, Thank you for resolving the issue so quickly. Now we can avoid downgrading our test suite. ;) From the resolution comments I see that it was an issue escaped QA not the neglecting of the Java spec. In general, the article is not about an issue in JBoss. It’s about the importance of complying with the (standard) specifications. There is an (owful) phenomenon in the industry concerning “emulation of old bugs just to let the existing applications work”. We are still a long way from removing that bad practice from the software platforms but I hoped to make a decent contribution to it by warning the people who might be unaware of those issues. Vitaly Mikheev Excelsior Java Team http://www.excelsior-usa.com/jet.html
  13. There is an (owful) phenomenon in the industry concerning “emulation of old bugs just to let the existing applications work”. We are still a long way from removing that bad practice from the software platforms but I hoped to make a decent contribution to it by warning the people who might be unaware of those issues.
    I commend your intentions but the real problem here is that this industry lacks an apprenticeship and mentoring culture. Developers graduate from college (or not) and start hacking away without any guidance. You are pointing out something that is extremely well known by experienced developers. I guarantee you that many many people have made this observation over the history of software. As to the practice of emulating old bugs, the problem of explicit vs. assumed contracts is not a new issue. It's something that people have been trying to solve for decades. You might as well point out that cancer makes people sick.
  14. I commend your intentions but the real problem here is that this industry lacks an apprenticeship and mentoring culture. Developers graduate from college (or not) and start hacking away without any guidance.
    Exactly. That’s why we hire exclusively through internship thus providing enough level of guidance. It involves extra costs but it pays back.
    You are pointing out something that is extremely well known by experienced developers. I guarantee you that many many people have made this observation over the history of software.
    No doubts. However not all developers are experienced as you mentioned.
    As to the practice of emulating old bugs, the problem of explicit vs. assumed contracts is not a new issue. It's something that people have been trying to solve for decades.
    Sure. I’ve been keeping an eye on using formal methods in the software industry since 1995 or so. I must say there is good progress in it but such techniques are still too expensive to be widely adopted . Not to mention that the (not graduated) developers will unlikely be able to use them.
    You might as well point out that cancer makes people sick.
    Both deceases will be eventually cured, I believe. Vitaly Mikheev Excelsior Java Team http://www.excelsior-usa.com/jet.html
  15. Isn't it obvious?[ Go to top ]

    The method order being relied upon is the order of declaration. Even if the API promised this to be the consistent sort order, most (hopefully all) of us here would agree that relying on that would be a mistake. Would you really want your code to break when someone reordered the constructors in the original source code? :) Better than worrying over someone not reading every detail of the API documentation (who does?) when using the method, just follow a simple rule: - Any method that returns a list should be assumed to return it unsorted, unless explicitly guaranteed otherwise. 9 times out of 10 these methods don't sort, as the caller rarely wants a sorted result anyway (thus it would just be wasted CPU cycles). Nice article... its nice to remember that most "incompatibilities" between VMs are just the result of extremely brittle code.