The software circles of hell: Java, NetBeans, Maven, Tomcat, and about 50,000 vaguely-named Java libraries
-
None of this shit (the shit in the subject line there) works. None of it. Maaaybe Java, if sane developers used it. (Java's shit for a desktop app, but for a web server its disadvantages pretty much disappear and it's not nearly as awful.)
NetBeans:
* Double-clicking to select a word works maybe 50% of the time
* The Build icon doesn't grey-out after you press it, meaning at one point I accidentally had three simultaneous build processes going
* The aforementioned "it can't render fonts correctly", and "it gives vague, stupid Subversion errors for no reason"Maven:
* About a third of the time after a build, I find it hasn't bothered to copy over the most current .js files.
* After even slightly touching my build profile, it decides it has to re-download all (seemingly) 36 terabytes of libraries Java developers apparently think they need to build a website
* Maven and Tomcat aren't talking to each other in some way that boggles my mind, see belowTomcat:
* Loves to return 404 errors when I know *know* the file exists, almost always after rebuilding the project
* So I've adopted the following rebuild process:
1) rebuild
2) bounce Tomcat
3) rebuild again
but despite doing that, it *still* returns a 404 error maybe 25-33% of the time (and Maven decides not to update my JS files a similar percentage of the time) and I have to do it again
* Pops up an error every time I log in, when its little system tray app fails to start the Tomcat service-- apparently they never bothered to test with a non-Admin account, or on a computer with UAC enabledThis is the only office in our company doing web dev in JSP. Why would anybody pick this shit software stack? Is it like Stockholm Syndrome or something?
-
Extra bonus points on having to install a library to talk to MS SQL Servers-- Java can't use ODBC? Or maybe these idiot developers think that would be too easy. Must... overcomplicate... project...
-
@blakeyrat said:
Why would anybody pick this shit software stack?
It's free!
-
@blakeyrat said:
Java can't use ODBC?
It's been years since I last touched it, but IIRC (though my memory is super faulty) it uses ODBC standard so it's probably the too easy thing.
-
@blakeyrat said:
Extra bonus points on having to install a library to talk to MS SQL Servers-- Java can't use ODBC? Or maybe these idiot developers think that would be too easy. Must... overcomplicate... project...
great example to show how ignorant you are
-
Thanks! I'm loving the mental image of you red-faced, screaming at your monitor, slamming your keyboard on your desk, and generally just losing your mind at this stuff. There's nothing like a little schadenfreude to brighten up a Friday afternoon. :)
Seriously though, I can't imagine that anyone else is having quite the terrible time as you've had this week. Fonts not rendering correctly, things not greying-out when you click on them, errors that you don't understand. Sounds terrible.
-
you know that you don't have to redeploy a war when editing static content, right. I think, from your last comment, that your company has no clue about any of the tools you're using. Your Maven build process is broken. Subversion, don't get me started. Tomcat 404 is because your WAR is broken. Saying that Tomcat is a piece of crap shows your real ignorance. That's not bad, you probably are used to a walled MS environment and being in a strange land makes you feel uncomfortable and angry.
-
If everything appears to be shit to you, is that because of "everything" or is that because of "you"? Considering that you're also really rude, I figure it's not because of "everything".
-
Try Eclipse. It's also free, and I had no major issues using it at the big company where I interned. (They had to provide some proprietary extensions, but I think those were just for cross-referencing code and Javadocs from parts of the company code base that weren't in your source-control client.)
-
-
So Eclipse doesn't work for you. NetBeans doesn't work for you. Maven doesn't work for you. Tomcat doesn't work for you. Subversion doesn't work for you.
Mmm. Maybe you need a different line of work. Bricklaying, maybe. Street cleaning. I don't know. Pick something where you don't need to know very much at all and you'll do fine.
-
@ubersoldat said:
you know that you don't have to redeploy a war when editing static content, right. I think, from your last comment, that your company has no clue about any of the tools you're using. Your Maven build process is broken. Subversion, don't get me started. Tomcat 404 is because your WAR is broken. Saying that Tomcat is a piece of crap shows your real ignorance. That's not bad, you probably are used to a walled MS environment and being in a strange land makes you feel uncomfortable and angry.
blakey and I are used to an MS environment where the tools actually work. When tools don't work, like in Java land, we get uncomfortable and angry for good reason.
@Seahen said:
Try Eclipse.
The IDE that has no project file so you have no idea what to check into your source control? And that randomly breaks your project when you check it out? And that crashes without any error messages when it can't load your project for whatever reason? Yeah.
-
"The IDE that has no project file so you have no idea what to check into your source control?"
What does that sentence mean?
-
@JasonSykes said:
Bricklaying, maybe...Pick something where you don't need to know very much at all and you'll do fine.
Really? You honestly think that bricklaying is not something where you need to know lots? Wow, just wow.
-
True. Probably something different, I don't know, something where when something doesn't work for you it must be shit, without the smallest chance that you yourself haven't understood something because you've, for example, not spent time with tutorials or read documentation.
-
@JasonSykes said:
That means the tools these guys are used to have a file that stores project settings. The IDE doesn't rely on file system magic and assumptions. Source control tools can parse what's in these files and automatically store relevant files. It's a feature worth paying for."The IDE that has no project file so you have no idea what to check into your source control?"
What does that sentence mean?
-
But when you use a different IDE, don't you start by spending time learning how it works? Or do you fumble through and then start swearing in forums and on Twitter about it? Really hope no one tries to help this guy. Garbage in, garbage out.
-
@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work [b]the way we expect them to[/b]. When tools don't work [b]the way we expect them to[/b], like in Java land, we get uncomfortable and angry for good reason.
I took the liberty of modifying your statement to reflect the point that I think ubersoldat was trying to make.
-
@frits said:
@JasonSykes said:
That means the tools these guys are used to have a file that stores project settings. The IDE doesn't rely on file system magic and assumptions. Source control tools can parse what's in these files and automatically store relevant files. It's a feature worth paying for."The IDE that has no project file so you have no idea what to check into your source control?"
What does that sentence mean?
Indeed. Visual Studio stores all its project-specific settings in a grand total of TWO files, which you check out, change, check back in and everything works. Eclipse stores project information, refactoring shit, its internal organs, debugging shit, and everything else under the sun in the .metadata folder. But if you check that in, the next person who checks it out will be left with a project that might build, but more likely won't even open. It's like playing Russian roulette with a bullet in every chamber.
FYI, when I Googled "site:bash.org java shit" the first result was http://bash.org/?search=java+slow&sort=0&show=25. EVEN GOOGLE KNOWS THAT JAVA IS SHITTY AND SLOW.
-
Could it simply be that you don't understand how Eclipse works?
-
@The_Assimilator said:
@frits said:
@JasonSykes said:
That means the tools these guys are used to have a file that stores project settings. The IDE doesn't rely on file system magic and assumptions. Source control tools can parse what's in these files and automatically store relevant files. It's a feature worth paying for."The IDE that has no project file so you have no idea what to check into your source control?"
What does that sentence mean?
Indeed. Visual Studio stores all its project-specific settings in a grand total of TWO files, which you check out, change, check back in and everything works. Eclipse stores project information, refactoring shit, its internal organs, debugging shit, and everything else under the sun in the .metadata folder. But if you check that in, the next person who checks it out will be left with a project that might build, but more likely won't even open. It's like playing Russian roulette with a bullet in every chamber.
FYI, when I Googled "site:bash.org java shit" the first result was http://bash.org/?search=java+slow&sort=0&show=25. EVEN GOOGLE KNOWS THAT JAVA IS SHITTY AND SLOW.
What, like the .project and .classpath files in Eclipse?
Stand down, .NET losers, stand down. You guys aren't talented, you guys aren't funny, and you sure as hell can't figure out anything unless Intellisense is feeding it down your throat. Get out of here.
-
-
@boog said:
@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work the way we expect them to. When tools don't work the way we expect them to, like in Java land, we get uncomfortable and angry for good reason.
I took the liberty of modifying your statement to reflect the point that I think ubersoldat was trying to make.Are you guys seriously telling me that bugs like, "double-clicking to select a word only works about half the time" are due to me not knowing enough about Java?
-
@blakeyrat said:
"double-clicking to select a word only works about half the time" are due to me not knowing enough about Java?
I believe their point was that you don't know enough about the IDE rather than java. For example you apparently don't know that you must have tapped your left foot three times in the last four minutes for the double-click select to work. Which would be obvious if you were to pay attention to the satellites beaming documentation to your tinfoil hat.
-
@blakeyrat said:
Are you guys seriously telling me that bugs like, "double-clicking to select a word only works about half the time" are due to me not knowing enough about Java?
Are you seriously telling me that bugs like "the fonts don't render correctly" constitute [i]not working?[/i]That said, I've never encountered the double-clicking bug you describe. I [i]have[/i], in Oracle products (including *sigh* Java), encountered a different double-clicking bug, where I double-click one word, then drag to select multiple words. This seems to work properly in most applications on all operating systems, except when it's an Oracle tool: only the double-clicked word is selected. It's terribly frustrating when I expect it to work differently (though not so bad that I'd say it "doesn't work boo-hoo").
The worst thing about it is that I've actually used tools where the double-click-and-drag-to-select-multiple-words works the same as it does everywhere else, then Oracle buys the product, rapes it, and it stops working that way.
-
@boog said:
Are you seriously telling me that bugs like "the fonts don't render correctly" constitute not working?
Yes.
@boog said:
That said, I've never encountered the double-clicking bug you describe.
I think it may be due to using the program via. Microsoft Remote Desktop. When I was actually at the keyboard on Wednesday I don't recall experiencing the bug. Still unacceptable quality though.
-
@The_Assimilator said:
Eclipse stores project information, refactoring shit, its internal organs, debugging shit, and everything else under the sun in the .metadata folder. But if you check that in, the next person who checks it out will be left with a project that might build, but more likely won't even open.
Is the .metadata folder necessary for the project? Can't you tell source control to ignore it?
-
The double-click problem you describe is fixed in 7.1 version of NetBeans:
http://netbeans.org/bugzilla/show_bug.cgi?id=89607
-
Oh I take it back, NetBeans is a quality product:
-
You ever try to install the Android SDK, blakeyrat? Right off the bat, there's an error that they've known about for at least a year where the installer can't find the JDK. You click Back, and then Next and it will go through. I don't have an ingrained hatred of these products (though I also had a fun experience with TomCat), but damn, that made me shake my head.
-
Holy shit. Anyone who DIDN'T know this was a Blakeyrant just from the title, please raise your hand.
-
@blakeyrat said:
Oh I take it back, NetBeans is a quality product:
You sure your network connection isn't f'ed up? And gee, this is Chrome, it's free software, maybe there's a problem with IT too!
Just sayin'.
Congrats (I think) on 5K posts . . .
-
@locallunatic said:
It could be worse. They could be Java bricks.@JasonSykes said:
Bricklaying, maybe...Pick something where you don't need to know very much at all and you'll do fine.
Really? You honestly think that bricklaying is not something where you need to know lots? Wow, just wow.
-
@El_Heffe said:
@locallunatic said:
It could be worse. They could be Java bricks.@JasonSykes said:
Bricklaying, maybe...Pick something where you don't need to know very much at all and you'll do fine.
Really? You honestly think that bricklaying is not something where you need to know lots? Wow, just wow.
So bricks that fill up your short term memory with where they are and what they are doing?
-
"I'm in a building, sitting here"
But wow, this blakeyrant looks like it might have even got some people to join the forum. Not that that's a great thing, just like that weird skyrim thread.
-
@The_Assimilator said:
Eclipse stores project information, refactoring shit, its internal organs, debugging shit, and everything else under the sun in the .metadata folder. But if you check that in, the next person who checks it out will be left with a project that might build, but more likely won't even open.
Do not check it in. .metadata is part of the workspace. Do not check it in. It contains lots of user/machine specific data, such as path names, window positions, and log files. Do not check it in.
-
@frits said:
Until you discover your team are using different IDEs and find all sorts of crap being stored with the sourcecode. Great if all your company does is write Windows stuff and coders are required to use MSVC4.0. Not so great if you're doing cross-compilation and everyone's using their favourite IDE.@JasonSykes said:
That means the tools these guys are used to have a file that stores project settings. The IDE doesn't rely on file system magic and assumptions. Source control tools can parse what's in these files and automatically store relevant files. It's a feature worth paying for."The IDE that has no project file so you have no idea what to check into your source control?"
What does that sentence mean?
-
@PJH said:
Not so great if [. . .] everyone's using their favourite IDE.
What is this I don't even
-
@PJH said:
Great if all your company does is write Windows stuff and coders are required to use MSVC4.0.
... We're on MSVC 10+. Please tell me you don't honestly believe the world of native Windows development hasn't advanced in more than a decade. Furthermore, MSVC isn't the name of the IDE anymore and hasn't been for a decade.@PJH said:
Not so great if you're doing cross-compilation and everyone's using their favourite IDE.
Every time I've seen this actually occur, it was a bullshit cowboy environment and only ever succeeded in turning out crap. Most commits consisted of "Fixed style" and "refactored" (which was shorthand for "I rewrote it because I didn't like the perfectly valid approach taken")And really, I've seen some beautifully organized source trees that support MSVC and a half dozen other IDEs without having any cruft checked in at any point and without having those IDEs stomp over each others meta files - you just have to configure the repository to exclude said cruft (which is much more labor intensive to maintain than just using a uniform IDE, which is why, IMO, this approach is only valid for opensource catherding operations)
-
@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work. When tools don't work, like in Java land, we get uncomfortable and angry for good reason.
I know both sides of the fence, since I do both .NET and Java development on different projects (sometimes even in the same project). Both the Java and the .NET tools work fine, each in their own way (otherwise nobody would use them) and also both of them have their own little problems.That the Java side just doesn't work the way you're used to is your own problem, not that of the tools.
It's kind of like going abroad to a foreign country, and instead of learning the local customs and trying to blend in, you fly into a boiling rage about how everyone talks funny and does weird shit all the time.
-
@Anonymouse said:
This.Both the Java and the .NET tools work fine, each in their own way (otherwise nobody would use them) and also both of them have their own little problems.
That the Java side just doesn't work the way you're used to is your own problem, not that of the tools.
It's kind of like going abroad to a foreign country, and instead of learning the local customs and trying to blend in, you fly into a boiling rage about how everyone talks funny and does weird shit all the time.
If I were to believe everything on these forums about how shit everything is, I would change professions and be ... idk, a pumber. I'm gaining weight so it makes sense.
Well, that or a Node.js developer.
-
@Anonymouse said:
Can we agree that the learning curve for setting up a working development/debug environment for Java is steeper than .NET?@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work. When tools don't work, like in Java land, we get uncomfortable and angry for good reason.
I know both sides of the fence, since I do both .NET and Java development on different projects (sometimes even in the same project). Both the Java and the .NET tools work fine, each in their own way (otherwise nobody would use them) and also both of them have their own little problems.That the Java side just doesn't work the way you're used to is your own problem, not that of the tools.
It's kind of like going abroad to a foreign country, and instead of learning the local customs and trying to blend in, you fly into a boiling rage about how everyone talks funny and does weird shit all the time.
I just seem to find myself going to documentation or Google much more often when using Java tools. Of course this results in an escalation of commitment, so maybe this is by design?
-
@El_Heffe said:
They could be Java bricks.
Actually, those vacuum-sealed packs of coffee they sell in supermarkets would be useful for making a structure with a fairly high insulating R-value.
-
@frits said:
@Anonymouse said:
Can we agree that the learning curve for setting up a working development/debug environment for Java is steeper than .NET?@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work. When tools don't work, like in Java land, we get uncomfortable and angry for good reason.
I know both sides of the fence, since I do both .NET and Java development on different projects (sometimes even in the same project). Both the Java and the .NET tools work fine, each in their own way (otherwise nobody would use them) and also both of them have their own little problems.That the Java side just doesn't work the way you're used to is your own problem, not that of the tools.
It's kind of like going abroad to a foreign country, and instead of learning the local customs and trying to blend in, you fly into a boiling rage about how everyone talks funny and does weird shit all the time.
I just seem to find myself going to documentation or Google much more often when using Java tools. Of course this results in an escalation of commitment, so maybe this is by design?
Why not go directly to a product's site and look at its tutorials instead of using Google? I'd do that if I were learning .NET and would have as hard a time as you're having (with the difference that afterwards, with .NET, I'd not be able to provide for a large percentage of my customers who all hate Windows).
-
@JasonSykes said:
Why not go directly to a product's site and look at its tutorials instead of using Google?
Because I want the answer.
User contributed tutorials, tips, answers, etc. are often times more valuable than manufacturer documentation. Especially when getting past sticking points. Also, search engine page rankings are generally a good indication of the quality of a result. BTW-I'm a fan of Microsoft products and I still use Google to search MSDN.
-
@frits said:
Can we agree that the learning curve for setting up a working development/debug environment for Java is steeper than .NET?
I'm happy to agree (without measuring) that the learning curve is probably steeper. I'd even go so far as to admit that most of the widely-used Java stacks are far less polished than their .Net equivalents.But to say that Java "doesn't work"? That's just crybaby bullshit, of no real value to anyone - the .Net folks will agree, the Java folks won't, and everyone will just be dumber in the end.
-
@frits said:
Agreed. Besides, whenever the product's site does have the best answer, Google usually sends me there anyway.@JasonSykes said:
Why not go directly to a product's site and look at its tutorials instead of using Google?
Because I want the answer.
User contributed tutorials, tips, answers, etc. are often times more valuable than manufacturer documentation.
-
@The_Assimilator said:
blakey and I are used to an MS environment where the tools actually work.
Wow. I wish my MS environment were like that. My experience has been that VS well deserves the nickname Visual Estúpido.@Anonymouse said:
I know both sides of the fence, since I do both .NET and Java development on different projects (sometimes even in the same project). Both the Java and the .NET tools work fine, each in their own way (otherwise nobody would use them) and also both of them have their own little problems.
<snip />
It's kind of like going abroad to a foreign country, and instead of learning the local customs and trying to blend in, you fly into a boiling rage about how everyone talks funny and does weird shit all the time.
++
-
@boog said:
But to say that Java "doesn't work"?
Even when it actually and literally was not working at the time I typed the post? Like, I'm sitting there watching Tomcat deliver a 404 error when I know, know, that a file exists at that location?
Look, maybe my criteria for "doesn't work" is stricter than yours. I'd say a text editor where double-clicking a word doesn't select the word 100% of the time "doesn't work". I'd say a web server that returns 404 codes for files that exist on disk "doesn't work". If you disagree with those two assertions, you're welcome to disagree. But I still think you're an idiot who uses these shitty tools that don't work.
Edit: Oh and I will admit that my experience was at least partially due to a bad Maven configuration, because after the project file was updated in source control, Tomcat worked much more reliably. It still had issues with updated .JS files, but at least I didn't have to bounce the service every single time I built the project.
-
@frits said:
BTW-I'm a fan of Microsoft products and I still use Google to search MSDN.
Isn't that the only way to search MSDN (unless you're developing for Windows Mobile)?
