Posted
by
samzenpuson Monday January 16, 2012 @01:53PM
from the a-different-approach dept.

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."

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.

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.

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.

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".

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.

Compared to other development platforms (eg. MS C++, C#.NET etc) the influence of Oracle is less important than many people may think. Basically the OpenJDK is more important than Oracle's commerical offering (the successor of the Sun JDK - which is very similar to OpenJDK as they have almost all source code in common). But even if this were not the case the Java 'world' has a lot of alterantives: the IBM JDK, GNU GCJ, Apache Harmony. This means that Oracle can try throw its weight around but it is not as devastating as Microsoft would be in the.NET world. This is one beauty (for end-users/developers) with the Java ecosystem.

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.

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).

> Or if you try to use the wrong path separator.
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

I would say the majority of Slashdot readers using Java do so in an enterprise environment. The Java Enterprise Edition (JEE) specification is controlled by the JCP, where Oracle has heavy influence. JEE application servers adhere strictly to this spec.

No. I got a job a year before I left school. While it's likely that this is the reason I haven't had to touch Java since school (we're mostly a Perl/PHP shop), no one I know in my major has gotten a job where they had to deal with Java either. It's mostly C (And Objective C for the one who went on to be an iPhone dev).

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.

I suppose. I did some programming for iOS a few years ago and enjoyed it, but rather then learn an entirely new API for Android I decided to dive into HTML5 so that I can make apps that run on iOS, Android, AND the modern PC. Well eventually anyway, once they get the standard figured out.

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

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/).

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

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.

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.

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".

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

All I mean is:Object a = new Object();Object b = a;a = null;// Michael expects a to be freed now but he has forgotten about b. So instead I want this:free a;// Sets a to null and throws an exception if the object it pointed to has more references

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.

Yeah, that's the theory.
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

Keystores...and a lot of potential candidates for the keystore where the app might consider looking in.
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.

Memory leaks in any auto GC environment means that references to stuff are being leaked out to placed where they shouldn't go to.

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

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.

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.

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.

There is one good use for goto that I've seen. It's for when you have to use a loop, and you want an action to occur if an item was not found. In C or C++, you can do this with...for (/* for loop */ ) { if (/* condition */ ) {/* do something with found item (maybe) */ 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).

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.

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

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

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.

That OpenJDK could just get the lion share of development and mindshare. If LibreOffice can functionally replace OpenOffice there's hope for OpenJDK. Unfortunately LibreOffice had years of a head start on that front (functionally go-oo, etc).

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.

The Java Community Process, through a series of initiatives lead by chairman Patrick Curran, is aiming to improve its transparency and agility. JSR 348, which is the first in a series of reforms Oracle plans for the JCP, has passed final approval ballot. It represents relatively minor changes, but it is still an important step, requiring that in the future all Expert Groups conduct all of their business in public, using a public mailing-list and a public issue-tracker.

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.

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.

Stop suing Google and get a fair license for Android if they choose to stay with SUN java and not OpenJDK..

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.

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?

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.

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

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

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.

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

"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

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

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.

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

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.

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?

not my experience at all, seen some companies have major data center deployment train wrecks of j2ee apps because of windows development environment completely different from mainframe or big Unix iron. From directory structure and file naming, to permissions and ownership, to date/time....the list goes on and on. Developers need to understand and work on the target platforms, and any java developer for "big iron" that can only function on a windows box is fit only to be cut up for chum.

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.

Maybe it's just me. But especially when the first lines of TFA are "after a rocky start...". I expected..."Steve Oracle, the lead singer and charismatic head of the Ecosystem riffed on a delicate C-sharp rising inflection to bring the crowd to it's knees with the country&western ballads that we've all come to know and love"

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

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

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.