 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2008XML support in Java 5?
The javax.xml and javax.xml.stream packages have some classes that look very useful for writing and reading XML (the latter package especially). Unfortunately, as near as I can tell they are for the most part only supported in Java 6 and later. The few things that are documented as being in Java 5, I don't see how they are useful for actually writing XML. The XMLStreamWriter and XMLStreamReader classes are the ones in particular that I'd find useful. But I need something that doesn't require Java 6. I can write a simple implementation myself for my own purposes. What I'm writing isn't very complicated and I can get by without a full-fledged XML-compliant class. But I'd just as soon use a built-in class if there is one. I've searched the Sun docs every way that I can think of, but the only thing that turns up each time are the Java 6 classes. The closest thing I could find is a writer in the SQL package, but it doesn't seem appropriate for my use (there's no database involved here). Is there any simple XML support in Java 5? If so, can you please point me to the appropriate class name or documentation page? Thanks! Pete > The javax.xml and javax.xml.stream packages have some classes that look > very useful for writing and reading XML (the latter package [quoted text clipped - 19 lines] > Is there any simple XML support in Java 5? If so, can you please point > me to the appropriate class name or documentation page? The XML stream stuff is what is known as STaX. It became standard as part of Java 6, but you can get STaX for older Java versions as well. One implementation is here: http://stax.codehaus.org/Download Reading XML has been part of Java since version 1.4 - you can choose between W3C DOM and SAX. One of the weird things about the Java W3C DOM is that it does not have something simple to output XML. You can use XSLT or my preferred solution: the XMlSerializer class that comes with Xerces and also exist in SUN Java. I have lots of coding examples of W3C DOM, SAX, JDOM, XMLSerializer etc. - just say what you want and I can post something. Arne >> The javax.xml and javax.xml.stream packages have some classes that >> look very useful for writing and reading XML (the latter package [quoted text clipped - 35 lines] > You can use XSLT or my preferred solution: the XMlSerializer > class that comes with Xerces and also exist in SUN Java. And then there are also JAXB and the XMLEncode/XMLDecode that has existed since 1.4. Arne Thanks for the suggestions. My thoughts... > The XML stream stuff is what is known as STaX. It became standard > as part of Java 6, but you can get STaX for older Java versions > as well. > > One implementation is here: > http://stax.codehaus.org/Download I'm looking for something that would already be in the JRE. If I'm going to deliver any XML implementation along with my application, it's going to be a bare-bones one I wrote myself. I don't really even need this to be XML...I just like XML because it's a little more readable. > Reading XML has been part of Java since version 1.4 - you can choose > between W3C DOM and SAX. Okay, I see org.xml.sax, with some reader-like things. I assume that's what you're talking about with SAX. I also see org.w3c.dom. > One of the weird things about the Java W3C DOM is that it does > not have something simple to output XML. Just looking at the API, it would _seem_ like the DOM packages would be useful to me. Manipulating an XML document looks very easy. Constructing a Source and Result for use with a Transformer is also very easy. And as near as I can tell, I can go both ways. Unfortunately, I'm having trouble getting a DOMImplementation. The most reliable technique (at least in my environment) appears to be to get a DocumentBuilder instance and use that to retrieve the DOMImplementation. But when I look at the class it returns, the package (com.sun.org.apache.xerces) isn't one I recognize from the Sun Java docs, which makes me wonder if I can really count on it being installed in any Java 5 run-time implementation. This technique actually involves the least lines of code of the ones I've looked at. Serialization might be shorter if the data I'm trying to save out to a file were encapsulated in a class designed for serialization. But it's not. So using the XMLEncoder/XMLDecoder from the XML serialization requires additional retrofitting work to allow my code to work with it. I'd rather just use the DOM stuff if I can be assured that it's portable. If it's not, then maybe XMLEncoder/XMLDecoder is in fact the best solution given the Java 5 restriction. That seems certain to be in any Java 5 implementation. > You can use XSLT or my preferred solution: the XMlSerializer > class that comes with Xerces and also exist in SUN Java. Xerces is the name of the package I didn't recognize above. If I can count on it being standard in Java 5, then either the DOM approach or using the XMLSerializer you mention could be a useful approach. But if not, it's not suitable for my needs. Is it standard in Java 5? > I have lots of coding examples of W3C DOM, SAX, JDOM, XMLSerializer > etc. - just say what you want and I can post something. Well, writing the code isn't the hard part. Knowing where to look for the general API I need to use is. Also knowing what's standard in Java 5 and what's not is difficult. My assumption is that if it's not at http://java.sun.com/javase/6/docs/api/ then it's not part of the standard Java (and of course, if it's listed there but is "Since 1.6", it's too recent for my needs). So I appreciate the offer of code, but what I really need is a map to navigate the various APIs to know which ones are actually potential solutions or not, based on their portability. Pete > [...] > Just looking at the API, it would _seem_ like the DOM packages would be > useful to me. Manipulating an XML document looks very easy. > Constructing a Source and Result for use with a Transformer is also very > easy. And as near as I can tell, I can go both ways. Okay, I got this working. Except for one little problem: the StreamResult I created isn't using any whitespace to format the XML. This doesn't prevent the XML from working, of course, but it does negate much of the readability I was hoping for in using XML in the first place. With the DOM API, is there any way to tell it to format the output with newlines (and as a bonus, with indentation)? I've used other XML implementations that provide this as a simple boolean property on the output class instance. But I can't find anything like this in the StreamResult class, or even in the other related classes. Pete >> [...] >> Just looking at the API, it would _seem_ like the DOM packages would be [quoted text clipped - 13 lines] > output class instance. But I can't find anything like this in the > StreamResult class, or even in the other related classes. I do this using the setOutputProperty() method on the Transformer object: TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer(); transformer.setOutputProperty(OutputKeys.INDENT, "yes"); transformer.setOutputProperty("{http://xml.apache.org/xslt}indent- amount", "4"); Cheers! GRB  Signature--------------------------------------------------------------------- Greg R. Broderick usenet200801@blackholio.dyndns.org A. Top posters. Q. What is the most annoying thing on Usenet? --------------------------------------------------------------------- > I do this using the setOutputProperty() method on the Transformer object: > > TransformerFactory tFactory = TransformerFactory.newInstance(); > Transformer transformer = tFactory.newTransformer(); > transformer.setOutputProperty(OutputKeys.INDENT, "yes"); Ah, much better. I actually wrote a little custom Writer class to wrap the Writer I was actually using for the StreamResult. It inserts whitespace as necessary between XML tags. That did the job, but this is obviously much better. Thanks for the tip! As for this one: > transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", > "4"); I suspect the default will be fine for me anyway, but...the above looks implementation-dependent. Am I essentially guaranteed to be using the Apache Xerces XML component, and thus the implementation-dependent property is fine? Or is the apparent implementation-dependent property actually supported by other XML implementations, so there is no cause for concern? Or am I back to my previous question, with respect to whether the method I'm using to get the DOMImplementation is actually portable for all Java 5 implementations? The DocumentBuilder-based solution works on both OS X 10.4's Java and Java 6 on Windows XP. But that's a pretty limited test. I'm wondering if it's truly universal or if there are Java implementations for which that won't work. Thanks, Pete >> transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", >> "4"); > > I suspect the default will be fine for me anyway, but...the above looks > implementation-dependent. It is. Bur Xerces is by far the most widely used JAXP implementation. > Am I essentially guaranteed to be using the > Apache Xerces XML component, Only if you explicit use Xerces or uses a Java version (like newer SUN) that has Xerces as its default implementation. > Or am I back to my previous question, with respect to whether the method > I'm using to get the DOMImplementation is actually portable for all Java [quoted text clipped - 4 lines] > if it's truly universal or if there are Java implementations for which > that won't work. java.xml javax.xml org.w3c.dom org.xml.sax must be in any Java implementation of a Java version where they are required. org.apache com.sun are implementation specific. Arne >>> transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", >>> "4"); >> I suspect the default will be fine for me anyway, but...the above >> looks implementation-dependent. > > It is. Bur Xerces is by far the most widely used JAXP implementation. Um. Well, I suppose I can live with that if I have to. But I'm hoping I don't. It turns out the default isn't fine for me after all, as the default turns out to be 0. I don't understand why the default should be 0. That's basically "no indent", which is pretty much the last thing someone would want, I think, if they've specifically set a property named "indent" to "yes". But, given that the default apparently is 0, doesn't it make sense that the base API would offer some way to change it to a value that actually _indents_? Why would they provide the "indent" property, but not offer any way to actually get the XML indented? I see two possibilities that would be preferable to just using the Xerces qualification for the property: * Somehow getting the actual URI for the qualification from the Document or DocumentBuilder, and using that. There still remains the chance that a non-Xerces implementation wouldn't understand the "indent-amount" property, but at least those that follow that convention would indent properly. The XML is still usable without indentation, so this is more about getting the indentation to work in as many implementations as possible, rather than the application breaking when it doesn't. * Even better, and ideal IMHO, would be a property name that is guaranteed to work unqualified on all Java 5 implementations and later. Are either of these possibilities available to me? Pete > [...] > I see two possibilities that would be preferable to just using the [quoted text clipped - 5 lines] > > Are either of these possibilities available to me? Ding-ding! We have a winner. Maybe. :) Okay, I found a bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6296446) complaining that setting an "indent-amount" property for a specific qualified URI doesn't work. Contained in that was a description of a work-around that, lo and behold, the work-around for that bug solves my issue as well. In particular, calling TransformerFactory.setAttribute() with the name "indent-number" and the indent value I want actually causes the desired indentation to happen (provided I also set the "indent" property on the subsequently created Transformer instance to "yes", of course). The thing is, I don't see any explicit documentation of this attribute. The documentation for set/getAttribute seem to imply that the attribute is implementation-specific. So even though it's not qualified, I'm concerned that I'm still relying on implementation-dependent behavior. Does anyone have any specific knowledge of this technique who is willing to comment on the validity or usefulness of it? My current proposed use is to use that work-around, putting the call to setAttribute() in a try/catch block and just ignoring any error. The worst that would happen in that case is my XML doesn't get indented. (It's funny...I've been doing some Googling, obviously, on this issue and it appears that not only is how to get XML indented as desired using Java a broadly-confronted issue, there's a surprisingly large number of ways to accomplish it. Here's a sample thread: http://forum.java.sun.com/thread.jspa?threadID=562510 (I'm especially enamored of the technique in reply #22, in spite of -- or maybe because of :) -- the fact that it's relatively complicated, as compared to just setting an attribute on the TransformerFactory)). Thanks, Pete >> It is. Bur Xerces is by far the most widely used JAXP implementation. > > Um. Well, I suppose I can live with that if I have to. But I'm hoping > I don't. It is worth noting that distributing with Xerces would not break WORA. Xeres is pure Java. If it is an applet, then the size of the Xerces jar could be a problem, but for desktop and server apps it is not a problem. And it is not just me thinking so. I just checked my harddrive. I have 68 copies of Xerces. Because so many apps come with it. BEA, Borland, SUN, JBoss, IBM, Apache, Oracle. Arne >>> It is. Bur Xerces is by far the most widely used JAXP implementation. >> Um. Well, I suppose I can live with that if I have to. But I'm >> hoping I don't. > > It is worth noting that distributing with Xerces would not break WORA. Sure. But it _would_ break my other goal of not having to distribute additional components with my application. > Xeres is pure Java. > > If it is an applet, then the size of the Xerces jar could be a problem, > but for desktop and server apps it is not a problem. It's an application, but a small, relatively simple one. Its JAR is only 400K, and it's only that big because it's got a poorly-compressed AIFF audio clip in it (accounting for the lion's share of that size). I don't know how large the Xerces (or similar) download would be, but I suspect it could equal or exceed the total size of my application (and that even assumes that I don't eventually figure out how to get the audio clip to be an MP3 instead...if I can get the audio clip's size down to something reasonable for its length, the disparity would be that much larger). I'm also not interested in introducing installation complexities, such as those that might be required as part of delivering a third-party component with the application. > And it is not just me thinking so. > > I just checked my harddrive. I have 68 copies of Xerces. Because > so many apps come with it. > > BEA, Borland, SUN, JBoss, IBM, Apache, Oracle. Well, I have to say: just because everyone else is doing it, that doesn't mean it's a good idea. Also, what's reasonable to include with an application depends a lot on how large that application is. Maybe if my application were larger, and maybe if I needed some specific XML implementation behavior that that particular package provides, it would be something I'd consider. However, I've got a much better solution (and this is thanks to you, for what it's worth :) ). The only problem with the solutions offered here was that the built-in XML implementation wasn't handling indentation properly, and the XSLT-based work-around I found on that previous link addresses that nicely (the single-character linefeed in the XSLT even gets converted to the CR/LF pair when running on the Windows Java implementation), without introducing any implementation-specific dependencies. So now I've got my application working just fine (well, with respect to the XML :) ), with a minimal amount of code, and without any dependency other than the original Java 5 requirement. Pete >> It is worth noting that distributing with Xerces would not break WORA. > > Sure. But it _would_ break my other goal of not having to distribute > additional components with my application. Xerces is distributed as part of the JRE 1.5, so you don't need to distribute any additional components. Signature--------------------------------------------------------------------- Greg R. Broderick usenet200801@blackholio.dyndns.org A. Top posters. Q. What is the most annoying thing on Usenet? --------------------------------------------------------------------- >>> It is worth noting that distributing with Xerces would not break WORA. >> [quoted text clipped - 4 lines] > distribute > any additional components. I'm afraid I don't have the time to research this myself, and unfortunately I'm getting mixed signals here. Arne's reply implies that while Xerces is "by far the most widely used JAXP implementation", that does not mean that all Java implementations use it. Arne's suggestion that he's got 68 versions of it on his hard disk implies to me that it's not part of the implementation (why would people deliver it as an add-on if it were?). On the other hand, you say (or at least imply) that _all_ 1.5 implementations will have Xerces. Is this fact documented somewhere official? Or is it just something that's "common knowledge"? In any case, I appear to have a solution that isn't dependent on the implementation (which frankly, I feel should always be a goal in Java development -- even though the environment has strengths other than that, certainly it's my feeling that's one of the greatest ones). So it's somewhat of a moot point. But if you have some official source that clearly documents whether a specific implementation can be assumed, I'm all ears. Thanks! Pete >>>> It is worth noting that distributing with Xerces would not break WORA. >>> [quoted text clipped - 24 lines] > that clearly documents whether a specific implementation can be assumed, > I'm all ears. Peter, the fact that the classes are documented as part of the API (e.g., the org.xml.sax package) *is* the guarantee that they're part of the language. You may relax. SignatureLew > Peter, the fact that the classes are documented as part of the API > (e.g., the org.xml.sax package) *is* the guarantee that they're part of > the language. You may relax. Well, I don't see it as being that cut-and-dried. I'm not using a specific class. I'm using an interface. The fact that the interface is in the API only means that if someone implements the interface, it will conform to the API. It doesn't actually guarantee someone has actually implemented the interface. Furthermore, in the context of this thread, the other thing that came up was a suggestion (not a bad one, mind you) of how to configure the XML output to use a specific indent for formatting. The property being set to control the specific indentation was not one documented in the API; it was specific to a certain implementation of the interface being used. I am relaxing, because I have found what appears to be a reliable, portable solution to the questions I've posed. But only because I've been assured by Arne that even though I'm using a factory to get an implementation of an interface, all 1.5 implementations will include _some_ implementation of this interface. Without that assurance, there is absolutely no reason to assume that just because the API documents an interface all implementations of the API include an implementation of the interface. Pete >>>>> It is worth noting that distributing with Xerces would not break WORA. >>>> [quoted text clipped - 28 lines] > (e.g., the org.xml.sax package) *is* the guarantee that they're part of > the language. You may relax. java.xml, javax.xml, org.w3c.dom and org.xml.sax is guaranteed to be there. They are part of the JAXP interface. But the Xerces implementation are not guaranteed to be there. (the classes in org.apache.xml in the real Xerces and com.sun.org.apache.xml.internal in SUN Java) Arne >>> It is worth noting that distributing with Xerces would not break WORA. >> Sure. But it _would_ break my other goal of not having to distribute >> additional components with my application. > > Xerces is distributed as part of the JRE 1.5, so you don't need to distribute > any additional components. SUN uses Xerces as their JAXP implementation. It is neither guaranteed to be so in future SUN versions or in non-SUN versions. Arne >> The XML stream stuff is what is known as STaX. It became standard >> as part of Java 6, but you can get STaX for older Java versions [quoted text clipped - 4 lines] > > I'm looking for something that would already be in the JRE. Is it that bad to have your jar file and instruction that it runs on 1.6 as is and on earlier versions with another jar file in the classpath. No code changes. >> Reading XML has been part of Java since version 1.4 - you can choose >> between W3C DOM and SAX. > > Okay, I see org.xml.sax, with some reader-like things. I assume that's > what you're talking about with SAX. I also see org.w3c.dom. Yep. >> One of the weird things about the Java W3C DOM is that it does >> not have something simple to output XML. [quoted text clipped - 8 lines] > DocumentBuilder instance and use that to retrieve the > DOMImplementation. The standard sequence is: DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.parse(new File(filename)); > But when I look at the class it returns, the package > (com.sun.org.apache.xerces) isn't one I recognize from the Sun Java > docs, which makes me wonder if I can really count on it being installed > in any Java 5 run-time implementation. This is true interface programming. You get a Document back and you can call all methods in that interface. All Java implementations (version 1.4 and higher) will have that. With SUN Java you get a com.sun. class as implementation. With IBM Java you may get a com.ibm class as implementation. If you are unhappy with the one that comes with your Java, then you can another one like Apache Xerces and by defining a system property get your code to use that. No code changes. [SUN are using Xerces in their Java just renaming the package, but you could still want a newer Xerces for whatever reason] >> You can use XSLT or my preferred solution: the XMlSerializer >> class that comes with Xerces and also exist in SUN Java. [quoted text clipped - 3 lines] > using the XMLSerializer you mention could be a useful approach. But if > not, it's not suitable for my needs. Is it standard in Java 5? The code I prefer is: OutputFormat fmt = new OutputFormat(); fmt.setIndenting(true); XMLSerializer ser = new XMLSerializer(ps, fmt); ser.serialize(doc); You can use either Xerces (package org.apache.xml.serialize) or the builtin in SUN Java (package com.sun.org.apache.xml.internal.serialize) - see above for explanation. As the name indicate then it is not standard, so you will need to either distribute with Xerces or assume SUN Java. >> I have lots of coding examples of W3C DOM, SAX, JDOM, XMLSerializer >> etc. - just say what you want and I can post something. [quoted text clipped - 7 lines] > what I really need is a map to navigate the various APIs to know which > ones are actually potential solutions or not, based on their portability. What is supported in what context is very well defined, but unfortunately not very easy to describe. Arne > Pete > Is it that bad to have your jar file and instruction that it > runs on 1.6 as is and on earlier versions with another jar file > in the classpath. No code changes. Well, without wasting time on the particulars, yes. It would be that bad. It would to a large degree negate the whole point of me coding the project in Java in the first place. > [...] > The standard sequence is: > > DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); > DocumentBuilder db = dbf.newDocumentBuilder(); > Document doc = db.parse(new File(filename)); Well, that looks like for reading. I'm also (and in one sense, more) interested in writing. Unless I can write, reading isn't useful to me. My earlier effort (which does work) was based on some sample code I found, and it calls DocumentBuilder.getDOMImplementation(), and then uses that to create a Document instance. But now that you mention it, I see that there's also DocumentBuilder.newDocument(). Can I assume that calling that is equivalent to getting the DOMImplementation and using the createDocument() method on that? Or perhaps it's even superior than bothering with the DOMImplementaton? It certainly seems simpler if I can just use the DocumentBuilder rather than messing around with the DOMImplementation instance. I guess the one difference I see is that I can provide parameters when creating the document using the DOMImplementation, but I don't see how to replicate those going through the DocumentBuilder. But I suspect that comes down to my inexperience with XML, and that there's probably some general-purpose method on the Document itself that I can use to configure the document properties (for example, the document namespace and name). I just need to look for it. (But if someone can spoil the adventure for me by just telling me the method and/or parameters needed, feel free :) ). >> But when I look at the class it returns, the package >> (com.sun.org.apache.xerces) isn't one I recognize from the Sun Java [quoted text clipped - 7 lines] > > All Java implementations (version 1.4 and higher) will have that. I realize that all Java implementations will support the interface. But that's different from saying that on all Java implementations I'll be able to get an instance of the interface, via the mechanism described here (e.g. using DocumentBuilder). Can you clarify that the latter is true? > With SUN Java you get a com.sun. class as implementation. > > With IBM Java you may get a com.ibm class as implementation. Well, I know for a fact those aren't the only Java implementations. Fortunately, the Apple implementation is known to me to support this (since it works :) ). Are the above the only other Java implementations? If not (and I suspect not), am I guaranteed to get _some_ implementation of Document, regardless of the implementation? Or is a provider for this interface optional? > If you are unhappy with the one that comes with your Java, then > you can another one like Apache Xerces and by defining a system > property get your code to use that. > > No code changes. I'm only "unhappy" if no implementation at all is provided. But installing an implementation isn't an option. I'm looking for something as close to "write-once, run everywhere" as possible. After all, that goal is the main reason I'm even using Java. So it's important to me to know the difference between something that is found in several implementations versus something that is guaranteed to be found in any Java 1.5-compliant implementation. Thanks for the help. Pete >> The standard sequence is: >> [quoted text clipped - 15 lines] > certainly seems simpler if I can just use the DocumentBuilder rather > than messing around with the DOMImplementation instance. It is. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.newDocument(); Element one1 = doc.createElement("one"); one1.appendChild(doc.createTextNode("A")); Element one2 = doc.createElement("one"); one2.appendChild(doc.createTextNode("BB")); Element one3 = doc.createElement("one"); one3.appendChild(doc.createTextNode("CCC")); Element all = doc.createElement("all"); all.appendChild(one1); all.appendChild(one2); all.appendChild(one3); doc.appendChild(all); > I guess the one difference I see is that I can provide parameters when > creating the document using the DOMImplementation, but I don't see how [quoted text clipped - 5 lines] > adventure for me by just telling me the method and/or parameters needed, > feel free :) ). doc.createElementNS create elements with namespace. >> This is true interface programming. >> [quoted text clipped - 8 lines] > here (e.g. using DocumentBuilder). Can you clarify that the latter is > true? It is true. DocumentBuilderFactory and DocumentBuilder will be in any Java implementation version 1.4 or newer. (and for 1.3 you can get them as external packages) >> With SUN Java you get a com.sun. class as implementation. >> [quoted text clipped - 6 lines] > _some_ implementation of Document, regardless of the implementation? Or > is a provider for this interface optional? You will always get some implementation of Document. There are many implementation: SUN, IBM, BEA and Oracle each has their own. Companies like HP and Apple also have their own for their operating systems and hardware. My guess is that the last category base their versions on the SUN version. >> If you are unhappy with the one that comes with your Java, then >> you can another one like Apache Xerces and by defining a system [quoted text clipped - 9 lines] > implementations versus something that is guaranteed to be found in any > Java 1.5-compliant implementation. Then W3C DOM and outputting via XSLT seems as the way to go. Arne > [...] > You will always get some implementation of Document. Okay, good news. Thanks for all the pointers. Looks like I've got a plan. :) Mon, 28 Jan 2008 21:02:53 -0500, /Arne Vajhøj/: > The XML stream stuff is what is known as STaX. It became standard > as part of Java 6, but you can get STaX for older Java versions > as well. > > One implementation is here: > http://stax.codehaus.org/Download I've seen there's ongoing work to add StAX to Xerces2 but I don't really know when it will be available in it. > Reading XML has been part of Java since version 1.4 - you can choose > between W3C DOM and SAX. > > One of the weird things about the Java W3C DOM is that it does > not have something simple to output XML. Have you tried the DOM Level 3 Load and Save API [1]? As far as I see it is part of the Java 5 API [2] and is available for Java 1.4 users through plugging the Xerces2 library. [1] http://www.w3.org/TR/DOM-Level-3-LS/load-save.html [2] http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/ls/package-summary.html SignatureStanimir Mon, 28 Jan 2008 17:45:25 -0800, /Peter Duniho/: > The XMLStreamWriter and XMLStreamReader classes are the ones in > particular that I'd find useful. But I need something that doesn't [quoted text clipped - 4 lines] > full-fledged XML-compliant class. But I'd just as soon use a built-in > class if there is one. I can't advise you more than using a library which implements the interfaces, like Arne already did, but at least XMLStreamWriter is easily implemented over the standard Java 1.4 transformation API and implementation, using an TransformerHandler [1] which basically provides SAX API to generate a result as opposed to parse an input using SAX. I've done simplified version for my needs time ago and its inner workings are the same as this example: <http://mail-archives.apache.org/mod_mbox/xml-xalan-j-users/200801.mbox/%3c479729 21.1020300@netscape.net%3e> As for XMLStreamReader - it could be implemented over a SAX implementation too, but the implementation must use two threads and the penalty of synchronizing them is too much over the benefit of ease of use. One could also implement it using the Xerces2 pull-parsing interface, but as you want it pretty much out-of-the-JRE-box everything I've written here is only as "interesting to know". [1] http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/sax/TransformerHandl er.html SignatureStanimir On Mon, 28 Jan 2008 17:45:25 -0800, "Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote, quoted or indirectly quoted someone who said : >Is there any simple XML support in Java 5? If so, can you please point me >to the appropriate class name or documentation page? Why are you limited to Java 5? Java 6 came out over a year ago on 2006-12-12 SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com > On Mon, 28 Jan 2008 17:45:25 -0800, "Peter Duniho" > <NpOeStPeAdM@nnowslpianmk.com> wrote, quoted or indirectly quoted [quoted text clipped - 5 lines] > Why are you limited to Java 5? > Java 6 came out over a year ago on 2006-12-12 From the OP - User-Agent: Opera Mail/9.24 (MacIntel) Simon. > Why are you limited to Java 5? > Java 6 came out over a year ago on 2006-12-12 That's an excellent question. The answer is: because Apple can't be bothered to provide a Java 6 implementation for their operating system. Even for OS X 10.5 (Leopard), at best they've got a beta download of Java 6, and there's no indication at all that Java 6 will ever be supported on OS X 10.4 (Tiger) or earlier. You are right...a full year after the release of Java 6, you'd _think_ that you could rely on it being ubiquitous. But if you did, you'd be wrong. :( If I seem a bit bitter about this, well...it's because I am. :) Pete >> Why are you limited to Java 5? >> Java 6 came out over a year ago on 2006-12-12 [quoted text clipped - 12 lines] > > If I seem a bit bitter about this, well...it's because I am. :) Huh? My wife's Powerbook got (via System Update) Java 6 a couple of weeks ago when she was still running Tiger (she's on Leopard now). SignatureJohn W. Kennedy "Sweet, was Christ crucified to create this chat?" -- Charles Williams. "Judgement at Chelmsford" >>> Why are you limited to Java 5? >>> Java 6 came out over a year ago on 2006-12-12 [quoted text clipped - 15 lines] > Huh? My wife's Powerbook got (via System Update) Java 6 a couple of > weeks ago when she was still running Tiger (she's on Leopard now). <http://developer.apple.com/java/> > Mac OS X includes the full version of J2SE 1.5, pre-installed with the > Java Development Kit (JDK) and the HotSpot virtual machine (VM), so you > don't have to download, install, or configure anything. ... > Apple has recently released a new developer preview of Java SE 6 for Leopard > via the Apple Developer Connection (ADC) site What does "java -version" say on that Powerbook? SignatureLew >>> Why are you limited to Java 5? >>> Java 6 came out over a year ago on 2006-12-12 [quoted text clipped - 15 lines] > Huh? My wife's Powerbook got (via System Update) Java 6 a couple of > weeks ago when she was still running Tiger (she's on Leopard now). There was a thread about this a while ago in c.l.j.p: <http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/0e 5f2b1771436088?fwc=2> Looks like it's "Java 1.5 Release 6 or something like that. DF. > Huh? My wife's Powerbook got (via System Update) Java 6 a couple of > weeks ago when she was still running Tiger (she's on Leopard now). As Daniele points out, what your wife got (I got it too) was what _Apple_ calls "Java 6". But it's not the 1.6 version of the JRE. It's Apple's sixth version of the 1.5 JRE. I leave it to the reader to assess what Apple's motivation might have been in using a phrase associated with the actual latest version of Java in describing their far-obsolete own implementation of Java. Pete Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.