Everything is networked, but as long as you have latency there will be a need to perform rendering locally. The stuff that needs to be sent over the network (commands, data) is already handled by HTTP (or proprietary TCP/UDP protocols).

I have never, not once, used X remotely, in the 10+ years I've been using Linux. I use Linux because, as a developer, there is no reasonable (free) alternative to the GNU tool set, console emulators, etc. available in Linux. But I have a single machine with a single monitor and I really don't need to run applications on other systems. I also use it on my Netbook because it's fast, functional, and virus free. In neither scenario do I have any need whatsoever for remotely running applications. So why have the overhead?

I would much prefer the smallest, most lightweight rendering layer possible, so that I get the maximum performance with the least CPU/GPU cycles. Running through API after API is silly 99% of the time. The problem is that with X I don't really have the option--it's always on. At least with X on top of Wayland I can run lean when I want to.

I can see where it would be useful in a server situation, but I would imagine no sane sysadmin would use Ubuntu in the server room. Ubuntu is a consumer distro that is targeting the home PC / netbook segment, which loves the shiny. For them, Wayland is a perfect fit.

The AMD drivers AFAIK are supported almost entirely by the community. There are some devs at AMD that contribute to the drivers, and AMD has been releasing specs and documentation in increments. 3D is still not fully supported on most chipsets, so you need the FGLRX drivers for that, but for normal 2D desktop operations the radeon drivers are actually faster and more stable (fewer artifacts, etc.). At least, that's been my experience. The radeon driver also supports KMS (FGLRX does not) meaning it's the only option for Wayland.

There is also a lot of developer activity on the forums (Phoronix in particular) and you can really see progress being made literally from day to day. It looks like come Christmas/early next year the open source radeon 3D stiff will start catching up to FGLRX in the upstream releases (Xorg, Mesa, Gallium) but it will probably be a while before that finds its way into most distros.

If you're a KDE user, however, you'll probably want to stick with NVidia for a little while longer. Kwin compositing does not work well with FGLRX or the radeon driver and the KDE devs insist that it's the driver (whereas Compiz runs just fine on the same drivers).

The most frustrating thing about responses like this is that NetBeans has no project model. NetBeans uses plain files and directories with the most common/default path structure appropriate for the selected build tool (Ant or Maven). If you have a Maven project, then you have a pom.xml in the project root; a src folder (with src/main/java, src/main/resources, src/test/java, src/test/resources, and src/main/web if it's a web application); and a target folder. If you're using Ant (the default) then you have src/java, build, and target (I think; I haven't used Ant in ages).

NetBeans is smart enough to know (just by looking for a build.xml or pom.xml in the project root) what build system you are using and display appropriate shortcut nodes in the project view. src/main/java becomes "Source Packages"; src/test/java becomes "Test Packages"; src/main/resources becomes "Other Sources"; src/test/resources becomes "Other Test Sources"; and src/main/web becomes "Web Pages". And if you don't like that, there's always the "File" view which shows you the raw directory layout (the tab immediately to the right of "Project").

Why is this frustrating? Because Eclipse does not use any kind of standard model. It has its own proprietary (hidden) IDE-specific artifacts without which it will not work *at all* (.classpath). The user has to go out of his way to use Ant or Maven (by installing and configuring plugins). And even in doing so, Eclipse still uses its incremental build *as well*. Eclipse is not able to automatically glean classpath info for it's internal incremental build system from the build tool artifacts (build.xml/pom.xml) despite that fact that all of the information is contained there, which means you have redundant (and potentially out of sync) classpath info in your project. And .classpath is usually excluded from source tools (as it references workspace-specific environment info or canonical path references) so each developer in a team has to build and maintain it. It's madness.

Oh well. To each his own.

I'm curious about all of the NetBeans hate. NetBeans ships with:

  - A standard Ant- or Maven-based build system with stellar support for both
  - All kinds of VCS integration (CVS, SVN, Mercurial)
  - Plugins for Jira, Bugzilla, and other ticketing systems
  - Support for every major app server
  - Very decent XML/schema editor with auto-complete and recognition of tags in context-sensitive help
  - An incredibly powerful formatting and styling engine
  - Has an integrated database query tool with SQL syntax highlighting
  - Ctrl+o to quick-search any type in any project you have open (ctrl+shift+o for any file, period) with recognition for acronyms/camel case abbreviations
  - Excellent integration wtih JUnit
  - SVN revision highlighting with mouse-over diff and undo/revert (change by change)
  - Incredible diff and conflict resolution interface
  - WYSIWYG JSF editor
  - JSF tag auto-complete (even with Seam and other third-party taglibs)
  - A full-featured profiler with the ability to take snapshots the entire runtime
  - JavaDoc validation and auto-complete
  - Project groups so you don't have to close and re-open your IDE to switch "workspaces"
  - Language support for Ruby, C++, PHP, and scripting languages (JavaScript, Groovy)

I can appreciate that there is a group of developers that prefer to use lightweight editors and command-line tools, and that's fine. But if you like big honkin' IDEs then NetBeans is a worthy platform, and I've found it to be a huge time saver.

It wasn't until very recently (first with JSF, and then with Glassfish) that Sun got into the business of providing any kind of reasonable implementations. Apache has been the defacto RI producer for as long as I can remember:

Servlet/JSP: Tomcat
JSF: MyFaces
JAX-RPX/JAXWS: Axis
JAXB: JaxMe
EJB: Geronimo/OpenEJB
JPA: OpenJPA
JCR: JackRabbit
Java Logging: commons-logging, Log4j, SLF4j

(Those are just the ones I know off the top of my head). Apache was also a leader in developing most of these technologies with projects like Struts, Turbine, Velocity, Log4j/commons-logging, etc.

The JCP and open-source RI combination benefited Sun immensely. First, most developers had access to most tools and platforms for free, so there was no barrier to entry. The result? One of the largest developer bases for any platform. Second, developers had access to the RI source code, which means they can trace through the framework code, find/fix bugs, and offer their own improvements. The result? One of the largest support bases for any platform (BugZilla, Jira, forums, blogs, etc.). Finally, both of these offer tremendous incentives for commercial third parties to create their own offerings, which has lead to incredibly diversity: RedHad/JBoss, IBM/WebLogic, BEA/WebSphere, Oracle/OracleAS, Apache/Geronimo, Sun/Glassfish, and tons other.

And all of this creates a positive feedback loop that builds on itself.

So where did Sun benefit financially?

1. They receive licensing fees from the commercial third parties and in handheld devices (JavaME)
2. Certification fees
3. Hardware/software/support in their integrated platform offerings (admittedly this has suffered due to the popularity of commodity OSs like Linux)
4. (Indirectly) Not having to pay development staff to produce and support implementations

Oracle is attempting to dam the river so they can sell water to people downstream. If they are not careful, people are just going to find another water source.

I don't see this as the "end of Java", but I do see it as the end of the cohesive, constructive community built around Java. I expect to see fewer JSRs being ratified, more independent third-party libraries being used, and a lot of fragmentation in the community like we saw with web UI frameworks before JSF was introduced. I think it will be up to the container providers to try to hold it together and provide a consistent experience for developers.

Why? I've been using JBoss for years and it seems to be a very robust, agile, and well-managed project, particularly after being acquired by RedHat.

Besides, I wouldn't expect "JBoss" itself to mess with the JVM. I would expect RedHat and SuSE to put effort behind maintaining/optimizing the free JVM, especially given their respective stances on free software.

Why would you have to memorize anything? In the video they have a very cool animation where the letters are magnified as the finger moves. Presumably the same kind of interface could be (or has been) developed to aid in memorizing the gestures. I absolutely cannot stand virtual touch keyboards on mobile devices--this on the other hand would actually make me consider a touch-screen device. (I currently have a e71x with a tiny little physical qwerty keyboard that I can almost tolerate.)

Oracle is not in the mobile market, except in the sense that they now own Java and want to collect royalties for the use of Java in handheld devices. Sun has always required royalties for J2ME (Micro edition) in handheld devices. The issue here is that Google tried to weasel out of royalties by making a Java-compatible VM based on J2SE (Standard Edition) which is GPL and open. The problem is that this move violates the *spirit* of the original Java licensing agreement, which as to open Java for desktop/server use and charge royalties for Java on handheld devices.

I listened to Jonathan Schwartz's keynote at Java One in 2005 and he made the claim that handhelds were the future and where Sun's focus would be. One of his statements was about how there were virtually no desktop computers or land lines in rural areas / developing nations (India, China, Africa) but cell phones were ubiquitous. J2ME (at the time) was on 1 billion handhelds (now over 2 billion I believe). Whatever the royalties are, it is a significant source of revenue.

The success of Oracle's lawsuit will depend whether the wording of the licenses is such that a derivative of J2SE on a handheld device can be considered to be essentially J2ME. I.e. does any flavor of, or derivative of, Java on a handheld require licensing and royalty payments? And it may come down to whether certain APIs or implementations are shared between J2SE and J2ME, which is almost certainly the case.

Google tried to have their cake and eat it too. They wanted the ability to leverage a massive preexisting class library and huge developer population without paying the royalties to Sun/Oracle. So they made a byte code translator to allow developers to build and compile using Java, and execute on the Dalvik VM.

Harmony is in the clear, because the Apache Foundation is not trying to sell handheld devices with Harmony embedded. (Same with OpenJDK, GCJ, etc.)

I think Sun could have successfully sued Google over this, but chose not to, probably because it would be messy and because the goodwill with Google was more valuable. For Oracle it's a potential revenue stream. The intent isn't to kill the goose that lays the golden eggs, but to get a chunk of each egg that comes out.

Break down your tasks into actionable items and ask management for a priority. When "Do X" becomes "Do I work on A, B, or C first?", and it is apparent that A, B, and C require nontrivial investments of resources, then it becomes more real to management. Further, in doing pieces A and B you can demonstrate progress toward completing X as a whole, whereas the nebulous "X" is either done or it is not.

This is an old technique for software project management. Take each requirement, break it into use cases, and put a level of effort next to each use case. A high-level requirement like "Add security to the app" becomes hundreds of "Restrict action A on target B to roles X,Y, and Z" use cases. Each one may take an hour. So whereas a manager might reject a blanket 100 hour estimate for "Add security to the app", showing him or her that there are hundreds of source objects to update, each of which requires checkout, modification, testing, and check-in, then the 100 hour estimate seem more reasonable. (This also shows that you put thought into the estimate and its not an off-the-cuff figure.) And if you get 8 use cases done per day, well that's measurable.

Also, if you can demonstrate a high degree of accuracy in your estimates then you will be taken more seriously. The smaller the unit of work, the more accurate the estimate. If you do 6 use cases in 6 hours (at 1 hour apiece), and then have 2 hours worth of meetings, you're still 100% accurate. Whereas if you estimate 100 hours for X and three weeks later it isn't done, then your credibility is shot. Meetings don't (usually) show up in the issue tracking system, so they aren't measurable. (The 50% or 75% devoted argument is not very effective in my experience.)

I used to say that I didn't have time to do the administrative part of development. But the reality is that I don't have time *not* to do it. Break it down and make it measurable, and then the demands (or at least the expectations) will become more realistic.

I writer server software as well, but I get irritated to the point of distraction by the laggy performance of my IDE (NetBeans in my case).

Probably a troll, but I'll bite.

My point was that NetBeans and Eclipse are written in Swing and SWT (respectively). These, as well as SQuirreL, JXplorer, and a number of other Java client applications perform as well as native applications on Windows and Linux. Not so with OS X. And to make matters worse, the look/feel of the Cocoa bindings hasn't changed since the early 10.1/10.2 days, and the bubbly aqua stuff is really out of place with the rest of the OS.

I'm primarily a web-based applications developer, but I've done a few things with Swing. It has an impressive API and NetBeans/Eclipse are proof that applications written with these technologies can be made to perform well.

I can't think of a single reason to drop Apple _hardware_. Their hardware is fantastic. I have a 3-year old MacBook that has survived to major drink spills, being dropped many times on a tile floor from the arm of a couch, and being routinely trampled by a 1- and 4-year old. I love their hardware.

But if you are a serious Java developer, there are plenty of reasons to drop OS X, though, foremost being the performance of Swing/SWT and the version lag. I've always felt that Apple's support for Java was grudging and second-rate.

Java on OS X has always been a second-class citizen. Swing and SWT apps (read: NetBeans and Eclipse) have always been ridiculously slow and ugly on OS X compared to Windows or Linux on similar hardware and the OS X JVM /JDK is always months (or years!) behind the official version.

So as much as I like Macs and OS X, I ended up switching to Linux a long time ago. Cheaper, faster, better tools.

This is some of what Java has going for it:

  1. Massive standard class library covering everything from smartphones to distributed application servers
  2. Huge amounts of third-party support. If you can think of it, someone somewhere has written a library for it, and chances are it's open source
  3. The best IDEs in existence. NetBeans, Eclipse, IntelliJ, etc. all come with built in support for unit testing, dependency management, source control (mercurial, SVN, git, you name it), profiling, local and remote debugging, etc.
  4. Agent support for instrumentation and runtime redeployment. Using tools like JRebel I can edit code in my IDE and see the results instantly in the application server, and *still* take advantage of strong typing, etc.
  5. Object-Relation-Management (ORM). Tools like TopLink and Hibernate mean that you can reverse engineer a class model from a DB, or generate a DB from a class model, and use the ORM API to effortlessly add optimistic locking, transaction management, and object based queries to your app
  6. Application servers support distributed transaction management (XA) and messaging (JMS) on top of a generalize connection management framework (JCA) in which any vendor can provide a standard connector (resource adapter) to their systems and participate in global two-phase transactions
  7. Open driver support for virtually every data store; lots of choices for embedded in-memory SQL/RDBMS databases
  8. Container-based pooling, caching, and transaction management
  9. Dependency management and build systems like Ant, Maven, Hudson, and Sonar that enable you to very easily configure scheduled builds with static code analysis, automated unit tests, and concise reports of errors with references to changesets included in the build
  10. Perhaps the largest collection of forums, blogs, and online documentation for any platform
  11. Strong typing, API contracts, and runtime introspection identify issues at compile/deploy time, rather than runtime
  12. Strong industry support from multiple vendors (Google, Oracle, IBM, RedHat, etc.)

So, if you're writing a little GTK widget for managing your MP3 collection, maybe Java isn't for you. But if you are a medium-to-large business chances are you either develop or administer an enterprise-scale Java application.

Another thing to consider is that the vast majority of Java tools and libraries are open source, and many of the specifications are formed once an open source toolset reaches a certain level of maturity/popularity. For example, Hibernate did most of the legwork for JPA; JSF was initiated largely due to the success of Struts; and WebBeans is a formal spec defining the basics what Seam provides. So all Oracle really has to do is keep the JCP going and publish the standards while RedHat (JBoss), IBM, the Glassfish development team, and everyone else provides the implementations. Oracle stays competitive with IBM and RedHat by offering a development stack (based on Oracle DB, Oracle AS, Oracle JDeveloper, etc. all of which use Java) *and* continues to collect licensing fees from the other players. Plus they have a little more say in the JCP process, which gives them a slight advantage when ratifying new APIs.

Not to mention that Java is installed in over 2.6 billion handheld devices, each of which pays a royalty fee to Oracle.

What surprises me is that Oracle is partnering with IBM on this venture. I wonder what IBM has on Oracle?