Eclipse is broken (but we knew that)



  • I have a Java project in Eclipse for a compiler class. It's set up to use SableCC to auto-generate code based on what is basically a config file. The problem I ran into is that the project suddenly began to fail to resolve the project's package and its contents in the code's import statements. I tried a lot of things - refresh the project, close and reopen the project, close and reopen Eclipse, delete and re-import the project folder, and nothing seemed to work. After googling the issue, I found a recommendation to clean the project and rebuild it. I tried that and it worked!

    All right. Ok, that fixed it. I can do my homework project.

    But, what? Seriously? How in the world do the output files (or possible lack thereof - I'm not sure which it was, exactly) keep the source items from being resolved? I think it can't be a circular dependency: the unresolved names were all defined in the source files, not the output from the generator.



  • Maybe an old or erroneous output file that wasn't correctly being generated anymore, I don't really see the WTF here. Furthermore, isn't the problem probably in your SableCC plugin? That's not exactly Eclipse's fault



  • @dtech said:

    Maybe an old or erroneous output file that wasn't correctly being generated anymore, I don't really see the WTF here. Furthermore, isn't the problem probably in your SableCC plugin? That's not exactly Eclipse's fault

    No it always does that. Sometimes even in Java projects. Annoying like hell.
    I think it comes from some cashing somewhere. Still annoying.


  • Discourse touched me in a no-no place

    @Jedalyzer said:

    But, what? Seriously? How in the world do the output files (or possible lack thereof - I'm not sure which it was, exactly) keep the source items from being resolved? I think it can't be a circular dependency: the unresolved names were all defined in the source files, not the output from the generator.
    Eclipse is a honking pile of shit at times, and the way it caches stuff in mysterious ways instead of just loading it off disk when needed is very close to the centre of the WTF. (Either that or maybe the way it screws with the class loader system, which is outright scary.)

    I'm also not convinced that the way it caches things is particularly efficient either. Because that would be too logical.



  • @dkf said:

    and the way it caches stuff in mysterious ways instead of just loading it off disk when needed is very close to the centre of the WTF. (Either that or maybe the way it screws with the class loader system, which is outright scary.)
     

    If you don't want eclipse to cache things from disk, just enable the setting which force eclipse to always check if a file have changed on disk before accessing the cached version. 



  • @mt@ilovefactory.com said:

    If you don't want eclipse to cache things from disk, just enable the setting which force eclipse to always check if a file have changed on disk before accessing the cached version.

    1 - How does that make eclipse stop caching things?

    2 -  Do the eclipse devs realise that some (only about 90% of them, nothing of importance) people use their program on Windows? Why do they need to touch every Windows WTF? (Cause Windows still has no reliable way of telling if a file was updated.)



  • @Mcoder said:

    @mt@ilovefactory.com said:

    If you don't want eclipse to cache things from disk, just enable the setting which force eclipse to always check if a file have changed on disk before accessing the cached version.

    1 - How does that make eclipse stop caching things?

     

    Sorry, it does not make eclipse stop caching things. But it causes eclipse to check if a file have been updated before it uses the cached version.

    And yes the true wft is that both Linux and Windows, are really bad at the "Just tell me if a file have changed" thing, thus forcing software to check last update changes on files. -(

     

     



  • @mt@ilovefactory.com said:

    If you don't want eclipse to cache things from disk, just enable the setting which force eclipse to always check if a file have changed on disk before accessing the cached version. 

    You mean "work correctly" is an option, and it's disabled by default. I've seen that in a lot of software, but it's still WTF.



  • @Planar said:

    You mean "work correctly" is an option, and it's disabled by default. I've seen that in a lot of software, but it's still WTF.
     

    Yes, that's because it does not work as intended.



  • I no longer have any understanding for people using Eclipse. There simply is no excuse for succumbing to that garbage. Even if your class requires you to, do all coding in a decent IDE (IntelliJ IDEA first, NetBeans second) and import to Eclipse when done.


  • Discourse touched me in a no-no place

    @veggen said:

    I no longer have any understanding for people using Eclipse. There simply is no excuse for succumbing to that garbage. Even if your class requires you to, do all coding in a decent IDE (IntelliJ IDEA first, NetBeans second) and import to Eclipse when done.
    Neither IntelliJ IDEA nor NetBeans support all the features of Eclipse that I'm using. Eclipse isn't too bad apart from the excessive caching and the occasional gnostic message, provided you've got lots of memory and CPU spare.



  • Ok, I'm hooked. What are the features you're speaking of?


  • Considered Harmful

    @veggen said:

    Ok, I'm hooked. What are the features you're speaking of?

    It has a checkbox that causes the build to not break randomly.


  • Discourse touched me in a no-no place

    @veggen said:

    Ok, I'm hooked. What are the features you're speaking of?
    I'm long bored of this conversation. Summary: I'm using plugins which have no equivalents in the other IDEs, and I've zero interest in being a plugin developer for anyone or anything.



  • You had to clean your output to fix some kind of build issue? Wow, that never happens with Visual Studio. And who would have ever thought to try that? That's some Wozniak-level shit right there. /sarcasm

    Seriously, as a longtime user of Visual Studio who more recently picked up Eclipse for Android development, I can tell you that Eclipse is pretty damned good. When I started with it, I'd heard a lot of complaints and was quite wary. I was pleasantly surprised; Eclipse seems to me to be very stable, rational, etc.

    I'm sure Eclipse has its issues like everything else, but in my opinion the biggest tool-related WTFs out there are 1) Resharper and 2) NuGet package manager. Get into an issue with NuGet, and you'll wish that cleaning your solution output was all it took to get things going again.



  • @bridget99 said:

    1) Resharper

    1. It's not something that comes with Visual Studio.

    2. It's one of the best tools I've ever used.

    3. It's usually more right than you are, once you disable a few stupidities (such as "use var everywhere you can")



  • @veggen said:

    I no longer have any understanding for people using Eclipse. There simply is no excuse for succumbing to that garbage. Even if your class requires you to, do all coding in a decent IDE (IntelliJ IDEA first, NetBeans second) and import to Eclipse when done.

    Work requires me to use it.  At least when I'm working in Java (which is most of the time).



  • @Maciejasjmj said:

    @bridget99 said:
    1) Resharper

    1. It's not something that comes with Visual Studio.

    2. It's one of the best tools I've ever used.

    3. It's usually more right than you are, once you disable a few stupidities (such as "use var everywhere you can")

    I don't disagree with most of the "advice" given out by Resharper, I just hate what it does to Intellisense, and to the overall experience of using Visual Studio. It really goes haywire if you start renaming variables outside of its own magical renaming facility, for example. I think there's a philosophical difference between me and people who use Resharper, too. I'm more focused on delivering code, and they're more concerned with "skill set" and specifically in developing narrow but deep expertise in .NET (and in the .NET party line, as articulated by people like Rockford Lhotka, Jon Skeet, etc.); personally, I'm not really interested in that.



  • @bridget99 said:

    I'm more focused on delivering code, and they're more concerned with "skill set" and specifically in developing narrow but deep expertise in .NET (and in the .NET party line, as articulated by people like Rockford Lhotka, Jon Skeet, etc.); personally, I'm not really interested in that.

    Bringing you the code, no matter how bad it hurts!

    Also, having a skill set related to writing readable and maintainable .NET code helps in writing readable and maintainable .NET code. It doesn't mean that you suddenly forget everything about Java once you've learned where to use lambdas in C# (though I wish it was so).

    Sure, "as long as it compiles" way is also a way, but woe be upon those who inherit code like that.



  • @Maciejasjmj said:

    @bridget99 said:
    I'm more focused on delivering code, and they're more concerned with "skill set" and specifically in developing narrow but deep expertise in .NET (and in the .NET party line, as articulated by people like Rockford Lhotka, Jon Skeet, etc.); personally, I'm not really interested in that.

    Bringing you the code, no matter how bad it hurts!

    Also, having a skill set related to writing readable and maintainable .NET code helps in writing readable and maintainable .NET code. It doesn't mean that you suddenly forget everything about Java once you've learned where to use lambdas in C# (though I wish it was so).

    Sure, "as long as it compiles" way is also a way, but woe be upon those who inherit code like that.

    I'm not advocating a return to the garage hacker ethos of the Eighties. I do think there's a time and place for studying the practices others find useful, and a time and place for actually producing salable code, and there's less overlap between the two than many developers seem to realize. I see a lot of developers work in ways that basically guarantee that everything they do will be an uninterrupted learning experience (e.g. always selecting the very newest version of everything) and I think these people suffer from a certain lack of perspective. If you're using Resharper for this reason, you're basically misappropriating project resources to advance your own career. I also disagree with the notion that because, say, Jon Skeet invented much of C# Jon Skeet therefore has oodles and oodles of relevant things to tell me about how I should apply C#. My feelings are almost diametrically opposed to that view, and history tells us that many good programmers agree with me; game programmers certainly did not use the VIC-20 display hardware in this way, for example, or even the IBM VGA. The whole concept of a RESTful web app is basically an abuse of the original vision of the people who designed HTTP. Applying C# strictly in the manner Microsoft originally envisioned would be a grave mistake.


  • Discourse touched me in a no-no place

    @bridget99 said:

    Get into an issue with NuGet, and you'll wish that cleaning your solution output was all it took to get things going again.
    I'll see that and raise you Maven in Eclipse. Mostly it works, but when it doesn't, it's entirely mysterious and understanding Maven outside Eclipse doesn't help. (Well, not much. The consequences of the weirdness of the way the classloaders vary inside Eclipse are profound and very hard to predict ahead of time.)

    If you don't know what I'm talking about, you're very lucky.



  • @dkf said:

    @bridget99 said:
    Get into an issue with NuGet, and you'll wish that cleaning your solution output was all it took to get things going again.
    I'll see that and raise you Maven in Eclipse. Mostly it works, but when it doesn't, it's entirely mysterious and understanding Maven outside Eclipse doesn't help. (Well, not much. The consequences of the weirdness of the way the classloaders vary inside Eclipse are profound and very hard to predict ahead of time.)

    If you don't know what I'm talking about, you're very lucky.

    Yeah, in fairness to Microsoft, NuGet really does remind me of basically every *Nix package installer. NuGet's less excusable, though, in that Visual Studio had a perfectly fine system of reusable libraries before NuGet was foisted upon us. Microsoft had every ability to do something better, and blew it, likely in service of some corporate goal that will be abandoned with the changing of seasons



  • @bridget99 said:

    Stuff

    Using the example of game programmers to justify programming practices automatically invalidates your opinion.



  • @Maciejasjmj said:

    3. It's usually more right than you are, once you disable a few stupidities (such as "use var everywhere you can")

    What do you find wrong about using var everywhere you can?



  • @Arnavion said:

    @Maciejasjmj said:

    3. It's usually more right than you are, once you disable a few stupidities (such as "use var everywhere you can")

    What do you find wrong about using var everywhere you can?

    Maybe it's just me, but if I receive a value from a function call, I prefer to specify its type for future reference.

    Obviously there's nothing wrong with

    var v = new SomeObject<AnotherObject, YetAnotherObject<AndOneMore>>();
    , but
    var v = someFunction();
    requires you to keep looking at a function header to know what type v is.



  • @Maciejasjmj said:

    requires you to keep looking at a function header to know what type v is.

    I agree Intellisense isn't necessarily available (because sometimes I want to quickly check something in a text editor instead of launching VS). Still, your function name should tell you what it's returning. Script.GetProperties() obviously returns you a ScriptProperties object. UI.Strings returns you a collection (probably a list, maybe a dictionary - the difference might not matter) of UI strings.

    I did used to have a similar policy as yours - I only used var if the type was already used in the same line elsewhere, like in the "new" expression or a cast. Nowadays I'm just lazy and use var everywhere. Doing more Javascript on the side might have contributed to that...



  • Script.GetProperties() obviously returns you a ScriptProperties object.

    Unless it returns a list of Property objects. Or a comma-separated string. Or a byte stream, because a year ago some dev showed up to work drunk out of his ass.



  • @Mcoder said:

    Cause Windows still has no reliable way of telling if a file was updated.

    I guess this doesn't exist then.



  • @bridget99 said:

    Applying C# strictly in the manner Microsoft originally envisioned would be a grave mistake.

    I'm pretty certain Microsoft, and any platform developer, would totally agree with you. An ecosystem is constructed by its inhabitants.



  • @Ben L. said:

    @Mcoder said:
    Cause Windows still has no reliable way of telling if a file was updated.

    I guess this doesn't exist then.

    This doesn't address files that have changed when the application isn't running.


  • Discourse touched me in a no-no place

    @Soviut said:

    This doesn't address files that have changed when the application isn't running.
    Caching the modification times is acceptable. Holding on like grim death to the concept of what the file contained, even though the file has long since changed (e.g., to get rid of the stupid original bug in the code)… not so acceptable.



  • @Soviut said:

    @Ben L. said:
    @Mcoder said:
    Cause Windows still has no reliable way of telling if a file was updated.
    I guess this doesn't exist then.

    This doesn't address files that have changed when the application isn't running.

     

    Easy workaround. Just create EclipseFileWatcherService.exe and register it as a service. That way it's ALWAYS running.



  • @anonymous234 said:

    @Soviut said:

    @Ben L. said:
    @Mcoder said:
    Cause Windows still has no reliable way of telling if a file was updated.

    I guess this doesn't exist then.

    This doesn't address files that have changed when the application isn't running.

     

    Easy workaround. Just create EclipseFileWatcherService.exe and register it as a service. That way it's ALWAYS running.

    Filed under: for some reason it uses 350MB of RAM


Log in to reply