Evan Summers's Blog

The sharp end of the stick

This morning i stumbled across Dan Cresswell's "Java is not a programming language" where he mentions Java being "blind-sided" by Ruby. I got me to musing...

The Java language is a general purpose programming platform, on which one can build RoR'esque and PHP'esque solutions, via libraries, frameworks, or whatever.

People are naturally trying to invent easier reusable ways of solving specific classes of problems. (Often at the expense of their current employer, as talked about in Bruce Eckel's "When Reuse Goes Bad".)

PHP did a fantastic job of making the transition from editing static HTML pages, to building dynamic ones, as smooth and painless as possible, and accessible to non-programmers, who quickly became highly effective programmers. And RoR hits the database web frontend nail on the head, from what i understand.

Java frameworks will borrow and follow RoR. But we want the Java community to innovate and lead. Or do we?

Surely there is real value in being a conversative language, that evolves at a carefully controlled pedestrian pace. Because enterprises like that.

The larger the community is, the more conversative it's gonna be. Like a huge committee, innit. In a way, a happy victim of it's own success.

So I say let's follow and borrow. Let C# et al innovate for the future, so that Java can innovate for the present, learning from the best of the rest, as much if not more from their mistakes as their successes.

C# did it to us, now we can do it back to them. Hee hee.

Comments

• "The larger the community is, the more conversative it's gonna be. Like a huge committee, innit. In a way, a happy victim of it's own success."

  But are we a happy victim? Look how long it's taken to get the EJB3 standard together and how many people have said "we don't need it"?

  Why is it that we've taken so long to start thinking "you know, maybe all this J2EE stuff is just multi-tier programming and maybe it's had it's day"? People were building these systems 10+ years ago and only now have parts of the community started to notice - fast moving that ain't :)

  
  Clearly, there's a happy medium - sometimes follow, sometimes lead - I just think that we don't lead as much as we should because we've closed our minds, confined ourselves to the same well worn paths, been corrupted by our own past and not paid enough attention to our history and what we could learn from it.

  Posted by: dancres on July 12, 2006 at 02:07 AM

• 
  Thanks for your comments, Dan. And for your article which i enjoyed reading this morning :)

  You're right about leading and following. What's great about Java Community is that projects like Apache, and others on java.net et al, can innovate freely "on the edges," and what really works might lead to a JSR down the line, to be standardised as being "part of Java."
  Or otherwise at least be an alternative de facto standard, eg. as one might describe Spring and some Apache projects. The great thing about de facto standards, is that there are so many to choose from ;)

  I'm not much of an EJB/web programmer, so i'm not qualified to say much about EJB. Distilling what i've read, EJB1/2 was a godsend to some, but over-applied by others, like using a supertanker for some sunday afternoon sailing ;)
  
  I guess the lightweight containers eg. Spring with TDD-enabling dependency injection, and lightweight persistence engines, eg. JDO and Hibernate, gave the EJB vendors a wake up call. Although to be fair, EJB3 is only possible now thanks to annotations of Java5. Without those, the defacto EJB3 would be Spring+Hibernate i guess.

  With EJB3 i've got very excited about "enterprise java" for the first time. The annotated standardised Persistence API, and JAXB2, and web services, look great, and tremendously useful even to Swing programmers like myself :) Because Swing applications also need to integrate to databases, XML, and increasingly, web services :)

  What appeals to me about EJB3 as well, is the promise of GlassFish, and its toolability via Netbeans et al. Everything will work out the box with Netbeans, including a fully-cocked database server ie. Derby/JavaDB. Enterprise development will be a pleasure, even for donks like me. Kudo's to Sun and Oracle, for Glassfish and Netbeans EE with Kodo et al ;)

  Posted by: evanx on July 12, 2006 at 07:01 AM

• Just a tick Evan,

  the Java community is huge, and it is far from monolithic.

  Sure, on the JEE front, things are galciating. That is the nature of their domain, conservative. This is a group that requires specifying what technologies they are going to use, before formalising what they even need to do. They get along as best they can, with their horse pushing their cart.

  However, in the JSE and JME communities, and their subcommunities, tremendous innovation is taking place; clusters, WebStart, graphics, mobile apps, etc.

  Please do not use such a broad brush. There is a lot more to Java than simply enterprise computing. I have to disagree with Dan, Java actually is a programming language; and it is also a runtime environment: three of them actually.

  John

  Posted by: cajo on July 12, 2006 at 07:22 AM

• Sorry, glaciating. Just what I mean however, here we have a huge system like collab.net, and yet no spell check. ;-)

  Posted by: cajo on July 12, 2006 at 07:30 AM

• "I have to disagree with Dan, Java actually is a programming language; and it is also a runtime environment: three of them actually."

  Hmmm, so thought exercise time: Are all those API's part of the language? Or are they part of the runtime? Are all API's available across all runtimes? Which runtimes are available on which hardware platforms?

  Do I write my code against the hotspot runtime from SUN or the runtime from IBM or an opensource one or do I write my code against a defined set of API's which are provided by one or more runtimes?

  Posted by: dancres on July 12, 2006 at 08:36 AM

• The language comes from the language specification.The APIs constitute the runtime environment.Runtimes vary in content and resources, by use case, and by platform.People really shouldn't code to specific JITs.People should code to their intended runtimes.Does one size fit all? No way. That is fortunate. The applications are just too diverse. I would actually like to see a few more runtimes; like Java Browser Edition, and Java Hard Real Time Edition.Nice chatting with you again Dan.John

  Posted by: cajo on July 12, 2006 at 09:09 AM

• * Are all those API's part of the language?

  No. Some aspects are mandated by the JLS, though.

  * Or are they part of the runtime?

  Yes.

  * Are all API's available across all runtimes?

  No. J2EE != J2SE != J2ME. There isn't even a strict subset relation.

  * Which runtimes are available on which hardware platforms?

  Depends on the runtime. There are a lot of choices to cover different needs: From Kaffe, which has been ported to anything that has a gcc for it, to $arbitrary_single_platform_proprietary_runtime.

  * Do I write my code against the hotspot runtime from SUN or the runtime from IBM or an opensource one or do I write my code against a defined set of API's which are provided by one or more runtimes?

  The latter. Coding for a specific runtime is bad practice if you want to have portable results.

  Posted by: robilad on July 12, 2006 at 09:10 AM

• "The latter. Coding for a specific runtime is bad practice if you want to have portable results."

  And thus I would contend I'm not writing to a runtime, I'm writing to a platform which is available on a bunch of runtimes. I know nothing about those runtimes and in fact should avoid knowing anything wherever possible.

  At the end of the day this is the nitty gritty - my real reason for motivating this kind of discussion was to encourage thinking about language and API collections and tools. Otherwise there's a couple of dangers:

  (1) We get focused on adding language features where tools or APIs might be a better solution.
  (2) We get to seeing Java as fixed sets of API's and language and forget about the more dynamic elements available to us.

  Posted by: dancres on July 12, 2006 at 09:37 AM

• If you care nothing about the runtimes, how can you leverage their specialised features? This might work fine for infrastructure things like Blitz, (maybe not, does Blitz run on JME?) but what of specific end-user applications?

  Posted by: cajo on July 12, 2006 at 10:15 AM

• "If you care nothing about the runtimes, how can you leverage their specialised features? This might work fine for infrastructure things like Blitz, (maybe not, does Blitz run on JME?) but what of specific end-user applications?"

  I care which platform I run on JME, JSE etc and then I look for a runtime that supports that platform on the hardware I've chosen. Thus maybe I'd _like_ JSE on a phone but maybe there's no runtime to do that but lots of runtimes that support JME.

  And then maybe one of those runtimes has a better garbage collector so I'd prefer that one but I don't _need_ it. If using a slower runtime gets me onto more phones maybe I'll choose that one to do most of my testing on albeit that I could use others.

  Posted by: dancres on July 12, 2006 at 02:42 PM

• 
  John, I like your comment about the differences in pace, carts and horses, in JEE vs JSE vs JME :) As you say, JEE community must needs to be a glacier, while JME is upwardly mobile ;) And in the JSE Swing space, there is also lots of activity, eg. SwingLabs/JDNC, JSR296.

  Dan, i like your enumerated points (1) and (2) above.

  The problem with introducing "dynamic elements" into Java progams, for me anyway, is that this means strings, which are not toolable, ie. not dissectable by the IDE, eg. for auto completion, prompting and error detection, in and by the IDE. The most common example is reflection, where we need to reference fields and methods using fragile string references, which hinder refactorability.

  The (temporary) problem with dynamic languages on the JVM, and in general, for me anyway, is the lack tool support, ie. via rich powerful IDEs like Eclipse, Netbeans, IntelliJ, JDeveloper, Visual Studio, et cetera. Having said that, the JVM and standard libraries is a platform that supports other languages innit, eg. Visual Basic, Python, Groovy, and more to follow I'm sure. But the "platform" in this sense, is infrastructure, which doesn't get programmers very excited, not me anyway. I guess if I was Python programmer, and had to integrate with a Java system, and deploy to their JVMs, then i would be very excited about it.

  On the issue of language evolution vs APIs. Personally i would like to see language features introduced where literal strings are now widely used, eg. database queries, property references, XML references, reflection references, etcetera. It is a big ask. Anyway i program around string literals/references (in Bean Curd articles), so i'm happy if my wishes aren't fuflfilled, but i expect they will be, eg. in response to LINQ.

  I know that languages are not designed for IDEs, but visa versa. But i feel that toolability is so important going forward, that new language features should be designed specifically and only for toolability, ie. turning the tables. Annotations is a great example of this. Generics too. (And LINQ.) Varargs and Enums are not, but i can't live without those ;)

  For instance, if it is not possible to tool up database and XML queries inside strings, or via an API with binding in the language (and not via fragile non-toolable string references), then i for one see the value in introducing new language features to "rectify" that.

  
  

  Posted by: evanx on July 13, 2006 at 01:18 AM

• If someone believe Rails blind-sided Java, they were in fact the ones blind-sided. A lot of people innovate in the Java space, and it's very condescending to them to just say "oh, yeah thats nice, but Rails does it better."

  If anything Rails just packaged a handful of concepts, put it in the same installer, and somehow claimed a "genius" label. Pretty ridiculous.

  I thank book authors like Bruce Tate for this huge misconception.

  Posted by: ilazarte on July 13, 2006 at 05:14 AM

• Evan, if I was a python programmer having to deal with legacy Java code, I'd use gcj to compile it to native code, and then use Python's sane foreign function interface to access it. Like a lot of people do with PyLucene, for example.

  Posted by: robilad on July 13, 2006 at 05:30 AM

• "I know that languages are not designed for IDEs, but visa versa. But i feel that toolability is so important going forward, that new language features should be designed specifically and only for toolability"

  It's kinda interesting that introspection on .class files can tell you a whole lot and is potentially more amenable to tool manipulation than doing it via the source code. Obfuscation became a big deal precisely because of this issue.....
  

  Posted by: dancres on July 13, 2006 at 07:15 AM

• 
  Just for fun in Detroit terms:

  Java is to GM, as RoR is to DaimlerChrysler. DaimlerChrysler takes a risk on new car models. If successful, the monolithic GM will implement a similiar model at no risk to mirror the success of the DaimlerChrysler model (PT cruiser vs. HHR, Minivans).

  Anyways, I think the best part about Java is that it hasn't entirely succumbed to the control of the community. Sun drives and owns Java. If Sun doesn't like something about Java, they change it. Sun didn't like multi-threading in Java 1.4, so they added on bells & whistles in Java 5. Sun didn't like the archaic implementation of web services, so they re-wrote the JAX-WS standard and implemented on GlassFish. These types of actions are the definition of innovation itself.

  Compare control of Java to SQL, C, C++, ECMA, XHTML, or WSDL. These ANSI or W3C compliant specifications / languages haven't evolved much, or at all. The product at its release was innovative, but since release none of them have evolved. Not innovative at all.

  My point is - Java is far more innovative compared to many other programming languages. Definately more than the Java-wanna-be C# on a JVM...errrr excuse me, CLI. Ruby's got a bytecode interpreter as well? That wasn't innovative at all of Ruby.

  Add in performance of Ruby is slower than Perl or PHP - and all I see is an over-hyped programming language that will be great for small dynamic websites, similiar to CGI or PHP, but with worse performance.

  Let's get this straight. The innovation for Ruby came from Java. Not visa versa. You want to see how popular Ruby is? Go check the want ads and tell me the ratio of wanted Java developers to wanted Ruby developers. Then tell me what's over-hyped.
  

  Posted by: phlogistic on July 16, 2006 at 05:44 AM

• 
  nice one, phlogistic. If i gave the impression that i think Java is not innovative, then i gave the wrong impression. You're right, Java is still innovating hard, eg. Java5, EJB3, and very many JSRs in progress, and very many more to come i'm sure. And around Java too, eg. Apache, Spring, and immense number of projects on java.net et al.

  In terms of core language features, we do seem to be "following" C# but i suggest this is not a bad approach - "take the best of the rest and innovate for the present" as i said.
  C#'s LINQ for instance, is very innovative, and given Java's competition with C# for the hearts and minds, we'll be taking the best new features of C#. In terms of APIs, the "rest" includes many cutting-edge Java projects, more so than "foreign language" projects.

  Doesn't matter if we follow the best of the rest, in 6 months, or a year later. That's just a blink of an enterprise's eye :)
  

  Posted by: evanx on July 17, 2006 at 05:53 AM

• 
  Ah I see - you're right I took that out of context about innovation. Yes, agreed Sun should borrow some of the better parts of .NET. Say the Java 5 syntax of for(Object o : myCollection).

  I think status quo as we've been sailing is working good. I think as a whole most of the community is pretty happy about the pace of enhancements & innovations. Not as crazy fast as the Microsoft camp, not as slow as say C++

  Posted by: phlogistic on July 17, 2006 at 09:25 AM

This work is licensed under a Creative Commons License.