TheServerSide @ JavaOne 2003 - Day 1 Coverage

Discussions

News: TheServerSide @ JavaOne 2003 - Day 1 Coverage

  1. TheServerSide @ JavaOne 2003 - Day 1 Coverage (34 messages)

    Day 1 coverage of JavaOne 2003 gives an analytical synopsis of the general and technical keynotes and what to expect this year. Some of the sessions covered are JSF, 'An Objective Comparison of J2EE and .NET', and a J2EE Expert Panel consisting of Mark Hapner, Bill Shannon, and Linda DeMichiel. The highly anticipated Borland Party was also attended.

    Read TheServerSide @ JavaOne 2003 - Day 1 Coverage

    Threaded Messages (34)

  2. OUTSTANDING coverage!

    I did not get this much out of JavaOne when I was there.

    .V
  3. Very helpful. Thanks, guys!
  4. JCache dead ?[ Go to top ]

    The note about JCache being "basically dead" is worrisome. Can anybody shed more light on this?

    - Ghanshyam
  5. JCache dead ?[ Go to top ]

    JCache spec was (very) limited functionally. So, it’s good that it’s gone (or at least it seems so). From the other side, I still would like to see some standardization in this area, but rather evolutionary rather than ad-hoc.

    Regards,
    Nikita Ivanov.
    Fitech Labs., Inc.
  6. JCache dead ?[ Go to top ]

    Nikita: JCache spec was (very) limited functionally. So, it’s good that it’s gone (or at least it seems so). From the other side, I still would like to see some standardization in this area, but rather evolutionary rather than ad-hoc.

    You have never seen the spec, although that is not your fault, since it cannot be seen outside of the expert group until it's probably too late to make significant contributions. I have lamented this topic before, so I will not harp on it again ... the JCP is improving bit by bit.

    Regarding complexity: Software APIs should be as complex as they need to be, and no more. For caching, developers have successfully used java.util.Hashtable since JDK 1.0 to cache, and I can't see why anyone would make the API much more complex than that. Just my $.02 ... and that of the expert group as well.

    The JCache expert group is still active. There were close to twenty emails on the mailing list in the first week of June, for example. I assume that the rumor of JCache being dead is referring not to the JSR, but instead to one of the other companies that sells a "JCache product". Just to clarify, that particular company is not actually dead, just smaller than they used to be.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  7. JCache[ Go to top ]

    I don't want to divert away from the main topic, but what is the reason for the slowness? One would think that the expert group members would be anxious to finalize the spec and get it out, especially commercial vendors. I know that you would like the spec to come out asap but I am curious as to why others in the expert group aren't in a hurry. I suspect there would the usual bickering but there seems to be more to it, considering that it's one of the slowest.

    - Ghanshyam
  8. JCache[ Go to top ]

    ...what is the reason for the slowness? One would think that the expert group members would be anxious to finalize the spec and get it out, especially commercial vendors.

    Perhaps the purpose of the JCP is to prevent the emergence of standards and allow the member vendors' proprietary hacks prolonged glory. What do the leading vendors gain by divulging innovative proprietary interfaces with lagging vendors?
  9. JCache[ Go to top ]

    Brian: Perhaps the purpose of the JCP is to prevent the emergence of standards and allow the member vendors' proprietary hacks prolonged glory. What do the leading vendors gain by divulging innovative proprietary interfaces with lagging vendors?

    Ouch, that hurts. No, I think there are far simpler reasons that would explain the phenomenon. For example, people being busy, changing jobs, writing software ... to be honest, the JCache JSR has *very little* disagreement in it ... there's only one item that we haven't been able to agree on so far (ask anyone on the JSR about "Object args" in the loader ;-) and even on that topic the conversation is very civil and respectful.

    Regarding vendors that sell JCache products, the "leading vendors" are definitely high on the contribution list for the JSR; of that I am certain.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  10. JCache dead ?[ Go to top ]

    JCache is heavily based on OCS4J which is publicly available. As far as java.util.Hashtable, I am always referring to what Einstein used to say “The theory should be as simply as possible, but not simpler.”...

    Regards,
    Nikita Ivanov.
    Fitech Labs., Inc.
  11. JCache dead ?[ Go to top ]

    Nikita: JCache is heavily based on OCS4J ...

    I cannot begin to convince you of something you cannot see, nor shall I try.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  12. JCache dead ?[ Go to top ]

    Well, if JCache has deviated significantly from OCS4J then I think the whole business of being "JCache compliant" is bogus at best and commercially misleading. Everybody who’s not on the JSR assumes that JCache means to the most degree what is written in OCS4J, at least as far as design direction.

    So, what does this mean to be JCache compliant (Coherence, SpiritCache) if nobody has seen the spec and cannot even verify it, at least design-wise? Having java.util.Map interface?.. :-)

    Thanks!
    Nikita Ivanov.
    Fitech Labs., Inc.
  13. JCache dead ?[ Go to top ]

    Nikita,

    You are absolutely correct, and it sucks, and I'm sorry. Honestly. I have lamented this before. It isn't fair to anyone who fails to get on the JSR expert group, which I was *lucky* to get onto (not that it is an exclusive club or something).

    Trust me, I am not defending this process. I did not publicly rail against it until after I was on the JSR, to avoid being a hypocrite (complaining only because I was *not* on it.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  14. JCache dead ?[ Go to top ]

    Nikita,

    >
    > You are absolutely correct, and it sucks, and I'm sorry. Honestly. I have lamented this before. It isn't fair to anyone who fails to get on the JSR expert group, which I was *lucky* to get onto (not that it is an exclusive club or something).
    >
    > Trust me, I am not defending this process. I did not publicly rail against it until after I was on the JSR, to avoid being a hypocrite (complaining only because I was *not* on it.)
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Easily share live data across a cluster!

    Sad to say it, but the only JCache related session or BOF I have seen was Oracles today, and the best part of that whas the Tangosol whitepaper that you handed out before it...
  15. JCache dead ?[ Go to top ]

    Nikita,

    For my public thoughts on the matter, see http://www.freeroller.net/page/cpurdy/20021010.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  16. JCache[ Go to top ]

    The note about JCache being "basically dead" is worrisome. Can anybody shed more light on this?

    The news of JCache's death are greatly exaggerated. I asked Cameron earlier today and he confirmed the specification still seemed to be alive (although from his own admission, half of the emails are from him).

    It is definitely the slowest JSR ever, though... two years in the making and not even in community review. Shame.

    --
    Cedric
    http://beust.com/weblog
  17. Un blog en francais javaOne2003[ Go to top ]

    Un blog en francais javaOne2003_fr_FR
    http://blogs.application-servers.com/blogs/page/doj&mag
  18. In practice, though, I'm not so sure if the vendors actually do always step up to the plate. Sometimes they do, but sometimes Sun actually has to push customer requests down the vendor's throats by actually baking the requests into the next version of the spec. It certainly makes for interesting drama, but slows innovation in the platform.


    Vendors don't know their own customer requests better than Sun, and Sun has to push customer requests down their throats? Even though the vendors make money on software and Sun has not been able to do so in a big way as far as investors can tell, Sun knows vendors' customers better than they do? Vendors don't fight and argue to get fixes and changes into specs over time and instead only Sun bakes the good stuff into the specs? Vendors slow down innovation instead of Sun?

    Put down the Sun koolaid, TSS reviewers. From what we hear in delivery, vendors fight for what their customers really want and need and must suffer through Sun's overbearing academic assertions about what systems technology needs instead [as opposed to what customers need] as well as Sun's control of the JCP in order to get it into their products.

    Ease of use for systems programmers is not the same as ease of use for the masses. Simplifying complexity is a lot harder than growing simplicity to achieve complexity. Hiding complexity behind tools is not the same as providing elegance and ease of use in the app model in the first place. Anyone who believes that Sun can execute on bringing systems complexity downstream to the masses and that vendors with proven economic successes in that sector need Sun to push this down their throats is just mad. They're the same folks who think the licensing on java.net open source projects won't be some mutated form of the scsl instead of a true open source license. Sun is good at a lot of things and has been good to all of us one way or another but please don't drink the entire barrel of koolaid, eh?
  19. JAX-RPC, JAXM[ Go to top ]

    "we basically heard (if you read a little between the lines) that:
     JAXM is basically dead, and JAX-RPC is the now, the future, and noone
     cares about JAXM [...]"


    Can you elaborate? JAXM is dead?

    Sun is advocating JAX-RPC over JAXM?
  20. BoF Session: Ask the J2EE Experts[ Go to top ]

    I went to this session and left after 10 mins due to the poor quality of questions. Also had the same experience at another BOF that night when someone asked if the speaker thought Struts was a stable enough framework to use. I felt I should have stayed in the java.net launch discussion as at least they had beer.

    In general I have been pretty dissapointed so far with the quality of the Sessions and especially the BOFs. The BOFs IMHO always used to be the best part of Java One and this year they seem to have had little effort put in to them.

    On a social note I went to the Compuware dinner at the W Hotel tonight. Panel discussion was ok and the Middleware company was there. Apparently they had done some project work for Compuware into Model Driven Architecture.

    David
  21. Objective comparison?[ Go to top ]

    'An Objective Comparison of J2EE and .NET'?
    No offense, but I dont think there is a person alive in this world who would be capable of that.. :)
    Everyone will have their preferences, and even if the criteria would be "fair", what preferences set the criteria?

    Ok, now on to reading the actual article (havent done that) and see what they came up with..
  22. Many thanks for the excellent coverage.

    Reading it I’m more and more convinced that .NET is rather good news for Java – it really seems to have given Sun a much needed kick in the backside. As well as the enhancements to the language I’m really pleased to see the Sun is finally starting to put its own marketing muscle behind Java through both java.com and java.net and also through deals with other hardware companies - Dell and HP agreeing to ship Sun’s JVM on their hardware rather than the MS JVM from the last centaury is great (and rather surprising).
  23. The kick in the backside was/is much needed. There are still holdouts, though.
    For example,

    "He believes that the manifesto that we J2EE developers have is:

    We believe in choice
    We believe in heterogenous systems
    We believe in competition
    We believe in open standards
    We believe in platform neutrality
    We believe in community process
    "

    Is not .NET a choice? Wouldn't the non-existence of .NET mean less choice?
    Same thing for competition.

    "If you have to compare, compare the entire stack: Hardware -> OS -> App Server -> Component Stack. This shows that if you buy in to Microsoft you have no options."

    Can you not put J2EE on MS OSs? PHP? CGI? ?????

    I think he means to be specific about .NET but it's typical of Java luddites to
    misuse open-ness, competition, lock-in, choice, etc.
  24. It's a Mirage[ Go to top ]

    Microsoft .NET is not a choice, it is rather a mirage of "choice". It attracks you towards a quicksand!
  25. .NET is a choice[ Go to top ]

    .NET is a choice in much the same way suicide is a choice. It's very likely it's the last one you'll ever make.
  26. First please be careful who you call a Luddite on these threads, I was the presenter for the J2EE vs .NET session and this session was by no means delivered from a Luddite perspective, and believe me I am one of the most pragmatic guys around. Honest ;-)

    When carefully considering how to structure and author this session I spoke to a number of typical JavaOne attendees and clearly asked them what do you need in this space?

    Do you want a low level API comparison or a detailed feature function comparison of say ASP vs JSP and the overwhelming response was NO - we've got that stuff.

    The request that came through to me loud and clear was that Java developers today are finding their management agressively targetted by MS salespeople and they wanted to know how to defend themselves. MS has a very effective pricing model when they initially sell .NET into organisations and Java developers are finding their senior management overriding their technical perspective based around short term license costs without regard to broader long term technology platform issues and longer term cost of ownership over time.

    The goal of this session was to provide those Java developers with the belief that they can beat the MS Salesguys and that they can clearly articulate the case for J2EE vs .NET in an "Objective" way to their management. It was a toolkit and I had many people tell me that this presentation was precisely what they needed to engage their management as to why they should not go .NET.

    I firmly believe that an open and fair discussion of these technologies is vital and that the Java Developers in the organisations out there targetted by Microsoft should be able to defend themselves and clearly describe why not to go .NET

    That's pretty "Objective" to me.
  27. Embrace, not defend against[ Go to top ]

    .NET is a good news to Java programmers, because it opens them doors into new job markets.
  28. .NET is not a job opportunity[ Go to top ]

    Anybody can retrain to a new technology and look for jobs in that area. The key issue to consider when hiring individuals is actually the depth of experience and the skills of real implementations that the particular individual has evolved over time.

    This is where .NET is genuinely an issue for Java Professionals, threatened with migration. Who in their right mind would wish to go from architecting a mature if complex platform using proven design patterns and toolsets / frameworks, to retrain to .NET to then have to rebuild their experience and go through the pain of climbing that new hill using a technology that singularly lacks best practises, frameworks, design patterns or even a diversity of tools to cover the whole lifecycle. Yes J2EE can be complex but .NET is overly simplified and lacking in diversity of platform, technique and tooling.

    The Java developer lives in an extremely priviledged world, if a toolset, design approach,O-R mapping technique, testing platform etc etc. doesn't work for them for whatever reason then they have a wide set of choices commercial or open source to make to find the tools and techniques that will deliver for their circumstances. .NET just doesn't provide this diversity, with .NET the best you get is a damn good tool for building ASPx and there the story ends, even then VS.NET doesn't stand up to scrutiny against say a combination of Dreamweaver and one of the leading IDEs (JDeveloper, JBuilder, TogetherCC etc..). As other vendors begin to deliver .NET tools and challenge the dominance that Microsoft has in this area it will be extremely interesting to watch if Redmond will grasp this nettle and become enlightened and willing to let go of some of the stranglehold they currently have on the .NET platform. This is their only way to genuine success.

    The best strategy Microsoft could possibly adopt with .NET would be to make its interfaces open, accurately documented and provide a guarantee of backwards compatibility. Until they do this it seems unlikely that the strength and diversity of ideas / products will build on .NET and the community will remain primarily a weak departmental community rather than a genuine body of professional software developers architecting genuine solutions.
  29. At first glance, Rave looked like Microsoft Visual Studio. Then it behaved like Visual Studio - the live demo crashed :-)

    Seriously, (evaluation based on the demo) it is probably a good start. I am not sure how it will be useful for writing complex applications. The SAP presenter (Agassi) hinted that Rave would not work well with SAP since SAP has a complex datastructure with many hundred tables and complex relationships.

    Hope it does not produce ASP like spaghetti code.
  30. And what do you think about Project Rave ?

    Dmitry Namiot
    Coldbeans
  31. What I think about Rave[ Go to top ]

    I watched the demonstration of Rave. I am impressed with it. Rave looks very much to me like Visual Studio.NET. It lets you graphically lay-out a browser-based application, manage connections to various datasources on the backend, reuse drop-in server-side code libraries, and handle fonts and colors through style pages. It makes a very sexy demo. Rave should be out in beta form later this year with a final sometime next year according to the product manager I spoke with.

    I wonder at what cost Rave will be to Sun's efforts to work on other parts of Java. Every Sun employee, contractor and vendor I speak to begins coversations with "It's insane how much our budgets have been cut back..." That being the case, is Rave moving resources off other projects? Sun is partnering with Borland, Oracle, BEA or IBM to deliver JavaServer Faces in their IDE products. So why does Sun need to create its own "reference implementation" of JSF?

    -Frank Cohen
    http://www.PushToTest.com
    TestMaker 4.0 tests Web-enabled applications for scalability and performance.
  32. great coverage. Thanks a lot.
  33. It's the BYTE-CODES stupid![ Go to top ]

    I'm bugged by the lack of support for Jython at Sun. To thier credit at JavaOne, Sun did mention Jython when talking about JSR-223 (Java support for Scripting Languages) and scheduled a birds-of-a-feather session here at JavaOne. However, Jython was slighted too: The BOF started at 11:20 pm, and Tim O'Reilly messed up and said Jython is a good combination of Pearl and Java. He meant to say Python and Java.<br><br>

    Sun seems to be missing-the-boat on what Jython really brings to Java: IT'S THE BYTE-CODES STUPID! Jython compiles into Java byte-codes and runs natively on the Java VM. To a Java developer that means full access to all of Python's objects and also to all of Java's objects. Sun should throw away JSR-223 and start again. They should start by writing a specification that lets all scripting languages compile to Java byte-codes. That would be progress.<br><br>

    Jim Hines of MIT pointed me to a list of languages that compile into Java Byte-Codes. It's an eye-opener how many exist:<br><br>

    http://www.robert-tolksdorf.de/vmlanguages.html<br><br>

    -Frank
  34. Trifork offers JDO highlight[ Go to top ]

    I was looking for information on JDO at JavaOne. There just didn't seem to be a whole lot on JDO. My interest was peaked after I started a consulting project for Trifork.

    Trifork makes a Sun certified J2EE application server that is meant to be integrated with your application. At JavaOne I got to meet a bunch of the Trifork people. They impress me as the little company that "can do." Also, the team knowledge is great. For example, Lars Bak (inventor of HotSpot) is on the team.

    At Javaone Trifork released the Trifork Application Server 3.3 and started offering a JDO engine in partnership with POET.

    -Frank Cohen, PushToTest
  35. Thanks for the Coverage[ Go to top ]

    I missed this year's Java One because of budget constraints with my organization. Thanks for bringing out such a nice coverage.

    Shital