Oracle and the Java Ecosystem 157
First time accepted submitter twofishy writes "After an undeniably rocky start, which saw high profile resignations from the JCP, including Doug Lea (who remains active in the OpenJDK), and the Apache Software Foundation, Oracle is making significant efforts to re-engage with the wider Java ecosystem, a theme which it talked up at the most recent JavaOne conference. The company is working hard to engage with the Java User Group leaders and Java Champions, membership of the OpenJDK project is growing, and the company is making efforts to reform the Java Community Process to improve transparency. The firm has also published a clear, well-defined Java roadmap toward Java 8 and Java 9."
*Yawn* (Score:5, Insightful)
Re: (Score:2)
Re:*Yawn* (Score:4, Insightful)
... java is history, so to say.
No, it's not. And the reason it's not is because it's already entrenched. Hell, just last week [tiobe.com] it was reported that Java was still the #1 language being used; it's certainly not disappearing anytime soon. Oracle will get it right, or face hundreds of pissed off businesses and governments.
Re: (Score:1)
If they're still suing Google over Java they can fuck right off.
Re: (Score:1)
Get it through your head already. The JRE and JDK are open source, most if not all of JEE is open source. Java Mobile has ALWAYS been proprietary and continues to be proprietary, and that's what they're suing Google over. Had Google modified the JDK or JRE to make Dalvik, this wouldn't be a problem.
Cite even one instance where they've litigated over the JDK or JRE since it's been open, just one.
Re:*Yawn* (Score:5, Funny)
Larry Ellison IS the devil. Haven't you seen a photo [silicon.com] of him?
Re: (Score:2)
He's a dead ringer for Patrician Veninari...
Re: (Score:2)
Scala derives much of its benefit from being compatible with the Java libraries and running on the JVM.
Re: (Score:1)
Scala already is Java 9. Java the JVM remains relevant, but Java the language is no longer interesting.
Re: (Score:2)
That, and they'll be shifting back once they see what godawful disaster Scala is in terms of linguistic complexity.
Note to Lift library developers: implicits to implement CSS-style selectors and replacements in snippets is even less cool than C++ operator overrides.
The Play Scala framework provides a better web framework. It's more natural to understand. I do agree that Lift wasn't intuitive (although I may go back to it at a later point in time). I disagree with the linguistic complexity. A lot of Scala borrows from FP paradigms and FP attempts to reify programming patterns that are experienced throughout a programmer's life. I don't understand what your criticisms towards Scala are considering Scala is more than just Lift.
Re: (Score:1)
I also disagree with the claims that Scala is too complex. But I'm happy that the undiligent think it is.
jigsaw (Score:4, Insightful)
seeing what's happening on the modularization front i'm afraid it'll be just like the fiasco with log4j and jdk logging which came afterwards. modularization is what java applications (well, backend servers powering too complex enterprisey-apps) need, and that should be achieved through the means of easy to use osgi tools instead of yet another (sun|oracle) screwup mimicking an "oss standard".
Re:jigsaw (Score:4, Interesting)
Modularization is what java applications (well, backend servers powering too complex enterprisey-apps) need, and that should be achieved through the means of easy to use osgi tools instead of yet another (sun|oracle) screwup mimicking an "oss standard".
I think you're missing one of the main points of Jigsaw - which is modularizing the platform, not the application. This is especially important if Java is to get back into the embedded space, where JavaME and CDC are so antiquated it's just not funny any more. Having a range of well defined platform profiles which span everything from headless embedded devices up to a full enterprise stack (while using the same underlying codebase) would be a major step forward. Personally, I don't care what the implementation details are - the changes aren't going to stop anyone from using OSGi to modularize their applications if they want to.
Oracle matters less thank you'd think (Score:5, Interesting)
Re:Oracle matters less thank you'd think (Score:5, Informative)
I disagree, OpenJDK (specially for Java 6) has many incompatibilities. Try running Intellij IDEA on it (they don't recommend it), or even some app servers.
Re:Oracle matters less thank you'd think (Score:5, Informative)
I would recommend against using OpenJDK 6 for anything really. OpenJDK 7 is a bit different though, as it is the official Java SE 7 reference implementation [wikipedia.org].
I see OpenJDK 6 as their initial "hey, look at what we're working on", as they tried to completely open source the JDK (they had to re-write at least 4% of the Sun JDK when turning it into OpenJDK). With that re-write, lots of things were probably broken, and testing was required to get them working again. Now that OpenJDK 7 is out, Oracle, IBM and other will be putting their efforts into improving it and making it as complete as possible.
Re: (Score:2)
Re: (Score:2)
Some app servers have compatibility issues if you run them on different Sun JRE/JDK version.
Re: (Score:2)
That might be right, however on the desktop client part it seems the situation is better.
Re:Oracle matters less thank you'd think (Score:5, Interesting)
Funny thing, we experienced the exact opposite. We have issues with various Oracle JDK6 version on Linux that we don't have with OpenJDK 6 versions. Our application would simply segfault when it reaches the set memory limit (instead of garbage collecting).
Re: (Score:2)
Oracle had (has?) its own JVM called JRockit, which is different from the Sun JVM. Which one were you referring to? Java stored procedures is a different matter all together.
Re:Oracle matters less thank you'd think (Score:4, Informative)
But even if this were not the case the Java 'world' has a lot of alterantives: the IBM JDK, GNU GCJ, Apache Harmony. [...] This is one beauty (for end-users/developers) with the Java ecosystem.
Until what you wrote for for one doesn't work on the other. Java likes to say it's cross platform, but there's still lots of implementation specific hangups in the various JREs.
Re: (Score:2)
Until what you wrote for for one doesn't work on the other. Java likes to say it's cross platform, but there's still lots of implementation specific hangups in the various JREs.
It is cross platform as much as C/C++ is portable.
I don't know why anyone would think either means no effort is ever required, because anyone can write a Java runtime or C compiler that doesn't work. It does't make the whole thing a lie.
Re: (Score:3)
Great example I see all too often. This one is a classic signs of a terrible programmer. How hard is it to use File.separator instead of hardcoding "\\" or "/" in your paths?
Basically there are a lot of lazy muppets (or muppet sympathisers) out there who would trash Java rather than accept that it is actually programmer error for putting "Window-isms" into their code. They do this crap in every language and despite Java's "Write once [automated unit test
Re: (Score:2)
that most developers who are writing Java either don't give a shit, or just downright bad
the correct affirmation would be : that most enterprise developers who are programming either don't give a shit, or are just downright bad
Oracle matters more thank you'd think (Score:4, Insightful)
Re: (Score:2, Insightful)
I would say the majority of Slashdot readers using Java do so in an enterprise environment.
I would say the majority of Slashdot readers using Java do so in class.
Re: (Score:3, Insightful)
Re: (Score:2)
This. I haven't had to use Java since I left school (and hell even in school we only used it to learn the basics of programming)
Still looking for work, are you?
Seriously, the only thing that comes close to Java in terms of job availability is .NET, and the two are more or less neck-and-neck.
Re: (Score:2)
Like I said before, even in school they only covered it for one class, to teach the basics. After that it was C and Perl.
Re: (Score:2)
And I haven't really spent that much time with Java to be considered a GOOD Java developer. I know it, but I don't know the ins and outs the way I do with C or Perl. If I lose the job I have now and the only thing open is
Re: (Score:2, Insightful)
Of the alternatives you list, only the GNU GCJ is not shut down. Apache Harmony has been discontinued (retired to the Apache attic http://attic.apache.org/projects/harmony.html) and IBM has pulled their Harmony committers to OpenJDK instead (http://www.sutor.com/c/2010/10/ibm-joins-the-openjdk-community/).
Re: (Score:1)
The Apache Harmony project shut down. Also, Oracle has been threatening to sue companies using their patents that don't agree with Oracle's ideas for Java. So Oracle still very much holds the reins.
Re: (Score:1)
Really? You're list of "must haves" starts with "goto"?
I know that there are still some diehards out there who insist that unstructured branches (i.e. "goto") have a place in a modern programming language, but the only example I have ever seen where a "goto" actually provided some value was in a performance critical piece of system code (specifically, it was part of the Linux kernel). Given that Java is an application language, not a system language, I see absolutely zero value in introducing unstructured b
Re:Oracle matters less thank you'd think (Score:4, Insightful)
Adding unsigned types to the language would add very little value, but it would add at least some value, so I won't argue with that one.
Not having unsigned types is probably the second dumbest decision in Java's design, after compulsory garbage collection.
Sure, you can work around it by using larger data types (e.g. short when you really mean byte), but it's a real pain when interoperating with code in other languages.
Re: (Score:3)
Re: (Score:1)
Are you sure the research delivered, because avoiding gc still gives a huge performance boost in most apps. You might not notice on your nGhz PC but you will on your phone.
Re: (Score:1)
I have no industrial experience with phone software, so I can't speak to that. But the research surely delivered for software in the large. In the same way that compilers can no longer optimize code as well as virtual machines can, it's a bit conceited to think we could hand-code memory management of complex systems better than the computer itself.
Also, in addition to app performance, the second metric to consider is programmer productivity, and gc's impact there is incalculable.
Re: (Score:2)
I see too many memory leaks in complex java code where references are kept to unwanted objects. I would prefer to see something like an assert_free(object) to make it easier to track when an object should be free.
Re: (Score:1)
Why do you care when the object gets freed?
Re: (Score:2)
I might care about that for operational reasons. For example I don't want a bunch of objects to be collected when my application is otherwise busy, but that wasn't the point. I might have references to objects which I expect to be freed up. I would like to say "this object should be free now" so the VM can say "so, it won't".
Re: (Score:1)
I might care about that for operational reasons. For example I don't want a bunch of objects to be collected when my application is otherwise busy, but that wasn't the point.
That I understand. Modern gc algorithms are pretty good, though.
I might have references to objects which I expect to be freed up. I would like to say "this object should be free now" so the VM can say "so, it won't".
That I don't understand. First, one can't possibly know for sure when an object is freeable. Moreover, how could one even say "free up this object"? If you can even say that, then you'd have a pointer to it, giving it a positive reference count! But, secondly, and this is really my question, why should one care? Even if an object is marked for deletion, that memory won't be made available until the VM is good and ready. (When swept.) S
Re: (Score:2)
All I mean is:
// Michael expects a to be freed now but he has forgotten about b. So instead I want this: // Sets a to null and throws an exception if the object it pointed to has more references
Object a = new Object();
Object b = a;
a = null;
free a;
Its because I am stupid and I forgot about b. This is important in non-trivial cases where humungus data structure schemes are used and references can be hard to track down.
Re: (Score:2)
Re: (Score:2)
Yeah good idea ;)
Re: (Score:2)
And then somebody comes up with a new and improved
public boolean isTrue(boolean b) {
boolean returnValue;
if(b != true) {
returnValue = false;
} else {
if(b == true) {
returnValue = true;
}
}
return returnValue;
}
I don't want to live on this planet anymore. I actually found one of those in SVN. I didn't even bother looking at who checked it in. I simply deleted it, didn't bother to fix the code so the whole thing didn't compile. Instead I sent this
Re: (Score:2)
That's like searching for a specific egg in a chicken farm. You need to break it to find the right one. Even thinking about it makes me butthurt.
Re: (Score:2)
You need to be careful to pass Collections, arrays and the likes out of their application architecture scope.
But I do see a lot of current generation Java developers who don't understand the basic concept of pointers and the GC. Without that you WILL get memory leak issues. But guess what, the same coders would cause the same troubles in any other language. And even if you HAD
Re: (Score:1)
Not having unsigned types is probably the second dumbest decision in Java's design, after compulsory garbage collection.
If these things are important to you, then you are programming in an arena where Java is the wrong choice. These are not defects in Java's design, but Java is not the best language for, say, writing device drivers.
Re: (Score:3)
Really? You're list of "must haves" starts with "goto"?
I know that there are still some diehards out there who insist that unstructured branches (i.e. "goto") have a place in a modern programming language, but the only example I have ever seen where a "goto" actually provided some value was in a performance critical piece of system code (specifically, it was part of the Linux kernel). Given that Java is an application language, not a system language, I see absolutely zero value in introducing unstructured branches. The structured branch constructs are perfectly sufficient.
Adding unsigned types to the language would add very little value, but it would add at least some value, so I won't argue with that one.
Goto isn't used in Linux for performance reasons. It's used because C does not have exceptions and using goto to jump to clean-up code prevents code duplication. Any sufficiently experienced C programmer will encourage you to do the same.
Of course, Java has exceptions and the finally keyword, so goto is not strictly needed for this purpose.
Re: (Score:1)
Goto isn't used in Linux for performance reasons. It's used because C does not have exceptions and using goto to jump to clean-up code prevents code duplication. Any sufficiently experienced C programmer will encourage you to do the same.
Why not put the cleanup code in a well named function instead? Also, there are plenty of experienced C programmers who loathe gotos.
Re: (Score:2)
for (
if (
goto finish;
}
}
// perform action when not found
...
finish:
// continue
With Java, this has to be done with an extra boolean to keep track (and it's much uglier).
bo
Re:Oracle matters less thank you'd think (Score:4, Insightful)
Personally, I think the use of an explicit boolean to flag the "not found" condition makes the code much clearer. That's actually one of the main arguments against unstructured use of GOTO. The code is generally more readable and maintainable if you don't use GOTO. In your Java example, it is quite clear, even without looking at the loop code, that the code after the loop will only execute if the item is not found. This is not clear in the C/C++ example using GOTO, where it is necessary to look at the loop code to understand the code that follows it.
Obviously this is a simple example, but it does demonstrate how an unstructured jump provides at least a little obfuscation, where a more structured approach provides clarity.
The Python case just looks odd to me. There's nothing about a loop construct that necessitates an "else" condition. Obviously, I understand what you're doing in that example thanks to the previous two examples, but if I were to just look at the Python code on its own, I'd be at a loss to figure out what the "else" even means. Logically, the "else" should belong to the "if", which would indicate that the string literal would be printed each time that X was not equal to 12 (meaning it prints 10 times). The indentation suggests that it belongs with the "for", but given that "for" is a loop construct, not a conditional construct, what does "else" even mean in that context? It's very bizarre.
Basically, I can see some (limited) value in the construct, but I disagree with that implementation.
Re: (Score:2)
I sometimes like to use gotos (along with a flag) to handle final 'flush' logic in a loop during which intermediate flushing may take place. This could be done 'cleaner', I guess, by making the flush logic into a separate function (though that might require passing in a bunch of local variables). Sometimes, though, it's actually clearer to have the flush logic in the main loop, and when that logic is significant, the goto trick is certainly better (and clearer) than the copy/paste jobs you often see lazy
Re: (Score:2)
Other than 'goto-less purity', how about listing some of those horrors.
I'll admit the code's 'ugly', but it does have the advantage of letting you know exactly what it's doing. Sure, it would be 'better code' to split out the flush logic into a function, but that would involve defining a structure to pass it all the accumulated data (or worse, passing a whole bunch of parameters). This has the advantage of locating the accumulate and flush logic together where the relationships between the two are obvious
Re: (Score:2)
Re: (Score:1)
Actually,
if (conditionImLookingForIsFound())
doFoundThing();
else
doOtherThing();
is most readable. Keep all the code in view at the same level of abstraction.
Re:Oracle matters less thank you'd think (Score:5, Informative)
Java has gotos:
loops:
for (int i = 0; i < MAX_I; i++) {
for (int j = 0; j < MAX_J; j++) {
break loops;
}
}
Re: (Score:2)
Re: (Score:2)
ASM assembler : http://asm.ow2.org/ [ow2.org] is what you need if you ever decide to patch a library for covariance support to maintain backward compatibility or some esoteric shit like this...
Re: (Score:2)
Java bytecode supports goto. Not having goto in the language is just a design decision. Goto is a reserved keyword in java, so you could actually modify a compiler to support goto, and that compiler would be perfectly backwards compatible with other compilers and code (because code not written for your compiler would never use goto as a variable, class, or method name).
As for the bytecode thing, there are plenty of tools that can compile assembly for the JVM.
Wooohooo (Score:1)
Oracle knows, the nineties were the best :D
I wish ... (Score:5, Insightful)
Re: (Score:3)
That OpenJDK could just get the lion share of development and mindshare. If LibreOffice can functionally replace OpenOffice there's hope for OpenJDK.
Unlikely. Java is too important to too many people. Imagine Java being run by a consortium of IBM, Red Hat, Hitachi, Samsung, Nokia, SAP, and about three hundred junior members, with nobody clearly in charge. I don't see how anything would ever get done. Part of what makes Java popular is that it tends to keep up with modern trends in computing (or even establishes them). If Java becomes the next Ada, some other technology will take its place.
Re:I wish ... (Score:5, Informative)
Sounds promising (Score:4, Insightful)
It should be readily apparent from my own open documentation and planning approach for MSS Code Factory and Singularity One just how much I believe openness to be CRITICAL to running a modern technology endeavour. The days of closed door development and the sudden release of new technology products is not only disruptive to the industry and employment, it's a fundamentally wrong-headed approach to someone who believes in the GPL ethos as I do.
Kudos to Oracle for realizing the way they were handling things was going against the principles of the way Sun had originally configured the Java community.
Re: (Score:2)
Have no fear, Oracle ala Larry Ellison will find some way to screw it up in the end.
Most people have ZERO faith in Oracle and there's a reason for that... OpenJDK or move to python or Scala or .NET/C#.
Linux Distros and Android. (Score:1)
Stop suing Google and get a fair license for Android if they choose to stay with SUN java and not OpenJDK. And let FREE operating systems distribute correctly built packages of Java. Then I might give a crap what Oracle is or isn't doing as far as engaging the community. Other then that they can go pound sand.
Re: (Score:2, Insightful)
You do realize that J2ME (what Android uses) is the primary source of revenue for Java, right? It's why the patents are royalty free for J2SE and J2EE, but not for J2ME. All those featurephones pay to have that little-used JVM on them.
So yeah, Google can license J2ME from Oracle, but not for free, otherwise Java really would die because it won't make any money at all.
Of course, if Android implements f
Re: (Score:2)
You do realise Google are in trouble because they couldn't licence J2SE for phones (Sun/Oracle wouldn't allow it), J2ME is too limited for what they wanted to do and so Android is NOT based on it.
This is the direct fallout of Sun's policy of barring J2SE use on mobile by withholding the tools needed to certify it.
Java: Was write once run everywhere ever the case? (Score:2)
Disclaimer: I am no Java expert.
Is it the case that until Android came around, Java, the language, the libraries and the VM collectively known as "Java" was write once run everywhere platform? Or is was Oracle, now Sun being unfaithful in its representation of what Java really is?
It's write once run everywhere with small niggles (Score:5, Insightful)
--Coder
Re: (Score:3)
Except it's *always* been "least common denominator". For example, Java runtimes have never supported the Windows named folders. (Basically, they hand you the Roaming App Data folder, tell you that's "home" and you're stuck with it-- there's no way of fetching other named folders or even taking the value it gives you and reliably finding the Documents folder using it.
Basically, they took the bare minimum POSIX features, assumed that was all you need to support every OS ever, and implemented it with that ass
Re: (Score:2)
What the holy hell does that link have to do with my post?
Hint: the answer is "nothing at all"
Re: (Score:2)
Speaking from current experience (porting a large codebase which includes several languages, including Java and C++), this is generally true. But that doesn't stop people from doing really stupid things.
For example, previous developers on the code I'm working with decided to use Runtime.exec() everywhere. Need to copy a file? Try running 'cp' ... and be sure to hard-code the path where you think it will exist. Need a directory listing? Call 'ls' ... and be sure to rely on a specific output format for e
Re: (Score:1)
But that doesn't stop people from doing really stupid things.
Oh, I hear that. The stories we could tell over beers!
But even when using Java's "native mechanism", things like filename case sensitivity can still bite you. And here's another example. When I start a Java thread, does that run in the same OS process or not? And if the answer is "that depends", then that has some serious implications for availability, testing, and even security.
Stroustrup famously quipped that Java is not platform independent -- it's a platform.
Re: (Score:1)
Seriously, unless you are doing something weird, reasonably OK written java app would run under any platform. There might be some small issues, but cross-platform apps with Java are much much much easier to write than cross-platform apps with anything else.
Sure. If I'm writing an email client or something. But if I'm composing a complex system, then there are performance and functional characteristics that vary, and these could very well make or break the product. I appreciate the desire to defer architectural decisions to the last responsible moment. But picking the OS can drive so many other design decisions, that one should get that right almost from the beginning.
With Java predominantly on the server side instead of in the browser, what exactly is the
Re: (Score:1)
"Everywhere" is clearly not true, but I've been rather successful run my compiled Java server code on Windows, Linux, HP-UX, and even Solaris with only a few minor changes where I flubbed (windows pathing and such). In the last 10 years I think I had 1 single issue that was JRE related and it had something to do with how the HP JDK handled threading on a low level. Other than that it's been quite smooth. Now, at the other end of the spectrum with embedded java on cell phones and such it's been a total ni
Re: (Score:1)
Is it the case that until Android came around, Java, the language, the libraries and the VM collectively known as "Java" was write once run everywhere platform?
I was there. It was never, ever that way. You couldn't even run multiple java apps on the same computer, because one service provider would only run under and support (made up version) 1.1 and another would only run under and support (made up version) 1.2 and they'd crash horrifically on each other's version. So you'd have workers with two PCs on their desk because they need access to both apps. It was just a nightmare.
It was supposed to be multi-platform across anything, but it wasn't even as inter-com
Re:Java: Was write once run everywhere ever the ca (Score:5, Informative)
All depends on what you're doing with it. I work on an enterprise level webapp written 100% in java and we have deployments on Windows, Linux, Solaris and OSX-Server using the EXACT same code base and this is an app with over 1000 classes and 250k+ lines of code.
Re: (Score:2)
It's not whether or not it's true, it's whether or not anyone cared.
When Java was something that would run in a browser, yes, that was important. But Java went on to run back-end server and enterprise systems, and there it really doesn't matter because people engineer for specific hardware.
Yes, there are exceptions. There's still some "run anywhere" exploited on the desktop - e.g., Crashplan's desktop GUI. But most companies who are doing Java at any scale are doing it on specific hardware - i.e., their
Re: (Score:2, Informative)
But Java went on to run back-end server and enterprise systems, and there it really doesn't matter because people engineer for specific hardware.
Actually, that's precisely where I see the "write once run anywhere" in action. I have been developing server-side code for about a decade, and I have always done my development and testing on Windows, but deployed to either Linux or Solaris, without any platform problems whatsoever.
Re: (Score:1)
I have been developing server-side code for about a decade, and I have always done my development and testing on Windows, but deployed to either Linux or Solaris, without any platform problems whatsoever.
I find that a little scary.
But I'm curious. Do you do that because as a developer you find Windows more productive for you?
Re: (Score:1)
Re: (Score:1)
The problem here is perception of Java, Java as desktop app is to be blunt problematic and idiot devs out there who don't know what they are doing. Java on the server is an absolute dream.
Windows isn't any more productive then say Linux or OSX its just convenient because most people use stuff like Outlook/Project/Visio etc.
Re: (Score:2)
Do you do that because as a developer you find Windows more productive for you?
In my experience, IDEs run roughly the same on Windows as on Linux. Not a lot of difference here.
The reasons for developing on Windows are mainly:
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, there are exceptions. There's still some "run anywhere" exploited on the desktop - e.g., Crashplan's desktop GUI. But most companies who are doing Java at any scale are doing it on specific hardware - i.e., their backend processing system runs on x86, SPARC, POWER, or whatever and so who cares if they could pick up the Java code and move it? They're never going to.
All the companies who bought Itanium beg to differ.
Re: (Score:2)
Re: (Score:1)
We used to joke "write once run away".
Great name for a rock band (Score:2)
By all means, mod me off-topic, but it was worth it.
Re: (Score:2)
Oracle would never go with C-sharp.
You need us more than we need you (Score:2)
Oracle has been hostile to open systems on every front. Oracle has been indifferent to the concerns and contributions of legions of developers, and no meaningful effort was made to avoid the trauma that has ensued with the acquisition of Sun. Oracle clearly does not give a damn.
I've used most of the common tools of the trade that have appeared during the last 20 years. Java was among those at least 4 occasions that I recall. In each of those cases Java was one of several choices available to me, and i
Re: (Score:2)
I will also not use Java for any project where I have the choice to do so and will continue to boycott Java as long as Oracle continues with its lawsuits against Android and Google.
Meanwhile evil continues to rampage at Oracle (Score:2)
Meanwhile the legal rampage against free and open source software continues. The war against Android - once the pride of Sun's success with Java - is raging.
Oh, and don't even get me started on the crapware Ask-Toolbar they started pushing with the Java update/installer, with the "Yes put crapware on my system" option pre-selected for me...
Yes, Oracle is certainly doing a lot of things for Java. Like killing it
I'll just come right out and say it. (Score:2)
IMHO, the involvement of Oracle would be enough to make me avoid Java even if I liked the language. Developing applications is stressful enough without having to worry about what Larry Ellison might do.
And I don't like the language either. The nature of its widespread use only strengthens my feeling it is the 'new' BASIC, a dead-end educational toy that is used far beyond its capacities. Worse, this has gone on long enough for its oversimplified world view to affect what often masquerades as "design". Stitc
Re: (Score:1)
The nature of its widespread use only strengthens my feeling it is the 'new' BASIC, a dead-end educational toy that is used far beyond its capacities.
So because it's widely used, it must therefore be flawed?
No, Java is not fast. Java is a programming language. Virualized RISC machines can be fast within their own arenas and a lot of good work has gone into JIT compilers and the machines running underneath "Java".
When people say Java is fast, they mean they can write applications in it that will perform similar to ones written in a platform targeted language (an important measure for choosing a programming language for a project, where trade-offs against $$$ are determining factors). Whether the underlying reason for this speed is because the JVM is really clever, or runs on really clever machines, is not important in this context.
The claim does nothing but reveal your lack of knowledge and perspective.
Oh, someone certainly needs p
Re: (Score:2)
Re: (Score:2)