Discussions

News: Article: TheServerSide's JavaOne Day 2 Coverage

  1. During the BEA keynote, Bill Roth highlighted WebLogic Server support for EJB 3, plans to incorporate openJPA (JSR 220) in WLS and demonstrated BEA Workshop support for Beehive, Spring, Struts and Tomcat. Other day 2 coverage includes Thomas Kurian's keynote outlining Oracle's vision around SOA 2.0, and native support for XML in Java.
    Roth told developers that BEA is highly involved with several open source projects. For instance, Roth expects BEA to incorporate an OpenJPA (JSR 220) based on Kodo 4.0 in BEA technology. OpenJPA is in the Apache Incubator now. Roth told developers that WebLogic Server support for EJB 3 delivers session beans, message-driven beans, resource Injection via Spring (JSR 250) collaboration using Kodo as a persistence provider. BEA is working with Interface21 to deliver Java annotations (JSR 225) to WebLogic Server. He also told developers to expect this code in Spring next week. He went on to describe BEA's strategy of blended technology: commercial, open-source, and standards-based. He demonstrated how the new BEA Workshop blends Beehive, Spring, Struts, WLS, and Tomcat. On the subject of other languages, Roth pointed to JavaScript, PHP, Ruby, and Groovy. BEA is looking at a multi-language future. To back this up Roth did a demonstration that blended application development, EJB 3 and OpenJPA, and multi-language support by showing the new AppXRay utility to analyze the JSPs and configuration files to show code dependencies. AppXRay shows a visual map of dependency relationships between a Web page, JavaScript and Java classes. Roth demonstrated EJB 3 functions in BEA Workshop by exploring a relational database schema and mapping it into EJBs. He clicked on a schema and AppXRay built the EJBs to provide a Web interface. This is similar to Ruby On Rails but much more visual with lots of extra options. With the new visual tools, developers don't lose any code-level access. The new EJB 3 Persistence Entities Editor shows relational schema in design mode and Java source in edit mode.
    Get the full coverage and be sure to keep checking back for more JavaOne coverage.
  2. Native support for XML in Java[ Go to top ]

    This is an extremely *bad* idea, where do we vote against this?
  3. Re: Native support for XML in Java[ Go to top ]

    Totally agree, utter madness! There are so many better things they could spend their time on, what's the point? Interoperability? With what? Everything worth communicating with is already Java, leave MS to their own devices, let them implement native support for JRMP, IIOP or AMQP, much more useful. -John- CTO C24
  4. Here's my thinking on why native XML support is a good thing... I've been doing Web Service and SOA performance testing for a while now and one of the big problems I see is a lack of focus on XML itself. There are so many choices (JAXB, DOM, JDOM, etc) that answering a question like "How do I build well performing and scalable XML-based Java software?" gets an "It depends" answer. At least if there was a single way to compose XML that would create some focus so we could test-and-improve Java's XML capabilities. Please elaborate on native XML support being bad? -Frank
  5. It's not bad - it's just unnecessary bloat in general purpose language like Java. IMO. It *could* potentially be helpful in *some* *specific* cases, but it just doesn't mandates inclusion this feature into language itself. Look, if one introduce 'native' support for XML, why not to introduce native support for, let's say, embedded SQL? Frankly, in most projects I deal more with SQL than with XML (in code), so why not something like this: "select foo from bar".foreach( String foo ) { System.out.printf( foo ); } What about support for native regexps like in Perl? String foo = "134"; if ( foo =~ /[\d]+/ ) { ... } Maybe more syntactic sugar in regard of Collections? HashMap bar = [ "A" => 1, "B" => 2 ]; Great ideas, aren't they? Frankly, they aren't really. Look at Perl - it's most bloated language ever, just because it implements all those things. If something can be implemented in the language easy I'm against including it into language spec. Let's keep the language simple as possible, and let's keep standard library rich as possible. It's java way and, hope, will be in the future. Artur
  6. Thanks Artur for explaining it to me. I appreciate you explaining it to me. I look at the need for native XML from a performance and scalability perspective. Most of the XML, Web Service, and SOA tests I've conducted over the past few years have shown really poor throughput when a Java-based service tries to deal with large XML messages (100K+) and complex schemas (25+ levels of nested elements.) On a dual cpu 3 Ghz server i've seen 1.5 - 2 transactions per second. A lot of the slowness comes from transforming XML into pojos. I've seen java.lang.String performance get better over the years - especially through HotSpot improvements - and I'm expecting the same to be true of java.lang.xml after it eventually comes out. It seems to me that Mark's work on native XML is an acknolwedgement that an object-to-xml binding mechanism has not emerged. SQL has its Hibernate and others. XML has too many binding mechanisms to choose from and nonen of them the clear winner. -Frank Cohen http;//www.xquerynow.com http://www.pushtotest.com
  7. A lot of the slowness comes from transforming XML into pojos.
    What a news !! Marshal/unmarshal has always been the biggest (performance) pb in distributed computing. (Well, it was htons & ntohs too). A lot of problems come from this ridiculous "feature" of having IPC messages being human (un)readable. What big step ahead is XML adoption for IPC ? Just to follow some smart technicians crying "I want MY ipc standard, I want MY ipc standard" (having failed with DCOM) ? There have already been really dangerous "improvements" that are creating huge damages: annotations being used for runtime configuration purposes and generics being used to create unreadable code. Let's add native XML and we can throw Java in the trash can. Guido
  8. Dolphin will be improving the ability to integrate scripting languages to run on the JVM. Groovy has much better capability for doing language level XML via its markup language feature - and other niceties like easier to use regular expressions (which still rely on the Java class library regular expression classes under neath the improved syntax). I'd suggest, therefore, having enhancements for XML reside in the scripting languages and leave the core Java language untouched. The integration capability between Groovy and Java is so seamless that there really wouldn't be any impedence mismatch issues by taking this approach. Well, I know because I've already started doing some of my XML markup in this fashion.