Java's Backup Plan If Oracle Fumbles 276
GMGruman writes "In an InfoWorld blog, Paul Krill suggests that those concerned that Java might get lost in Oracle's tangle of acquired technologies should relax a little: Java's future isn't wholly in Oracle's hands, so if Oracle screws up or lets Java languish, the popular language has other forces to move it forward nonetheless."
What could possibly go wrong ... (Score:2, Informative)
Re:What could possibly go wrong ... (Score:5, Informative)
The issue was violating the the compatibility constraints, so that code would no longer be portable to non-Windows O/S. This was precluded by the license which MSFT signed, so the lawsuit was reasonably decided.
Re: (Score:2, Informative)
But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment, and this only got worse as Sun kept cranking out a shitty new theme with each release of Java. Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.
The situation was slightly better for server-side Java, but we still ran into the
Re: (Score:3, Insightful)
Java's cross-platform compatibility has always been a myth
Don't talk nonsense, man. Back that up with something.
If you write the code properly, and stick to Java (no JNI stuff), it's cross-platform. How is that a myth?
Re: (Score:2, Informative)
The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.
Re: (Score:2)
Python, yes. C, no. Not unless you include the source code, and recompile for the new platform.
Sun's claim was that Java class files wouldn't need to be recompiled to run. I found that reasonably true. (Of course, you had to be running on a compatible JVM which had been compiled for the appropriate local platform.)
Note, by the way, that Python achieves cross-platform capability by an exactly comparable means. Ruby and ECMAscript basically don't HAVE a compiled form, but if they did it would be the same
Re:What could possibly go wrong ... (Score:5, Interesting)
Rubbish, Java *is* especially cross platform when compared to other languages. For example, C - which you cite.
If you write a simple command line app, then sure, C and Java are about as cross platform capable as each other. Write a GUI app in C and Java and the former has no cross platform options.
In C, you have to worry about endianness, in Java you don't.
In C, you have to allow that primitives types may have different sizes, in Java you don't.
In C, you have to allow that structures might pack differently, in Java you don't.
In C, critical issues like threading will be platform dependant or non-existent, in Java it's consistent and standard.
Java also has a consistent memory model, which provides a lot of value in working cross platform as well as the huge common library which is likewise valuable.
I could go on, but I think that's sufficient to call BS on your claim.
In Haskell or JavaScript, there are nowhere near as large *common* sets of libraries, so you can't as easily rely on your library of choice being supported on a client system.
Christ, JavaScript doesn't run the same browser to browser, let alone cross platform.
Re: (Score:2, Informative)
Java has never really been a viable option on Mac OS X, and Mac OS before that.
The reason for this was never Java itself, but Apples stranglehold on the implementation and their very public "fuck you" attitude toward developers wanting a release within 2 years of the releases on other platforms.
Re: (Score:3, Interesting)
So *why* was/is Apple in charge of the Java implementation for Mac? I don't buy the 'too much resources' argument I've heard. If your entire company is about Java (changing your stock symbol to JAVA for goodness' sake!) why cede control of implementation on a major developer platform (or one which could become a major developer platform)?
Re: (Score:3, Insightful)
According to the Sun engineers I've talked to it all has to do with a really old license agreement between Apple and Sun that they can't change for now. It originates from the very early days of Java, a time when Apple was almost desperate to get more attention to the Mac and saw Java as a lifesaver as applications developed for it would almost automatically work on the Mac as well. So they basically gave Sun a big load of money in exchange for the exclusive rights to make Java for the Mac platform. That ga
Java cross-platform DOES work (Score:3, Informative)
We have java swing code that runs on window, linux, and os-x. We use a custom look-and-feel so things are consistent. Ok, the one-button mouse is a pain.
We java backend code that runs on intel (windows/linux), powerpc, and arm. I routinely deploy and test on linux-x86 and deploy to powerpc and arm targets with zero problems.
Re:What could possibly go wrong ... (Score:5, Insightful)
Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.
That's the fault of the programmer(s), not Java.
Besides, while you have valid points, they are irrelevant to the topic at hand; MS signed a licence saying that they could not introduce Windows-specific classes into the java.* package hierarchy, and yet they did so. No one would have cared if they'd put them in com.microsoft.*, but they chose not to do so.
Re:What could possibly go wrong ... (Score:5, Informative)
But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment,
Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately ? Visual Studio looks different then the rest, Office looks different from the rest, Outlook looks different from the rest of Office, Media player looks different from the rest, Home Server UI looks different from the rest and I could go on and on.
and this only got worse as Sun kept cranking out a shitty new theme with each release of Java.
In the like 14 years of Swing existence there have only been 3 themes in the JRE: Metal, Ocean and Nimbus. And metal is selected by default. Java never sets one of the newer themes by itself. So basically the default theme hasn't changed.
Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.
So there are people who make crappy programs in Java. How exactly is that different from other languages ?
early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).
A few years before pure JDBC drivers were available ? That was when, 2000 or something ? Since that problem is long solved I don't really see how thats relevant today.
Java has never really been a viable option on Mac OS X, and Mac OS before that.
Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.
Re: (Score:2)
Who really actually cares Java on the desktop?
Many people who don't write shrink-wrapped end user applications for the mass market, but things like specialized UIs for corporate desktops and workstations.
Re: (Score:3, Interesting)
Apple cares about consistency on the desktop? that must be why Safari 5, QuickTime X Player, iTunes and Finder all look the same. Oh wait. None of them look the same.
Apple doesn't give one tenth of one shit about their own HIG and they never did.
What I find really interesting about Mac OS is that it's the last environment using a "Unix-style" file picker where you have as many panes as you like and each subdirectory click results in a pane shift to the left as the new directory is opened in the rightmost pane. Meanwhile KDE has a totally Windows-styled version and GNOME has a sort of fusion of Win and Mac.
Re: (Score:3, Interesting)
Dolphin's column view is kind of crap, but that doesn't mean it's useless. Shuffling files and folders around is something I do daily, and it's mighty nice when I can access several dozen folders from one window, rather than having to open a bunch of individual windows and juggle them with Alt-Tab or very meticulous tiling.
That said, the fact that this view is predominantly used on Apple's nerfed OS is quite ridiculous.
Re: (Score:2)
Re:What could possibly go wrong ... (Score:5, Insightful)
But Java's cross-platform compatibility has always been a myth.
Bollocks.
I've been a Java developer and manager of Java developers for about 10 years now. Before that, 20+ years as C/C++/asm guy across a wide variety of platforms ranging from embedded system to Honeywell/Bull and IBM mainframe and just about every mainstream business platform in between (AS400, VAX/VMS, various Unix flavors, Linux, Windows, Mac, etc.). So application portability is a subject I have a bit of experience with. While in the earliest days of Java portability was more wishful thinking, I can unequivocally say that since, oh, Java 1.4 if not earlier, cross platform portability has been spot on. It just works. I can't even remember the last time I took a Java application I've written to a platform that it didn't work on. Even today I am always mildly surprised to take a fairly complex GUI application I've developed on, say Windows, and drop it on another platform, like Linux or OSX, and watch it run flawlessly. I recently wrote a manufacturing line simulator to use as a test backend for a Java-based shop floor system. This is a multi-threaded GUI app simulating and displaying in real-time movement of product through the line, while interfacing with OPC servers and host applications via message queues and databases. When it was done, I dropped it on an Ubuntu desktop box and aside from the slight differences in the Linux GUI appearance, you wouldn't know which one you were looking at.
The only portability problems I've seen are either from dependency on native JNI code (which is rarely but occasionally necessary) -- and almost all databases these days support pure-Java Type4 drivers without dependency on native clients -- or due to lousy programmers who hardcode platform specific constructs. I have *never* had an issue with filesystem path portability over the hundreds of Java applications I've written or managed in the last decade, because I never assume/hardcode anything specific to the platform I'm developing on. This is a common failure of your typical VB developer that is new to Java -- all they think about is Windows, many have had zero exposure to other environments, so that's all they know. Which is fine I guess if you're a 100% Windows shop or targeting a Windows base, but then I'd certainly question the transition to Java in that case. Regardless, don't blame the language for its misuse by developers -- if so then we could condemn every programming language ever made.
I like Java well enough and am proficient enough with it that even if I were stranded in Windows purgatory forever, I'd still consider using it over .NET even without the portability benefits. I've had the occasion to have to write some C# due to some OPC/DCOM integration code that required it. While there are some things about the .NET platform and languages that I find appealing, there's not enough there to win me over from Java.
Re: (Score:3, Informative)
we still ran into the FS path problems
Yes, well, when trying to use some platform or technology, it helps to RTFM [sun.com].
Seriously. Java won't make any code written in it portable automagically, but it does give you everything you need to write portable programs, and has plenty of documentation explaining how to do just that.
Re: (Score:3, Interesting)
Also a side effect of it was the web getting stuck on Java 1.1.6 for so long. Basically it got stipulated that MS had to ship that version, unmodified, in IE. That's what happens when you let lawyers after tech issues. Sun wanted MS to not make special mods to their version of Java but basically it can down to having to have that version. So the MS Java in IE languished at 1.1.6 and people kept using that because they wanted to be compatible. Finally MS was able to just remove Java and say "download it your
Re: (Score:3, Insightful)
You are wrong.
Microsoft wanted to provide their own extensions and JVM that was not compliant with Sun Java while still calling the environment Java and using Sun Java trademarks and logos. The entire lawsuit was about the Java trademark. Eventually MS released their own language that is partially compatible with Java, you should know about it, it became what's known as J++ and later J#.
MS was forbidden from using the Java Compatibility trademark - the steaming coffee cup logo.
restraint of trade (Score:2, Informative)
Go away, lying revisionist troll.
The lawsuit in 1997 against Bill's Microsoft by Sun was about contract violation. Microsoft had a contract to distribute java, not their own proprietary version of java, but bona fide java true to the published specifications. The allegations, proven in court, were that Microsoft aimed to harm to Java platform, violated the Sherman Act by illegally monopolizing and illegally maintaining aon the Intel-compatible PC OS market and the web browser market and the office prod
Re: (Score:3, Interesting)
While the Right Thing resulted from the lawsuit, it's funny how it hurt Sun and Java more than it hurt Microsoft, which was Microsoft's real goal anyway.
The thing is, I remember around that time that Sun's CEO Scott McNealy was constantly ranting and raving about how the goal of Java was to take over the desktop and specifically "Kill Microsoft". Launching a frontal assault against Microsoft (especially at that time) was foolish, and look at what happened. If the good folks at Sun had kept their mouths shu
Re: (Score:3, Informative)
It is a curious fact that the original NCSA Mosaic documentation did not mention CERN or 'World Wide Web' anywhere. That despite the fact that 60% of the actual code in Mosaic was libwww from CERN. I know those facts as a member of the CERN team whose work was plagiarized. Later Andressen commissioned a book titled 'Architects of the Web'. It p
Re: (Score:3, Informative)
No, it was a breach of contract suit; Sun and Microsoft agreed to a (publically available) contract about Microsoft making the reference implementation of Java on Windows, but then Microsoft broke the terms by doing stupid things like adding keywords (delegate, multicast [sun.com]) to the language and methods and fields/constants to the standard classes.
I mean, this is public knowledge - why do you choose to lie? Yes, Sun was late in specifying JNI, and hence both Microsoft and Netscape came up with their own impleme
Re: (Score:3, Informative)
It depends on what you mean when you say Java.
The Java(tm) name is owned by Sun/Oracle.
The Java Language Specification is owned by Sun/Oracle and is offered online for free, with a few restrictions however. As an example you are only allowed to print it once and not make any copies of it.
The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.
So the answer varies depending on what you mean with Java. While the phenomenon known as Java
Re: (Score:3, Informative)
No, it's not decoupled enough to be independent...but it's decoupled enough to *become* independent, if enough people put enough time and work in on it. (The constraints listed mean, e.g., that the entire documentation would need to be recreated in a logically equivalent form, but in a form different enough to not run afoul of copyright restrictions.)
Still, good progress seems to be being made in that direction. But much more should be done, even if Oracle demonstrates both commitment and competence.
Oracle actually uses Java (Score:4, Interesting)
Oracle uses Java for supporting it's bread and butter database.
The Universal Installer is written in Java as are a number of other tools.
It would cost Oracle millions of dollars to rewrite these tools if they killed Java.
They could still kill Java but it it would not be an easy decision for them to make.
Re: (Score:3, Insightful)
It isn't just the Universal Installer that's written in Java; for some things there are shell scripts that bypass it. A much bigger and profitable product for them is the E-Business Suite, which is mostly Java with a few native code components. Letting Java languish would mean losing billions of dollars in support and maintenance fees as customers abandon EBS (and the Oracle database by extension) for more up-to-date enterprise software.
Re: (Score:2)
The tools you're referring certainly didn't have production costs of millions of dollars. They're not very complex and a bit crappy.
Well, this is Oracle we're talking about.
Letting Java languish is not the problem. (Score:5, Insightful)
Oracle will not let Java languish, they need Java to exist because it's part of their ecosystem now whether they wanted it or not. It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.
The issues for Java are either Oracle getting into a fight with IBM and resulting in a fork of Java or distrust of Oracle pushing a critical mass of developers away from Java and onto .NET. As to the first, Oracle has to suppress their natural desire to charge like wounded bulls for everything they own, and try not to interfere with the JCP much at all, which is a big ask really. For the second, it's already starting to happen in certain areas. There are shops out there who have spent an awful lot of time and money getting Oracle out of their DC and they don't want it back again.
Re: (Score:2)
So... should we expect to see using non-Oracle databases from Java becoming harder?
Java isn't really built for the future is it? (Score:2, Troll)
There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor. Multi-core and multi-processor methods are expected to transition to multiple cores. At the moment, we have the core OS managing processor time on multiple processors but that's not the efficiency that has been imagined even it if it helpful and yields good results. So what about Java? The language itself is of the classical va
Re: (Score:2)
There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor.
The 1970s, 1980s, and 1990s called, and they want their predictions back. People have been saying that single core architectures have reached their limit for a long time now, so what makes you think it is definitely true now as opposed to a decade ago?
Re: (Score:2)
The fact that CPU makers have stopped boasting about their chips megahertz rating and instead switched to boasting about how many cores they have comes to mind. Also, graphics cards are massively parallel (1600 cores in Radeon 5870), and there seems to be a push to get them to work on general computing.
Re: (Score:2)
Re: (Score:2)
So you are basing your argument on marketing?
Everyone and their mom is building processors for the consumer and server markets alike with more and more cores. Even handhelds have gone multicore. If this doesn't tell you that we're in the age of multicore processing, then I don't know what can help you. But maybe you could try to keep up with the pack [slashdot.org] so that you too can see where we are headed [slashdot.org].
Right now basic limitations of physics mean that we're going to have to make a sort of right turn and go beyond basic photo-litho procedures if we're going to c
Re: (Score:2)
I'm basing my argument on the simple logic that if a CPU manufacturer could make a single-core CPU that's significantly faster than the current ones, they would, rather than force the programmers to make parallel programs which, as you yourself noted, is hard.
Was this really that difficult to understand, or did you simply figure this would be a nice cheap shot?
Re: (Score:2)
Re: (Score:2)
Just what are you talking about? Blaming a language for something that is an architectural decision?
I've been using multiple cores in a 2-quad core processor environment for over a year now, of-course my design allows me to do so and has nothing to do with the language itself.
Under GNU/Linux use taskset to attach a process by Id to a specific core (or to a number of cores) and start more than one JVM and have your application's architecture use that cluster correctly.
Re: (Score:2)
Well, that would work. But it would be LOTS of work.
A better choice would be a dataflow language, like Prograf was. (Though preferably one that didn't only have graphical representations of it's programs.)
In the meantime, even Google's go would appear to be an improvement over Java in this area. (It needs LOTS of work on it's documentation...or at least it did the last time I looked at it. And it's libraries are still pitiful...but they claim a knowledgeable user can add any C library, so that should be
Re:Java isn't really built for the future is it? (Score:5, Insightful)
You have an aptly chosen user name. Not only is multi-threaded programming in Java quite easy to use, Java hasn't been interpreted in quite a long time.
Re:Java isn't really built for the future is it? (Score:4, Insightful)
Is Java doomed to get stuck behind in the single processor world
Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.
Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.
Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.
This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/ [baptiste-wicht.com]
Re:Java isn't really built for the future is it? (Score:4, Insightful)
Elegance? Closures? Now you have me scared. Really scared.
The most serious problem with Java today is the whole complexity of the generics feature added in Java 5. Typing container classes was fine (and the only thing any working programmer I have talked to actually uses), but as soon as you venture beyond that it descends into a nearly incomprehensible API, all in pursuit of the elusive and trivial pursuit of absolute type safety (at which it fails anyway). Angelika Langer's FAQ about Java generics is 512 pages long. One of the world's leading Java experts, Ken Arnold, cannot explain the meaning of the Enum generic class's definition, I could go on and on.
As a whole the generics is a useless and dangerous disaster. If you mastered Langer's FAQ and could actually write code using generic wildcards no other programmer could understand and maintain your code. And I am doubtful that you could yourself, 6 months later. Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field).
And the root cause of this disaster, as opposed to a useful tweak (typing containers and letting it go at that) is the search for "elegance" in a formal Comp Sci PhD dissertation type way.
What we need right now is for whoever is guiding Java development to find away to back out of the generics disaster to simplify the language and leaving only features people can actually use. This will clear the field for actual useful innovations.
Re:Java isn't really built for the future is it? (Score:5, Insightful)
Generics seem pretty straightforward to me, even the "? extends Whatever" syntax. Maybe you could give some concrete examples as to the problems with generics. The only problem right now is that type erasure makes arrays of generics impossible. Hopefully they'll fix that with the next revision.
Re: (Score:3, Interesting)
Here's an example [gmane.org] of how complex it can get. Extract:
Re: (Score:3, Insightful)
I don't think generics are a 'disaster'. More like 'potential disaster if you don't watch your ass'. And to date, I still haven't seen a better way to do it. (Your suggestion, "typing containers and letting it go at that", makes no sense; there was no way to do that without adding generics to the language, or something that works like generics.)
Anyway, it doesn't matter. There's no way in hell that they'll be removing a widely-used feature from future versions of the language. As long as we're coding in Jav
Re:Java isn't really built for the future is it? (Score:4, Insightful)
As a whole the generics is a useless and dangerous disaster
You keep repeating that. Citation needed.
Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)
So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.
I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.
Re: (Score:3, Interesting)
As a whole the generics is a useless and dangerous disaster
You keep repeating that. Citation needed.
Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html [java.net] and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 [artima.com] and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html [sun.com].
Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)
So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.
Indeed it is a bad thing. A probl
Re: (Score:2)
The trouble with generics is that to allow backwards compatibility they broke the implementation. Otherwise it's an excellent idea. (I'm not really sure I like the syntax, though.)
Still, if you use them properly and carefully, they allow much cleaner code.
OTOH, I'm not at all sure about Java7. I recently downloaded NetBeans 6.9, and it keeps crashing. It's usable, but just barely. And not enough that I continued to use it. (I've started to use Eclipse instead. This is a pity, as Eclipse seems to assu
Missing the point... (Score:2, Insightful)
In a rare fit, I actually read the TFA (I know, I don't know what I was thinking), and it leaves with the feeling that Paul is concentrating on the wrong argument...
He appears to be arguing that third-party vendors control Java through the development of their frameworks and tools. While most modern-day development is relegated to gluing together frameworks instead of actual programming, I think this misses the point in the same vein as when people talk about JEE being Java.
Java is a language upon which th
Hear, hear. (Score:2)
Yes, Java core language is stagnating. Even JDK7 has not much new features.
Java does have a nice ecosystem of libraries, but by now we've explored about 100% of what can be done in libraries without changing the core language. But there are limits, and a lot of things are just not possible to do in libraries.
For example, java.util.concurrent library is quite nice. But it's rather clumsy even with the planned closures support, any parallel algorithm is quickly drowned in the clutter of anonymous classes. In
Re: (Score:2)
Yes, Java core language is stagnating. Even JDK7 has not much new features.
I disagree. Java is evolving at a reasonably steady pace and while each subsequent release is not as radically different as its previous as in some newer languages, this is to be expected since the language is already fairly mature. Its usage however, is ever expanding.
http://langpop.com/ [langpop.com]
If you check out the link above, you can see that C# is considerably behind Java in popularity (its even behind old standbys like C, C++, PHP and Perl) which makes me wonder where the "java is dead" crowd are getting t
Re: (Score:2)
"Its usage however, is ever expanding."
Where? Java is pretty stable only in enterprise because of large volume of legacy code. All other usage areas are disappearing.
langpop is rubbish. If you want to get real picture - try searching Monster.com or freelance sites. C# now dominates Java in nearly everything.
The pace of Java development can hardly be described as 'steady'. It's more like 'spastic' - 5-7 years without any updates followed by stinky code drop from some obscure JSR group. Come on, Java6 is clos
Re: (Score:2)
Where? Java is pretty stable only in enterprise because of large volume of legacy code. All other usage areas are disappearing.
Where? Everywhere. I don't know what enterprises you work in, but I've been in enterprise development for 35 years and I've never seen such a sea change in such a short time toward any particular platform. Java is in nearly every major enterprise application available on the market nowadays - EAI, ETL, CIS, HRM, ERM - you name it - the big vendors are either switching to or already using Java. Outside the enteprise, there's a burgeoning new development ecosystem building steam around Android - of which the
Re: (Score:2)
"Where? Everywhere. I don't know what enterprises you work in, but I've been in enterprise development for 35 years and I've never seen such a sea change..."
Yeah, yeah. I know. And I'm absolutely not interested. The world of enterprise is a world of stale old tenchnologies, it's a world of hopeless legacy. Java gave it a brief time of excitement, but now it'll fall back on being soul-crushing boredom. Only now with Java instead of COBOL.
While small and nimble companies will use good tools (.NET, Python, etc
Re: (Score:2)
Yeah, yeah. I know. And I'm absolutely not interested. The world of enterprise is a world of stale old tenchnologies, it's a world of hopeless legacy. Java gave it a brief time of excitement, but now it'll fall back on being soul-crushing boredom. Only now with Java instead of COBOL.
Wow, now you've really exposed your naivety and cluelessness. The world of enterprise is what drives all the significant developments. Small, nimble companies that are successful are inevitability consumed by "enterprisey" companies the moment they show potential for profit. Most are started with the dream of being successful enough to be bought out by a larger company. The technologies they possess are added to the portfolio of the consuming company so your argument doesn't hold water.
You seem to want to
Re: (Score:2)
"Virtually, every single phone in the world..."
J2ME is dead.
"oh, and there is Android too."
Which is not Java(tm) and they also think about making Go language the first-class citizen.
Re: (Score:2)
Which is not Java(tm)
You're splitting hairs now. This is equivalent to saying Mono is not .Net, but in reality, they are slight variations of the same theme. True, the Delvik JVM is not officially the Java JVM, but it runs equivalent bytecode that has been directly translated to the dex format. The libraries are not the same as the Sun/Oracle reference libraries, but it is based on the Apache Harmony project which was an open source implementation of the Java libraries.
Re: (Score:2)
Actually, Mono is a certified CLR implementation...
But I'm ready to concede the point about Android. It really is Java, but without most of Sun's UI cruft.
However, Java was chosen there not because it's good, but because it's the only choice for real cross-platform development of reasonably fast code.
let Java languish (Score:5, Funny)
Oh wait, i thought this was a poll.. Nevermind.
Paying for Oracle Java? (Score:4, Insightful)
What about the prospect of having to pay for Oracle Java? The client would continue to be free (JRE) but if you want to compile code it will cost you. How would Java fair if there was a $100 developers license?
Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...
Re: (Score:2)
How could you "corner the market" like that? Java has an incredibly strong free software culture around it; making the compiler proprietary (it's free software today) and then even charging for it, would be Oracle Java's death knell and a free fork would take over.
Re: (Score:2)
Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...
Don't lose any sleep worrying about that, as it has a near-zero chance of being reality. Oracle certainly could try such a move (it's in the corporate culture), but it would have no teeth. When SUN open-sourced Java, the former assumed the role of steward, and surrendered the role of dictator. There is no way that Oracle can now force people to bow down to its will with Java.
There would be short-term angst for developers, and short term profits for Oracle, but there would be an inevitable fork of not onl
Re: (Score:2)
I would see something like that working like RHEL vs CENTOS.
Some companies would pay the fee ( for extended support? ), while others would use the free alternative.
And let's face it, there would be a free alternative. Within minutes of the announcement, a million forks would be created from the last release.
Java's future not in the hands of any one company (Score:2)
Java was never in the hands of any one company, not even Sun- because Java (both language and frameworks) is controlled and evolved using the JCP [jcp.org] (Java Community Process).
There are a variety of companies on the various panels so any one company cannot hijack (or kill) the language or platform.
That was always part of the strength of Java, instead of going through a more hidebound standards body they created one specifically for Java, run by the people of the Java community.
IBM would take it over (Score:3, Interesting)
I keep wondering why people forget about Big Blue these days. Java and Linux support are the keys to their offerings and both are said to save mainframe/big server business of them.
Eclipse is Java too. A lot of IBM applications, even client side stuff relies to Java.
Lets not forget Google Android which is a huge success is enhanced J2ME/Java, billion cell phones have J2ME built in, the "winner" high definition format, Blu-Ray has J2ME/Java.
Sorry to say the idea of Oracle wasting Java is really stupid to begin with. Perhaps Java will focus on the thing it does best is a better theory, I mean huge servers, databases, J2EE?
Re: (Score:3, Insightful)
I think checked exceptions are largely misunderstood. When people complain about them, they unknowingly, but almost always complain about the try..catch construct -- it is very wordy, annoying, inflexible and is almost impossible to factor out common idioms.
Re: (Score:2)
Re: (Score:2)
The thing is, that in a lot of cases you actually should use Runtime Exception instead of static ones. Actually, as far as I know Java is the only language that has static exceptions. (C++ has only runitme exceptions, scripting languages too; I don't know about C#)
The worst thing you can do is catch all exceptions silently in the outmost method.
Re: (Score:2)
"The worst thing you can do is catch all exceptions silently in the outmost method."
No, it is actually worse to have only RuntimeExceptions and handle none. In the static version, at least a code reviewer will immediately see the empty catch blocks, while in the dynamic case the problems will remain hidden.
In the checked case, when I ignore exceptions (catch, and do nothing) at least I document it explicitly in the code by writing the empty catch block. This is not true for unchecked ones.
Re:Doing all my programming in C# (Score:5, Insightful)
C# is really more sort of the averaging of Java and C++ than anything else, and VB is now C# with a slightly different syntax(sort of wish Microsoft had the balls to just end it rather than farting around with putting god awful VB syntax onto a language which is nothing like it.
I do agree that Microsoft needs to do something about the exceptions though, not necessarily checked exceptions cause those are a pain, but some easy way in Visual Studio to get a list of exceptions that can be thrown by a call so you know what you could check for. You're also right about javadoc.
That said, LINQ is just incredible, and IIS with .NET is a hell of a lot easier to configure and tune than Tomcat, it's really 6 of one and a half dozen of the other with Java and .NET at the moment, which is why what Oracle does is so important.
Re: (Score:2)
IIS with .NET is a hell of a lot easier to configure and tune than Tomcat
I find LAMP easier still, also the main webapp I run at work can't run on ISS7 so I know it's not all green hils over there. Of course I've never written anything big enough to spend any significant time on tuning. Don't make too many DB queries is my general rule.
That said, LINQ is just incredible
I've been looking for some excuse to use LINQ in my code, but the closest I've come is lambda expressions. Do see the value though.
Re: (Score:3, Interesting)
C# is really more sort of the averaging of Java and C++ than anything else,
C# is just like Java except without some of the problems and with some good things added. E.g. Java generics aren't really worthy of the name, while C# generics are pretty spiffy.
Re: (Score:3, Informative)
C# has declaration-site variance for generics, while Java has use-site variance. What this means is that interfaces which are always co- or contravariant (e.g. IEnumerable in .NET, which is analogous to Iterable in Java) can be declared as such. But if an interface has a mixture of methods, some of which are covariant and some are contravariant, the result has to be invariant in .NET. For example, IList<T> is invariant, because it has both Add(T), and indexer returning T.
In Java, due to use-site varia
Re: (Score:3, Insightful)
Re: (Score:2, Insightful)
No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:
public interface EntityManager {
* Make an entity instance managed and persistent.
*
* @param entity
* @throws EntityExistsException
Re: (Score:2)
Re: (Score:2)
I disagree. A checked exception in this case would do you absolutely no good; if your application encounters an error during a DB operation, then there's usually nothing you can do to recover, so it doesn't matter if you catch the exception yourself or let the container handle it.
Re: (Score:2)
"Then they decided to use a library that used a library that dynamically loaded some JDBC drivers that threw unchecked exceptions in some cases. "
In other words, checked exceptions can only help when they are used.
Re: (Score:2)
You're supposed to assume that all exceptions can be thrown from all code.
I disagree. I catch the general execeptions up in the code tree from where I will abort the whole opperation when they occur, putting my main focus on exceptions that are likely to be thrown - primarly on how they affect the user. Rare exceptions, even if an exception handeler can make a clean fix, are sent to the error box.
Checked exceptions also give you insight into the function that documentation often lacks. For instance I'm working on an app that connects to a database, the app have to work even wh
Re:Doing all my programming in C# (Score:4, Informative)
"Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance."
The same is true for invoking methods through reflection. Or transforming bytecode through custom classloaders, etc.
But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.
Re:Java is already dead for new development. (Score:4, Insightful)
You are insane.
Not only there is constantly new Java code written for the back end, not only there are millions if not billions lines of code that are running existing services on the back end, but people are writing front end code in Java, at least for corporate environments.
How do I know? I am writing some of it.
Re:Java is already dead for new development. (Score:4, Insightful)
The benefits that Java offers are more compelling than just about any alternatives. The arguments against its ability to "run anywhere" are old and most (if not all) are largely inconsequential to todays environments.
A majority of development today is web-centric (intranet or internet) so issues with AWT or pathname incompatibility across systems are rarely encountered, and when they are, there are plenty of best-practices for dealing with them.
The old line about Java performance being inferior is also largely a dead issue as it's be shown time and time again that the newer JIT enabled VMs allow byte code to perform on par with native C/C++.
As far as being a dead language, I certainly don't see that happening any time soon. The language is under constant development and significant new features are being added with each major release, both to the platform (performance, concurrency, garbage collection, etc) as well as the language itself (modularization, closures,annotations, etc). The language is constantly evolving, but still, as much as possible, retaining backward compatibility.
Even if the language itself is not able to keep up with advances in modern language design, there are spin-offs like Scala that can co-exist in the same JVM and are able to take advantage of the large java eco-system while providing a different programming paradigm.
I gave up being an fan-boy for technologies many years ago when I got burned with OS/2, and have since decided to embrace whatever languages and technologies are in demand, be it MS tools (VB and C#), Apple (Objective-c) or non-proprietary (Perl, PHP, Java, etc.).
Folks that are quick to declare Java dead are obviously naive and don't have a clue about the way the IT world works. They can line up with the folks that declared mainframes and COBOL dead twenty years ago, while (according to a recent Computerworld article) more than 200 million lines of COBOL are still in use and a COBOL gig is still considered the safest gig in IT today.
Re: (Score:2)
Whatever AC.
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data. HTML + browser is one of the slowest ways of doing it, Java beats that by orders of magnitude.
I know, because I measured it. An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a goo
Re: (Score:3, Insightful)
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.
Re: (Score:2)
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link.
- sure, but JNLP makes the entire experience into a click and done, and you have an applet that looks like a desktop application running in the browser, it immediately is installed and connects to the server securely. It can be ran outside of the browser, but that fact is irrelevant, the applet is a complex application but it is still part of the business portal so it is a web app.
The *point* of webbased apps is that there is no download involved
- that is a very narrow minded view of what a web application is. Also once it is installed one time, it is cached and any n
Re: (Score:2)
Well, substitute your "java applet" with "normal fat application", and you will get all the same advantages, except the fantasy about "1 click and it works" :) Sorry, 1 click will not even get you past the "please download the appropriate plugin" screen. Then the start is horrible slow --- I know, since I use one applet from my bank. We are talking 20-30 seconds, and the applet is very, very small (and probably cached, as you say). That is just not acceptable for a modern web application.
Personally, I pref
Re: (Score:2)
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
Re: (Score:2)
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
Oh, point taken. My company is linux through and through, so we just update the repository and all apps are upgraded automatically. Naively, I thought windows could do the same. Even so, that usecase could be handled more generally by simply using self-updating apps, like e.g. online games do, without being restricted to Java.
Re: (Score:2)
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.
So what?
An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.
Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once.
hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT
And did
Re: (Score:3, Insightful)
So what?
- for real, you are asking me 'so what' and that's your argument? My response is simple: I am recreating an application in a browser that my users have used in the past and that is now no longer supported that used to be a stand alone applications. Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop, those are not the kind of people who will want to switch paradigms from a desktop application to a web based one that is purely running as HTML/Javascript,
Re: (Score:2)
If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.
Re: (Score:2)
Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.
Be specific. How are they impractical? In particular:
Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.
And what's impractical about Lisp, particularly a Lisp with STM?
It's also funny that you mention this:
Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.
Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equi
What's the weather like on planet mars? (Score:3, Insightful)
Haskell and Erlang are barely a blip on the radar. I like and use Python regularly and it has it positives, but I have a hard time recommending it to my corporate customers (for various reasons having to do with availability of trained developers, performance and or broad industry support). By and large most work I see getting done is bein
Re: (Score:2)
However, we're seeing absolutely no innovation coming out of the Java community. Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl. The JVM is an absolute mess compared to .NET, of all things.
And we all know that .NET are the solution to everything? Right?
Re: (Score:2)
Many of these new languages have very strong features, it's just not always the features that corporate environments want. If you want a well structured, understandable and *maintainable* language, Java is still a long way ahead on all those new languages. Even worse, most of all those new languages are worse.
I'm also aching for a new language. A language that is even better supported by IDE's (refactoring, background compiling, static code checking and such). A language that has a better module system than
Java coders should be so lucky. (Score:4, Insightful)
Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.
Don't knock COBOL.
I know a couple of folks who are making a nice living as a COBOL programmer. And they're not that old. AND, when the majority of the IT market craps out, they always seem to have or can get a job. That's something not many programmers can claim.
Re: (Score:2)
But Scala uses a functional paradigm, and thus represents a different mindset to the OO nature of Java, and even the syntactic mindset of the C family. But yes, it is another tool for writing code targeting the VM.
An aside: How many .Net developers use F#, the functional programming equivalent there?
Re: (Score:3, Informative)
Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.