permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

Actually, it's Struts and Velocity that requires that, not XWiki code itself. See for more info

http://struts.apache.org/2.0.6/docs/sunone-70.html

This permission allows the use of reflection to access private and protected methods and attributes.

My ISP argues that they can't grant this without compromising the shared web container integrity, and uses Sun Java SE Javadocs as proof, see:

http://java.sun.com/j2se/1.5.0/docs/guide/security/permissions.html

A quick google search convinced me that all major Java frameworks including but not limited to Struts, Hibernate and Spring needs this permission, so banning it from the security policy means the shared hosting plan is useless for the vast majority Java applications.

Worse yet, mailing list postings from many sources indicates many other follow the same policies as my own.

Is this good business? Are all customers interested in Java hosting using “semi-dedicated” servers, or virtual machines? Can you imagine a PHP hosting plan that bans Pear, PHPlib, ADODB, PhpNuke, PhpMySQLAdmin and other popular PHP libraries and applications? Why the same reasoning doesn't applies to Java hosting?

Being pragmatic, all that Java frameworks, including many from Apache Software Foundation, couldn't be wrong. It doesn't make sense they would require something that poses a significant security treat.

I guess that using isolated class loaders for each web application context (as stated by the Servlet spec) should prevent any use of reflection to get sensitive information from other customers using the same shared web container, so there should no harm granting the permission required by Struts.

Besides I think granting suppressAccessChecks for ReflectPermission would not make a shared Java web container security worse than mod_php or mod_perl inside Apache or IIS. Am I wrong?

If I am wrong and the security implications of granting supressAccessChecks are realy severe, why don't pre-configure the most popular frameworks on the web container shared lib folder and granting permissions just to them, so that any Struts jar from the customer applications WEB-INF/lib folder are ignored? Would this be so hard for a hosting provider to do?

Anyway making it hard to deploy popular applications and frameworks on shared hosting providers hurts Java popularity and indirectly the profits of all who bet their carres and business on the Java platform. If there's a real problem, framework developers should fix their code so they can run inside a tightier security policy. If not, docs need to be updated to state the real risk and pactices to mitigate it. Letting eveyone be limited to use dedicated web containers may help selling java ee server licenses and suppport, but doesn't help the community in the long run.

When I found a YAAPJF (Yet Another Article Predicting Java Fall) featured on Java.Net, I though it would, for a change, provide useful insights on the problems we Java developers would have to deal with during the next years, as technology creates new opportunities, big corporations devise new strategies to achieve total market dominance and marketing hype diverts decision-makers from the real issues that makes dependable IT. But what I found was just another biased and badly-informed rant that adds nothing new on similar articles I've read during the latest 10 years.

The article repeats the old sayings about Java failure for desktop applications and Flash dominance as a web multimedia tool. But if you visit Dice.com, Google Trends or O'Reilly for a reality check, you'll see that Java still generates twice as much "market share" as the second-runner. As if web development were just about the browser, and enteprise or embedded development didn't matter.

I wonder why, after so many years of failed predictions, the so-called "industry experts" still insist that Java is doomed. My conclusion is that they (1) are serving their own interests (2) are being mislead by parallels with technologies that are from both a marketing and from a technology point of view radically different from Java.

1. We all know media and consulting firms needs new hypes to sell articles, conferences and reinventions of the wheel posing as new applications. A mature, stable and robust technology like Java limits their opportunities to cash. The web looked like the golden mine, with the promise for a complete revolution each year and a half, but no corporation can rebuild all its IS at such a pace. And fortunately they don't need to, thanks to Java. (To be fair, there are other web technologies, like PHP, that allows companies to build web applications and keep then running for a long time span. I have applications created for PHP/FI that still runs with PHP 5).

2. The IS arena was for a long time crowded with technologies that promised everything but world peace, but were replaced in just a few years by the next hype. Remember the 4GL languages, RAD IDEs and WAP? When I was at college, about fifteen years ago, Clipper was still the way to get a well-paid developer job; soon everybody was coding using VB under Windows 3.x; them PowerBuilder, Centura and Delphi were "the" solutions for IS development; but all they were left into oblivion by the web.

Enter the web era, there was a rush to learn Perl and CGI programming, which were quickly displaced by server-side scripting engines such as Cold Fusion, PHP and ASP. Even Java entered the wave with JSP. But only multiple-tiered development could deliver the reliability web applications needed, and soon everybody was talking about design patterns, MVC and frameworks like Struts. MS .NET did not had the impact they hoped for, and now the "market" seems to be in a quest to elect the new "must-use" development tool, with Ruby and Rails topping the bets.

Nothing against Ruby and .NET -- except the fact they are not Java ;-). I myself still develop lots of stuff using PHP, and I am also a good SQL Server DBA. But Java development is not about marketing hype. It's about building applications that stand the test of time and that can evolve to meet changing business needs.

The crazy state IS development was before Java was very convenient to lots of professionals and consulting firms that could not (or did *not wanted* to) deliver dependable applications. Their incompetence in building reliable software was masked by new looks, incompatible upgrades from development tools themselves, OSes and databases, and the novelty of each technology hype. Every customer was willing to live with a few reboots and lock downs to use the latest technology. Every one was eager to buy that networks and applications that would solve all their problems. And those professional / firms incompetency at building maintainable software was hidden by the need to re-create everything using the next cool technology. IS was the realization of the "motto continuum", the engine that feeds itself.

Now those professionals and firms are scared about the prospect of getting another 10 year of stability from the Java arena. I was at once reading articles and course material I wrote about Servlet development almost 10 years ago, and every word of them still applies. I took applications I developed 10 years ago for IBM Websphere (at the time named Lotus Domino Webserver) and run then under the latest JBoss release. Of course nowadays I want to use Datasources, JMX management, Hibernate and Struts/WebWorks. But the fact I didn't had to change any of those applications just to stay current with system software is remarkable by itself

For the most part, Java evolution was not revolutionary. It was additive (and adictive). There were few times new JVMs and APIs broke production applications (and programming mistakes accounted for most of them), and it was easy to solve the eventual incompatibilities. I can't imagine having this stability from my dark years as a Windows developer.

So the parallel between Java and previous IS development "best sellers" will lead to wrong predictions about Java being at the end-of-life. Java is much more like COBOL, which still powers some of the most critical IS, but with the advantage that with Java you don't need to stay frozen with IS technology as it was 30 years ago. Rest assured during the next 10 years there will be a great demand for development of new Java applications, not just maintaining old apps like COBOL programmers do today.

I don't want to go back to the previous state of playing catch-up with each and every new cool technology. Neither do any of my customers. Nowadays IT users are much more cost-aware and concerned with ROI. I really doubt most of previous development best sellers would have had any serious market share if IT buyers were in the past half as careful as they are nowadays.

Of course there are lots of people and companies that can't see times have changed. The fact is: we aren't part of a booming market anymore. IT is now a mature market. Sad for them. Good for us Java developers.

Maybe the best parallel to Java is the now decades-old Unix system. It's heir, Linux, is at the forefront of OS and networking innovation. That's where new developments and new research happens, and where more and more companies trust their mission-critical applications.

But mosf of them are scared of the bootstrapping procedure, except for the few lucy ones that already have a JPackage-compatible JVM as part of their (commercial) distros, or the few ones that are brave enough to try and find their applications already work with GCJ. Rebuilding a RPM package looks like mission impossible to them.

So I created the following shell script, that does everything you need to bootstrap your JPackage environment except for downloading Sun Java. Just save it on the same directory that has the Sun Java tarball and let it run. In the end, you'll have a few packages ready to copy and install on each Linux workstation or server in your network.

For the curious, this script (actually the JPackage RPM spec) generates the following packages:

• java-1.5.0-sun-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-alsa-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-demo-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-devel-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-fonts-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-jdbc-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-plugin-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-src-1.5.0.07-1jpp.i586.rpm

You may not be able to install the “sun-jdbc” package, but this does not means you won't be able to run JDBC applications. It just means you do not have installed unixODBC (and who does use the JDBC-ODBC bridge under Linux anyway?)

Likewise, you may not be able to install the “sun-alsa” package if you do not have the Alsa sound libraries installed. I personally don't think I need sound support to run my JavaEE application servers.

Finally, you do not need to install the “sun-fonts” package in every Linux workstation if you do use an X Font Server – you may need to install this only on the font server machine.

After installing the repackaged Sun Java, you can start downloading Java application packages from www.jpackage.org or, better yet, configure your yum repositories to point to the JPackage Project one.

Here's the script. It could be enhanced, for example not being hardwired to 1.5.0 update 7. But it does the work.

#!/bin/sh
# builds a JPackage-compatible Sun JDK RPM
# by Fernando Lozano 
#
# This script can be used, redistributed and changed in the terms
# of the Apache License 2.0 (http://www.apache.org/licenses/)
# provided these initial comments are not deleted nor modified.
# Of course you can add more comments if you like.

bin="jdk-1_5_0_07-linux-i586.bin"
srpm="java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm"

base="build-sun-java-jpp-rpm"

if [ "$1" = "-h" -o "$1" = "-help" ]; then
    echo "This script builds JPackage compatible binary RPMS"
    echo "from Sun JDK 1.5.0_07 binary download for 32-bits Linux/Intel"
    echo "options:"
    echo "  -h: ths message"
    echo "  -q: really quiet"
    echo "  -v: verbose (shows rpmbuild messages)"
    exit -1
fi

if [ "$1" = "-q" ]; then
    output="/dev/null"
else
    output="/dev/stdout"
fi

if [ "$1" = "-v" ]; then
    rpmout="/dev/stdout"
else
    rpmout="/dev/null"
fi

echo "Checking prerequisites..." > $output

if [ -z "`which rpmbuild 2>/dev/null`" ]; then
    echo "rpmbuild not found. Either you need to adjust your PATH" 1>&2
    echo "or you need to install package rpm-devel as root" 1>&2
    exit 1
fi

if [ -z "`which wget 2>/dev/null`" ]; then
    echo "wget not found. Either you need to adjust your PATH or" 1>&2
    echo "you need to install package wget as root" 1>&2
    exit 1
fi

if [ ! -r $bin ]; then
    echo "$bin not found. " 1>&2
    echo "You need to download it from http://java.sun.com" 1>&2
    exit 1
fi

echo "Configuring RPM build environment..." > $output

d=`pwd`
mv ~/.rpmmacros ~/.rpmmacros.sav.$$ 2>/dev/null
echo "
%_topdir        %(echo ${d}/tmp-$base/rpm)
%_tmppath       %{_topdir}/tmp

%packager       build-sun-java-jpp-rpm by Fernando Lozano 
" > ~/.rpmmacros

echo "Creating build directories..." > $output

rm -rf tmp-$base
mkdir tmp-$base
cd tmp-$base
mkdir rpm
mkdir rpm/SOURCES
mkdir rpm/SPECS
mkdir rpm/SRPMS
mkdir rpm/RPMS
mkdir rpm/RPMS/i386
mkdir rpm/RPMS/i586
mkdir rpm/RPMS/noarch
mkdir rpm/tmp
mkdir rpm/BUILD

echo "Downloading SRPM from JPackage.org..." > $output

wget -qc http://mirrors.dotsrc.org/jpackage/1.6/generic/non-free/SRPMS/java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm

echo "Moving required files to build dirs..." > $output

cp ../jdk-1_5_0_07-linux-i586.bin rpm/SOURCES
rpm2cpio java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm | cpio -imud --quiet
mv java-1.5.0-sun-*fonts.xsl rpm/SOURCES
mv java-1.5.0-sun.spec rpm/SPECS

echo "Building JPackage compatible binary RPMS..." > $output

rpmbuild -ba rpm/SPECS/java-1.5.0-sun.spec > $rpmout 2>&1

echo "Finished." > $output

echo > $output
echo "Sun JDK Packages are in $d/rpm/RPMS/i586" > $output

echo "You may need to mannualy create the Java plug-in symlink for Mozilla / Firefox:" > $output
echo "# cd /usr/lib/firefox*/plugins" > $output
echo "# ln -s /usr/lib/jvm/java-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so . > $output

If you are around, please come and join us!

Linux distributions packagers will have a special interest in the May 17, 2:30pm presentation. I can't tell the details, but it'll be about things you weren't legally able to do before. You probably heard about a new license Sun will announce during JavaOne, so stay tunned.

The full schedule of Java.Net mini-talks during JavaOne can ne seen on the Community Corner Wiki page.

I agree with them that no matter how big are vendors and JCP efforts to promote compatibility and interoperability, the ability to run apps is the real measure of compatibility, and you will only get that if most developers test their code with as many JREs as they can, and report back any unexpected behavior.

But I have to add that it's not enough to test the biggest proprietary JREs, which are all of them Sun licensees. Java compatibility will only be real when there's also an independent JRE implementation that is able to run most if not any Java app and you are free to port this JRE to the platform of your choice. That's the true meaning of IT standards: not having to rely on a single vendor to run your apps. David's request is about relying on just Sun as the direct or indirect supplier of JREs.

Even if you argue that free software / open source software JRE implementations are not yet certified and may lack important parts of the JavaSE APIs, there's a good chance they already have enough to run your app, and the problems you may find when they don't run your app are actually your fault, not JRE flaws, as in the case of OpenOffice.org (see http://people.redhat.com/green/linuxworldfreej.pdf).

Hey, they already run Eclipse and Tomcat! Red Hat guys are even running JonAS under GCJ! Why then wouldn't your app run under a free software / open source JRE?

Here's a few good candidates you can try. Please add at least one of them to your standard testing practices:

• Kaffe - http://www.kaffe.org
• GCJ - http://gcc.gnu.org/gcj (this already comes bundled with most Linux distros
• JamVM - http://jamvm.sf.net (good for embebed devices, small RAM footprint)
• SableVM - http://www.sablevm.org

The developers of these free software / open source software JREs found that the single bigger headache, which prevents them from running even some open source Java applications, is the use of vendor-specific, non-standard classes by the applications. Most of the time they are com.sun.* classes bundled with Sun JRE.

So I add to David's request: please treat any use of non-standard JRE classes as a programming error. This will help a lot achieving true standard, compatible and ubiquitous Java.]]> 2006-02-10T14:39:50Z 2006-02-10T14:39:42Z tag:weblogs.java.net,2006:/blog/flozano/217.4096 2006-02-10T14:39:42Z

This customer ran Fedora Linux 4 and Firefox 1.5. We tried other Firefox and Mozilla releases (but could not try old Netscape 4 because the portal uses recent CSS standards and they were planning to start using AJAX). We also tried other releases of Sun Java as far as 1.4.0, besides IBM and BEA JREs for Linux. None of them worked for that particular application.

And what the application did to break compatibility? Nothing so uncommon: it used JSObject to direct the browser window load another page. The applet was a virtual keyboard for user login and we tested it worked flawlessly under Windows with both Firefox, Mozilla and the virus / worms farm (IE). Applets that didn't use JSObject worked fine in both Linux and Windows.

The applet used only standard Java SE / Java Plugin classes, no com.sun.* stuff, no JNI calls and no third party libraries. It is a very basic Swing application.

Digging deeper into the problem, we found the cause was that Fedora 4 packages were compiled using GCC 4.0 while Sun, IBM and BEA Java for Linux were compiled using GCC 3.3 (and older releases with GCC 2.9). So memory layout differences between the code compiled with each GCC release made the interaction between the JVM and the browser lock both, but without generating a SIGSEGV.

We confirmed the problem running the applet under Fedora Core 3 (that uses GCC 3.4) and all went fine. So the customer was left with the option of re-engineering the web app to not use Applets at all, or downgrade the Linux desktop to an earlier Fedora release, that is about to have no support anymore. Unfortunately, free software JVMs like GCJ, Kaffe and JamVM do not yet support reliable applet execution inside the browser.

We would not have had this problem (and the stress it caused) if Sun had a more liberal license that allowed Sun Java to be bundled and distributed with community-supported Linux (like old proprietary but freeware Netscape 4 did) and recompiled / repackaged and redistributed by those distribution mantainers. I hope Harmony or some of the other free software JVM matures quickly enough to give me a real choice over Sun Java.

Major Linux distributions are already commited to JPackage, like Red Hat and Mandriva, and even Debian is using JPackage conventions and scripts for including F/OSS Java applications like RSSOwl and Eclipse in it's official download feeds.

In order to get a completely managed Java environment, JPackage even tells you how to repackage popular proprietary software like Sun JDK their way. Unfortunately they can't redistribute those packages because of license restrictions.

I manage a few Red Hat Enterprise Linux servers who already comes with JPackage RPMs for IBM JRE. It was very nice to be able to use their dependency information to deploy applications to our internal network and let yum take care of updates. It was also very nice to be able to use the alternatives system (from Debian) to switch the default Java from IBM JRE to GCJ when I was mantaining one app that made use of GCJ CNI. And I had no trouble deploying this update alongside others that required IBM JRE (or Sun JRE). JPackage makes sure each app runs on the JVM it needs.

Bottom line, the fact RHEL4 already uses JPackage made deploying and updating Java apps (both desktop and server-side) to a wide array of users and needs much easier than when I had to manually install, configure and customize Sun JRE and many vendors apps.

But now I need Java 5.0 for a new app and but I do not have it JPackage-enabled. Of course I could follow JPackage web site instructions on how to repackage Sun JRE 5.0 (or the new IBM Java Runtime 1.5.0) but it would be much better if they already provided JPackage-compatible RPMs. After all, I could use this time to do more important things for my employee.

Nothing prevents them to do so. The JPackage guys have already done all the hard work for Sun, IBM, BEA, Apache, JBoss and other Java vendors. Their work was already tested and validated by a number of users and corporations. And all major Java vendors already uses many F/OSS software as part of their products, so a few JPackage scripts should present no problem.

So, please, Java Vendors, make JPackage a standard part of your Linux packaging and support. You'll make your customers very glad.

I was always suspicious that NetBeans were a second-class citizen inside Sun, as most of their marketing and development were focused in Sun Studio. Of course I know Sun Studio uses NetBeans as its base, but this fact was never made very clear by Sun marketing, almost as if it were a secret. Besides that, sometimes Sun Studio and NetBeans seems to be developing the feature in parallel, for example Matisse x Raven or the J2EE features.

Well, Robert admitted that in the past Sun Studio and NetBeans teams did not interacted as they should, and a lot of effort was duplicated, but assured us that his vision is that both teams will be working together to improve NetBeans and delivering Sun Studio as a set of value-added plug-in modules for NetBeans. He said the focus is now on NetBeans and not on Studio, that core features will be developed by both teams as part of newer NetBeans releases and Studio won't hide anymore the fact that it is NetBeans + plug-ins.

It takes courage for a person in Robert's position to admit mistakes from the past, kudos to him. Better yet, his vision should benefit both NetBeans and Sun Studio users, who will getter better software and more advances. But I would like to see NetBeans leave Sun's umbrella. I welcome Sun efforts into the product and I am very grateful for them, but NetBeans should have ideas from people outside Sun. The user community should decide how NetBeans would evolve, not only Sun by itself.

And NetBeans 5 can help this a lot. The new support for creating NetBeans plug-in modules enables many small developers to improve NetBeans. Sun should use that to foster a healthy ecosystem around NetBeans, a more open and participative one. But people won't join if they perceive NetBeans as being controlled by only Sun and being just a “demo” for Sun Studio.

If you think this has already been done by Eclipse, think again. Most Eclipse projects look like elephants, too slow to move and “owned” by big companies. Nothing against big companies, but it is not easy to participate and influence Eclipse as an individual, the way we can with other open source development organizations like the Apache Foundation.

The end result is that Eclipse projects are not quick to bring in results (but I have to admit when they do bring results they are great!). Check, for instance, Eclipse VE and WTP against current NetBeans 4.1 and 5.0 betas. Eclipse projects may look more powerful on the web site, but NetBeans is ready for use right now.

My main disappointment with NetBeans 5 is the Matisse GUI builder. It is really great, until you get the wrong layout constraints and find that very few layout properties are exposed. Of course a beta release for such a new software is expected to behave somewhat erratically and miss some functionality, and in fact beta 2 is much more reliable than beta 1, but I don't like to have the visual tools as my only choice. I also have nothing against generated, non-editable, code sections, if these sections are simply property initialization and registering event handlers. But I'd like to change anything I want from the properties and inspector windows, just like I can do if I use other layouts like GridBag and Border. I want to be in control, I do not want black boxes as part of the Software I develop.

By the way, Matisse relies on a non-standard layout, the “Natural Layout” or “Free Design” as it is called from NetBeans menus. Inside the generated code, we see lots of instances of org.jdesktop.layout.GroupLayout. If you know from where it came from, please tell me. Was it created by NetBeans folks, or is it part of other open source project? It looks a lot like JGoodies FormLayout. My complain is, no matter how easy this makes drawing Swing user interfaces, most newbie Java developer's won't understand why the project jar generated from NetBeans will fail to run on another machine having the JRE already installed. But there's still time to add a “distribution packaging wizard” to add a “lib” folder containing all libraries and external classes used by an application project.

And what if I want to lower my app size for Swing-enabled smartphones, PDAs or just plain Applets? I'd like to have improved tools for dealing with other layout managers too. But if not using “Free Design”, we are stuck with the same NetBeans 4.0 features. It's a shame NetBeans still cannot visually edit a GridBag layout (the customizer is far from WISIWIG, although it is an improvement over 3.x). Eons ago I could do that using Visual Age for Java (today I could to this using Eclipse VE, but I'd need a faster machine than my 2.0 Ghz Athlon).

Other statement from Robert let me a little bit worried: he said the future of development tools lies with visual tools. I can understand the strong desire to get all VB developers out there using Java, but I don't thing cloning VB style of visual development is the key. Eclipse got its strength from helping coding, and newer Software Engineering practices like Agile Modeling focus on coding. Many tools that became indispensable to Java developers today like Ant and JUnit also focus on coding. Even Microsoft seems to be realizing this.

The VB style of development is opposed to current Java culture, and I don't think you can become the new “number one” by just imitating the current number one. You have to to make something different that proves to be better. So I think NetBeans (and Studio by extension) development may be constrained by the current Sun vision of fighting Microsoft by imitation.

But, if you do believe this the way to go, why not pursuing it from an Open Source project or JCP Expert Group? Why dont't we have yet “data-bound controls” as a standard part of the Java platform, ready to be used by whoever wants them, no matter the IDE of choice? Sun Studio won't win VB developers by being just another RAD tool. Delphi and PowerBuilder already tried that but with only limited success. Sun Studio per se is not compelling enough, but the Java Platform may be.

We should also wonder why haven't any open source library taken this space like Struts did. Maybe the RAD style of development actually does not matter so much.

Bottom line, NetBeans is a great IDE and Sun is still putting great technology within it. It is best of breed in many respects, but still has rough edges where such an old and mature software shouldn't. It is probably being hurt by too much Sun control over it and would benefit immensely from ideas coming from outside. The question is, what will Sun do to attract outside developers to NetBeans, and will Sun be willing to let them take control?

Natural language is imprecise, ambiguous, and its real meaning has to be inferred by the reader. Not all people who reads an article will understand exactly the same thing the author intended to tell them. This doesn't look to me as a good way to express computer instructions that should produce a reliable and predictable result.

If natural language were the way to develop better software, why would be invest so many time developing new modeling languages like UML, new specification languages and the like?

The problem is most people have trouble in thinking the precise, well-defined way a programming language requires. Learning how to program computers is hard. But people make the wrong assumption that it is hard because we use tools that are hard to use; the fact is that computer programming per se is very hard, and no tool will ever change that.

What did we get from "easier" development tools? The ones that from time to time promise "you won't need a real programmer if you use this tool"? Gartner and etc still says 80% of all software projects misses deadlines and cost by more than 50%.

That's why I like Extreme Programming: they focus on the real issues, that are people interactions and quality control.

We will always need programmers to develop software, and those programmers need to get proper education -- not just proper training, because they need to get the logic and other skills to be able to effectively use any programming tool.

It's just like giving a good programmer a course of drawing software. He may learn all about using the software, but he won't be able to create nice, pleasant figures. You need a different skill set to create graphics than to create software.

Actually, I think we non-English speakers (I'm Brazillian, my language is Portuguese) have a little advantage over Americans and other native English speakers: we don't fall into the mistake of trying to read a computer program as if it were natural language.

Programming language keywords are symbols with no relation to their usual meanings, same with function and method names: they are just like logical operators. But there are too many of them, so you cannot use symbols as mathematicians have used for centuries, and the fact most computers can't render and type symbols like "exists" (∃), "infinite" (∞) and so on simply gave more force to the temptation to "use natural language".

Our advantage is not bigger because most technical docs are in English.

I agree with Vickran in that I don't want Java to become neither more bloated neither more simplified. I also agree with John Reynolds that the Java Platform could make good use of domain-specific languages (that is, dynamic languages). But my vote in this respect is for Jython (a Python compiler / interpreter that generates standard JVM bytecode, built itself using Java).

We will always have new products and new technologies that promise to make computer programming easier, and most of then will continue to be vapor, although some of them will sell very well. But only the few ones that attack real issues, like Java did, and like Python, Ruby and others are doing right now, will have a real impact on programmer productivity.

Not to disregard the efforts of the kaffe, gcj, classpath teams and other involved with F/OSS Java VMs, but what are big open source java projects from Apache Jakarta and Eclipse, small projects like HSQLDB and JUnit, and even individual open source developers, doing to help them?

I remember a few months ago someone posted at an Apache mailing list a complain about the huge help the foundation provided to identify and fix bugs on Sun Java, receiving almost nothing in return. He asked, why weren't some of these efforts spent trying to identify where and how to improve kaffe and etc so they become reliable platforms for running apache software?

Now I ask the same question for open source developers in general: Why don't you spend a little time testing your apps under kaffe and/or gcj? If only to provide them useful bug reports. But most things that prevent current applications to run under these free JVMs are just a few lines of code away, if some more developers decide to contribute patches.

After all, if the community itself don't think F/OSS Java is worth their time and efforts, why should Sun think different?

The idea of using source-code annotations to replace deployment descriptors is not new. XDoclet did this for years, and it was the preferred tool by EJB 3.0 main drivers, the JBoss Group. But XDoclet allowed for misuses of its capabilities that were replicated by the current EJB 3.0 drafts. These are the specification of app-server dependent configurations on the EJB source code.

The Java platform is about compatibility and interoperability, but the J2EE platform have failed so far on this respect because their standards were not always complete enough to let the app developer do this job without interference from the app deployer. An example of this was the absence of a standard for OO/Relational mapping, but this is being solved by the EJB 3.0 spec.

See this fample from JBoss EJB 3.0 Preview docs: http://docs.jboss.org/ejb3/tutorial/security/src/org/jboss/tutorial

@Stateless
@SecurityDomain("other")
public class CalculatorBean implements Calculator
{
@Unchecked
@TransactionAttribute(TransactionAttributeType.REQUIRESNEW)
public int add(int x, int y)
{
return x + y;
}

The @Stateless, @Unchecked ad @TransactionAttribute annotations are fine. I agree these aspects are deeply affected by business logic so it's easier to deal with then using only one source file instead of two (the bean class and the deployment descriptor). But the annotation @SecurityDomain is not fine: this references a JBoss-specific feature, the use of JAAS-based application policies to configure a security realm. If I want to deploy this EJB using another app server, this won't work at all or this will become noop, just trash inside the class files.

If you take a deeper look at this, why the app developer should worry about application policies? Shouldn't this be the sole concert of the app deployer, or the app server administrator? See that if the app deployer want's to use another policy (say he has just configured the use of LDAP for authentication) he'd have to recompile the source code. Your QA department won't be happy with this.

Another example of misuses of EJB 3.0 capabilities come from the persistence example:

@Entity
@Table(name = "PURCHASE_ORDER")
public class Order implements java.io.Serializable
{

It looks pretty harmless until you talk to your DBA. Why should my persistent object specify the table name? Reading on the example (left out because of space), why should it specify the way relationships are implemented (foreign key, join table) and the look ahead strategy for loading related data? Shouldn't this be left for the DBA to decide, and not the app developer?

If the DBA, after some benchmarks, finds another way to map the relationships will yield better performance, or another read ahead strategy prove better given the current usage pattern of the application, he'll have to recompile all Java sources to effect the changes. I don't expect my DBA to be a senior Java programmer, and I also don't expect my Java programmers to be able to take the DBA job, so should one have to change the artifacts created by the other?

This was about performance. But about portability, the current spec and samples define the SQL column type as an annotation on the Java getter. If I use Oracle, a String property becomes a VARCHAR2 column. But this really matters to the developer, who could well be using MySQL? What about many ERP and CRM systems out there, which have to support whatever database the customer does have? Will they have to provide different binaries (ejb3 or ear) for each supported database? A new port should require recompiling Java sources? Wasn't persistence frameworks about database independence?

The current EJB 3.0 drafts encourages developers to write EJBs that are very dependent on the app server and database used and not portable without changing sources and recompiling. Previous releases, if they did not get real portability because they did not defined important things, allowed the app deployer, DBA and others to adapt the application to new environments without touching Java code, but only deployment descriptors. And in this respect the proprietary deployment descriptors most J2EE app servers require are a good thing: just one new / changed file for each new supported app server. Not many changed Java classes for each server. So the new release is a step backwards as along as a step ahead in ease of use.

I am very worried because the EJB 3.0 specs treats deployment descriptors as useful just for backward compatibility. The syntax is not even described on the latest drafts, although they say something about the descriptor overriding what was specified by source code annotations. If this is left for late including on the specs, we may get a deployment descriptor that's not useful at all.

So, please, EJB 3.0 EC members, take a careful look at this. I don't want to use annotations for everything. I don't think deployment descriptors are a bad thing that should be taken out of J2EE development. I want to use they as the main source of info about security policies and OO/Relational mapping for my EJBs. I want my app developers to work without interfering with app deployers, DBAs and infrastructure administrators, and vice-versa. I want to be able to fine-tune for performance without recompiling Java sources. The only way to do this is having deployment descriptors.

Of course, deployment descriptors needs a simpler, more concise and consistent syntax. There's much room for improvement here, and much to gain.

J2EE developers, beware: many people on the EJB 3.0 EC do work for app server vendors. They won't be hurt if you cannot easily migrate your EJBs from one server to another. That's not to say they will consiously produce a spec that generates non-portable EJBs, but they have a big pressure to offer ease of use to their customers and will easily forget about portability issues.

Don't be fooled by the simplicity of “hello, world” examples, they won't scale to full corporate Information Systems. Everything you may hate today about EJBs was created for a reason, and these reasons may still be valid. Please remember the mess that was created by “source code only” compatibility on Unix standards.

Making an analogy among the current EJB drafts and web development, the url-mapping for Servlet classes would be a source-code annotation. If you do not like the standard “*.do” pattern for Struts actions, you'd have to recompile Struts itself. Would Struts become such a widely deployed and successful MVC framework if it were not the flexibility of web application deployment descriptors?