Let's put everything into Java?
There's an interesting discussion in the forums. It started with the topic Are you for or against "native XML support" in Dolphin?, but has expanded past that to include ideas for embedding other kinds of content in Java code, like SQL.
brucechapman kicks this kind of thinking up a level in Re: Are you for or against "native XML support" in Dolphin?:
Native XML in java sucks because it is so small minded. If anything is needed to solve this problem, then what is needed is a mechanism to support native ANYTHING. (Well anything that can be expressed in unicode anyway)
XML is one (and probably the most wanted and most obvious) of those anythings, But there is also SQL, regular expressions, and a myriad of other things that have their own syntax (like BNF, and ITU's ASN.1 - those are examples not ways of expressing the syntax) which for some people would be nice to have supported natively.
On the one hand, there's a definite appeal here -- if we're going to have efforts to embed different kinds of content into Java, it makes sense to have a common approach, since that would offer a consistent, predictable means of doing so. It would probably also eliminate overlapping and potentially incompatible appraoches among different embedding efforts. The fact that generics has already taken the angle braces so obviously needed by XML is one example of this.
On the other hand, at what point does this stop being Java? What is the learning curve like when you need to know not just Java, but anything that can be embedded into it, in order to read an arbitrary source file? Sure, I can think of some times when I'd rather have done something in LISP than Java, but how maintainable would it be for me to actually drop into LISP in the middle of a method? Then again, we already build up SQL statements in code today, and if this non-Java stuff were off in another file, how different is this scenario from needing XML deployment descriptors to be maintained in parallel with Java code today?
I suspect a lot of you have strong feelings about these issues. I hope you'll stop by the forum and let us all know what you think.
Also in today's Forums,
kohsuke has some help Re: JAXB and xsd:include (common type libraries across multiple schemas): "What you are describing further (you got schema S2 that refers to S1. You want to generate Java code J1 from some schema S1, and then later generate Java code J2 from schema S2 and you want J2 to be using J1.) is what we call "separate compilation." The story of separate compilation in JAXB is still weak. Today what we are suggesting people to do is to have S2 generate both J1 and J2, and remove the duplicate pieces. Even if we improve the separate compilation story, it will probably start with namespace as the smallest unit."
In today's Weblogs. Ed Burns has an irc followup: let's try JXTA: "To follow up to my previous blog about the desire for irc.java.net, I'd like to talk about using Project JXTA in the interim (and perhaps indefinately, if people like it) to fill the gap."
In Project Matisse: An update, Gregg Sporar writes: "I did a demo of Project Matisse for the Austin Java User's Group. The feedback was overwhelmingly positive. Read on for an update on what it's like to use Project Matisse in its current state."
John O'Conner reveals Charset Pitfalls in JSP/Servlet Containers: "The J2SE platform has come a long way in internationalization. Some things are just easy...like entering your name in a Swing text field. Unicode prevails within the Java core. Unfortunately, entering non-ASCII text in the J2EE world isn't nearly as easy."
In Also in Java Today, Automatic garbage collection doesn't exempt you as a developer from the risks of memory leaks. Retain enough objects in caches, hashtables, and other such structures and you may find yourself memory constrained. According to Staffan Larsen, there are two things you need to do: learn best practices for writing non-leaking code, and employ a tool to find the leaks you do inadvertently create. In the dev2dev article Memory Leaks, Be Gone, he discusses how to write non-leaking code, and how to use the JRockit Management Console to find the leaks that get through.
Using business rules can help you develop more agile application; the power of business rules lies in their ability both to separate knowledge from its implementation logic and to be changed without changing source code. The specification for the Java Rule Engine API (JSR 94) defines a Java runtime API for rule engines by providing a simple API to access a rule engine from a Java client. Toward Rule-Based Applications article provides an overview of JSR 94 and discusses how to fit business rule technology into Java technology applications.
In Projects and Communities, the Portlet Community home page is highlighting the article Liferay open source portal 3.5 released. Liferay is an open-source portal "designed to deploy portlets that adhere to the Portlet API (JSR 168)." It also notes that Liferay integrates with Spring and has been used for a number of significant deployments.
Amy Roh's weblog announces FishEye for GlassFish: "FishEye delivers a unified view of your source repository that provides easy navigation, powerful search, historical reporting..." and that "GlassFish just started to support FishEye for its CVS repository and folks are finding this very useful."
In today's java.net News Headlines :
- Clustered JDBC 2.0rc1
- Flux 7.0 - BPM, Workflow, Job Scheduler
- Apache Derby Graduates Incubator
- Early Draft Published: JSR 196 - Java Authentication Service Provider Interface for Containers.
- JXMLPad 3.5
- OpenWFE 1.5.4
Registered users can submit news items for the java.net News Page using our news submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to thejava.net News RSS feed.
Current and upcoming Java Events :
- July 27-31, 2005 ADHOC 2005
- July 29-31, 2005 Desert Southwest Software Symposium 2005
- August 12-14, 2005 Lone Star Software Symposium 2005: Austin Edition
- August 19-20, 2005 Salt Lake Software Symposium 2005
- August 23-24, 2005 Pragmatic Studio
- August 26-28, 2005 Southern Ohio Software Symposium
- August 29-September 1, 2005 Enterprise Java Architecture Workshop: Munich
- September 9-11, 2005 - Greater Michigan Software Symposium
- September 14-15, 2005 - JavaZone 2005
- September 16-18, 2005 - Great Lakes Software Symposium
- September 23-25, 2005 - New England Software Symposium 2005: Fall Edition
- September 30-October 2, 2005 - Western Canada Java Software Symposium 2005
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Let's put everything in Java?