Slashdot Mirror
XML and Java, Developing Web Applications
Unfortunately, they might have put a little more thought into the bigger picture with this approach, because what they have ended up with is a book that reads like a play with two completely different acts: the second showing a wide variety of applications of XML for the Java platform, which works well enough, and the first, which attempts to teach the basics of working with XML and Java, which isn't quite so strong.
The GoodOne look at the table of contents should convince you that the book rates pretty highly on buzzword compliance (XML, DOM, SAX, SOAP, XLST, WSDL, UDDI, JSP, EJB, etc.). When it comes to content that should impress your manager, you could do worse. The accompanying CD-ROM also comes with some neat stuff, like Tomcat, Jakarta and Xerces, and trial versions of WebSphere and DB2. As an added bonus, the code within has been tested on both Windows and Linux.
For the most part, the progression through the topics is well-directed, with in-depth discussion about the different means of XML parsing and generation using both DOM and SAX early on, and after going through the early chapters the reader should already have a decent idea about what techniques might fit their own personal projects. Tamura's chapters on DOM and SAX in particular stand out, not just for the coverage he gives the two, but also for his comparisons of one versus the other. They serve as a decent enough primer to prepare for the latter chapters, although the reader might be better equipped if they gained some extra foundation from other sources (more on this in a bit).
Despite the breadth of topics, they don't throw in the kitchen sink. Readers are expected to get their introductions to XML and Java elsewhere, and while one can probably get away with a surface understanding of XML and still get what they need out of the book, the same cannot be said for the needed Java knowledge. However, for someone who has a good understanding of Java and the various surrounding technologies (JavaBeans, Java Server Pages, and so on), there's some pretty good coverage of the different ways that XML can be incorporated. They've even taken care to provide appropriate supporting material, talking about where the various standards may be headed, some coverage on the theory behind Schema design, and there's even an appendix that explains JDBC, to serve as a counterpart to the chapter on XML and databases.
This book is in many ways an example of the way second editions should be. This book has double the chapters of the original, and efforts have been made to cover as much additional (but still relevant) material as possible, including XML Schemas, namespaces, messaging, web services with SOAP, and security. Some of these topics were in the first edition, but bunched together into a single chapter. In this book, they get individualized treatment.
The Not-So-GoodIt's a hopeful endeavor to bring together nine authors and expect that there can still be stylistic continuity, and this book is a good example of what happens when the editor doesn't lay a heavy enough hand. There are inconsistencies from one chapter to the next in the way code snippets, method lists and diagrams are incorporated (in particular, the use of line numbering by Uramoto and others is unintelligible to the point of inspiring wrath). Furthermore, because each author handles their subject matter just a little bit differently, it's hard to get into any sort of a learning rhythm. In this case, the whole is probably weaker than the sum of its parts. A good section, like the one contributed by Tamura for instance, loses some of its luster if the chapters preceding it or following it aren't up to snuff, as is sometimes the case throughout the book.
To be fair, things do improve in the latter chapters when the authors are focusing on more specialized cases, and such expectations of continuity become somewhat moot. However, even then, the authors obviously have different opinions on how steep the learning curve needs to be. The chapter on JSP, for instance, eases you in and begins with simple examples, despite the fact that embedding programming code within HTML is pretty intuitive, comparatively speaking. The chapter on WSDL, on the other hand, makes no such assumptions of a beginner's audience, and it's trial by fire, with long stretches of code and in some cases nary a comment in sight. It's understandable that talking about distributed programming necessitates long code listings, but a newbie is going to experience some serious hymen-breaking here.
If there is any consistency, it's a pretty clear editorial bias towards Xerces over JAXP early in the book, including a special chapter on parser tricks specifically for Xerces. No real surprise there, as several of the others have been key contributors to IBM's open source project. Still, it's poor form to be using the pages of a learning guide to talk smack about one over the other, if for no other reason than the fact that it becomes a distraction to somebody who's trying to learn with an open mind towards all the possibilities. If a comparison is absolutely necessary, it deserves its own chapter away from the rest of the learning material. This brings up another problem, in that by mixing JAXP and Xerces techniques together early on, you run the risk of overwhelming a neophite who'd be glad to figure out just one way of doing things. There's already a marked difference between DOM and SAX parsing, and doubling this with the duality of JAXP vs. Xerces makes for an introduction that's a little too busy.
Also, what was mentioned in the previous section as one of this book's strengths is also a bit of an audience-limiter. If you try coming to this book without a solid founding in Java, there's a decent chance you'll find it difficult to get into this book. People who are already soured on Java will likely find their distaste further entrenched, and it's doubtful that anything beyond the most conceptual of the subject matter will be portable.
ConclusionThere's something to be said for bringing in the biggest authorities in the field to present a subject -- however, it's one thing to know a subject and another thing completely to know how to teach that subject well. John Madden once said that the best teachers are the ones who got C in school because they're the ones who best understand the intellectual bumps and bruises that can come from learning a new subject, and can help prepare and guide a student through them. There are no C students in this bunch -- readers are left to their own devices to keep up with the authors and fight through the numerous obstacles to get at the core knowledge within, which is admittedly impressive enough. Far be it for a lowly Slashdot contributor to tell the folks at Addison Wesley how to do their job, but on a third edition they might want to put the material through a stronger editorial filter to make things a little easier on the reader. This is definitely a book to preview in the bookstore very carefully before considering a purchase.
Table of Contents Preface.1. Web Application, XML, and Java.
2. Parsing XML Documents.
3. Generating XML Documents.
4. Working with DOM.
5. Working with SAX.
6. Parser Tricks.
7. XPath and XSLT.
8. Bridging Application Data Structure and XML.
9. Working with Schemas: Datatypes and Namespaces.
10. XML Application Server.
11. XML and Database.
12. XML Messaging.
13. Web Services.
14. Security.
15. Data Binding.
16. Principles of Schema Languages.
Appendix A. About the CD-ROM.
Appendix B. Useful Links and Books.
Appendix C. XML-Related Standardized Activities.
Appendix D. JDBC Primer. Related Links Addison-Welsey website
W3C's XML page
Sun's Java page
You can purchase XML and Java, Developing Web Applications from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.
Come on Grandad, tell us what it was like in the 90s before .NET was invented.
.
I bet you know some stories about that old time JAVA they used to use.
Cut to picture of JAVA hackers face down in the dirt with arrows in their backs. . . .
Because Microsoft is trying to drop Java, and Sun isn't driving it as hard as it used to, I personally don't view Java as a viable solution for web development anymore. Java had it's place, but I think it's no longer fast enough for current practices. I think PHP or another webside language/scripting language would be more beneficial at this point than using Java, and certainly easier to intereface with XML from what I've seen. In fact, with HTML servers these days there's already native XML/XSLT support, making server side scripting/applications not even needed in some cases.
There's about 64 million people fluent in XML and Java, and approximately 4 jobs available (3 of which are already going to relatives). Good luck getting one--try the lottery, the odds are better.
Java is the ONLY way to do efficient stored procedures in Oracle. PLSQL is nice for strict data chunking but anytime you need to do something useful like opening up a socket, Java is the way to go
"...to show just how much of a heavy-hitter Java still is in the enterprise world."
For me,I don't really need a book to convince me that Java is still a heavy-hitter. It has always been one the major languages to me; it was just two or three years ago that the thing actually had it's own comic book (JAVAMAN! Saving the day from bugs and viruses!).
3l33t 0p3n S0uRc3 d00dz always have and always will use C!
OO is just crap. The only people who care about speedy development are sell outs trying to meet a deadline for the man!
And buffer overflows that are always a part of C programs are important becuase it keeps fascist sysadmins from keeping root power from the users!
Java is just a tool of the man.
Programming languages should be frozen in time like it's 1969 forever! C forever!!!
Unfortunately, a major problem with web application is the trade off between the too-simplistic HTML only model, and the too-heavy Java model.
.. well, using Java. Slow to load and slow to use, the trade off here is responsiveness.
For example, take an HTML form. Let's say you had a few hundred choices for one of the textboxes on that form. It would be incredibly useful to be able to type in the few first letters of the text and press a button to search for all matches and display them in a selection box next to it.
HTML is too simplistic to do that, even with Javascript extensions, but it would be an incredibly useful feature for a data entry application.
Trying to use Java for it would mean
Until such basic input methods as forms can be made to work as well as traditional (client/server) based applications, web applications will fail.
And XML? Big deal. There has been a standard format for data exchange around for years, and it's called 'CSV files'.
Apache XML projects
Apache Java projects
Explore the projects at the above two links. All the most exciting and usable Java/XML technologies are in there, ranging from SAX/DOM Schema aware parsers to transformers, databases and query languages for XML.
XML is not a Java only technology, far from it. I fail to understand why so many books appear to try and make it look so.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
The reviewer seems to be worried about the information density in this book. I would say it is a good thing that this book doesn't bother explaining how to compile hello world. If you don't understand the Java syntax, you're reading the wrong book.
Another good thing is that it doesn't include API documentation. API documentation seems to be a popular way of wasting dead trees but IMHO it is much easier to browse/search in HTML form. That leaves more room to content you'll actually need. There's so many Java books out there that use more than half of the pages for introductory stuff and API documentation and then try to squeeze the stuff you really need in ten pages or so.
Jilles
JAXP and Xerces do different things. JAXP is essentially a standard interface that can be used to decouple your parsing code from a particular parser implementation. Xerces is one such implementation (for DOM, SAX, etc.) which can be used underneath JAXP and therefore unseen by a developer. As such it can be used by JAXP but is never in competition with JAXP.
As far as I can remember, JAXP has little or no implementation code.
From the article: The accompanying CD-ROM also comes with some neat stuff, like Tomcat, Jakarta and Xerces, and trial versions of WebSphere and DB2. As an added bonus, the code within has been tested on both Windows and Linux.
So in other words, the CD has a bunch of (almost certainly) out of date versions of Open Source software in order to drive the price up. Vote with you dollars -- don't buy books with CDs!
Content about things like WSDL is also likely out of date by the time it is published.
I'd say there are probably a lot of good online tutorials on these topics that are probably more up to date.
I am not a number! I am a man! And don't you
Q: Why use reinvented tools for reinvented tasks?
A: To reinvent the solution!
Makes perfect sense to me. If you are wondering, XML is nothing more than flawed S-expressions and Java is a reinvention of a P-code interpreter. Combine the two and you have more reinvention. All paths lead back to the future...
"...it was just two or three years ago that the thing actually had it's own comic book (JAVAMAN! Saving the day from bugs and viruses!)"
Can anyone provide a link to any JAVAMAN comic strips or pictures?
I agree. Java and Linux have not always gotten along, but that's changing now. It's even more important that this happens in order to provide an alternative to .NET. Now if only we could get a good open source/free software JVM . . . (anyone know of one other than Kaffe?)
Who said Freedom was Fair?
For good reason. There is zero demand for XML web services on the right now, no real support for security, and still-evolving standards.
I wonder if M$ is going to change a lot for these 64M unemployed. I guess .NOT
Download the full Manning book J2EE and XML Development (pdf) here
You can also get a full copy of Bitter Java there.
Geez,what does that make us COBOL-85 hackers?
Piltdown man probably...
From my Autobiography - "Lifestyles of the Sad and Desperate"...
I never really spend too much time advocating Java, even though I develop in it just about every day. There will always be people who play the other side, the devil's advocate, who regurgitates all the possible negative things that can be said about it...slow, not open, run once and debug everywhere, etc.
.NET thing has given me great pause. When it first came out, so many of my friends, mostly developers, started gleaming with energy about .NET. It was the greatest thing since sliced bread, and it was going to revolutionize computing as we know it. It was so tight, elegant, powerful, with great performance, and a much better GUI library.
So now, I want to say just how much I really enjoy and appreciate it as a technology. It's a complete dream to work with, with an absolutely huge library, extremely well done documentation and support, instant answers to just about ANY question at Google Groups, and a huge community around it. I think Sun has found a great balance between being open and providing leadership and definition.
As a professional, the whole
Instead of the hype settling down into seeing it just as a good tool, almost all of them have switched away from it. It was cool at first, they explain, but now they realize that it's still run by Microsoft, it still needs Windows, and almost everyone except Microsoft still has no idea what's going on under the hood.
So it seems like it's simply a pre-requisite to the Internet Age that the source code must be available. The rules have changed, and the game people now are most excited about playing requires that the source code is available. It's now just a part of the ground rules. You can still play the old game, but the best and brightest are now playing a new game, and to prove yourself and be a part of the new game, you have to play by the rules. There are still people pretending (especially to themselves) that this old game is really exciting, but those playing the new one see how much better it is.
So, I definitely expect that Java will continue, and that the ringing endorsement of Java by Microsoft will lead to a huge renaissance. It may be that it will have to become GPL'd to have a chance, but that's not clear at the moment. I think it's just a matter of time before it starts to take over on the client, and the eventual GUI for Linux will be written in Java. In the same way that you don't notice the BIOS when you run the OS, you won't even notice the OS when you run whatever becomes the NET GUI.
I haven't read this book, but from the fact that I own already a couple of such XML books with plenty of chapters with different technologies, I know that the only effect of it is that it doesnt cover a shit in details any of the technologies. Hence useless.
...) that you happen to use has its corners, side effects, and many little things that make XML IN THE REAL WORLD NOT A STANDARD AT ALL, NOR XSLT, NOR ANY SHIT. For this reason, a book that only tells you that XML is an interoperable standard made of elements and attributes is SIMPLY LYING TO YOU. Money for it should be given back.
What's even more uncomfortable to my mind is that I never hear any developer here talking about the fact that EACH XML PARSER (including expat, xerces, msxml,
(Above is an affilate link)
It was nice of you to say so, at least, but for myself I don't really like it when people post affiliate links like this. This is too much like a barely-on-topic advertisement for my taste.
In case readers don't know, Amazon's affiliate program is basically a system of kickbacks. Person X signs up with the affiliate program and starts handing out special links to the Amazon site. If person Y clicks person X's special link and then buys something, person X gets a small amount of money from Amazon. They say up to 15% of what person Y spent, but I'm sure it's a lot less that than most of the time.
Long story short, people who post affiliate links to Amazon's site are really trying to maximize their gains from the affiliate program. I can't put my finger on it, but that just gives me a funny feeling for some reason.
I'm not flaming you or anything, so don't get mad. I'm just voicing my opinion. Slashdot soapbox and all that.
--Socrates
But there is still plenty of work to do getting it into the system. I've got this pagination engine, see. It doesn't have an integrated lisp machine. In its absence I'll have to stumble along with pointy brackets.
The AC is thick, the comment tendentious. XML consciously borrowed the concept. Have a look at XSLT; remind you of anything?
illegitimii non ingravare
ability of public speaking is not the same as intelligence.
who had better grades in college, GW, who had better SAT's GW.
gore is a better public speaker (i dont like his speaking ability either though, to much of a stereotypical politician
Python isn't hyped as much as Java. This has had a positive effect on the quality of books written about the language. You don't have to plow through hundreds of bad books when looking for a good book on the language. The referenced Python book had the following description on Amazon.
http://www.blackdown.org/
Python still can't match Java for XML developement.
...
JAXP Java API for XML parsing.
JAXM Java API for XML messaging.
JAXM Java API for XML Registries
JAX-RPC Java API for XML-based RPC
SAAJ SOAP with Attachments API for Java
JAXB Java API for XML binding.
The above API are very well designed and have amazing features, for example you can change with JAXP your XML parser at runtime, JAXB allow you to generate Java objects from your XML documents which facilated web services, JAX-RPC makes soap so much easier to develop and deploy
Add on top of these the rich J2EE platform, J2ME and the Java standard APIs and you could see why java is the best platform for large scale web application.
No marketing-driven language has got it right yet. Common Lisp can, though.
Markup is inherently platform-independent for the same reason that scripting languages are: requires an interpreter on your platform.
Pop quiz: Where does the term markup originate?
illegitimii non ingravare
IHBT. :)
You can always identify the leader in a race by looking for the guy with all the arrows in his back.
but I was alone.
illegitimii non ingravare
assuming somebody comes up with something that can be done better with web services than with a regular browser-based web app or a Java app or something
t -architecture to user tools like Windows Update or whatnot. Any application can use the SOAP protocol to communicate with their server instead of proprietary binary, text, or XML formats; multi-tier architectures will increasingly use SOAP to communicate; etc.
Web services are for anything without a user interface: from replacing DCOM/CORBA/other-proprietary-distributed-componen
Basically, whenever one computer talks to another computer without user interaction, it'll increasingly be done with SOAP (ie. Web Services) instead of the plethora of proprietary and customized communication formats. Just like text, TCP/IP, HTTP, and XML, SOAP standardizes how computers talk to each other. I'm sure you can think of some more business examples of computers talking to other computers...
The only thin about SOAP that's useful is the platform neutrality of the protocol. It's an XML message over a protocol which is widely enough implemented that compatibility is not really an issue. If you're just doing a distributed Java app, use Java native tools; unless you expect to incorporate non-Java clients.
All the languages referenced in your links were not statically typed (Python, Perl, Lisp).
The dynamically-typed languages are very useful and powerful for individual programmers, smart programmers, and small, tightly-knit teams. But static typing is an important feature in the commercial world, where software has to be worked on by ever-changing teams of often mediocre people. Static typing provides an enormous safety net in these environments, and supports capabilities - such as automated refactoring and IDE hinting - which are nowhere near as powerful in dynamically typed languages.
The best way to understand the benefits of static typing is to ask the question "would it help if the computer had more information about the program it was running?" The answer, by many criteria - performance, safety, reliability, maintainability - is yes.
As for p-code, the last widely-used p-code based system that had static typing was probably USCD Pascal, which dates back to at least 1980 or so. Java is certainly an improvement over that. Java did in fact advance the state of the art, quite significantly. Considering that Guy Steele, coinventor of the awesome language Scheme, was on the original Java team, perhaps they got some things right which you haven't understood yet.
Finally, the "XML as flawed S-expressions" meme may have some truth to it, but it's also so misleading that it's valid to characterize it as simply wrong. The real benefit of S-expressions arises in "code is data" languages like Lisp. No-one has yet come up with a statically typed language that supports this model, so it's not valid to claim that Java+XML is a reinvention of Lisp+S-expressions; it's an evolution in a direction in which Lisp has typically been very weak.
- It works perfectly with relational algebra;
- It allows meta-programming;
- Predicates are the perfect fit for WHERE expressions;
- Database concept is already in Prolog.
The only problem is the lack of Prolog skills in Oracle CorporationLess is more !
There's one more thing you need: JDOM. It's basically a wrapper for XML parsers that make manipulating XML in Java much less painful. It's good enough, in fact, that Sun has adopted it as a JSR (JSR 102, I think). I bumped into it a few months ago, and it's already made a huge difference in terms of productivity. With JDOM you spend less time worrying about all the oddities of the DOM or the limits of SAX - instead you mess with good ol' Java objects and JDOM does the rest.
The review talks about the difference between Xerces and JAXP. I thought Xerces implemented JAXP - could someone explain how they are two different approaches?
Thanks, Andrew
http://www.acooke.org
As far as I can tell nobody has it right yet.
Where are my voice/gesture aware applications and 3D interfaces?
Well, in an attempt to cut through all the anti-.NET FUD, let's throw out a few facts: - MS was first company who had a very, very good XML parser (MSXML 2 and 3) back in the IE4 and 5 days. MS is one of the major contributors to the advancement of XML and XML-related standards such as XML Schema (which is SOOOO much better than DTD, let me tell you ) - Java's support for XML was pitiful, broken, and horrible until just recently. There wasn't even a complete XML DOM solution in Java until JDK 1.4 which was only recently released! - There still is no good Web Services implementation in Java other than costly commercial implementations from BEA and IBM. In short: Java + XML is a joke. .NET has much better and pervasive XML support. Download the .NET Framework SDK (or view the docs online) and see the System.Xml namespace. Then, look at the javax.xml package in the JDK1.4 and then laugh at Java.
Needless to say, saying that "java got it right first" is a complete lie.
Exactly, and that would be Perl on Unix. That got it right before Microsoft knew there was such a thing as HTTP.
I bet you haven't tried this. It performs fine, we use a Java XML-bound combo box in in-house web apps which replaced traditional two-tier GUI apps. Used by professional data entry operators who love it. It's not slow to load or use.
Python 2.3a0 (#1, Jun 15 2002, 15:12:54)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "The cow jumped over the moon".find("jump")
8
>>>
Also, the Python language is being improved by the open source community. It's growth isn't hampered by corporate interest. With the release of Python 2.2 the meta programming interface was added and work began on class/type convergence. The meta programming capability enables the core Python object model to be customized from within the language.The type/class convergence has made it possible to derive subtypes from builtin types int, list, dict, or str.
This isn't to say that people cannot be productive using Java. The huge library of software available for Java makes short work of some problems. The purpose of my post was to point out a good book on XML processing and to suggest that Python might be of interest to anyone doing XML processing.
Linux always was the land of scripting languages. Python and Zope have more future on Linux platform than proprietary Java.
An, er, unnamed US state's child support system (terminals connecting to VAX servers) is being replaced with a Java-based web client app.
The old system's usability is simply better. The users can just fly through it, using not very complicated keyboard shortcuts. Even before they learn the shortcuts, they get simple menus they can either arrow through, or type a number and hit enter (for say menu item 5). Tab between fields, of course, and a jump to a field key sequence.
The new app has pulldown menus, clicky buttons, click click clik. Some things you just can't do with keyboard strokes, others are just difficult. Even people who are fast at it aren't as fast as you can be with the old app.
You just can't beat some old terminal interfaces. I wish more people would look to them for inspiration.
All thos JAX* APIs are killing very good competitive implementations, like Apache Xerces. Java becomes more and more proprietary platform of solely Sun. And as such it will die.
I do use python, all my system management scripts are written in python and I love a lot of python's features but i do not think it is a good language for web application and for complex applications that need xml parsing.
I cut my teeth on the old style orange data terminal with fixed width fonts and no pictures. When designed well, the end user's learning curve was extremely low. New people, with no computer experience, were up and working within an hour of their new job. After moving to GUI (Windows) and OO formats, the learning curve increased, and quality of data and data entry speed decreased. For pure number crunching, data entry and access, these old systems were lean and mean, and accurate, and have not been improved upon by the GUI world. Of course, pure number crunching or efficiency is not end of existence or only consideration in designing a system...however I don't buy into the argument that the Java/XML/OO world is better in every way to ideas from the past. Different approaches have different strengthes.
Java will continue to have its place in internet development because of its cross platform abilities.
.Net requires far too much money upfront to build even the simplest applications, including a huge investment in hardware infrastructure to make it work as it was intended. I won't even get into the licensing issues, just to outfit a small group of 5 developers you could spend well over 100K to build and deploy .Net applications.
Java is the only language that will insulate you to the degree of managing a diverse enterprise that requires software development.
It will also for the first time, preserve that investment across OS and hardware upgrades.
That means you don't have to rewrite your business logic just because your hardware or OS technology changes.
The cost savings by using Java is enourmous, without even considering the vs some other companies solution, feature for feature.
So right out the door you have a major incentive for using it in this very highly networked world where vendors, customers, and suppliers, distribution channels all have very diffferent computing environments.
I keep seeing "Java is too slow" comments from people on Slashdot that obviously have never used or have never developed web applications with it lately. So I won't even bother to say your wrong, your just way too inexperienced to understand a discussion on the topic.
Ridiculous.
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
There's hardly an MS shop out there that hasn't felt some misgivings about Microsoft and specifically .NET over the past couple of years - whether because of Microsoft tightening the licensing screws, dumping support for Java, radically changing VB for .NET, or pushing a brand new language (C#) for Microsoft's own benefit, or simply all the information that's come out in court which makes it clear that Microsoft has always been more than willing to screw their customers to make a buck.
IOW, Microsoft has provided us with an enormous amount of FUD ammunition, all we have to do is load up and start firing. Don't be too in-your-face about it, though. Instead, start by asking questions:
Don't get overly emphatic about any of this, you're just asking questions. Once the target has had a chance to think about this - maybe over a period of days, weeks, or even months, depending on the degree to which their brains are set in Microsoft concrete - you can slowly start pointing out the benefits of open platforms.
For example, running Java means using any hardware and OS as your server, today. The WORA creed actually does apply to Java on the server side - we regularly run our server apps on Windows, Linux and Solaris, without changing a line of code. Linux server farms are a heck of a lot cheaper than Windows farms, because of licensing. And if you need a single box that's bigger than any PC-class server, you can't beat the Unix-based hardware that's out there.
Running Java means wide support from multiple vendors, some of them very large and reliable, like IBM and Sun. There's competition amongst vendors in the form of multiple implementations of application servers, JVMs, and Java compilers - you can pick what you need, from open source to expensive enterprise-oriented products. The equivalents on .NET are all single-sourced - no competition, no openness.
The lack of competition within .NET has important implications: Microsoft can't fill all niches, and it doesn't even try. Its offerings are usually skewed towards the most lucrative markets, the biggest enterprises, and as a result smaller businesses that don't need all the features have unnecessary stuff pushed on them. In the Java world, if you want something small and light, you can just download an application server like Jetty, a lightweight but powerful persistence solution like Hibernate, and you've got a kick-ass application development and deployment solution. Powerful open and extensible IDEs abound, with Eclipse being a top contender.
What it comes down to is that companies have to be on some weird kind of crack to think that it makes sense to commit their development to .NET. Microsoft has upped the stakes in platform commitment required from their customers, but it's not offering anything in return. Meanwhile, there's a widely used, widely supported, competitive, successful, open, multi-platform alternative that's available today. The choice here is a no-brainer, folks.
[P.S. for those who object to the Java-centricness of all this, I'm talking about commercial scenarios where Perl, Python etc. are just not considered options. But once companies begin using open solutions, they tend to become more open to other such solutions - I had one IT manager who switched from IIS/ASP to Java/JSP recently ask me where he could download Perl for Windows.]
...go python.
I like the Java language ... but this Java Virtual Machine is a hindrance. For things like downloaded applets that need to run in anyone's browser on any machine, a portable run-time is essential. But for building server-side applications, the JVM is the problem. So I'm looking for a compiler system with libraries that compiles Java to native machine code (with many platforms supported), and still does everything any Java program would expect ... except for things like being able to share the runtime code, both the executeable and the libraries, across thousands of process instances, and the raw speed native code gets. Oh, and GPL, LGPL, or BSD style licensing would be nice.
now we need to go OSS in diesel cars
Strings are objects in Java:
$ 9 [../lib]> java -classpath bsh.jar bsh.Interpreter
BeanShell 1.1a16 - by Pat Niemeyer (pat@pat.net)
bsh % print("The cow jumped over the moon".indexOf("jump"));
8
bsh %
As an added bonus, the code within has been tested on both Windows and Linux.
In later, DOM compliant browsers (ie5+,ns6+,mozilla) the div can even be positioned to the end of the text inside the field, to simulate code completion style behaviour. You also need code to allow the selection of the correct option from that div and then write it to the form field. This is entirely doable from javascript using only it and HTML 4.0.
As a side note: You can use java at the backend to provide the generation of the javascript code. Truly advanced web applications usually make use of a combination of technologies to provide better functionality (java servlets and xml for backend business logic, jsp's for presentation)
--
Overcaffeinated. Angry geeks.
Asp.net is great, but I wouldn't recommend using .Net for making fat apps for anyone. After spending three months working on a small fat application for internal use in our office I ran into all kinds of troubles at deployment. The client target was a series of win98se workstations (which M$ swears supports .Net). After testing a zillion scenarios on four different workstations, wiping and re-imaging after each attempt, the application never ran. I continued to get a System.Policy.PolicyException although there were no policies being enforced on the machine(s) by the network, I was not working from a network share, etc. I exhausted all resources, including M$ support, M$ public newsgroups, dejanews, etc. Now the app ran perfect the first time tried on win2kpro or winxppro. You know what M$ support said? "Well, why don't you upgrade the target machines to win2kpro or xp?" My response? "The machines don't have the hardware to run those platforms, and I'm not authorizing additional expenditures to fix this problem we didn't cause. I'll cancel the project first." So, I did.
.net for fat apps can go take a flying leap for all I care. I'll run VS6 into the ground first.
I'll continue to use Asp.net in my office, but
btw, C# looks so much like java it makes me ill.
Ever considered combining PHP with C-based CGI? I found that opens up a lot of doors. I'd wanted to do something similar to what you were doing, mainly, doing some socket work with PHP to talk to a search engine running in the background, and I wasn't comfortable with what PHP offered.
Still, I found I could pass off the PHP search page to a C-based CGI page that itself connected to the search engine, and then after getting the results pass that back to a PHP page for the search results rendering, and it worked pretty well.
Is that sort of solution unrealistic in the enterprise environment?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
"There's a whole lot of posturing going on in the world on Internet programming right now, and with all of Microsoft's slick marketing for .NET there's never been a better time to remind the industry which platform got it right first."
Yeah, Perl.
"Enter XML and Java, Developing Web Applications (2nd Ed.)"
Whaaaa? Java? The most overrated, overblown programming language ever created. I can, in perl, do everything you can in java, but faster (both development and runtime).
Face it, the *only* reason java has made it this far is because Sun refused to let it die the death it deserved. No such fake support for perl - it's huge because it works.
Course I'm bitter because the dot.bomb I worked for spent 56 million dollars writing a "digital safe" in java that could have been written easier, cheaper, more stable, and modular in perl. Dumb fucks...
Personally its not God I dislike, its his fan club I cant stand (bash.org)
Well that would depend on what your definition of "is" is...
or something like that...
heh.
There are things that the GUI could improve on these old systems: color and shape cues, better formatting, pretty fonts, etc. But too many GUI designers are enamoured with "clicking" and icons.
(* Maybe not in the Internet world, but for internal sytems within companys with heterogeneous applications, there is a great demand for it. We have a whole host of different applications written in a multitude of languages and running on a whole host of operating systems that need to communicate. Web Services offer a great way of doing this. *)
Why not either communicate via the database systems or regular HTTP Post and Get? Send some parameters, and get back the result in whatever format you like: comma-delimited, XML, HTML, BrainF*ck, etc.
Databases already offer queuing, contention management (multi-user), transactions, etc. Why find other ways to reinvent a wheel that you are already paying for in the DB?
Or even FTP for a third option. Between these 3, you have plenty of choice and approaches.
Web services has the same marketing foot that "push services" did. Fortunately, it was pushed into the dump. Somebody just wants to move boxes off the store shelves to keep their pockets fat.
Table-ized A.I.
(* I really enjoy and appreciate it as a technology. It's a complete dream to work with, with an absolutely huge library, extremely well done documentation and support, instant answers to just about ANY question at Google Groups, and a huge community around it. I think Sun has found a great balance between being open and providing leadership and definition. *)
That is not Java the technology, but:
1. The 'network effect' where the more people that use it, the more info there is on it. Sun is playing Microsoft's game.
2. Standard API's.
Why should standard API's be tied to any one language? What is needed is standard GUI interfaces, standard network interfaces, standard file system interfaces, etc. Then the language nor platform would matter. Python, C++, or FORTRAN could all talk to the same API's.
I know, other languages can still talk to Java API's through some fiddling, but the Java API's are optimized for Java syntax and design.
And, the run-time-engine thing does not mean much for server software.
We have plenty of languages already (viva choice). We just need standard protocols so that the OS does not matter for GUI's, etc.
Table-ized A.I.
(* I'm astounded by people who think XML is an acceptable language for writing code....*)
LISP fans have found out that simply by replacing the parenthesis with angle brackets in the interpreter parse rules, they can convince their PHB that they are "programming in XML", but really doing LISP.
They can then be "with it", AND use their favorite language (invented in the late 50's). Retro and cool.
Personally, I like the verbs to the left of the parenthesis....I mean brackets, but to each their own.
Try ColdFusion if you want one flavor of XML/HTML-like programming constructs. I cannot say I recommend it.
Table-ized A.I.
(* using it as they realize exactly how powerful J2EE is for large distributed web applications. *)
Why do they need to be distributed if they are web-based?
I thot the idea of web standards is that it does not matter where the servers are. Thus, you might as well put them all in the same room to reduce/consolidate management costs of them.
Or, are you talking about B-to-B stuff? (In that case, use HTTP Get and Post. You don't need complicated Java crap for that.)
Table-ized A.I.
1. The 'network effect' where the more people that use it, the more info there is on it. Sun is playing Microsoft's game.
.Net is supposedly slanted toward C#. Yes, you can also access the API from C++, but in a constrained way such that your code is similar to C#. VB was changed to VB.net, but it looks a lot like C#. POSIX and much of Win32 is slanted toward C, and thus many things are not done in an object-oriented way. The Java API assumes object-orientation (of course) and is constructed accordingly. Another thing is seen in much of the Java API: The API usually reflects the normal usage pattern. Creating either a server or client socket application is very intuitive in Java, but less so in C.
I'm not sure what the original author of this thread meant, but I wouldn't agree with your statement. The JavaDoc documentation for the SDK is distributed with the SDK, and very easy to navigate. If I am programming with a section of the API that I am unfamiliar with, I often can get by with only the information in the SDK documentation. I have yet to see this sort of thing outside of Sun's Java SDK. Microsoft has MSDN, but I've found it to be less efficient to navigate, and I often must rely on search, which can be very frustrating, where in Java I can use the type hierarchy (i.e. start in java.net for network-related stuff).
Why should standard API's be tied to any one language?
Because each language has strengths that are reflected in the corresponding API. If you have a universal API, it often is slanted toward one language.
(* I often must rely on search, which can be very frustrating, where in Java I can use the type hierarchy *)
Sun's hierarchies often seem *arbitrary* to me. They stuck things places simply because they didn't know where else to stick them. I would rather search on keywords than traverse funky hierarchies and following dead-ends. Demeter lives!
(* Another thing is seen in much of the Java API: The API usually reflects the normal usage pattern. Creating either a server or client socket application is very intuitive in Java, but less so in C. *)
I find very little "intuitive" about the Java API's. I kept thinking of ways to rewrite them to make them "sane" the last time I tried to use them. Lets just agree to disagree and move on. Perhaps you just think like the Sun designers.
(* If you have a universal API, it often is slanted toward one language. *)
I don't know if this has to be the case. Unix-influenced protocols often use text as their transport mechanism so as to not tie things to particular binary representations. This is one of the reasons that HTTP and CGI can run on just about anything.
(* The Java API assumes object-orientation (of course) and is constructed accordingly. *)
What if OOP and/or Java fall out of style? You are dooming something to legacy-land faster if you tie it too closely to a given paradigm or language.
You don't think OO and Java are the pinnicle of programming, I hope.
Table-ized A.I.
.NET? Dunno if that's even a player right now..why don't *YOU* take a look at the Web Services Journal awards:
2 62 002
... plain naive. So what? There's tons of great XML parsers for Java out there, all very good, all with particular advantages. Welcome to the freedom of choice with Java - the benefits of competition and innovation!
.NET/VB user might very well be astonishing - that I know for a fact.
http://www.sys-con.com/2001/PR/code.cfm?page=06
Saying that XML isn't well supported in Java because it just got included in JDK1.4 is
There's been incredible support for XML in Java for years, and the power of some of the Apache XML and XSL based tools to a
Wake up and smell the Java - check out an incredible world pal - you will be impressed. Sure Microsoft's got some good tools, their SOAP toolkit is well respected, what they don't have is the huge development support behind Java.
I, for one, think it's good that Sun hasn't loosened the reins too much on Java, so that it doesn't become fragmented like Unix systems. *ramblings*... Sure, I'd like to add a couple new operators, and I could probably do it without breaking binary compatibility, but where's the long-term benefit?
Yes, I sense your fear, your fear of the bungus.
As to me, I don't believe anything. I *think* its okay to use superior tools, but I find it much more effective to simply describe their superiority, particularly when I raise my voice.
illegitimii non ingravare
If you want to use XML in PHP, then you may want to look here.
Phillip.
Property for sale in Nice, France