Slashdot Mirror

One of the patents in question: "A portion of the virtual machine instructions of the function are compiled into native machine instructions so that the function includes both virtual and native machine instructions."

Nothing about caching for later use. This is the way that even the old BASIC interpreters worked.

Verdict: Bogus patent.

Or you could try this.

I can't tell if you are trolling or not, but just in case.

I'll bet Amazon.com doesn't have 13,000 CONCURRENT clients. Gimme a break! When you LIE, at least make it believable

In fact, I wonder if there is a database on the planet that has that many CONCURRENT accesses.

Google has over 30,000 searches per second. Secondly he states that 13,000 users where using it simultaneously, not that the database had 13,000 open DB connections. Slashdot probably has more people viewing it than that now. I am sorry you suck at computing, but writing a web app to deal with 13,000 simultaneous clients is trivial. You will have room to talk when you need to deal with 30,000,000.

First, is Google running on PHP and MySQL? I think not. They use thier own database called Bigtable. Bigtable is NOT an SQL database. In fact, it isn't even a Relational Database. They even run their own custom Linux distro, don't they?

Sorry you suck at RDBMS design, and fact-checking. I would imagine that Google doesn't use Apache, neither. Nope. They use the Google Web Server. So, what was your point, again? Second, it depends on what he meant by 13,000 simultaneous users were USING it.

Third, I still call shenanigans because FMP Server has a hard limit of 100 concurrent web users (100 concurrent sessions), if they were using it to publish the database directly. And if they WEREN'T using it to publish the database to the web directly, I'm not sure how they were getting the data to the clients. And if they were using FileMaker Clients, FMP is only tested to 250 clients. It has no actual maximum; but 250 is pretty far from 13,000. and FMP isn't like MySQL: You don't open a connection; do a transaction or two, and close the connection, like you do in PHP/MySQL. Opening a FMP database is a many-seconds-long process. He said that FMP ran for 3 hours before it buckled. I don't think 13,000 FMP clients could have OPENED the database in 3 hours!

Ok, let's look at some REAL concurrent numbers. We'll leave the likes of Google, Yahoo, eBay, the NFL, GoDaddy and Amazon out of it; because what they are doing is FAR from trivial. And BTW, anyone can throw numbers around; but I am having a real hard time verifying your claim, other than the Google number. And as I said, what they are doing has NOTHING to do with PHP/MySQL; and so is a non-sequitur:

This Tomcat/Apache and Tomcat/IIS article seems to suggest a number of concurrent sessions that is a couple of orders of magnitude LOWER than 13,000 simultaneous users.

Apache documentation seems to suggest that 13,000 concurrent open sessions is pretty damned many, too.

OTOH, WebSphere has the ability to handle hundreds of thousands of concurrent connections; but again, we ain't talking no steenkin' LAMP configuration, like the original LIAR suggested. And those applications aren't thrown together in six hours, neither. So again, not germane.

So, the bottom line is: I'm positive it can be done; but it is not "trivial" to make it run well, and I have serious doubts as to whether a LAMP solution can get there in six hours worth of real-world MySQL/PHP coding.

Don't forget, Microsoft has a nice disclaimer that they ship with Windows regarding using it in conjunction with nuclear facilities:

http://www.theserverside.com/blogs/thread.tss?thread_id=38213

Yes, they wrote it specifically about Java, but it's still there.

Sorry for the late response but a read over here can tell you a lot about what I was talking about.

Uh, does anyone else have a problem with this thing running on Java? Java causes death

Look at the timestamp of this presentation :) It's a bit of old news.

It was discussed here: http://www.theserverside.com/news/thread.tss?thread_id=48449

And it mostly shows that NIO is deficient. I encountered similar problems in my tests. Solved them by using http://mina.apache.org/ .

that's because there aren't any high profile web sites written in Java - they're too slow, buggy and useless. Even assuming what you say is 100% true, how come vendors patch security flaws in Java itself and they never get exploited?

We had our corporate system breached due to a flaw in a very big, expensive 'Enterprise' java web system so I know it from experience.

How about a quick google for information. This one has a table of java web framework security features. This one (pdf) describes "Our static analysis found 29 security vulnerabilities in nine large, popular open-source applications, with two of the vulnerabilities residing in widely-used Java libraries. In fact, all but one application inour benchmark suite had at least one vulnerability."

as well as "A recent penetration testing study performed by the Imperva Application Defense Center included more than 250 Web applications from e-commerce, online banking, enterprise collaboration, and supply chain management sites [54]. Their vulnerability assessment concluded that at least 92% of Web applications are vulnerable to some form of hacker attacks"

Ho hum. I guess you think Java is completely secure. What a fool. Hope no-one hires you to write any of them, well, not until you go to java.net and look up all the 'how to make your java app secure' tutorials. Sounds like "fucking morons" like you need them more than most.

He's not that smart a technologist. Seriously, it took them 6 years to add closures (they'll be in JDK 7 which is due in 2011) and other trivial changes. WTF?

Look at Anders Hejlsberg at Microsoft for a good example of technical leadership. Under his guidance .NET evolved from a carbon copy of Java to a quite interesting framework with unique features.

I'm seriously glad that I've switched my new project to .NET. At least, I can use a language with real generics, type inference, closures, lamdas and LINQ. It really feels uber-cool to use these features instead of writing reams of stupid Java code. Oh, and having a GUI framework which doesn't suck.

Also, read the recent Gosling's keynote speech http://www.theserverside.com/news/thread.tss?thread_id=59733 - it's all about EJB3. He has nothing noteworthy except yet one more 'enterprisey' API standard. Fail.

1) http://www.theserverside.com/news/thread.tss?thread_id=46887
2) http://weblogs.java.net/blog/alexwinston/archive/2005/04/strongly_types_1.html
3) http://www.developer.com/java/other/article.php/3300881 ?
4) http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
5) http://java.sun.com/j2se/1.5.0/docs/guide/reflection/proxy.html ?

Absent? (Admittedly, I don't code in Java, but I got those links just by googling all your points.)

I hired my current "minion" based mostly on the ability to understand that variables set by javascript can't be loaded into the database in PHP farther down the page without either A) submitting a form B) loading a link or C) using XMLHttpRequest

Some people I interviewed (and once had the misfortune of working with for a few days before it was obvious that it wasn't going to work out) just don't seem to be able to wrap their head around the idea of distinct server side and client side scripting. (You should see their faces when they look at PHP code that writes javascript!)

I've found that these are also the people that tend to use Header("Location: form2.php"); (or worse, a blank page with a redirect that screws with the user's back button) when writing a form spanning multiple pages that may or may not be used, wasting a round trip and making it the client's job to move to the next page instead of include("form2.php"); to just show the user the next page (I'll make an exception for "PRG" designs... when you're too lazy to check to see if the form had been resubmitted yourself in the event the user realized they made a mistake and hit back to fix it). I can see where the original version might be useful if the URL was actually meaningful or users were expected to meaningfully bookmark the result of a POST, but otherwise its a waste of everyone's bandwidth (and god forbid the user's browser caches the Location response rendering the form unusable until the cache is cleared). Again, it's another one of those where you should see the look on their faces.

I use [the Post Redirect Get] paradigm 100% of the time.

Likewise, both for the ease for a user and for the cleanliness of the UI. I _know_ what the program is going to do at any given point. There have been many good articles on the PostRedirectGet pattern. The argument against it is the increase in bandwidth. However, considering the rather small size of gets and redirects, compared to the mass of a post or full-page response, this is chump change.

A lot of people forget that C has very strong typing (that you can get round it with a cast doesn't detract from that fact that *you* have to perform that cast, you cannot accidently pass the wrong type in)

Some 'safer' features, such a GC to name a fashionable one, only shift the source of errors to a different place - GCs happily use up lots of memory, happily hang the system while they collect, and often you end up (like the Princeton DARPA team) assuming things are dealt with when they get 'stuck' in memory because there's a reference hanging around somewhere). I mean, a GC is fine for most things, but I'd still want a better form of memory management to be used first, and I certainly wouldn't want a GC used in a nuclear bomber. At least Sun's Java licence knows to make that explicitly clear.

The biggest problem with C is dynamic memory allocation. The way to fix it is, simply, not to use dynamic memory allocations! You can easily write C/C++ code where everything is on the stack, everything is a local variable. Ok, the other problem with C is array bounds checking - especially C-style strings, but you can still use fixed-length types and your own non null-terminated copy functions.

Modern, easy-to-use languages give you the illusion of safety - but really they just sweep the problems under the rug so you don't notice. Even some things that are designed to make your code safer, often require as much care as before

In short, it doesn't matter what you use, you have to think about it and you should never, ever assume someone else has fixed all your problems for you.

An enterprising developer is already working to get FreeBSD's Java 6 on Leopard:

http://www.theserverside.com/blogs/thread.tss?thread_id=47500

They're working on it.

The crucial factor is having faith in the technology and convincing backend Java EE experts to endorse a rich client interface over markup based solutions such as struts, JSF or whatever 'framework of the month' they read about on TheServerSide.

Artima
eWeek
InfoQ
Java home
JavaLobby
JavaWorld
JDJ
The Inquirer
The Register
TheServerSide

try the following link:-
http://www.theserverside.com/tt/books/wiley/master ingEJB3/index.tss

Good intro to EJB in Java EE 5

It doesn't prove anything, that if there is Spring and Hibernation somewhere at the bottom of Grails, the whole thing will be fast.

I am puzzled as to why you say this. It is common practise in Ruby to drop through to C or C++ to improve speed. In Grails, you aren't just dropping through to Java - 99% of the framework is Java, and Java which is fast and scalable, and highly tunable in ways that Rails simply isn't.

You've made the bold clame that Grails is faster than Rails, so show us the bold proof (benchmarks, numbers...)!

Again, I am puzzled as to why this is supposed to be a bold claim. I suggest you read a detailed comparison of the two frameworks:

http://www.theserverside.com/tt/articles/article.t ss?l=RailsHibernate

I would also suggest you attempt to run single transactions involving, say, 100,000 records in Rails and see what happens (something I do routinely).

A "tech talk" on GWT is posted on TheServerSide. Of course, if you're generally interested in Ajax you should also check out the tech talk on Ajax Push with ICEfaces just below the GWT talk. In keeping with allowing the developer to write Ajax applications in pure Java, ICEfaces also promotes Ajax development without JavaScript.

Just use Netbeans which can use VB 6 and build java apps.

Links:

http://www.theserverside.com/news/thread.tss?threa d_id=40344

http://blogs.sun.com/herbertc/entry/project_sempli ce_visual_basic_for

http://blogs.sun.com/roller/page/herbertc?entry=pr oject_semplice_visual_basic_for

http://www.sitepoint.com/blogs/2006/05/19/write-ja va-web-apps-in-visual-basic-or-javascript/

http://vbwire.com/brief.asp?9342

http://blogs.zdnet.com/Burnette/?p=107

First of all, nobody uses Java 1.5 in production.

Most professional IT shops are just starting to roll new projects over to Websphere 6.0 which is based on J2SE 1.4 and J2EE 1.4. J2EE 1.5 is not even out the door yet, much less of any interest to people who do real work with Java.

Third, there is no question the Sun VM is superior at the moment. But the key phrase in that sentence is "at the moment."

Five years ago Solaris wiped the floor with Linux. Today I don't see people flocking to Solaris despite its handful of technological perks. Linux is just too damn handy.

There are realtime versions, secure versions, embedded versions. All based on the same kernel, all free and open, and they all just work. There is not really a huge advantage to run the same kernel everywhere. Especially not when the API's are very similar as is the case of Linux and Solaris.

On the Java side the VM is even less important since you don't even need to recompile your binaries. The argument that, say, SableVM would take over on the server just because they have an embedded version just doesn't make any sense. There are no visible differences between two competing, certified, versions of Java. However, if SableVM manages to come out with a certificed, compatible version that wipes the floor with the Sun VM on the server, then why wouldn't people use it? However, right now they can't because they're stuck trying to catch up with Sun who are always 2 versions ahead.

To make a relevant comparison, you can talk about how ICC optimizes this and that in such an elegant way that it's 100x faster than GCC for this specific use.

It doesn't. It's a few percent faster. Not usually niceable unless you hit some very specific edge cases. GCC is quite decent on Intel hardware. Thies goes back to the onvenience argument I made earlier. Technological advantages are usually not the major deciding factor.

And if you've been following the open source movement the same thing is happening at Debian and RedHat. They are not targeting Sun's Java 1.5. They are targeting SableVM, GCJ, and GNU Classpath.

Most Java projects doesn't care one bit what the Linux distributions target. They would never deploy on anything but the Sun VM anyway.

I suppose its worth noting that this book has a game project in it... interestingly, you can get that particular chapter for free: http://www.theserverside.com/tt/articles/article.t ss?l=AjaxWarrior

By the way, Grand Strategy looks very nice indeed, I'll enjoy giving it a closer look as time allows.

Java development in Windows is "standard", in linux is good and in Mac it is great.

Except for a small point: Java Mustang Betas were available on Windows/Linux for more than one year. What about the OSX version ? Correct me if I'm wrong, but they had to wait until the B77 version in May to get it. Oh, and how long was it to get a working Java 5 on OSX ?

Sure, the coding tools are nice - but there's more to take into consideration.

And the difference between Linux and Mac is performance. *Usually*, a Java application runs faster on Mac than on Linux, because the Java VM in Mac is done by Apple, meaning that its built by the ones who knows the OS.

Wrong; benchmarks never displayed such a performance edge of Java/OSX over the Linux version.

In Linux, as you certainly know, is a certain pain to install Java (you need to follow one or another howto to get things working),

Ah, well, it was indeed a pain to be able to unpack an auto-extract archive and link the java executables in your /usr/bin, was it ?
Moreover, don't forget that it was for the Java SDK. The JRE, the only one that interests the non-coder user, was packaged by lots of distributions for some time already.
I'd also point out that with the recent changes of the JDK licence, it is now easier for distributions to package the Java SDK directly - that's what Debian did, for example; so there is no "manual" handling of the install required.
If you had to follow an howto to install the Java SDK on a Linux box during the last three years, well, your knowledge of Linux and computers is probably so thin that it is understandable that you prefer the Mac. But you definitely don't examplify the "geeks" out there.

and the performance is *usually* worse than in a Mac, because the VM is done by Sun, which is concerned mainly in getting things working. Yes, they care about performance, but not that much

The performance point is grossly wrong. Grab a Mustang JDK and benchmark them both on OSX and Linux on a MacBook, and come back when you got numbers. You may also want to get a couple informations about the relative performance of Java on OSX - for example http://www.theserverside.com/tt/articles/article.t ss?l=JavaMac .

I'll not comment on the Ruby part of your experience, because I don't have enough knowledge of that language - but given the amount of rather biaised information you presented here, I think people interested in Ruby should take your opinion with caution.

their search engine is quite a special beast but for quite a lot of other stuff Java is heavily used at Google. They hired some of the very best Java programmers of the planet (like Joshua Bloch, who went from Sun to Google). If you're Google-fu is strong you can find a long and interesting talk (in english) by "Knut risvik" (as a mp3) on the way they use Java at Google (I've got it, but renamed the file and can't seem to find the original back). GMail is backed by Java, that's for sure. I don't know the specific details but if you're interested in how Java's used at a "Fortune 1" site, handling more than 100 millions pages view / day and more than 7 millions concurrent sessions, here's how Java 1.5 is used at Walmart (oops, with oil price that went up Walmart is only Fortune 2 now ;)

http://www.theserverside.com/tt/articles/article.t ss?l=MigratingtoJava5/

I have started a new web project and looked at RoR. Having done an app with Tapestry/Spring/Hibernate, I was sick of all the work one has to do to bring up a bunch of views in a browser and then persist results. I love RoR and Ruby for all the reasons mentioned in TFA. Note - I don't like the pluralisation default, but one can easily turn it off by setting the following in config/environment.rb:

# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false

There were two scalability concerns I had about RoR:

(1) Ruby is interpreted and 'slow' - however, the JRuby team (http://headius.blogspot.com/) is working on running Ruby within a JVM (currently interpreted, but they are starting on a compiler). When they get to 1.0, the compiler won't be as good as Sun's, but it will probably be "good enough"

(2) RoR uses the Active Record Pattern and Hibernate uses the Data Mapper Pattern (http://www.theserverside.com/tt/articles/article. tss?l=RailsHibernate). The Data Mapper Pattern is almost certainly more efficient when implemented well (as Hibernate does). The coolest thing about Hibernate is that it is much more efficient than I am without a big effort on the persistence side, and I am concerned that Active Record will not be nearly as good. However, what are the odds that someone (or some group of people) will work on implementing a persistence solution within Rails that uses the Data Mapper Pattern? Pretty good, I would say. Once again, it probably won't be as good as Gavin King's work, but it will be "good enough". And if someone else does not do it, maybe I will start the project.

Given the above and the speed with which one can develop in RoR, the choice was obvious, to go with Ruby and Rails.

Googling "PHP JVM", my second hit was Caucho Resin adds PHP: "Caucho, the company behind the open source application server Resin and the open Web Services protocols Burlap and Hessian, has recently added PHP to its list of supported features. Apparently, the PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php!"

Being able to call some of the Java libraries from PHP or even Ruby would be pretty nifty; there's some really top-notch stuff that has been developed in Java.

But everybody knows that Java is slow (I tested it myself in 1997, so I speak from experience), so that must be total bullshit, huh?

I've read my fair share of e-books - years ago during slow summer jobs, or more recently on a laptop in bed. They have their advantages and disadvantages. Advantages: in certain ways, e-books are more portable than plain-old-books; I can keep them in my gmail account and access them from any computer, for example (or on a PDA if I had one). There's lots of quality free content out there (been lately making my way through some of the java books from http://www.theserverside.com/tss). There are, of course, disadvantages, many of which I agree with and have been mentioned in other posts.

Even though I've read a fair number of e-books, I haven't BOUGHT any, and I don't see myself doing that anytime soon. Buying anything electronic is, at best, renting it. Paper books don't become obsolete; they don't get lost in hard drive crashes, left behind when you switch computers, put on a CD and forgotten about, etc. They just sit there on a shelf, you can take them out, read them, and put them back with no fuss, and the only time you really have to worry about them is when you move. It's a physical object you OWN, and which is superbly suited to its purpose, which is not the case with e-books. Perhaps even more importantly, books are expensive, but they're not THAT expensive - I generally feel it's a fair price for what you get (an exception would be university textbooks, but that's another story :p)

At most, I could see myself paying for a subscription-based system - pay a fixed fee, have access to all the e-books in the system. Even then, I'd only really see myself doing that for technical books - I find the information I need, I use it when I need it, and I don't worry about it again.

Singletons in the J2EE framework. Compare this monstrosity with a sigleton implementation in any sane language, including the simple, non-J2EE Java. Mind you, I'm not bashing J2EE here , the singleton issue is the price you pay for scalability.

Using Java for GUI on Windows. Most GUI libraries built on top of the winapi at least let you get the window handle from their widget implementations so that you can get straight through to win32 and do your hacking there (possibly fkcuing up the lib, since it doesn't know about your updates, but that's another issue :) ). This is not the case with Java - if a winapi function is not reflected in the Java API, you are pretty much screwed.

Persistence frameworks. "You won't have to write a single SQL statement for the rest of your life!". But if the statement generated by the framework is suboptimal, then guess what? Yup, screwed again.

Good luck choosing your framework. I hope I scared you to death, because, in my opinion you cannot be too scared of frameworks :)

MDA's central failing is that current implementations use UML. As Booch et al. say "the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (MDA Manifesto, Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). In other words, MDA is the OMG's attempt to copy something that has been going strong for over a decade: Domain-Specific Modeling.

Domain-Specific Modeling is about creating modeling languages whose concepts map to your problem domain concepts, rather than everybody's solution domain concepts. UML concepts - at least those from which code is generated - are from the solution domain: classes, attributes, operations. DSM concepts are different for each domain - buttons and icons for digital watches, menus and text message sending for phones, mouse buttons and cacodemons for FPS games. Models are thus at a significantly higher level of abstraction, and independent of any particular implementation technology. They capture just enough (and no more) detail to enable full code generation - and of course the code generators too are domain-specific.

As always, the more specific a tool is for a job, the more productive it can be for that job. It turns out it's best to create a modeling language and generator specific to a single range of products for a single company: the cost of creating the language is more than offset by the higher productivity, providing you're building more than a couple of products. Industrial cases of DSM consistently show productivity increases of 500-1000%. Compare that with MDA, where even vendor-sponsored studies show only 35%.

Whilst it's early days yet for the Microsoft DSL tools, other mature DSM tools exist, both for commercial and research use. I've been involved with one for 13 years, so a) you should suspect me of being biased, and b) I have some small experience of how this stuff actually works in the real world. One key thing is that with a decent DSM tool, building your language, code generator and modeling tool support has to be easy - both at the start and as you evolve the language based on experience. Even our largest customer - with several hundred users and the biggest modeling language we've seen - only has one person assigned part time to that task.

Interesting, this past week there was another article about the potential for elimination of QA staff due to agile programming techniques:

http://www.theserverside.com/news/thread.tss?threa d_id=38785

Software quality management is maturing into a discipline unto itself, and becoming much broader than testing. Manual testing is being replaced by automated tools.

Up here in Canada, I have seen an increase in the number of .NET positions too, although I don't think it is any stronger than the increase in Java positions. The demand for software developers has really picked up, and, just informally from the ones I have talked to, most head hunters are reporting being overloaded with opportunities to place people, as much as a 250% increase in demand for people over a few months ago.

I also agree with Steve.

To the best of my knowledge he isn't actually a coder. Yet he has concisely and accurately identified the key weaknesses in comtemporary competing products. (Maybe he has good people working for him?).

Managed code like C# (and Java and maybe Ruby, Python, VB) is slow, and this a problem when developing and deploying apps in a competitive market place.

Also garbage collection is a performance hit and does tend to use CPU at just the wrong time.

Actually wrt memory management garbage collection entirely misses the main memory management problem I have to deal with. Now how can I explain what this is... here we go it is "keeping heap out of virtual memory (e.g. off the disk)" (from http://www.theserverside.com/news/thread.tss?threa d_id=29865 i love google).

No comment on C# vs Objective C libraries. I'm not interested in Objective C or C# as I mainly do cross platform GUI development on code that has to be fast. I need mmap more and more.

(Can you guess who I work for?)

For more information about Spring checkout

Developing J2EE applications without Spring? Why?
http://www.theserverside.com/news/thread.tss?threa d_id=38021

Transactional J2EE Apps with Spring (Nice interactive presentation)
http://media.techtarget.com/tss/BeJUG/J2EEAppsSpri ng/player.html

I second that!

"The Pragmatic Programmer" is the best book about programming that I have read recently--- an infinately better read than the constant stream of pretentious 900 page "j2ee architect" drivel that passes for computer literature these days.

Here is a nice interview with one of the authors...
http://www.theserverside.com/talks/videos/DaveThom as/interview.tss?bandwidth=dsl/

Bah. Real programmers write their own. That's what's running on my site (don't give me any slashdot crap about ASP, it's crap but it works). Only took a few hours but it's configurable to the EXTREME!

Actually, I'm in the process of installing rails for a look at the moment, but this thread is a good place to ask - is there anyone here familiar with powerful persistence frameworks who knows how the one in rails fares?

No, I'm not qualified to comment, but here's an interesting article comparing RoR and Java/Hibernate: http://www.theserverside.com/articles/article.tss? l=RailsHibernate

Myself, I'm learning Ruby and Rails. I'm new to web development and was inclined to learn PHP, but got swept away on the Ruby bandwagon. Java and the slew of frameworks I could choose to work with it are complete overkill for my needs. RoR seems nice for the small stuff, with room to grow.

All the current suggestions from other posters I would agree with, Dr. Dobbs, ACM, IEEE, CUJ. But probably, like regular media, the smaller players are picking up the slack, even if they are web only. ServerSide, JavaLobby, IBM Systems Journal, Software Development, Artima Developer, JavaWorld, and DeveloperWorks are a few of the excellent ones I regularly read.

I thought OC4J was licensed from Orion?

http://www.theserverside.com/news/thread.tss?threa d_id=36502

Looks like JUnit4 is adopting most of its ideas from TestNG. This is good, as JUnit feels highly constrained and somewhat crippled compared to TestNG, but why even bother with JUnit4? TestNG can run JUnit tests unaltered, so backwards compatibility isn't really an issue.

Unless JUnit is going to add quite a few more features, it still won't be nearly as flexible as TestNG. I think the JUnit developers are stuck on this idea of independent tests, which certainly has its merits but ends up excluding a lot of powerful options or forcing you to use ugly workarounds.

TestNG is more of an all-purpose testing framework, equally adept at unit testing as well as higher level functional testing. As a developer, I want to be able to test things in whatever way fits the task at hand. For instance, sometimes it's easier or arguably makes more sense to test a multi-step process (say, user registration and verification) in a defined order. This is possible with JUnit, but it definitely goes against the grain of the framework, which does not support test dependencies and therefore doesn't support ordered tests. I don't appreciate being penalized by a framework because its developers have a very specific concept of "pure" unit testing.

Perhaps I should elaborate: I'm sure the JUnit developers know far more about unit testing that I do, but I want to write more than just unit tests. I'm perfectly happy to admit to writing functional and acceptance tests (and even tests that talk to a real database) in addition to true, pure unit tests. I understand why the differences should be recognized, but the fact remains that JUnit simply does not accomodate a broader view of testing.

I hate to be critical of something that's brought so much improvement to how we write code (JUnit), but I think we've all learned a lot about unit and other types of testing and it's time to move on to something that embodies those lessons.

Here are a couple of articles explaining why the distinction between tests and unit tests are becoming irrelevant:

http://www.theserverside.com/news/thread.tss?threa d_id=36502
http://beust.com/weblog/archives/000319.html

This is a pretty useful comparison matrix of all major app servers IMO:

http://www.theserverside.com/reviews/matrix.tss

Ajax In Action Sample Chapter Released! http://www.theserverside.com/articles/article.tss? l=AjaxinAction_CH4_PT1

Don't write up Lucene just because they're not using Lucene for the site search. Lucene is good. I've only used it on my laptop to index a couple of hundred thousand news articles, but even on a laptop Lucene performs well.

Take a look at http://www.theserverside.com/ - the enterprise java community. Their search is powered by Lucene. It's pretty fast and a very capable site search.

You also have open source projects, such as Beagle (the desktop search for Gnome), that uses the .Net version of Lucene. Lookout, a search plugin for Outlook (recently bought by Microsoft), also uses .Net Lucene for the indexing and searching.

On the subject of using MySQL with J2EE, Sun recently submitted some SPECjAppServer2004 benchmarks using MySQL and Sun Java system App Server 8.1. http://www.theserverside.com/news/thread.tss?threa d_id=35375 Before anyone starts criticizing benchmarks - the submissions demonstrate a couple of things : 1. You can get some great performance with FREE 2. MySQL has past the strict J2EE Compatability Test Suite - demonstrating that it is more than capable of supporting J2EE (wrt. portability) 3. That MySQL has it's place, as does Oracle - in terms of price / performance / features - though I think the feature argument gets less important with every release. Rich Sharples Sun Microsystems http://blogs.sun.com/roller/page/sharps/

I've used a lot of different things professionally but I consistently find that large projects go a lot smoother with Java. It's easier to find skilled developers, especially web developers.

The platform is effectively free (Tomcat, MySQL, Eclipse). I never have trouble finding JARs or examples of solutions to any and all common problems.

There's a wealth of work being done on high-level design and patterns (Struts, J2EE, personal info fave: The Server Side).

When you're trying to juggle a dozen coders: Java's OO roots, built-in documentation generation and relative ease-of-use all contribute to making things run smoothly.

And while a great development team is the best resource of all, the reality is you sometimes get stuck with un-experienced, un-talented and/or lazy programmers. If there's an easier language to teach, understand and use than Java, I haven't yet found it.

• http://www.onjava.com/pub/a/onjava/2004/08/04/mave ntips.html
• http://www.theserverside.com/articles/article.tss? l=MavenMagic

Basically Maven is an extra layer on top of Ant. Or another way of putting it is that Maven is way to program Ant in an XML based language called Jelly. Maven has the concept of repositories and versions, so that you can say that a particular jar file requires specific versions of other jar files in the repository. If you find yourself writing a lot of similar Ant code, Maven is definitely worth a look. It takes a little while to get into, but once you do it is fairly straight forward.

where do you get those numbers?

A quick search I did came up with very different numbers.

Eclipse - 45%
JBuilder - 16%
IDEA IntelliJ - 10%
netbeans was well below, at around 6-8%, hard to tell from the graph.
all others combined (including netbeans) make up less than 30%

In the light of the recent news that JBuilder is merging code with eclipse, I think netbeans is quite doomed !

here is the survey:
http://www.qa-systems.com/products/qstudioforjava/ ide_marketshare.html

As I was searching for some info about JBuilder, I stumbled across this juicy bit that I had not seen before.

Borland announces JBuilder Roadmap; future will be Eclipse-based

The jist of the story is that in the first half of 2006, JBuilder will ship a new version, code-named "Peloton", which will be completely Eclipse-based !!!

http://www.theserverside.com/news/thread.tss?threa d_id=34246

below is much of the article text in case it gets swamped.

Borland has announced their technical roadmap for JBuilder. Later this year Borland will ship JBuilder 2006 which will add shared code and shared debugging features. In the first half of 2006, JBuilder will ship a new version, code-named "Peloton", which will be completely Eclipse-based and add better dependency analysis features.

The shared code and debugging will allow developers in different locations to participate in shared coding and debugging, as though they were sitting down together in the same room.

The Eclipse news follows up from their February announcement of joining the Eclipse board and their intention to re-build their entire application life cycle management product suite on top of Eclipse. Borland sees Eclipse as an integration framework upon which they will be building JBuilder as well as their other products. By leveraging Eclipse, they can realize the cost savings of not having to worry about maintaining IDE functionality, and integration with other Borland tools, as well as gaining a larger audiece via Eclipse and benefitting from the large ecosystem of Eclipse tools.

According to Rob Cheng, director of developer solutions at Borland, the major new addition planned for Peloton will be a dependency analysis feature. It will be able to understand the dependencies between different artifacts in the project, such as the link between JSP's and struts controllers, EJB's and the persistence tier, without the user needing to configure these explicitly or switch views. Debugging will be improved - stepping into different tiers will be easier without end users needing to manually set additional breakpoints.

Code-name Peloton comes from a cycling metaphor, which is used to describe a group of cyclists who can ride faster together than they could individually, reflecting Borland's emphasis on team collabortation features in JBuilder.

Borland has not announced any pricing information, but they are looking into offering a separate 'distribution' of JBuilder on Eclipse all integrated to make it easy for corporate clients to deploy.

Borland chose Eclipse over Netbeans after watching industry momentum and listening to customers who think Eclipse will be their next major platform.

When asked about what their differentiators for JBuilder-Eclipse over Websphere Studio will be, Borland responded that WS Studio is focused on Websphere, whereas JBuilder supports multiple application server platforms.

Luis De La Rosa in his 2005 predictions suggested that Eclipse will become the Java community's answer to Visual Studio.NET, as a de facto IDE; this being a good thing for the Java community, as Eclipse will help build a market/ecosystem for development tools much like Visual Basic, which is the real goal that Sun wants to reach: 10 million developers using Java.

Borland's decision to join IBM in basing their IDE on Eclipse is certainly bringing us closer to that prediction! What do you think?

Funny, I recall something about JBuilder moving to Eclipse...

Borland has announced their technical roadmap for JBuilder. Later this year Borland will ship JBuilder 2006 which will add shared code and shared debugging features. In the first half of 2006, JBuilder will ship a new version, code-named "Peloton", which will be completely Eclipse-based and add better dependency analysis features.

The OOo issue was largely a case a of miscommunication between FSF, Sun, various online publications, and bad PR firefighting. I don;t think anyone saw it coming until it surfaced in the Newforge article. And then wham! All hell was lose.

See Fedora Core 4 for a nice OOo 1.9.x that runs well with gcj. See the tools-jdk list for the current discussions about OpenOffice.org support for Free Runtimes, and how to avoid such things in the future (build deamons with gcj, for example),

I guess IBM gets a lot of sympathy for dealing with SCO. Heard anything crazy about GPL being an unamerican tool of terrorists from Darl lately? :) IBM's taking out the trash, and that's very kind of them, as it's not such a fun task.

My analysis of the JRL is very critical for a simple reason: noone wants to have to go to court, in particular over something that could have been avoided easily by analysing the license and trying to figure out the worst case, and make sure that it does not occur. The legal opinions I quoted give a pretty good reasoning why one should avoid getting bound by simplistic Residual Rights clauses, I think, and why it is so hard to prove in court that no copyright infringement occured if it comes to a lawsuit. Why create potential copyright problems in the future, when we are doing fine without that source code? If one looks at the last three years, Free Runtimes have prospered nicely without having or demanding access to Sun's source code. I don't think that whatever information is buried in the source code if worth putting an aura of doubt around our efforts and potentially putting Sun into an uncomfortable position oh having to pick their alegiances. Instead, such information should find its way into the official specs.

I think the SCSL is quite clear in that respect: when the Lutris developers accepted the SCSL, they were bound by it, and could not release their product os open source without violating the SCSL. There was no need for anyone to threaten anything as the issue is pretty clear cut, and if you read the enhydra archives from back then, it's pretty apparent that Enhydra App Server devs, after trying to negotiate with Sun about having a certified J2EE server under an open source license, gave up in frustration and chose to accept the SCSL and not to release their code as open source, rather then violating Sun's license. That's a very sane decision.

The JBoss agreement is the most puzzling part of the SCSL puzzle, as most news sources from back then indicate that JBoss and Sun had to clean up some licensing problems, and that cleaning up was monetary. JBoss was shipping Sun's code licensed under the BCL, according to Marc Fleury http://www.theserverside.com/news/thread.tss?threa d_id=9177 . Afaict, BCL has some pretty heavy obligations as well regarding javax namespaces, and by developing Jboss for javax.* APIs and distributing BCLd code prohibiting subclassing of those APIs, they might have violated the BCL. Nevertheless, most news reports back then talked about the SCSL, so I need to say that I am just speculating here, as no official statements on the background of the whole deal were released by either side.

If you've got a chance to get the javax.swing.text.html.HTMLEditorKit specification improved, please go for it, this was just meant as an example of the specs being somehwat incomplete. For a rather bad example, see RTFEditorKit.

What one usually does with such incompletely specified classes is to see what other literature exists describing the missing details (books on SWING, for example), and how the code is used in real life by Free Software applications.

cheers, dalibor topic