2007 Java Predictions 284
jg21 writes "Java Developer's Journal has published the results of its end-of-year poll of various Internet technology players, from its own internal editors to industry high-ups like the founder of Apress, Gary Cornell, and including too the thoughts of professor Tony Wasserman of Carnegie Mellon West. Participants were asked to foretell what they saw happening in 2007. Among the predictions — Cornell: 'The open-sourcing of Java will have no effect whatsoever on Java's slow decline in favor of dynamic languages (Ruby, Python) and C#'; Wasserman: 'The use of the GPL 2 for open-sourcing Java will inhibit the completion and acceptance of the GPL 3 proposal'; and Rails creator David Heinemeier Hansson: 'The stigma of being a Web programmer still using Windows will increase.'"
Open-sourcing of Java will increase its use (Score:1, Interesting)
As for Ruby... well, Ruby's fine but now we have even less resons to consider it. See, for example, "Ruby's rotting" article.
Crystal Ball time... (Score:5, Interesting)
The open-sourcing of Java will have no effect whatsoever on Java's slow decline in favor of dynamic languages (Ruby, Python) and C#.
That depends on what market we are talking about. Open sourcing Java will make a MASSIVE difference in terms of Java's appeal to the open source development community. Whether this translates to more Java software or not I don't know, but there are already some very good programs in Java that are open source (Jedit http://jedit.sourceforge.net/ [sourceforge.net], Jabref http://jabref.sourceforge.net/ [sourceforge.net] and JaxoDraw http://jaxodraw.sourceforge.net/ [sourceforge.net] come readily to mind). Seamless integration with Linux distributions has the potential to make it a much more popular language, and may also result in usability improvements to the environment itself.
Other languages will grow of course, but I would personally be surprised if Java fades too much except perhaps as the "new toy". There is a LOT of Java code out there, and it is doing important work.
The use of the GPL 2 for open-sourcing Java will inhibit the completion and acceptance of the GPL 3 proposal.
I don't understand this. GPL3 will go forward as it is going forward now, with much discussion - I can't imagine any issues Java would raise that aren't already being raised. Anybody with more knowledge of the process and Java know what he's saying here?
Now, just to get into the swing of things, my predictions:
a) Every major Linux distribution will deploy Sun's JRE as a core system component soon after a full open source release is made. Allow six months to replace any pieces that could not be released due to copyright/license issues. The Sun JDK will also see large scale integration.
b) Open source software written in Java that already exists will get a boost in interest and visibility, as it is no longer using a language that is non-free.
c) Graphics performance and native appearance of widgets will be a major focus of interest and effort, possibly resulting in Java applications becoming better integrated visually with the desktop. This may actually cost Java a bit in terms of name recognition, as end users will see less visual evidence of the difference between Java and other languages (I know, I know - that's not what makes Java different, but it's what can be SEEN that counts.)
d) As Linux distributions integrate and include Java by default, it will increase the appeal of both Java and Linux on the server side.
And one that I would like to see proven wrong:
e) No major OEM computer maker will add the Sun JRE as a default part of their desktop, despite it being released as GPL.
that's funny ... (Score:1, Interesting)
That's funny, we're moving away from Ruby and going to Java.
(Severe performance problems with anything to do with Ruby and XML)
Re:My own predictions (Score:3, Interesting)
Java is for many practical purposes an operating system. What mobile java needs is a packaging system like Debian's or BSD's.
If there were a packaging system, then your (non-trivial) mobile application could reach many more devices. J2ME only exists as a number of proprietary implementations with incompatible libraries, and hard to obtain unless it is bundled with your device. They all pass compliance tests, but the bare minimum API is so bare that they all add some set of additional J2SE features. Use those features and your application is no longer portable.
Re:Umm...what stigma? (Score:2, Interesting)
A serious question - when is using SQL server the right tool for any job? Or was it because that's what the client wanted/knew?
Re:Java's dead! (Score:3, Interesting)
And I don't know about moving from one VM to another, but on the Sun VM you can move across OSes without issue. In fact, with more recent Java releases any VM that meets their spec tends to be extremely good about running valid code. (There are certainly a few pitfalls that some programmers fall into, especially regarding threads, where their code makes assumptions about a particular VM's implementation that can lead to problems.)
Heh... Java's got it's place, but... (Score:3, Interesting)
The GC will always cut in at the worst possible times, impacting your ability to respond to data, etc. YOU try collecting 30 Gbytes of uncompressed
data daily with it sometime. We did use Java for front-ends to process the feeds coming from the trading markets at one of my previous jobs, but
the stuff that aggregated it and sent it to the trading engine and preserved it on disk was all PURE C++ code. The Java stuff couldn't cut it.
I certainly wouldn't use it to control anything like a nuclear reactor or a fly-by-wire system, let alone the task I mentioned.
Java's good for normal business apps, user interfaces where performance isn't absolutely critical, and the like. Something
like C/C++, Pascal, Ada, or even Forth would be a better choice in areas like those.
Re:'Javas slow decline in favor of...' oh please (Score:4, Interesting)
Re:Java's dead! (Score:5, Interesting)
I've never been a fan of the language. Performance is terrible, and moving an app from one VM to another often causes serious problems. The cross platform claims have consistently been exaggerated.
I work for a large .com that serves up tens of millions of hits per day, and we are a Java shop.
You don't know what you're talking about.
re: cross-plaform compatibility. I do my development on OS X, but most of our developers use Windows. Our dev and staging environments are Linux, and our production boxes are Solaris, although we've recently introduced Linux into that mix as well.
There have been several times where I have taken a jar file built on my machine, and deployed it to other developer's machines or our staging environment with absolutely no problems. The same jar runs on every OS we deploy to.
Nor has performance ever been a problem. VM technology has seen amazing improvements over the past ten years, and is now such that for most non-trivial applications it is more performant than the compiled C/C++/Obj C equivalent. The success that Java has seen would not have been so tremendous if this were not true.
Re:'Javas slow decline in favor of...' oh please (Score:3, Interesting)
Currently, in my area, Java -junior- programmers get snatched right up. You don't hire junior programmers in a declining industry, you hire senior programmers (because by the time the juniors become senior, the environment will be history). There has been an increasing amount of projects in Java, especialy since Java 1.5, since that was quite the milestone. Same with the last few J2EE versions.
On top of that, now in the latest specs, EJB 3.0 is actualy useful (and doesn't have to be systematicaly replaced by third party frameworks).
Now, on top of all this, more and more schools are using Java as a teaching tool. Which means all these people that come out of school, will be wanting to use their skills. Thus more demand, more support, more projects.
In the hardcore enterprise world, the only thing that can match this is
The one exception to this is the high end R&D stuff, which tends to use Python/C++ or something along that line (I beleive thats what Google use for a lot of things?), but thats a different market altogether.
Re:Java's dead! (Score:5, Interesting)
1. Rendering double-byte character sets on AIX and Solaris crashed the JVM for various combinations of language (ja and ko were notoriously fragile), JVM, and OS level.
2. Code that spawned processes worked correctly in Windows, AIX 4.3.3, and Linux, but failed under AIX 5L and Solaris.
3. Solaris would throw an erroneous OutOfMemoryError when lots of EJBs were loaded, but it worked fine under AIX 4.3.3, AIX 5L, Linux, and Windows.
Our project was a relatively simple and classic J2EE webapp with a few EJBs for adminstration, some JDBC for large dataset handling, and JSPs for the frontend. It had an "InstallShield Multi-Platform"(tm) Java-based installer. We generally found JVM errors at the rate of once a month. Most could be worked around, but a few had to be documented to the user, and some (such as running the installer in a particular double-byte character set) could not be solved at all given the existing necessary workarounds for other JVM bugs.
Perhaps the JVMs have improved in reliability and work now as you say they do. I moved away from Java after that project and I doubt I'll ever switch back now.
Re:Java's dead! (Score:4, Interesting)
C is unmatched in its ease of use from other languages and in the consistency of compiler support. That will ensure that it stays at the center of the programming universe. A library written in C can be used from virtually any other language in the world, on almost every system in the world, so a library developed in C will always have twenty times the users that an equivalent library in another language would. This is the real key to C's success, not anything else. Well, that and the fact that C is a simple language that is very easy to learn.
What do you need to write an operating system? First, access to the hardware. This seems like a deep and mysterious power, but whether a language can do this only depends on whether the language implementer decided it was a good idea -- you can hack a compiler for *any* language to emit the right sequence of instructions to access hardware controllers, handle interrupts, and control the processor. It doesn't take much linguistic support.
Actually, that isn't the way it's normally done anyway. That stuff is handled at the lowest levels by assembly code. The HLL part of the OS just has to interact with the assembly code efficiently. That means two things: the ability to define and manipulate binary data formats in memory, and the ability to call code written in assembly.
You'd also want the language to function without a large run-time system, to minimize the amount of assembly bootstrapping necessary to start up. You probably also want a language in which it is simple to write efficient code, unless you have more system resources than you know what to do with.
So that's all you need to write an OS:
Practically speaking, I can't imagine doing it without an imperative language with a clear linguistic separation between stack allocation and heap allocation. That's probably just my mental limitations, but let's allow it anyway. You still have a very large number of languages left, though most of them have been choked off by the success of C. Off the top of my head, Ada and C++ are well-established languages that meet all the requirements I just stated.
An argument is often made that an OS must be implemented in a language that *lacks* certain features, because those features shouldn't be used in kernel code. I really don't understand that. What's even more mystifying is that the argument comes from C programmers. A C programmer will chew your ear off talking about how languages shouldn't protect programmers from their own mistakes, programmers need the full power of the computer, if a guy can't handle pointers then he shouldn't be programming in the first place, blah blah blah, but if you mention C++, his scrotum shrivels up and suddenly he's afraid that this big bad language will force him to write bad code.
The idea that someone might have the intelligence and discipline to design and implement part of an operating system, but will willy-nilly inject terrible features into that operating system merely because the language supports it, seems utterly bizarre to me. Surely everyone who has programmed in C or C++ has had to follow project coding guidelines. Of all the coding mistakes you can make, accidentally using a forbidden language feature seems like a pretty easy one to avoid.
Another frequently cited problem with using languages other than C is compiler support. I don't know if you meant to include such issues in your question or not, and I really don't have the knowledge to comment about compiler sup