The Source for Java Technology Collaboration
User: Password:
Register | Login help    

Search

Online Books:
java.net on MarkMail:


Shock Doctrine

Posted by editor on July 17, 2008 at 7:32 AM PDT

If the Java language isn't the point, then what is?

As much as we've focused lately about other languages on the JVM -- wasn't it just yesterday that we pointed out NetBeans taking the InfoWorld prize for best Ruby on Rails IDE, to say nothing of Groovy, Jython, Scala, and all -- there are signs of a backlash to the seeming deemphasis on the Java language.

Joe Winchester presents this case in an editorial for Java Developer's Journal, What Does the Future Hold for the Java Language. He makes the case that's it's a perfectly viable choice to specialize in one language, certainly a better choice than to be a jack of all trades and master of none, and that Java's a good choice. He also points out that his prior language of choice, Smalltalk, tried to save itself with a "rearguard action" to make Java run on Smalltalk VMs, and that Microsoft has recently taken the approach of pushing nearly all of its various languages onto the Common Language Runtime VM. To Joe, this is an anti-pattern that Java needs to avoid:

What bothers me now is that there seems to be a resurgence of the idea that virtual machines can do anything. Rather than focus on Java and what the language needs to move it forward, there is a lot of hoopla and fanfare about making JVMs to run Ruby, PHP, or other equally trendy languages, as well as technologies like Java FX, which itself abstracts programming to an even higher and utterly non-Java syntax. If this all occurs, what do we have left? We have a virtual machine that can run Java but can run other languages as well; we have languages that compile to Java but aren’t authored in Java; and we have something that has lost its value proposition and is now all but indistinguishable from its Redmond counterpart. In other words, we’ve lost the plot.

Joe says that instead of throwing out Java in favor of scripting languages because they're more dynamic, better at the web, etc., that it would be more useful to improve Java to possess those traits.

Of course, that's the rub, isn't it? The endless debate over closures, or unhappiness over Java 5's generics implementation, has convinced many that Java can't evolve further. The most pessimistic even call for Java to be frozen in its current form, lest new changes don't work out.

So what do you think? Evolve the Java language, or give it up in favor of a language soup running atop the JVM?


Also in Java Today, Kirill Grouchnikov's blog has some pointers for using Swing applications and Mac OS X menu bar. "Every once in a while i get questions on using the Mac OS X menu bar for Swing applications running under Substance look-and-feel. This refers to the apple.laf.useScreenMenuBar VM flag that is respected by the native Aqua look-and-feel (and its third-party Quaqua extension). Up until this week the only advice that i could give was to use AWT menus (thanks to Quaqua’s author Werner Randelshofer for this). However, it is not the optimal solution for cross-platform Swing applications that wish to use Swing menus on non-Mac platform As i was thinking about this problem after being recently contacted by Sergiy Michka, i thought about an alternative solution which was later reviewed by Swing lead for Apple VM Mike Swingler."

Remote procedure calls (RPCs) are the precursors to modern Web services that are based on the Simple Object Access Protocol (SOAP) or Representational State Transfer (REST). Because all of the Java platform's Web service APIs are built on the concepts introduced in RPC, understanding the Java APIs for XML-Based RPC (JAX-RPC) is an almost mandatory step for writing efficient and effective Web services in the Java language. Brett McLaughlin's tutorial Build an RPC service and client using JAX-RPC takes you through getting and installing JAX-RPC, configuring it, and building a server-side RPC receiver and a simple client-side application.


In today's Weblogs, Joshua Marinacci has updates on OSCON and the JavaFX SDK. "We are now in the final push to get the first Preview Release of the JavaFX SDK out the door for the end of the month. I'm excited by what we've put together but also exhausted. We've done an incredible amount of work during the last year. Now I know what it was like in the early days of Java."

In My testimonial about Hudson, Bruno Ghisi offers a "post about my past experiences in finding a tool for Continuous Integration and now my love with Hudson."

Finally, Claudio Miranda looks at Jetty and Solaris 10. "Want to use manage Jetty with SMF service on Solaris? I have contributed a patch to Jetty and OpenSolaris to allow start/stop/refresh on Jetty server, with a plus, where non-root users can bind to privileged ports."


In today's Forums, cowwoc points out a critical need for JavaFX in Re: feasibility of JavaFX (vs Flash). Wanting a third opinion. "It remains to be seen whether Sun understands that any Flash competitor needs to ship with a rich development environment versus a nice looking script. Java is missing what Microsoft and Adobe have provided from day one: extremely rich visual editors. The Netbeans form editor is great, but it doesn't compare to the Microsoft/Adobe offering. I'd argue that we don't really need something like JavaFX as much as we need a richer IDE. We probably need both, but the graphical editor is more important than the underlying code."

whartung gives GlassFish installation a thumbs up in Re: RE: Request feedback on GlassFish V3 Admin Console one pager1. "And, frankly, all this seems like a lot of work to reduce the download footprint. Not that I'm in general favor of "bloat for bloats sake", but is the download size that big of an issue for Glassfish adoption? It's no Jetty, but it's not THAT big, not by todays standards and bandwidth expectations anyway. I happen to think the current GF install is really straight forward and simple. It it a button click? No, but it's much more flexible and faster (IMHO). It's biggest issue being, perhaps, setting up a Windows service (which I've never done)."

Tijl Houtbeckers points out that ME development is still possible on Intel Macs, in Re: Anyone developing Java ME on OS X?. "Don't know if this has been mentioned yet, but you can use the preverifier included with the Sun WTK for linux. It's a PPC binary but works just fine thanks to Rosetta."

Finally, cjplummer has doubts about some build suggestions in the thread Re: CDC + N800. "I have yet to see a case where setting CVM_COMPILER_INCOMPATIBLE=false is the right thing to do. When the long winded warning about the compiler not being compatible comes up, setting CVM_COMPILER_INCOMPATIBLE=false just hides this fact and sends you down the wrong path. If you see the warning, you either have the wrong compiler, or don't even have TARGET_CC set to a valid path for a compiler."


Current and upcoming Java Events :

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.


Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.



If the Java language isn't the point, then what is?
Comments
Comments are listed in date ascending order (oldest first)

I like the NetBeans/Ruby story because it's such a great win for that team. I once had nothing good to say about NB, but I was wrong.

i think that many "language changes" can be mocked up as Netbean's plugins for instance, which provide a view that looks a slick new language syntax/feature, but is just a special view of the code, hiding the boilerplate and presenting the intention neatly.

"Of course, that's the rub, isn't it? The endless debate over closures, or unhappiness over Java 5's generics implementation, has convinced many that Java can't evolve further. The most pessimistic even call for Java to be frozen in its current form, lest new changes don't work out. " The "rub" is that Sun's recent history of "evolving" Java has been one that's been mostly a disaster. "Features" are added and proposed (closures are a prime example) not because they improve the language but because other languages have them that are hyped ("Ruby has it therefore Java must have it or Java is DOOMED") or to stroke someone's vanity (people wanting their name on a JSR, never mind what it's about). And things that are a good idea (like generics and autoboxing) are implemented in a half-baked manner in order to preserve backwards compatibility with older versions at all cost, leading to problems that could have easily been avoided. That's why people are increasingly wary of any change to the language. They don't want the language to stay necessarilly stagnant (though C++ seems to do quite well without major upheavals for the last decade or more, thank you very much, and so does Cobol for the last 20 years) but because the changes that are implemented are either useless (or worse) or poorly implemented. Sun (and the JCP) has pretty much lost all credibility with a large proportion of professionals when it comes to evolving the language, yet they're the only ones who seem to have the best interest of the language and platform in mind. It's a major conundrum, and is in itself leading people to turn away from Java when it comes to new development, as people see a bleak future for the platform as a whole. Unless Sun can reverse that trend, by being extremely thorough and careful with the language and platform when it comes to new releases, they stand to loose major ground, maybe even see their stewardship of the platform become the reason that people abandon it in favor of competing technologies. What's needed is a clear focus rather than kneejerk reactions and adopting anything that seems like a good idea at the time (like closures, like putting http servers and SOAP stacks into the core libraries).

Java is dead if it ceases to evolve...You want Java to be able to compete with C# (and you should) you've got to forget about backwards compatibility. You need to still support the old versions of the language, but branch them off, seal them off, make it clear that some programs will need to be changed in order to make them work with the new language features introduced in newer compilers...Include helper programs like the Visual Studio Conversion Kit to help people keep up to date. Linguistically: Make Functions first class objects. The type of a function should be defined by its return value, and the type of its parameters. Introduce functional inheritance, or Classes of Functions, functions that extend other functions that do the same thing, but with more parameters or less. Make Java the razors edge, linguistically, and it will never be unpopular. Also, multi-core applications can be developed in a very elegant way using anonymous first class functions and lambdas(https://sourceforge.net/projects/multicore and Microsoft Parallel FX). What Microsoft is enabling C# developers to do is new...People haven't been able to develop multi-core apps in such an elegant way to my knowledge until C# filled this linguistic gap (python may have had something like it, but it is not so clean). I attempted to implement a Java branch of the multicore sourceforge project I lead, but the Java language was too cumbersome to allow for it. That needs to change, I view Java as the first in breed, but it is failing to evolve, it is losing pace. JavaScript is a stronger language for modern application development and so is ActionScript. THIS IS BAD!!!

we don't need Java to change itself to look like every other language out there, which is what you seem to want to do, Cory. Java is NOT dead if it retains its own identity. Quite the opposite. It's dead if it does as you suggest and becomes RubPythoC#++.

@jwenting I'm sorry if I came off that way, of course I don't think that Java should copy every language feature that pops up on the market. Maybe I can justify my point of view. Lets face it, C# is a copy of Java. I don't think Java should necessarily copy C#. I think that C# anticipated a change in the market of programming languages, and beat Java to the punch. I also think C# took the "Java looking" approach to closures and first class functions, so when I see all these suggestions to keep Java's identity by not changing or by implementing these things in different ways than C#, I think its just silly, if Java is going to implement those features, it should implement them the same way that C# did, because that's how Java would have done it from the beginning if it had had those features!!! (not necessarily the same keywords and such) would any one yell copycat if Java copied 'Java'Script and used "function" as a function literal keyword? (I know the language is really ECMAScript, I'm just making a point). Also, I can't help but think that Java's identity is not what's at stake, Java's survival is what is at stake. To me, Java is a very simple oo language with a solid but dated framework and a very solid, but also dated byte-code. Languages can be supplemented with frameworks into perpetuity, but if they become a liability in expressive power(linguistically), they will be cut from the professional's toolkit.