tag:blogger.com,1999:blog-56491083828100384172014-10-06T21:58:00.999-07:00Coding Java and XML with JAX-BJohn Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5649108382810038417.post-7256472787828043672013-01-21T15:32:00.000-08:002013-01-23T21:33:37.707-08:00A passionate defence of Java's virtues<a href="http://www.infoworld.com/t/web-browsers/how-disable-java-in-your-browsers-210882">Well</a>, <a href="http://www.infoworld.com/t/java-programming/how-kill-java-dead-dead-dead-210860">that</a> <a href="http://www.infoworld.com/t/java-programming/why-fixing-the-java-flaw-will-take-so-long-210946">was</a> <a href="http://www.infoworld.com/t/security/why-the-java-threat-rang-every-alarm-211061?page=0,0">quite</a> <a href="http://www.infoworld.com/d/security/just-patch-java-easier-said-done-210973?page=0,1">a</a> <a href="http://www.infoworld.com/d/security/major-flaw-in-java-based-spring-framework-allows-remote-code-execution-attackers-211066">pile</a> on, wasn't it?<br /><br />Just along one thread about the Java™ programming language, we get a number of solid reporters and a couple of "gurus". The reporters explain the facts about the current vulnerability in one Java sub-system; the "gurus" mount an all out attack on Java. I have three observations to make here:<br /><ol><li>In a neighbourhood afflicted by a string of burglaries, the headlines do not read: Locks Fail in Leaside. Every story about an "exploit" should, at least in passing, lay the blame where it belongs: with people who take advantage of that security flaw to harm or extort other people. Yes, I do mean every single story, every single web log post. I do expect journalists to continually remind us, and themselves, that we have a choice about living in the network version of Hobbes's war of all against all.&nbsp;</li><li>On the subject of war: the governments that have evidently decided to take their conflicts into our living rooms, work places, children's schools, power plants and hospitals by making it "cyber war" do not answer to some mysterious force from outer space. They answer to us. We can demand general disarmament. Whether or not we choose to do this, I expect the people now hounding Oracle for "security flaws" to at least mention the truth in passing. Government preparations to make war on the net don't threaten us because of Java; they threaten us because of the choices many of our own governments make. </li><li>Every day, I encounter downloads of applications from publishers that don't provide a digital signature and expect me to run their products in native mode, on the bare metal in my computer. Like most users, I make the best of this: I scan every file I load or download with two virus scanners, one of which keeps demanding that I uninstall the other. In this environment, the idea that Java stands out as a particular threat, particularly one so severe it requires government <a href="http://www.infoworld.com/t/java-programming/how-kill-java-dead-dead-dead-210860">coercion</a>, doesn't pass the laugh test.</li></ol>I have a simple plea: let us not lose sight of the many innovations of Java. Working with Java, I and many other programmers first encountered an integrated approach to coding and documentation through JavaDoc. Java offered the first and still some of the best facilities to integrate a flexible programming language and the W3C xml language.&nbsp; Above all, Java integrated the language and support routines, and in the process instituted and enforced coding standards. Languages such as c and c++ have no rules and standards for identifiers: Java does. That alone adds considerably to a priceless asset: any reasonably skilled programmer who knows Java conventions can read a Java application source and have a pretty good chance of understanding it. With c or c++ or some other language that does not provide a common naming scheme, a programmer must work harder to do the same thing. Java designers also added considerably to its readability by eliminating the requirement for headers, that fragmented the sources&nbsp;of c and c++ into headers and regular files, the simple rational structure of packages, classes and interfaces, and the rule that every public class should have its own source file, and that file should have the name of the class it contains. These simple intuitive rules, coded into the structure of the Java language, did a huge amount to propagate good program design practise.<br /><br />Given the advantages of Java for systems construction, it should surprise nobody that that it powers so much of the web we take for granted. Java gives the web Apache Tomcat, the Glassfish application server and many other important server-side systems, and its contribution to structuring good system design, much the way Algol and Pascal helped promote the structured programming approach taught by Edsger Dijkstra has helped the growth of the practical computing systems that power the web. In the current hysteria about security flaws in one or two parts of the overall Java system, the demands that we kill Java require careful scrutiny and a balancing of the contributions of Java's design against any defects some parts of the system may have.<br /><br />On one level, this represents a rational calculation. But whether the calls for the elimination of Java reflect merely frustration with the slow pace at which Oracle hardens the language against intrusions, or whether it reflects the desire of a few writers on security to force programmers and enterprises to do what they have failed to persuade us to do, it is simply unacceptable to ignore the contribution the designers of Java have made. John Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.com6tag:blogger.com,1999:blog-5649108382810038417.post-46674636327153760742012-08-29T19:39:00.000-07:002012-09-12T14:39:51.042-07:00Schemas: starting with elementsIn the previous post, I discussed the schema header. In this post, I intend to discuss the schema element template definition. Because every XML document must have a root node, every schema must have a root element template definition.<br /><br />The element template definition plays the central role in the schema. An element template defines the three parameters of any element: the element name, the permitted contents, and any attributes it has.<br /><br />An XML schema definition always defines an element template name using the <code>name=""</code> attribute. If an element definition template in a schema starts like this:<br /><pre><code><br />&lt;element name="anElement"&gt;...&lt;/element&gt;<br /></code></pre><br />then the corresponding element in a document that conforms to the schema will look like this:<br /><pre><code><br />&lt;anElement&gt;...&lt;/anElement&gt;<br /></code></pre><br />A schema has two ways to define the permitted contents and attributes for an element template: defining a simple or complex type, which will enumerate or otherwise define the content permitted, or else by template definition, or by defining a named type, either a simple or a complex type, within the schema, and referring to it using the <code>type=</code> attribute of the element template definition element. Type specifications determine what elements or raw data types an element may contain, as well as what if any attributes it may have, and whether users must define those attributes, and any default values.<br /><br />Essentially, creating a schema means defining data structures using XML, rather than a procedural or functional langage like the Java programming language, or an interface specification code such as IDL. XML schema represent actual structures using the <code>&lt;complexType&gt;</code> element. A <code>&lt;complexType&gt;</code>element typically contains a nested <code>&lt;sequence&gt;</code> element, which defines the nested elements the element template may contain, typically in the order in which they must appear.<br /><br />The main element of the SaleCo schema has the name of "definition" in other words, a document conforming to the SaleCo schema must contain one root element: <code>&lt;definition&gt;</code>. This definition element must, in a schema-compliant XML document, contain a series of elements: <code>&lt;driver&gt;</code> and <code>&lt;dbURI&gt;</code>. It may also contain optional elements <code>&lt;dbUser&gt;</code> and <code>&lt;dbCredential&gt;</code>, and any number of <code>&lt;report&gt;</code> elements. This permits a schema-compliant document to describe the basic parameters for performing an SQL statement using a database accessed through JDBC.<br /><br />The entire schema appears in the text box below. In the next post, I hope to take a first look at using and defining types.<br /><br /><textarea lines="18" readonly="true" style="height: 500px; width: 600px;"><?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jxb="http://java.sun.com/xml/ns/jaxb" xmlns:tst = "http://SaleCo.me.org/specification" targetNamespace = "http://SaleCo.me.org/specification" jxb:version="2.0"> <xs:element name="definition"> <xs:complexType> <xs:sequence> <xs:element name="driver" type="xs:string" /> <xs:element name="dbURI" type="xs:string" /> <xs:element name="dbUser" type="xs:string" minOccurs="0" /> <xs:element name="dbCredential" type="xs:string" minOccurs="0" /> <xs:element name="report" type="tst:NamedSQL" minOccurs="0" maxOccurs = "unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="NamedSQL"> <xs:sequence> <xs:element name="sqlCode" type="xs:string"/> <xs:element name="description" type="tst:Glossary" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="reportId" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="Glossary"> <xs:sequence> <xs:element name="note" type="xs:string" minOccurs="0" /> <xs:element name="fieldDef" type="tst:Gloss" minOccurs="0" maxOccurs = "unbounded" /> </xs:sequence> <xs:attribute name="language" type="xs:string" default="en" /> </xs:complexType> <xs:complexType name="Gloss"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="varId" type="xs:NCName" use="required" /> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema></textarea>John Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.com0tag:blogger.com,1999:blog-5649108382810038417.post-61928604800353061432012-08-27T17:23:00.001-07:002012-08-27T17:23:46.080-07:00On rules and opinions... and knowing the difference <style type="text/css"> <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } --> </style> <br /><div style="margin-bottom: 0cm;">Computer systems come hedged with rules no programmer can break: the specifications of the operating system interface, the syntactical rules of the language, the basic mathematical theorems that govern computing. It sometimes seems that everyone who writes about computers would like to make more. </div><div style="margin-bottom: 0cm;"><br /></div><div style="margin-bottom: 0cm;">I tend to group the rules for computing that I read about into three classes. The first class consists of rules derived from strong, meaning mathematical, theory. The computer scientists who designed the control structures we all know: if-then-else, while, do while, and so on, derived these structures from graph theory principles that determine the best way to get through a computer program. The rules and recommendations I group into the second class consist of common sense recommendations based on the actual social structure of programming groups, and the limitations of human beings at complex tasks like programming. These rules include decoupling modules, coding to abstractions, and generally making it as easy as possible to modify programs or systems without breaking them. The third class rests on esthetic perceptions. A book I looked into recently advised programmers to make routines as short as possible, in most cases four lines or less. While I applaud brevity in programming as much as anyone, I do not agree that breaking a method into two or more short methods makes it better, unless the program gains something by it, such as more effective code reuse, or a shorter or more elegant calculation. </div><div style="margin-bottom: 0cm;"><br /></div><div style="margin-bottom: 0cm;">Programmers laugh at ourselves over our habit of fighting bitter battles over matters of style. We laugh, but the habit we laugh at in ourselves has high costs: to our working relationships, to our important ability to collaborate, and above all, to our ability to reject arguments that really do not make sense. To change this, I suggest borrowing a technique from pilots: the concept of personal minimums. Pilots, like programmers, have a great many rules to follow, from those derived from the physics of flight, to government regulations. Within these rules, Pilots establish personal minimums: restrictions that go beyond the rules to fit each pilot's circumstances, talents, level of skill, and training. The concept of personal minimums has a huge advantage for programmers: a pilot can establish a personal minimum without making claiming any superiority over pilots who have different minimums. Language used by programmers, such as the term “best practices”, on the other hand, often imputes superiority to the programers who use certain recommended methods or tools or practices. </div><div style="margin-bottom: 0cm;"><br /></div><div style="margin-bottom: 0cm;">With this web log, I will try to make information I have gathered through research and experience available to other people. Like any web log, this one also reflects the perceptions and opinions of its writer. I will do my best to make the facts as accurate as possible, and also to make it clear when I do not know something. Please take the perceptions, opinions, and practises as those of one person. Accept them, or not, as they make sense to you, but above all, please evaluate them critically.</div>John Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.com0tag:blogger.com,1999:blog-5649108382810038417.post-92011089526551098512012-08-27T17:20:00.000-07:002012-08-27T17:33:15.341-07:00Schemas: starting at the top (with the header)This web log deals with the interface between schema-defined XML documents and Java programs. So what is an XML schema, and more important, how do you code one?<br /><br />When <a href="http://en.wikipedia.org/wiki/Charles_Goldfarb">Charles Goldfarb</a> and his team at IBM came up with the idea of describing text by what it should convey (markup) rather than by what it should look like, they developed the first markup language. At that time, a major distinction between text and other forms of data existed. The idea that markup languages existed to describe the presentation of human-readable text persisted right through html. By the time the World Wide Web consortium designed XML, the development of translation and other natural language processing programs had begun to erase the distinction between data and text, and programmers had come to appreciate the possibilities offered by markup languages for structuring input into programs. This led to a call for the development of XML schemas in the late 1990s.<br /><br />An XML schema describes the structure of an XML document, and the elements nested within it. The schema describes basic types for the contents of elements and attributes: an element can contain strings of characters, numbers, or sequences of other elements.<br />The first post on this blog described the process of compiling an XML schema. The name of the schema was “SaleCo.xsd”. Let's take a look at that file and see some of the basic elements of XML schemas.<br /><br />An XML schema consists of an XML document with an appropriately named root element of “schema”. The main element declaration for the SaleCo schema definition looks like this:<br /><pre><code><br />&lt;?xml version="1.0" encoding="UTF-8"?&gt; <br />&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <br /> xmlns:jxb="http://java.sun.com/xml/ns/jaxb" <br /> xmlns:tst = "http://SaleCo.me.org/specification" <br /> targetNamespace = "http://SaleCo.me.org/specification" <br /> jxb:version="2.0"&gt;<br /></code><br /></pre>This element declaration refers to several namespaces, all of which play an important role in the schema definition.<br /><dl><dt><code>xmlns:xs</code></dt><dd>Declares this document uses the XML schema namespace, as defined by the World Wide Web consortium. The schema namespace contains all of the elements, attributes and constants used to describe an XML schema.</dd><dt><code>xmlns:jxb</code></dt><dd>The JAXB namespace contains useful elements and attributes for defining a schema the JAXB processor will convert to Java. These include elements for adding JavaDoc comment contents to the Java code the JAVB compiler will produce. This makes coding the Java objects and methods that will use the data much easier.</dd><dt><code>xmlns:tst</code></dt><dd>Defines the namespace for the elements and attributes this schema will define.</dd></dl>You will notice the header defines the document namespace twice: once with a conventional xmlns declaration, and once with an attribute called “targetNamespace”. The target namespace defines, among other things, the name of the package that the Java classes compiled from the schema will belong to. The namespace defined in the target namespace should match the namespace defined for the elements and attributes the schema will define; I have found that when I did not ensure these values matched, my schema would not compile.<br /><br />Finally, the schema declaration contains a version number for the JAXB specification.<br /><br />That covers the header for this particular schema. Posts following this one will touch on other options provided by the schema element definition, and others will deal the other elements in this example SaleCo schema.John Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.com0tag:blogger.com,1999:blog-5649108382810038417.post-11455497495697741282012-08-14T23:51:00.000-07:002012-08-14T23:51:29.965-07:00Using JAXB with NetBeans.. the Hello World example<div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-aerKNLYqjM8/UCsa7_nUKcI/AAAAAAAABdI/OTR23u36elw/s1600/JAXB+001.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" border="0" height="276" src="http://1.bp.blogspot.com/-aerKNLYqjM8/UCsa7_nUKcI/AAAAAAAABdI/OTR23u36elw/s400/JAXB+001.png" title="Selecting the JAXB node to add" width="400" /></a></div>Netbeans makes using XML with Java relatively simple. To integrate an XML schema into a Java program using JAXB, first create your schema according to the schema rules. Then open or create a&nbsp;NetBeans&nbsp;project. The project node list will appear in the upper left panel of the NetBeans screen. Right click on the project node to get a pull-down menu and select <code>New</code>. You will get a new sub-menu listing the most commonly created files. If this menu of new types doesn't include the JAXB type, then select <code>Other</code> at the bottom. A file types dialog will appear. This dialog will have two panels: the file category, and the specific type picking panel. Your copy of NetBeans should have a file category of <code>XML</code>; choose this in the left-hand window. A list of specific <code>XML</code> file or object types will appear in the right hand window. This list should include a JAXB node. Pick this option and click &gt;code&gt;Next.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-2AVTKq7AVxs/UCtGag-Io8I/AAAAAAAABdg/DcOGf5LyV1I/s1600/JAXB+003.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="291" src="http://2.bp.blogspot.com/-2AVTKq7AVxs/UCtGag-Io8I/AAAAAAAABdg/DcOGf5LyV1I/s400/JAXB+003.png" width="400" /></a></div>Next, NetBeans will display the schema specification dialog. You have to specify two things about your schema: you have to give NetBeans a name for the JAXB node. This does not mean the filename or the package name. NetBeans just needs this name to refer to the node. In this example, I use <code>Test_Binding_01_v1</code>. Any string will do; I prefer to use a name with a version attached. Then, of course, you need to specify a schema. You can link to a schema from a web site, or load one locally. Here, I refer to a local test schema. Once you have named the node and selected the schema, click <code>Next</code>.&nbsp;Clicking <code>Next</code> starts the actual process. NetBeans will now create a <code>JAXB</code> node, copy the schema file you specify into it, and then compile the schema.<br /><br />Compiling the schema will produce a set of Java classes. These classes can contain the data from the schema, or to put it another way, they make it possible to translate an XML document that conforms to the schema into a Java structure. And the introduction ends here. I hope to go on to discuss some techniques for designing and coding schemas, translating XML documents read in from the web, some of the design paradigms I think apply to Java and XML, and go into a bit more detail about why I think the interaction between Java and XML will pretty much define the future of both languages as applications, as well as storage, moves deeper into the Internet cloud. <br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-aeoyu9NlkVU/UCtGaEaAHTI/AAAAAAAABdY/pZFdZW6Rr8w/s1600/JAXB+002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="444" src="http://3.bp.blogspot.com/-aeoyu9NlkVU/UCtGaEaAHTI/AAAAAAAABdY/pZFdZW6Rr8w/s640/JAXB+002.png" width="640" /></a></div><br /><br />John Spraggehttps://plus.google.com/113926804022938837896noreply@blogger.com0