Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Possible native XML support in Dolphin (Java 7)
URL: Michael Levin's Blog
At 6:31 PM on Jan 11, 2006, Riyad Kalla
wrote:
Fresh Jobs for Developers Post a job opportunity
I know .NET put together implementation groups to do this back in '02 for .NET, I don't know if it eventually made it in but there were interesting discussions about what it would mean for the language. I'm curious exactly what native support would mean more than what is already there (shipping the XML parsing libraries as part of the JDK). Would we get a new datatype and XPath expressions would become natively supported?
Maybe that's way off, what do you all think?
20 replies so far (
Post your own)
Re: Possible native XML support in Dolphin (Java 7)
If you by "native support" you mean sort of "embedding" XML into Java, then I think, simply, Bad. Really bad. Not quite Armageddon Bad, but Pretty Darn Bad.There's syntax sugar, and then there's this -- chocolate frosted syntax sugar with cherry sauce.
I mean, E4X, XML in Javascript is pretty cool, so y'all will think I'm being a hypocrit saying "Neeto" for Javascript and "Humbug" for Java.
The Javascript object model easily supports this kind of thing. Modulo the actual embedding of the XML in the source code (vs say parsing it from a source string), everything you see in E4X is simply Javascript.
But Java's object model isn't like that, at least not yet. We can't easily proxy arbitrary Classes in the Java language (we can Interfaces, but not Classes). Nor can we create dynamic Classes out of thin air in Java.
So, basically, I don't want the embedded XML "expressions" to be any different from any other normal everyday Java expression. And if XML can "create classes on the fly" so that I can reference:
<this><that><other>2</other></that></this>
like:
String s = this.that.other.text
Then I want to be able to do that on the fly with my own code as well.
Hell, you may as well throw in closures and dynamic compilation while your at it (without direct bytecode manipulation, of course). Since we're redefining Java from the ground up for XML support, throw in Scheme/Dylan syntax-rules style template macros as well.
Simply put, I don't want XML to be any different than any other Java object, and I don't feel that being able to do:
to be particularly valuable over simply:
org.w3c.dom.Document d = ContrivedDocumentFactory.docFromString("<this><that><other>2</other></that></this>");Going down this path makes Java too "4GL"ish, where the syntax is being done for "competetive" reasons rather than idiomatic or dogmatic "language" reasons. "Java! Now with more Cowbell!"
So, humbug.
Now pardon me while I dress for my 40th anniversary "School of Programming Grognards" reunion where I'm up for the "Paper Tape Curmudgeon of the Year" award.
Re: Possible native XML support in Dolphin (Java 7)
I liked your post Will, and while I am usually for more cowbell in any situation, even ones that don't need it, I do agree that to get really nice transparent support it would be core changes to the language that may either open the flood gates to changes, or just look weird as hell in the one case (XML) that they are supported.I'm still not clear what is intended by the JDK team by this... would be interesting to find out.
Re: Possible native XML support in Dolphin (Java 7)
Conventional XML parsing (SAX, XPP, StAX, ...) in Java is way slower than with C/C++/C# (about 3x). Thanks to the cost of the numerous String objects which have to be allocated (and gc); millions of them when parsing a large documents. To avoid this waste you basically have two choices:1 - Go native.
2 - Use non-standard API avoiding String creations such as Javolution SAX2-Like or XPP-Like parsers (as fast as C/C++/C# parsers and consequently 3-5x faster than standard Java parsers).
It seems that Sun prefer the solution 1, whereas the solution 2 would have been simpler...
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Possible native XML support in Dolphin (Java 7)
Well said ....Re: Possible native XML support in Dolphin (Java 7)
I agree with the previous posters but I think the situation is "Armagedon bad"Why is it that Sun thinks it needs to change the language in recent years? Its probably the bad influence of .Net or something that has these guys on a role. If they want an XML processing language just take JSP and modify it to match Java SE (yes I know you need to change almost everything) in this way you will get a brand spanking new language on top of existing code you don't break the existing language and can still build something very innovative.
Re: Possible native XML support in Dolphin (Java 7)
Great post WillRe: Possible native XML support in Dolphin (Java 7)
If Sun was listening to you the whole JDK would become JavolutionRomain Guy's Java Weblog, #ProgX, Jext
Re: Possible native XML support in Dolphin (Java 7)
Better xml support would certainly be welcome. I'm not sure if native language support is the solution though. The current set APIs for working with XML is far from perfect.DOM and SAX basically suck, JAXP is too complicated to work with. The vast majority of xml usage boils down to (un)parsing tree data structures to xml. The last thing a Java programmer wants to do is spend much time fiddling with the xml, thinking about how it should be structured, designing XSD schema for it, etc. The problem is simple: given this nicely Java typed datastructure parse and unparse the damn structure.
The solution currently consists of either messing with DOM and SAX, work with some complicated marshalling solution (e.g. jaxp) or writing a few regular expressions. None of these solutions is well suited for what I described above and sadly that is by far the most occuring usecase.
Your'd be amazed by the amount of programmers who simply write XML using a few out.writeln's. A good xml solution that can provide a convenient alternative to that style of working with xml is needed. Nothing out there in the market fullfills this need.
Re: Possible native XML support in Dolphin (Java 7)
>Your'd be amazed by the amount of programmers who simply>write XML using a few out.writeln's.
True, for simple cases it's easier that way. The only thing you have to watch for is special characters support. I got used to generate XML by hand in PHP a lot because of very very very crappy APIs in PHP4 (especially with ISO-8859-1). And I remember doing the same in Java a couple of times.
That said, I'd be really interested to get feedback from people who are using XOM (http://www.xom.nu/). I've taken a look at slides and examples and it seems to be really interesting.
Romain Guy's Java Weblog, #ProgX, Jext
Well ...
Even though I agree with most of your post, I do think that Dolphin doing more integration with XML is a must do step.But to be complete I will also be in favor of doing more integration with UML class diagram. And doing both at the same time is maybe not an impossible task as at the end they all bring a valuable of business contraints into the code.
Ultimate goal is to see Java reflect in an abstract way all the business contraints identified from the business requirements. Doing so, we could rely on automated frameworks behaviours to enforce those contraints and just spend time model designing application and no wiring the objects to some validator/controler mechanism that is not always safe process.
This will ensure strong data consistency plus simplify the development process by brindging the gap between modeling (UML Class Diagram) and coding (Java code). And will ensure the class model produce can be perfectly represented/extracted to XML Schema in a transparent way.
Just my morning thoughts ....
Re: Possible native XML support in Dolphin (Java 7)
I think this is a Good Thing. XML has established itself as a very common type of data, so to me it makes sense that XML should be supported at the language level.It's analogous to string support. Strings are really just arrays of characters, so in theory they should be supported just fine by having arrays in the language. But it turns out that having explicit support for them makes things a lot easier for us as developers. I believe the same principle will apply to having XML support in the language.
As long as it's done "right", that is...
Re: Possible native XML support in Dolphin (Java 7)
> >Your'd be amazed by the amount of programmers who> simply write XML using a few out.writeln's.
> True, for simple cases it's easier that way. The only
> thing you have to watch for is special characters
> support.
Ruby and Groovy have nice solutions for this with their
Builder concepts (I *think* Groovy might have had them before).
Builders aren't a language concept, but an idiom
that uses dynamic typing to facilitate creation of
output, eg. XML.
Look at this article for a simple introduction:
http://www.xml.com/pub/a/2006/01/04/creating-xml-with-ruby-and-builder.html
This approach is much cleaner than string output, and
has the benefit that the specific text output is abstracted away, so encodings or other details are handled by the library.
This isn't possible to do in Java yet (at least not as concise and simple), because you can only call methods that a type exposes, ie. there is no method_missing concept in Java. With the new invokedynamic bytecode (which is supposed to be in Java 7), this would get possible with JVM support... maybe adding some support for this to the language would be nice, and much more
useful than dumping silly XML literals into the language.
The Java language development team might want to take
a look at one of their fellow Sun employees, Guy Steele,
and his talk "Growing a language":
http://homepages.inf.ed.ac.uk/wadler/steele-oopsla98.pdf
They'll know it, for sure, ... but it might be something
to re-read before messing with the Java language ...
> That said, I'd be really interested to get feedback
> from people who are using XOM (http://www.xom.nu/).
> I've taken a look at slides and examples and it seems
> to be really interesting.
Have you looked at JDOM? I only glanced at the XOM tutorial, but I couldn't see any *major* differences (I know... there probably are big differences, but I didn't spot them).
Re: Well ...
> Even though I agree with most of your post, I do> think that Dolphin doing more integration with XML is
> a must do step.
Why?
Java has bundled XML (JAXP) since ... 1.4 (or 1.3? can't remember), including XML parsing with SAX or DOM interfaces, transformation with XSLT, query with XPath; Mustang will include JAXB 2.0 (which uses Annotations to facilitate data binding, google for it, it looks rather nice... at least compared to JAXB 1.0) and a Pull parsing mode, not to mention XML DSIG support, and all the JAX-RPC and the whole acronym ocean that comes with that.
Hmmm... seems like Java is already integrated with XML...
and since Java seems to accumulate .NET/C# features (autoboxing, generics, for loop, enums) like there's no tomorrow... how about gleaning some clues from LINQ or other efforts... which, BTW, do not propose to add SQL/XML/... syntax to the .NET language specs...
> This will ensure strong data consistency plus
> simplify the development process by brindging the gap
> between modeling (UML Class Diagram) and coding (Java
> code). And will ensure the class model produce can be
> perfectly represented/extracted to XML Schema in a
> transparent way.
If you want modelling support, take a look at the Eclipse EMF framework, which allows for simple modelling and everything you talk about. This is heavily used in many Eclipse projects, so it's definitely proven to work and useful. Not to mention that there are tools and frameworks that build on EMF (GMF using GEF) that facilitate writing sophisticated model manipulation GUIs
(stuff that goes far beyond simple databinding for for textfields).
Here's the link
http://www.eclipse.org/emf/
Here the link for the GUI part called GMF
http://www.eclipse.org/gmf/
Re: Possible native XML support in Dolphin (Java 7)
So what are we going to see, Java classes coded as XML files?Something like this:
<class package="dumbattempt" name="StupidClass"> <member type="int" name="someInt"> <init>1</init> </member> <method name="printSomething" returns="int"> <throws/> <params/> <body> <[!CDATA[return someInt;]]> </body> </method> </class>