Oracle rebrands Java, breaks Eclipse | Hacker News Reader

Oracle rebrands Java, breaks Eclipse

zdnet.com

61 pointsGarbage61 comments

This is really an Eclipse f-up than anything.

A better title for this story would have been: Eclipse bug exposed when Oracle rebranded Java

I think this is really making a mouse into an elephant for linkbait.

It's really a perfect reasonable solution - check company name to see if this is a JVM where we need to poke the default options. Company name changes, source and users need to be updated and users always had a workaround of specifying perm size anyway.

It's just a nothing story : dependency of an open source project changes, open source project required patch/workaround.

Yes. When I saw the headline I was expecting that Oracle did something gratuitous and stupid like renaming a standard package to start with com.oracle or whatnot. But for this, the Eclipse folks have nobody to blame but themselves.

In the sense that Eclipse is bloated, yes; but there is quite possibly no portable way to fix this.

And Oracle really should have tested stuff, even if Eclipse did do something stupid.

So you're saying that Oracle should be responsible for the defects in a 3rd party product?

If you're building a platform, yes, you should at least be testing your point releases against a handful of the most popular applications that run on your platform, because things like this, even if caused by bad decisions in those 3rd party applications, look bad against the platform as a whole.

If this was a big feature release like JDK7, that's one thing, but a bugfix release is completely different.

Edit: Everybody would be grabbing for their pitchforks if Facebook all of a sudden updated their backend and broke FarmVille. It's the same concept.

Just to add onto this: a company I worked for was a somewhat heavy user of a 3rd party api, and they integrated our key use cases into their test scenarios in order to avoid breakage.

Depending upon what percentage of Java developers use eclipse, seeing if it still works seems fairly reasonable.

Well - when you're at some serious size, it makes sense... Kind of like special-casing the memory allocator in windows if SimCity is running: http://www.joelonsoftware.com/articles/APIWar.html - how could they not be compatible with SimCity?

How can Java be not compatible with Eclipse?...

No, Oracle should be responsible for not breaking things with no warning that a large fraction of the customers use--it is not relevant whether or not those are third party things. A huge number of Java developers use Eclipse, and so it should be something Oracle tests with--that's just basic QA that any competent company should do.

Then, when they find there is a problem, they should notify the Eclipse people. If Eclipse isn't fixed in time for Oracle's release deadline, they should at the very least put something in the release notes that there is a problem.

Except that Oracle didn't actually break anything...

Though I agree, they would have been wise to test some of the popular 3rd party apps based on Java.

Wow. They changed a name property - something that you probably shouldn't be using programmatically a great deal - and it broke Eclipse.

I got the impression that this story wanted me to be irritated at Oracle, but was left with the impression that this problem has nothing at all to do with Oracle.

Yeah, the title made it look like Oracle did something sneaky and caused a problem. The problem was someone writing code that was very, very far away from "write once, run anywhere".

Anybody who still believes in "write once, run anywhere" has never tried deploying to multiple platforms. "Write once, debug everywhere" is more like it, which is why Eclipse has some weird property check that is Windows only in the first place.

That said, the JVM is probably the best environment for doing cross-platform deployment.

Oddly, I finished the article with an improved opinion of Oracle. They were willing to change the property back because of a bug in Eclipse... That's quite a bit more give than I would have expected from Oracle.

Of course, it might have been wise PR as the problem only showed up after updating the JDK. It would have been easy for developers to blame the wrong party.

I wonder how much this must have been already boning people over before who were using OpenJDK (or other JDKs bug for bug compatible with the Sun JDK but without the Sun string).

This is a great example of why software maintenance is so hard. People will use features of your software in unexpected ways. Even trivial changes to your software that should be inconsequential are almost always entirely far too consequential.

I find this amusing because in 2002 I downloaded Oracle JDeveloper IDE to try it out and it replaced files in my JRE directory with their own version that caused my JBoss to break. They have a lot of experience breaking Java.

On the other hand, this is really an Eclipse bug.

Just wow. Using the Java VM non-transparently and hanging a bunch of stuff on properties and mere conventions seems really slick until it all starts breaking.

This reminds me of the time when websites improperly checked for the browser version, breaking down at each release of Mozilla...

And how they still "break" with any version of IE that the programmer doesn't like. Just give me the crapified (text) version already.

Good example of why we need to use feature detection.

I'm still pissed at them for pushing out a point update that introduced a new security check that many, many Java applets failed, and that required a JAR rebuild to get rid of the warning dialog.

If you are already setting the JVM argument for MaxPermSize then I think this issue wouldn't affect you. For example, put "-XX:MaxPermSize=256m" in eclipse.ini

How could they not notice Eclipse doesn't work anymore before releasing the update? Are they forced to use Netbeans?

Well, it could be worse. They could be forced to use Eclipse.

What would you recommend? I'm not being snarky but actually considering an editor switch.

textmate is ok enough :/ IMHO It 'works'.

I draw my code in the sand outside, and then have a scribe enter it into a terminal at some later point. This 'works'.

But really, having a good IDE isn't a bad thing, is it? Does it make me less of a tough guy if I use one?

My IDE is the terminal. I don't want that in a text editor.

I use a text editor to edit text, and a terminal to do everything else.

As long as it can do syntax highlighting, copy paste, line numbering, can show files/dirs in a tree so you can select files easily, I don't want anything else.

Obviously I can understand that other people love clicking on "create a function" in their IDE, or tab completing variable names, or clicking on "build/run". But it's just not for me. Even the quote/bracket auto-insertion in textmate drove me crazy until I disabled it. All that extra crap 'refactor!' 'language bundles' etc.

The code I have seen (Java) produced from programmers using IDEs has been universally horrible. Full of duplication useless boilerplate and general rubbish.

</anecdotal>

If you were writing a novel, would you have a menu with common book 'patterns', or tab complete the character names? For me, it interrupts my flow.

There is a popular myth that you 'need' to use an IDE to code Java. Which is just ridiculous. Perhaps it's a self fulfilling prophecy though. Code produced by IDEs isn't nice to look at so you need to edit it in another IDE, or spend an hour cleaning out all the rubbish.

</rant against IDEs which I detest>

You are much better of using an IDE with java unless you want to write everything yourself using barebones and then do lookups for obscure bits and pieces that are only a simple completion away in an IDE.

Enjoy your elite way of doing it though.

I do :) And I enjoy having nice neat tight code as a result. I don't need the completion, shortcuts etc, because I "know" the code base. Sometimes I need to grep etc, but knowing, and having a handle on the entire codebase is pretty useful for when you need to do big sweeping refactoring.

I use an IDE, and I write clean, tight code. I don't see your point -- part of it is that I have far more important things to do with my life than learn the API, so code completion is a great resource for me when I'm working with 3rd party libraries or Java libraries that I don't use regularly.

Debuggers are another benefit to using an IDE.

Running my app within NetBeans also makes it easier to deploy and launch a web application, so that's another bit of tedium that the IDE alleviates.

For me it's a win-win. It takes care of grunt work, I take care of code.

I also hate debuggers. Tried them, don't like them. They're great for when you don't have the source code and need to reverse engineer something, but for finding bugs, I think they're terrible.

Different people like different things though. It sounds like you're doing a very different kind of development than I do - that whole scary J2EE beans webapp enterprisey stuff.

Well, not quite J2EE, but it is Spring based. Spring relies heavily on magic that makes tracing code very difficult without a debugger. It wasn't my choice, and I wouldn't choose it again, but at least it's better than J2EE.

And I enjoy having nice neat tight code as a result.

Huh? Being able to look up functions and read the Javadocs without grepping somehow makes code messy, now?

I don't need the completion, shortcuts etc, because I "know" the code base. Sometimes I need to grep etc, but knowing, and having a handle on the entire codebase is pretty useful for when you need to do big sweeping refactoring.

First off, the main reason people like code completion because it saves keystrokes. "syso CTRL+SPACE" is 6 actions, compared to "System.out.println()", which is 20. Not having to wait to compile to see whether doFoo(a,b) takes (Bar,Baz) as its arguments instead of (Baz,Bar)? Priceless...

Putting that aside for the moment...if it's even possible for you to know the entire codebase, then you're really just not working on a substantial enough codebase to understand why people like IDEs for refactoring; your refactorings are not even close to "big" or "sweeping". A heavy duty refactoring might touch a hundred files in a thousand places, and that's where you're going to end up with a lot of pain using grep (esp. since in large enough projects token names tend to get reused, so you really want something that understands the semantics of the language).

If a grep is all you need even in order to browse through functions, then you're probably not leaning on .jar libraries; you're definitely not leaning on any bytecode-only ones.

If you're happy with the command line for compiling + debugging, you've probably got a fairly simple test + deployment process, maybe just pure .java sourcecode with no testing on other devices or strange launch processes required; chances are, you're debugging with System.out.println instead of a debugger. That's fine for simple things, but it can be a major waste of time if you run into more sweeping problems that require a bit more exploration to solve.

Some more (possibly unjustified, to be fair) assumptions: you likely have not needed to profile your code, manage dependencies between different projects that by necessity can't be merged into one, hot-replace bytecode (a crucial feature for big projects), set up and maintain a Maven repo, work with type hierarchies complex enough that to need to check them to make sure you're not breaking things before you make changes, conform to specific code-formatting guidelines, sign .jars, test on different JVMs, work with code rewrite rules, pre-process annotations, maintain different .jar distributions, analyze logical dependencies, inspect generated bytecode, etc.

Yes, each of these individual things is something that you can accomplish with a few shell scripts and some elbow grease, true enough. But plenty of people have to do all of this stuff all the time, working with projects that are too big for one head to handle, and it really helps if you don't have to dig into twenty shell scripts each time you need to change something about your project. It sounds an awful lot like you're suggesting that they're in some way inferior for not wanting to manage all this complexity by hand; that would be a big mistake. Plenty of coders much smarter than you or I rely on IDEs every day to get their jobs done, and they create quite good code.

Yeah, well, there were some days when I thanked god for the Eclipse's refactoring capabilities. I had to refactor large amounts of code at one time and had I done it by hand, it would have surely taken a lot more time and would have been a much more tedious process. Not to mention that I would've probably introduced one or two more or less subtle bugs while doing that. This fact alone is enough to make me assured that, when writing code for a large enterprise app, IDEs just can't be beaten.

>> "when writing code for a large enterprise app, IDEs just can't be beaten."

For that case, then yes you're probably right. Thank god I don't write 'enterprise apps'. IDE's are good for getting mediocre productivity out of bad programmers.

IDE's are good for getting mediocre productivity out of bad programmers.

No, that's what Java is good for.

IDEs are good for maximizing the productivity that any programmer gets out of Java. Otherwise the best Java programmers wouldn't use them.

Anecdotal again, but every worthwhile programmer I've known does not use an IDE. But then as I say, a lot of this is semantics. My terminal, and my brain, is my IDE.

Anecdotal again, but every worthwhile programmer I've known does not use an IDE.

Not going to touch this other than to note that at Google, IBM, and Sun, most of the Java devs use one of the big 3 (Eclipse, Netbeans, or IntelliJ), you can certainly ask around if you doubt this.

I don't really look to big corporations to decide what to use. That was the whole reason I started a company.

Big corporations do things that make sense for big corps. One is to treat programmers like factory workers and have them all use standard coding styles, IDEs, etc. Everyone is just a cog and easily replaceable.

You're moving the goalposts. Your anecdote specifically related to "worthwhile programmers", not company size. Unless you're prepared to argue that most Google/IBM/etc. coders are not worthwhile?

Wait, what? Standard coding style is now somehow a bad thing? From your previous comments I can also see that you dislike debuggers? Doing things your way may work if you write small-scale applications, but when you have to work on a large-scale application with several other programmers, there is just no way that you can do that without some coding standards and IDE's debugging and refactoring capabilities. What I really want to say is, look, don't make it sound like all the programmers using IDEs are somehow worse because they use them - they have to maintain large codebases, and without IDEs to help them, they would really have a hard time doing their jobs.

My experience has been that different languages require different tools. Emacs has always been great for my Javascript and Python work, but, even with JDE, I can't get a good flow going with Java.

Regardless of how tough it makes you, I think it makes you smart for using the tools you work best with. :)

If I were in the position of writing some Java again, I'd probably use IntelliJ. I used it once before and it was an absolute treat.

I like IntelliJ IDEA a lot. I don't do much Java development, but it works really well for the times that I feel like I need an IDE for something.

It supports many languages out of the box and is usually one of the earlier IDEs to get plugins for new languages.

On the downside... you'll want to buy more RAM.

Take a look at this thread from the other week:

Ask HN: What is the best Java IDE? http://news.ycombinator.com/item?id=1523394

I'd love to give Netbeans a real shot, but I can't deal with the fact that it is completely unable to match the font settings of the rest of my GNOME desktop.

Eclipse (and any other SWT toolkit app) = matches my native fonts. Netbeans (and, presumably, other Swing apps) = horrible eye-bleed.

Yeah, its's been several years since I used NetBeans in GNOME. I've probably just blocked the image out of my mind.

Either that or I don't care about matching font settings. Or possibly I was so used to Windows fonts that I didn't even notice the discrepancy.

They probably don't use Windows. Many developers, given the choice, prefer not to. And Oracle's Java developers mostly came from Sun. Which had its own operating system that they probably used extensively internally.

It does point to serious issues in their regression test suite. Eclipse has to be in the top 5 Java applications, and they aren't testing that it will even launch on one of their platforms?

"Who fixes a bug by making something dependent on the dll/exe company name? Stupid...How are those outsourced indians working for you now Oracle and Sun!!!!"

Uh, did Oracle/Sun develop Eclipse?

No, IBM and Object Technology International did.

SandGorgon's law: As an online discussion about PROGRAMMING grows longer, the probability of a comparison involving outsourcing or Indians approaches 1, if Godwin's law has not already been satisfied

For those of you that don't know Godwin's law, it states: "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1".

Actually, Godwin's law states the the probably of comparing your opponent/opposing side to the Nazis or Hitler approaches one.

You need that ad hominem for it to be a Godwin.

Ah, sorry. I didn't actually know the law. Looked it up on Wikipedia.

http://en.wikipedia.org/wiki/Godwin%27s_law

It's wrongly stated there, so you might want to change it there as well.

http://en.wikipedia.org/wiki/Reductio_ad_Hitlerum

I've never been clear on whether stating Godwin's Law is equivalent to it happening? All of these Internet Laws can be confusing.

unless used in a reductio ad hitlerum or a reductio ad outsourcedum situation, it does not apply.

Reply on news.ycombinator.com