Skip to main content

Are you for or against "native XML support" in Dolphin?

31 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

This new feature is discussed here: http://weblogs.java.net/blog/kirillcool/archive/2005/07/native_xml_supp....

I for one am strongly against this. I feel that XML support belongs in the API layer, and should not touch the Java language. That's just my personal opinion. What do the rest of you think?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
brucechapman
Offline
Joined: 2004-03-18

I've done some more thinking on this, and read some more comments.

Whether or not the need for native XML support is 'real', this proposal is fundamentally flawed.

It is fundamentally flawed because it only solves the problem (if there is one) at hand, rather than solving the general case of these problems.

Taking such a meta view may be a foreign concept to many, in part due to the XP sect, but the fact is we cannot refactor a language.

Therefore any addition to the language must be done in a way that takes account of all future additions to the language. The XP development model just doesn't work with languages that have any desire for longevity.

Native XML in java sucks because it is so small minded. If anything is needed to solve this problem, then what is needed is a mechanism to support native ANYTHING. (Well anything that can be expressed in unicode anyway)

XML is one (and probably the most wanted and most obvious) of those anythings, But there is also SQL, regular expressions, and a myriad of other things that have their own syntax (like BNF, and ITU's ASN.1 - those are examples not ways of expressing the syntax) which for some people would be nice to have supported natively.

While we don't know how to do this practically for the general case, then we don't yet know how to solve this problem, and we should keep exploring till we do.

When we do know how to do it for the general case, then native XML support just becomes a library using whatever that general case feature is, as would native ASN.1 support, native regular expression support, native HumanReadableCodeSwingLayoutManager support etcetera.

I think it would be worth the wait.

grlea
Offline
Joined: 2004-05-26

brucechapman wrote:
> Whether or not the need for native XML support is
> 'real', this proposal is fundamentally flawed.
>
> It is fundamentally flawed because it only solves the
> problem (if there is one) at hand, rather than
> solving the general case of these problems.

As I commented on the blog, I'm very much against having native XML support in Java, for much the same reasons as Bruce Chapman. Java is a general programming language, not an XML-processing language. While many people do XML processing while using Java, many, MANY more don't!

As I also posted on the blog, the guys at JetBrains (http://www.jetbrains.com/) are making waves in trying to solve Bruce's "general case of these problems".
They are writing tools that allow engineers to easily create their own domain-specific languages (DSLs) (e.g. for processing XML?) and write programs in their new languages, even integrating them with existing languages (e.g. Java).
Eventually (if not already) I think it will be able to "mix" or "extend" languages, such that you could build an extension of Java that allows you to have your DSL for processing XML mixed in with your plain old Java code.
That's as good as native XML, without annoying the majority of people who don't want it, which, in a way, makes it better than native XML.

JetBrains MPS: http://www.jetbrains.com/mps/

(I have no association with JetBrains, I just think this is a great idea.)

wangzaixiang
Offline
Joined: 2004-11-24

It would be an exciting feature if futher Java support "native XML".

We love java because it provide a simple but strong program language, although Java's simple is a good feature, but it lose some good things also, eg, in C/C++, we can write code as:

Student student = {
/*name*/"wangzx", /*gender*/Male, /*age*/30, /*country*/"China",
/*address*/ { // a nested structure
/*address*/ "some address", /*city*/ "somecity", /*state*/ "somestate", /*zip*/ "zipcode"
}

};

Although we can do equal thing in Java(using constructor or more method calls), it is something ungainly, instead, the XML provide a even-more-clean capabilty to represents such data structures.

If Java has "native XML", then we can enhanced java with best data structure support, this will not make the java language more difficult, as XML is the general language during internet.

OOP = Data + Code, current Java provide good Code(Simple), and "native XML support" provide the best Data capability.

jwenting
Offline
Joined: 2003-12-02

> We love java because it provide a simple but strong
> program language, although Java's simple is a good
> feature, but it lose some good things also, eg, in
> C/C++, we can write code as:
>
> Student student = {
> /*name*/"wangzx", /*gender*/Male, /*age*/30,
> 0, /*country*/"China",
> /*address*/ { // a nested structure
> /*address*/ "some address", /*city*/ "somecity",
> ity", /*state*/ "somestate", /*zip*/ "zipcode"
> }
>
> };
>
Which is so completely unreadable as to cause me to throw anyone writing it out the window.
The fact that you think it a good idea AND you think writing Java code in an XML format would be an even better idea assures me of your ignorance.

>
> If Java has "native XML", then we can enhanced java
> with best data structure support, this will not make
> e the java language more difficult, as XML is the
> general language during internet.
>
No it's not. XML is NOT a language, it's a generic document type definition system.
It should never be used as a programming language.

> OOP = Data + Code, current Java provide good
> Code(Simple), and "native XML support" provide the
> best Data capability.

Bollocks.

wangzaixiang
Offline
Joined: 2004-11-24

Good, so please let's discuss it more.

consider the following code:

Customer customer =
1
Dan

1


1

;

System.out.println(customer.name);

Such an example can be runnable in rhino 1.6(javascript) already, of course you can using SAX or DOM or other XML api to do the same things, but how much code required for such a thing?

OOP = Data + Code? Not only OOP, C is also Data + Code, but OOP provide more. any Programming is Write your code(arithmetic) on your data, even more, the data structure is more important that your code, since it is the input and the output, the code can be change, refracted, or using a new language, it is the Data which makes Programing really valuable. To support XML as "native language", Java will be a good choice to represents complex data structure.

pdoubleya
Offline
Joined: 2004-02-09

I think the larger issue here is how Sun goes about making really significant changes to the language. Most JSRs deal with packages/libraries, and not changes to the language syntax itself. The question is, at what point does the language syntax limit you such that just adding a library (for example, for XML) will not provide an elegant solution.

Java is successful partly because the language syntax itself is so simple. There is low conceptual overhead to understanding a piece of Java code, when looking at the syntax, and the tough work is pushed onto understanding libraries.

I think the general policy should be to limit changes to the nice, relatively clean syntax we have wherever possible. I personally think generics are a plus. I also think we could find some way to bypass escaping within Strings, to make regexs easier to deal with.

The pressure on Sun right now is that everyone in the business development community is using XML very heavily, and this is likely to grow, not shrink. So the question is whether the extension-by-library approach is enough to keep people interested in Java, or whether they will gradually be turned off by the non-trivial work of binding even simple Java classes to XML.

On the other hand, any change to the language itself is irreversible...

Scripting is one solution, but for my part I can't imagine mixing in scripting with a larger application in Java just to get the benefits of working with, say, XML. It just makes project planning and management too difficult, and complicates testing as well. But that's just me.

I vote for keeping the core language as simple as possible, and use minor extensions to it in targeted cases where we get a lot of bang for the buck. Some people have suggested a sort of "meta-escape" syntax for strings that would obviate the need for escaping the strings manually. That makes sense to me. My guess is that the XML can be solved with good libraries and features like annotations.

Patrick

fak
Offline
Joined: 2004-11-18

I think the JSR guys should do us a favor: fix the features that have already been added before adding new ones. Namely, Generics. And it would useful to remove deprecated API, also.

1 – in Mustang, mark as deprecated all API that should be deprecated, or that you plan to deprecate.
2 – in Dolphin remove from the API all the deprecated code. People writing code for Mustang, avoiding deprecated API, should be able to run their bytecodes in Dolphin.
3 – in Dolphin, add runtime support for Generics. We will need a new class version, and Dolphin bytecodes will not run on Mustang. But it already happens with earlier releases, unless you force bytecode compliance to J2SE 1.3 or 1.4 by providing the compiler the appropriate parameter.
4 – only after that consider adding new features to the language. Until then, we will nurture and mature the ideas and proposals for new features.

I know the removal of deprecated API does not belong to this thread. I am adding this comment here because radical changes, such the discontinuity of API and changes in the class file format should be done at the same time. Such changes could make Java even better for the next decade…

prunge
Offline
Joined: 2004-05-06

> 3 – in Dolphin, add runtime support for Generics. We
> will need a new class version, and Dolphin bytecodes
> will not run on Mustang. But it already happens with
> earlier releases, unless you force bytecode
> compliance to J2SE 1.3 or 1.4 by providing the
> compiler the appropriate parameter.

I strongly agree for including runtime generics support.

I can see how native XML support might be useful, but the benefit it provides doesn't even come close to the cost of changing the language this much and adding complexity to the compiler.

vhi
Offline
Joined: 2004-10-11

On second thought, I think if there is a support for including any scripting language (after all, XML + XQuery can be considered as a scripting language) into Java syntax, then I would support this movement. This would make open the possibilities for including SQL, Groovy, XML + XQuery into the same source code. But it has to be done very carefully to ensure that not much bloat is added.

chris_e_brown
Offline
Joined: 2004-09-14

Rhino (Mozilla's Java implementation of JavaScript/ECMAScript) already includes "E4X", an extension that natively embeds XML into language syntax. This is a better place for it.

With Java's scripting engine plug-in API (javax.scripting), it's better than adding it to the core. Groovy's a great example of embedding all this stuff: it's available (along with SQL and other stuff) in an appropriate place.

- Christopher Brown

vtec
Offline
Joined: 2003-09-05

I would STRONGLY SUPPORT the idea of having special syntax to express XML inside Java.

1) Compare how easy is to use Regular Expressions from Java and from Perl. In Java you have to use heavily escaped completely cryptic Strings to express your patterns and in Perl you have special type for it that does not need escaping. The same would apply to being able express XML fragments as special type in Java code.

It would be MUCH MORE READABLE then to use escaped Strings or long run of DOM API calls that creates the XML fragment. It could even allow your IDE to syntax-highlight it.

2)The ability to work with these special type based XML fragments using DOM like API without any explicit parsing and serialization would make programming and debugging much easier. Just imagine how Unit Testing of any SAX ContentHandler implementation would be easy - just take the XML file your code has to process and paste it into your test file as constant of this new XML type.

3) Some things are MUCH better and easier described by XML then by Java Code. Swing application with its containers, layouts, components and their properties... Take a look at any complex layout structure - hundreds of Swing API calls that can be replaced by much more readable piece of XML - inside the Java file without any hassling. A bit similar situation is with Servlets - those big String constants are just not maintainable and could be replaced by this new XML type (serving XHTML).

4) Microsoft is searching for ways how to extend C# with direct SQL support - probably just inferior idea. This XML support in Java would be a great answer.

podlesh
Offline
Joined: 2004-07-26

IMHO:
1) These things are great for scripting languages, but doesn't really belong to basic, general-purpose language like Java.
2) XML is nice and popular, but what about (for example) SQL? Working with SQL is ugly (even more ugly then XML). Shouldn't it be integrated into language, too? After all, it's much older concept, used for twenty years.

Maybe it would be much better just to support integration of scripting languages into Java code. Long and ugly Java code could be replaced by simple code fragment in Groovy (or something like that). And it doesn't matter if you need to work with XML, SQL, regex, ASN or anything I can't even imagine - just add some new fancy script language.

From the conservative point of view, it's still ugly - but much better than adding XML as language feature.

tackline
Offline
Joined: 2003-06-19

SQL provides an interesting comparison. JSQL is Java with embedded SQL. It appears to make mixing raw SQL and Java much easier and, unlike this proposal, natural. Great for blasting out tables.

The relational model has some kind of sense to it. DOM is a reverse-engineered model of a handy way to mark up text.

Oracle stopped supporting JSQL for a while, although they have since reintroduced it for legacy code.

SQL is a much better candidate for blurring the line with business logic than XML. Still, you wouldn't want to mix Java and raw SQL in preference to Hibernate (or EJB3) for 99% of business applications.

sumitkishore
Offline
Joined: 2003-06-10

I'm pretty sure this feature is high on the agenda because Microsoft is planning to introduce the same to .NET. I do remember reading papers about this first on the .NET platform.

As to people against this proposal, aren't you carrying your biases too far? Isn't XML ugly precisely because there is not language level support for it?

alexlamsl
Offline
Joined: 2004-09-02

There are a class of people who have already established themselves in the society and hence would be reluctant react to changes. ;)

Having said that, they do exist, for at least, to counter-act another group of voices that keep wanting to change everything and hence pushing the development process towards instability.

A good balance between the two would ensure that Java won't go either obsolete (difficult to use in comparison with competitors) or unpopular (difficult to learn in comparison with competitors).

Just my 2 cents anyway :)

thiagohp
Offline
Joined: 2004-08-24

I disagree with the proposal of native xml support in Java for some reasons:
1) I think it makes source code much less readable and more difficult to understand, as you can assign a String to almost any kind of variable. Less readability = more bugs.
2) As already stated in this thread, there is a large number of errors that can happen (broken XML, documents that do not conform to their DTD, assignment of a XML to an incompatible object, etc).
3) We already have some very good Java XML packages. I recommend JDOM.
4) It is argueble that the cost/benefit ratio (is this expression right?) of extending the language to include native XML would be a good deal. The implementation of Java compilers would become way more complex.

alexlamsl
Offline
Joined: 2004-09-02

I'm all for the proposal - XML is at least one dimension more expressive than plain string for the very start, and with its elegant resemblance with Object's, it's just worth to make it a "first-class citizen" in Java ;)

kirillcool
Offline
Joined: 2004-11-17

The correct link is http://weblogs.java.net/blog/kirillcool/archive/2005/07/native_xml_supp_... including all the comments and my responses. The original link points to an older version of the entry which was subsequently revised and augmented. In case you wish to participate in a constructive discussion of the proposed syntax, please put your comment there. In case you just wish to rant that this only bloats up Mustang, you may rant anywhere :)

tackline
Offline
Joined: 2003-06-19

Can I get this clear. What is being proposed is that instead of having to write:

String str = toXML(mine);
and
MyClass mine = fromXML(str);

The language should be modified, so that we only need to type:

String str = mine;
and
MyClass mine = str;

Outrageous.

kirillcool
Offline
Joined: 2004-11-17

And how many lines do those toXML / fromXML functions have? Do they handle all possible exceptions, including unknown attributes, invalid structure, parser configuration etc.? Do you have one pair for each possible type of XML? Or do you just magically take these functions from somewhere? Have you read the article at all before responding?

tackline
Offline
Joined: 2003-06-19

Of course I have read the article, in complete disbelief.

The toXML and fromXML would be standard library functions. I didn't put in the import static, and also fromXML(str) should have been fromXML(MyClass.class, str). Write it as XML.from(MyClass.class, str) if you like. Handling sad cases in a library is no different from handling it in the language, only you get more flexibility with a library.

Absolutely no need for their to be any more than one pair of toXML/fromXML. Why would there be?

I didn't address the extends idea. The article had just got too bizarre by then. But it's easy to conceive of another (single) set of library methods

String age = XML.get(cust, String.class, "age");

I don't understand why your posting doesn't mention Commons Digester.

cowwoc
Offline
Joined: 2003-08-24

I think readers have misunderstood my original point: I am not against the idea of improving XML support in J2SE (by bundling better APIs for example). And this isn't an issue of how ugly or not XML is.

The point is: regardless of the merits of XML, it does not belong as a first-class citizen as part of the Java language. It belongs in the API layer.

This move makes as much sense to me as working a BNF parser into the language... Sure you could do it, but it is quite obviously the wrong to do so at the language-level. Java is not a BNF or XML parser. It is far more than XML specific and working this kind of support into the language will make it harder to learn for absolutely no good reason. Finally: XML parsing is already super easy to do with dom4j and jdom. Why the heck do we need anything more?! XML APIs are about as simple as they get nowadays. Who's actually complaining here?

Frankly, I think the fact that .NET is planning to make XML a first-class citizen is a waste of time. Let them bury themselves. If we focus too much on what Microsoft is doing and too little on what our users are actually asking for, we run the risk of being outmanouvered.

The only thing that is important is what developers need, *not* Microsoft's vapourware de jour.

Gili

kirillcool
Offline
Joined: 2004-11-17

jdom and dom4j are super-easy? For you and me perhaps, but most certainly not for the beginning developer and absolutely impossible for non-Java developer such as web designer.

I remember my earlier days when the first support for document models came in javascript. At first it was like a blessing - now i can control everything. And then it was a disappointment - what's all that stuff, and why working with it is so ugly?

Everything is super-easy to do after you programmed in the language for 5+ years. Do i enjoy working with Iterators now that in 5.0 i don't have to? It was one of the uglier parts of the API i've ever seen in Java (that seemed to be designed to be different from STL on purpose). Were they super-easy? You can argue that they were. Now i don't miss them at all (except when i need to remove a specific item during iteration).

XML is ugly. Period. Why should a programmer implementing business logic strive to understand how to translate the XML input into his object? Does it matter to him that we label SAX as efficient, DOM as powerful and StAX and JDOM as easy to use? To him it's fluff. Not stuff, just fluff. Unnecessary, pointless and boring fluff. He needs to write business logic, not wander through XML object model. He's got a business object model already.

cowwoc
Offline
Joined: 2003-08-24

kirillcool,

Sorry, but I disagree. First of all "most Java users" are not web developers. Why burden the majority of users for the benefit of the few? Secondly, I think you're promising the sky and no one will ever deliver this. I don't think dealing with XML will ever get easier than it is with dom4j. What makes you think embedding this into the language will make it easier?

Besides which, it sounds to me like you're talking about object persistence, not generic XML manipulation (which I was takling about). Frankly if that's what we're discussing, it does not get any easier than http://xstream.codehaus.org/

XStream *is* easy.

There are many great APIs out there that are very easy to learn and use (even if you don't have five years experience) and frankly they are better left to develop in their own rate, without Sun mandating it as part of the JLS.

Just my 2 cents...

Gili

brucechapman
Offline
Joined: 2004-03-18

To have a play with XML Literals in Java SE 5 ...
See https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/pr...

There should be a link to the instructions, but there isn't yet - see

https://rapt.dev.java.net/nonav/docs/api/index.html?overview-summary.html (Scroll down to "Using Generators")

To download the jar file go here https://rapt.dev.java.net/servlets/ProjectDocumentList

So is it any use?

Not generally, but it is GREAT for writing unit tests for code that processes XML. You can put the test XML data inside the unit test source code, and that makes the test code much easier to read and write.

jwenting
Offline
Joined: 2003-12-02

It's the next step towards making Java impossible to use because of the ever increasing BLOAT.
And it will seriously harm performance as well if everything is constantly parsed to and from XML whenever you make an assignment anywhere.

kirillcool
Offline
Joined: 2004-11-17

You are talking about implementation already. Who said that XML and object must be completely synchronized? Only when you marshal the object back to XML it can be updated.

vhi
Offline
Joined: 2004-10-11

I think XML in a language is not really well tested in general. There exists some research languages, but no other main stream language. Getting it right the first time will be very hard. Also, I cannot see any reason to include it. Sun generally follows 80/20 rule when implementing language changes. Look at Generics. It took 7 years to introduce Generics when a main stream language like C++ and other languages had already experimented and thus we know a great deal about it. Then why this XML in Java? Is it the most frequently asked feature? Why doesn't sun provide *real world* facilities (like ease of use for JNI, better support for Value Objects, Closure etc) instead of an academic exercise like XML-In-Java. These language changes (like Closure, proper Design By Contract) is very well tested, and provides well-known benefits. I would ask Sun not to waste time including something that is not really well known, instead include those features that we had asked for. I propose that we start voting/polls so as to influence Sun's decision.

sfitzjava
Offline
Joined: 2003-06-15

XML is not a language, as such can not be used effectively in writing logic. It is a data structure, and handles data formats fine, it can hold configuration information as well such as in the Web.xml, but IMHO keep that crud out of my favorite language, Java.

I for one don't like using XML. It reminds me of procedural programming, while better than Spaghetti code, not as elegant as OO. While it feels better than ridged data structures tightly coupled with the code, I think there are other options (maybe annotations and the APT tools, or an undiscovered option yet TBD).

Then there is always the size of XML. I mean why use 4 bytes, when you can say it in 50 characters? So then you say, what about binary XML, to which I say why not use Serialized objects, it's almost the same thing. I really wish SUN would have taken Serialzation to the next level and removed the issues.

I'm a Java programmer, not a XML doc formatter, keep the API's for XML's use but keep XML out of my language!

There are my opinions. YMMV.
-Shawn

tackline
Offline
Joined: 2003-06-19

Shocking.

peter_lawrey
Offline
Joined: 2005-02-24

I think there are number of use implementations which should be provided as an optional extension to java.
I think it would be available in a seperate development kit. i.e. not part of the core java.