Using Castor JDO for SQL Mapping.
Riddle me this, Batman.
Dodging the JDO question
I attended this J2EE shootout. I was the person that asked the question about JDO. [...] I also spoke to some of the other speakers. In general, the people were not knowledgeable at all about JDO, they did not have a JDO solution to offer, so they dodged the question. I also got the impression that these EJB vendors simply viewed JDO is minor competition. The fact that JDO can be used with their existing products seemed surprising to some of them. [JDO expert Dave Jordan, from a JDO Central thread].
Dev tool double-talk
"The IDE from BEA is very difficult. It isn't the traditional IDE that most Java developers are used to working in, with an editor, compiler, debugger-type of tool," Murphy said. WebLogic Workshop is oriented toward Visual Basic programmers, while TogetherSoft offers a traditional J2EE development, he said. [ InfoWorld, BEA, TogetherSoft partner...]
Wait a minute here, the IDE from BEA is both "very difficult" and "oriented toward Visual Basic programmers?" That sounds like a bit of a problem, doesn't it? I'm sure adding some UML tools is the key to dumbing it down to VB level... not! I do hope TogetherSoft can straighten those BEA guys out.
Perforce and Eclipse
Turns out, there is a Perforce plugin for Eclipse! It is called P4Eclipse. I just installed it and it looks awesome, even though it is only a v0.0.8 release.
Thanks Greg!
As cool as it gets, Eclipse (partially) has this really nifty feature! It's called "label decorations" and is a generic way to add custom information to labels associated with project resources. It has to be enabled in the preferences:
Window->Preferences->Workbench->Label Decorations->CVS
What's more, you can also heavily configure the format of CVS label decorations in:
Window->Preferences->Team->CVS->Label Decorations
You can see what's the status of your CVS controlled resources in the project tree. I'm not quite sure if you can see clearly who's doing what with files. [ Greg Klebus, Java To Go]
Thanks Greg, that is exactly what I wanted. Clearly, I need to spend a little more time RTFM'ing before I shoot off my mouth. And Greg, I've been meaning to tell you that your English is just fine - I would not have noticed that you were not a native speaker if you had not mentioned it.
Hey Perforce, are you reading too? If so, get to work on Eclipse integration. I'd like Eclipse to be as easy to use at work (where we use Perforce) as at home (where I use CVS for Roller). UPDATE: Turns out, there is a Perforce plugin for Eclipse, it is called P4Eclipse.
Eclipse and CVS usability
I'm still working with Eclipse and enjoying it. I do find that it gets sluggish at times, usually after I leave it alone for a while, but once it warms back up it is nice and snappy. Still, I have not totally weaned myself from VIM and I am not sure I ever will.
One thing that I find irritating with Eclipse is that it is difficult to figure out what files I have modified in my local work space. Sure, I can do a Syncronize With Repository and get a tree view that shows what files I have modified, but that is rather slow and cumbersome even for a fairly small CVS project like Roller. With WinCVS, I can easily see the files that have been modified as they show up with bright red icons. The WinCVS Flat-Mode is especially useful for this. It would be nice if the Eclipse Resource Perspective could use different icons for files that have been set writable, files have been locally modified, and files that are untouched.
My favorite source code management system Perforce uses change lists. When you check files out you must check them out into change lists. You can use these change lists to organize your work. I might have one change list for "Ekit editor integration" and one for "Admin UI security fixes." It is really easy to see what files you are working on in each change list and what change lists and files your coworkers are working on.
I know that CVS does not support change-lists, but it would be cool if Eclipse would make it easier to see what files you have modified in your local work space and what files your coworkers are editing.
More on JSF and Struts
Craig McClanahan has written up his thoughts on Struts and JSF integration. There is also a thread about this on Floyd's blog.
Rickard's comments on the shootout and the war
Rickard Öberg has posted some great comments on the J2EE Container Shootout. Before you get to the J2EE Container Shootout comments, keep an open mind as you read Rickard's comments on Bush's "war on terror" - like it or not, this is how we Americans look to some of our best allies.
Comments on the J2EE shootout
Andy Oliver, who was instrumental in putting together the TriJUG's J2EE Container Shootout, adds some comments to the shootout post on the Java Lobby.
J2EE Container Shootout Summary
I attended the Triangle JUG's J2EE Container Shootout last night and it was a lot of fun due in great part to the flamboyant verve of Marc "you can walk through walls, just like us" Fleury of JBoss fame. Also behind the panelist table were: Robert Patrick of BEA, Greg Ackerman of IBM, and Farzin Barazandeh of Oracle. There were twelve questions and each panelist was given from 2-4 minutes to answer each. Then there were free form questions from the audience. I will try to summarize from my notes what I considered to be the most interesting question and answers for you:
What applications justify the use of EJB?BEA: Robert says that even for small apps, you should design with future migration to EJB in mind. Use EJB if your developers have the skillset for EJB.
ORACLE: agrees that skillset is important. If you are a database house, you might not want to go the EJB route. EJB is not yet truly mature and does not do all the things that a great database can do.
JBOSS: Marc says: don't access the database directly from Servlets and JSP, use EJB intead. EJB caches data for web applications very well and can be ten times faster than ordinary database access. But Marc doesn't stop there. He goes on to say that some companies allow licensing costs to drive their architecture choices and stay away from EJB because of cost, with JBoss you don't have to worry about licensing costs. From the way the BEA panelist rolls his eyes, I get the feeling that he has come up against Marc before.
IBM: Greg also agrees that skillset is important and agrees with the other vendor's points. He also adds that EJB 2.0 brings some real developer productivity increases to the table. Greg recommends using IBMs "redbooks" and J2EE best-practices to determine your architecture.
What is the biggest threat from dot-Net and what are you doing about it?
BEA: Robert says that it is a sure bet that dot-Net will be "ready for prime time" in the near future. Currently, dot-Net only makes sense for small systems. To combat the threat Sun needs to work closely with the ISVs, improve development tools, and must have interoperability with dot-Net via web services.
ORACLE: Farzin answers that the biggest threat from dot-Net is the fact that it is from Microsoft and therefore will automatically gain acceptance. Java can't let it's community driven nature slow it down and at the same time needs to stick to the standards to ensure interop, portability, etc.
JBOSS: Marc proclaims that he is a "closet Microsoft lover" and that he takes Microsoft very seriously. But, he contends that Java has nothing to fear from Microsoft. Java is portable and the runtime is free. The difference between JBoss and Microsoft is philosophy. Microsoft wants to commoditize the $20/hour developer and JBoss wants to commoditize the runtime and the application server. As far as the standards are concerned, Mark says that Sun does move slow. Use JBoss and the standards will follow.
IBM: Greg says that IBM vs. Microsoft is not the story. Dot-Net is vapor now but Microsoft will eventually get it right. He says that to fight against Microsoft, Java needs to be more of a standard. Sun can't keep veto power and expect Java to keep up.
Do you support JDO and what are your plans for JDO?
JBOSS: we have been supporting JDO for quite a while via Castor and other means. But, JDO has not taken the persistence crown. EJB/CMP is much more powerful than JDO. JBoss is working to decouple the CMP engine from JBoss so that it can be used independently of EJB.
ORACLE: The Oracle app server does not supprt JDO, but our new TopLink product is very close, and may enable Oracle to support JDO in the future.
BEA: does not support JDO and says that JDO is not compelling vs. CMP 2.0.
IBM: Websphere 4 and 5 do not support JDO. IBM is still trying to figure out what to do about JDO.
Which of your competitors products would you choose?
ORACLE: Farzin tried to answer Orion, but Oracle's app server is an OEM version of Orion, so that did not fly. Then Farzin said that Websphere is too big, Weblogic looks OK, but since JBoss is free and easy to use he would choose it.
BEA: Robert said that JBoss is free and for development purposes would get the job done, but for mission critical apps he would choose WebSphere - but only if he could affort the IBM consultants required to set it up. He said that "WebSphere can be made to work," the dev tools are good, and the admin console is nice.
IBM: Greg said that he might download Oracle's app server, but he would be worried that Oracle would change code-bases before the download was complete. For mission critical apps, he would choose WebLogic because there are so many developers that are familiar with it.
JBOSS: Marc said that he would choose Oracle because Oracle is Orion and Orion was developed by Rickard Oberg's room-mate and therefore Orion is very similar to JBoss. His second choice would be WebSphere because IBM will be around for ever and ever - it is always a safe choice.
What do you see happening with J2EE and development in 5-10 years?
JBOSS: Marc says that J2EE is at the end of its road. Now developers need to learn to be container developers, to take apart the containers, and to pick and choose which parts they want to use in their apps. Then developers will be able to walk through walls like the JBoss folks do. Also, the dot-Net ability to hang attributes on methods and fields of classes will be come very important and combined with interceptors will enable aspect oriented programming, grid computing, blah, blah, blah. I'm not kidding, Marc really likes to say "blah, blah, blah."
BEA: Robert says it is very difficult to predict the future, but that he sees that XDoclet-like method and field attribute driven development will be important and that web services will be very important.
IBM: I can't remember what Greg said, but I am pretty sure he mentioned web services and grid computing. Oh yeah, he started off by saying that J2EE is not at the end of the road - it has a long, long way to go.
ORACLE : I can't remember what the Oracle guy said at all. Sorry folks.
Well, my lunch hour is over so this concludes my coverage of the Triangle JUG J2EE Container shootout ;-) Thanks to the Triangle JUG board, JUG member volunteers, and to the folks who submitted the questions for making this possible.
See also:
Andy Oliver's comments
Rickard Oberg's comments
Dave Jordan's comments
J2EE Container Shootout
Here's an anecdote from the hallway, between sessions at InfoWorld's Web services conference. I was chatting with a CTO and a VC. Both told me they've never seen a buyer's market like this one. Vendors are being expected to trot out their wares and perform in bakeoffs. Buyers have the time and inclination to shop slowly and carefully. When the upturn comes, the CTO and VC told me, IT consumers will be a lot smarter and better-informed than they were during the tulip craze. If they're right, marketing bluster alone won't drive many sales in the current climate. [ John Udell, The 39 Steps]
The Triangle JUG is having one of these bakeoffs tomorrow night, the J2EE Container Shootout, September 23, 2000 at 6:30PM at the MCNC. BEA, JBoss, IBM, and Oracle will be there and if you are a Java developer in the Raleigh-Durham area, you should be there too.
My Eclipse Review
I had to do some grueling work on the Roller persistence layer this weekend,
the kind that requires lots of searching, replacing, trial-and-error experimenting, testing, and debugging. I
decided to make the job fun by trying something new: Eclipse. Normally, I use WinCVS and VIM for my development. Sometimes I
use JBuilder when I need to
throw together a quick Swing UI or Netbeans
when I need to do some debugging. Here is the story of my first real
experience with Eclipse:
To start out, I downoaded the latest Eclipse 2.0.1 release for Windows. I also downloaded the Solare Eclipse, Jalopy, and Tomcat plugins recommended by Jeff Duska. The install went smoothly and installing the plugins was easy, I just unzipped them into the Eclipse plugins directory.
CVS integration
Once I got Eclipse up and running, I setup a CVS repository within Eclipse that points to Roller's SourceForce CVS repository. Even though CVS over SSH is normally a bitch to setup, it worked on the first try with Eclipse. Next, I used the Checkout-As-Project feature of Eclipse to checkout the Roller sources into a brand new Eclipse project. Generally, I found the CVS UI to be excellent, especially the file and directory diff tools.
Ant integration
The Roller build process uses a lot of code generation and this code generation is driven by XDoclet tasks in an Ant script. So, I couldn't just point Eclipse at the Roller sources and hit the build button. I used the Eclipse External Tools feature to setup Eclipse to run Roller's Ant build script. Again, this feature worked on the first try.
JUnit integration
I wrote some simple unit tests to test my changes and then did my work. Once I was done, I found that the Eclipse debugger's Run->Debug... feature allows you to automatically find, run, and debug into JUnit tests. Again, this feature was amazingly easy to set up.
Tomcat integration and the debugger
Once I finished up my work on the Roller backend, I had to make some corresponding changes in the Roller UI. I found it very easy to use the Tomcat plugin to launch Tomcat in debug mode to debug my changes. The debugger UI was pretty impressive and very responsive.
Overall, I was very impressed. Netbeans can do most of things I have described above, but they always seem like a struggle to me. This was my first time with Eclipse and things just seemed obvious to me. I hate to say it because Netbeans has served me well and I really like Swing, but Eclipse has a much more streamlined, intuitive, and snappy user interface. Eclipse is a pleasure to use.
Doh! JSF is Early Access and not Public Review Draft
Sun: "Due to a miscommunication, the community published version of the JavaServerFaces Specification was inadvertently released as the "Public Review Draft." It was not the intent of the Expert Group to enter the Public Review portion of the JCP process at this time." [via The Server Side]
Googling for thoughts on Java Server Faces
I have read the JSF spec.
I now understand that JSF is a UI component framework that is protocol
and markup independent, but aimed at HTML-based webapps. Now I need
to play around with the Early Access
implementation to really get a grip on JSF.
I decided to first do some googling and mail-list searches to see what others
have said about JSF. None of the major Java magazines have written about
JSF yet, but I did have some luck. I found couple of quotes from Craig
McClanahan:
In general terms, I look at JavaServer Faces (and the JSP Standard Tag Library) as "mainstream" efforts that will, ultimately, supplant the use of the majority of the Struts custom tag libraries. We'll continue to support the existing libraries (there are *way* too many apps using them to consider deprecating them :-)That sounds good. Sounds like Struts, and possibly other web MVC frameworks, can support JSF. If Struts and Webwork both support JSF, does that mean that I can develop a JSF UI Component and then use it in either Struts or WebWork without modification? I hope the answer is yes.
...
Happily, the Struts controller doesn't care what technology was used to create the user interface -- it deals with request parameters and request dispatcher forwards. We may need to do a little bit of glue work to emulate some of the "automatic" interactions between form beans and the UI components, but I don't anticipate any significant hurdles in this respect. [Craig McClanahan, Struts-dev mailing list, 1/14/2002]
I also hope that non-JSP solutions, such as Velocity, can support JSF. I did see some hints of this in the spec, so maybe there is hope.
Moving on, I also found an insight from from David Geary on the Struts dev list:
Another way to think of Faces is this: Take the Struts html tags and rewrite them so that instead of producing html directly, the tags delegate to a component that produces HTML. And you can plug your own custom components into those tags for a different markup language (although you'll want to change the html prefix to something else, like faces). Finally, you can create a new tag and a corresponding component to implement something wild like a WAP calendar. [David Geary, Struts-dev mailing list, 9/6/2002]That sounds good too, except that it does sound rather JSP centric.
I also found some criticism of JSF:
Inside the spec, I see a bunch of standard UI components, but I don't see any complex ones like Table or Tree, everything looks pretty basic, that's just too bad, I was hoping that they would do something like Swing.
Aha, looks like there's some mention of creating components recursively. Events, that are independent of HTTP, unlike Struts. Now, that they've defined a new Event framework, I'm not sure if this is compatible with Struts.
So, where's the beef? My quick browse of the spec tells me that there are only a few new things that are in this. The newest thing is some kind of standardization of UI components, something completely lacking in the Java world. As far as a toolkit I can leverage, well I don't think I'll find it here. [ceperez, ::Manageability:: weblog]
The reason you see no complex UI components is that JSF is supposed to
be a framework and not a toolkit. Sure, JSF includes some concrete
UI Components, but just the basics - without those the JSF Reference
Implemenation would be useless.
So far, I like what I see of JSF.
MVC not suitable for webapps?
It is rare that you hear anybody question the suitability of MVC for the web, so cheers to <a href=
"http://www.beblogging.com/blog/20020910-150241">Ugo and <a href=
"http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102494541728419&w=2">Stephano
for doing just that. I'm not saying that I agree with them, but I do like Stephano's point that MVC is not the end of the road in terms of webapp architecture.
Ugo says that webapps are based on a stateless protocol. That is true, but in practice essentially all webapps are stateful thanks to cookies and URL rewriting. So, saying MVC is not suitable for the web because webapps are stateless does not make sense to me.
Java Server Faces tutorial
In addition to the recently posted Java Server Faces Spec, Sun has also posted on the JSF homepage a Tutorial, an Early Access Implementation and a FAQ. I'm still trying to digest this stuff. I do not understand enough to comment on it yet.
O'Reilly weblogs?
I found that and another interesting article titled J2EE Open Source on O'Reilly weblogs today. They are dated August 30th and I guess I missed them due to my narrow-minded weblog-centric surfing habits. Anyhow... good stuff, but why does O'Reilly call those things "weblogs" they look like plain old articles to me.
Big month for the Triangle JUG
In case you don't know "the Triangle" area of North Carolina is defined by the three University towns of Chapel Hill, Durham, and Raleigh. In the center of the Triangle is the Research Triangle Park, a sprawling reseach park that is populated with drug, bio-medical, software, and micro-electronics companies and institutions. The Triangle has been hit hard by Bush Recession II like the rest of the country, but the Triangle Java Users Group is thriving and next month we have two, not one, but two excellent meetings planned. Mark your calendars for:
Introduction to Ant and XDoclet
by Erik Hatcher of eHatcher Solutions, Inc.
Special meeting September 23, 2002.
J2EE Container Shootout
With representatives from: BEA, JBoss, IBM
For more info, check the Triangle JUG's website. If you are interested in attending the J2EE Container Shootout, then the JUG urges you to submit questions for the vendors to Andrew Oliver. Please read the question guidelines before submitting questions.
Go Tomcat!
Cafe au Lait is reporting that Tomcat 4.1 has been <a href= "http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.10/"> released and has provided a nice summary of the new features (see below).
- JMX based administration
- JSP and Struts based administration web application
- New Coyote HTTP/1.1 connector
- New Coyote JK2 AJP 1.3 connector
- Rewritten Jasper JSP page compiler
- Performance and memory efficiency improvements
- Enhanced manager application support for integration with development tools
- Custom Ant tasks to interact with the manager application directly from the build.xml scripts
« Previous page | Main | Next page »