Earlier quoted context omitted.
How were you able to go back in time to create Spring?
You misspelled "Hibernate". Hope this helps.
Personally I go for the Jboss Spring Hibernate stack with a touch of Oracle thrown in running on Windows Servers.
Show HN: Java Bullshifier
61–70 of 84 posts
Re: Show HN: Java Bullshifier
#62Kind of off topic, but this reminds me of my internship this summer. What sucks about Spring is the horrible error messages. If there is something wrong in the XML configuration, or dependency configuration, it doesn't actually tell you that. Instead, it shows a deep stack trace with some strange exception that doesn't relate to the problem at all.
Then stop using spring. Don't get sucked into the vortex of using overhyped tools that require consultant engagements to fix production bugs.
You could also not use xml. Because spring supports java configuration and the stacktraces are easy to see.
Re: Show HN: Java Bullshifier
#63I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you are seeking between 200 lines of call stack prints.
Two questions: How do you debug your non-trivial applications: sprinkling print statements, some real time debugger, channeling your chosen god? Why do you think that's better?
Well placed print statements. I print only a few things. Of course, in Java & eclipse, it is hard to see the result because so much stuff gets printed (The stack trace, Maven showing useless details, tomcat doing the same, etc.).
In C/C++/rust/JavaScript/Python, the last things you see on a failed build/run is usually the detail that will help you fix the problem. The information is organized to be read by someone.
Re: Show HN: Java Bullshifier
#64Wonder if people will use this to post bullshified apps to Github to impress potential employers
That would actually work [1] to certain extend but once you have to prove your real skills during a technical interview it will be clear that you are not a real Java developer unless, of course, you are. If you are a Java developer this tool will (probably?) have the effect that you suggest, to increase the probability of an ATS [2] to hit your online developer persona.
I will actually try this because as people have mentioned before hiring is broken and this is either a way to exploit and/or bypass some of the inconveniences like coding challenges and the like used to filter non-programmers.
Re: Show HN: Java Bullshifier
#65Kind of off topic, but this reminds me of my internship this summer. What sucks about Spring is the horrible error messages. If there is something wrong in the XML configuration, or dependency configuration, it doesn't actually tell you that. Instead, it shows a deep stack trace with some strange exception that doesn't relate to the problem at all.
Then stop using spring. Don't get sucked into the vortex of using overhyped tools that require consultant engagements to fix production bugs.
Unfortunately, I wasn't in any position to make that call. Else, I would have ditched it.
Re: Show HN: Java Bullshifier
#66Earlier quoted context omitted.
You mean like Sentry? That's been around for ages.
Sentry doesn't give you the local variable state at the moment of error. Only environment related data. We use it as well, but only for JS frontend. It's more of an error tracker, rather than a root cause analysis tool. The benefit is that it's wider and doesn't only focus on Java, but you'll still need to spend time going through logs to actually troubleshoot those errors and understand what was wrong with the state…
Hey, Lewis from Sentry here. "Sentry doesn't give you local variable state" is not entirely accurate - it varies from platform to platform. We don't do it for Java (you're obviously ahead of us there), but we do with at least Python and PHP off the top of my head. I wish we could do it for JavaScript too, but it's only partially feasible and only in a very questionable way.
Note that in your browser JS use case, we capture breadcrumbs to show you console logs, user interaction events, XHRs, navigation events, prior errors, etc leading up to the error, so you should be able to easily just reproduce the error state rather than digging through logs to find out what it was. If you still find yourself needing to dig through logs to troubleshoot JS errors reported via Sentry, I'd really like to hear more about your experience to see if we can make it better.
Re: Show HN: Java Bullshifier
#67I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you are seeking between 200 lines of call stack prints.
Java's stacktraces aren't they much more verbose then Ruby, Python, or JS.
In fact, IMO they aren't verbose enough: they have only the file name of the source file, not the full path.
Re: Show HN: Java Bullshifier
#68Earlier quoted context omitted.
Two questions: How do you debug your non-trivial applications: sprinkling print statements, some real time debugger, channeling your chosen god? Why do you think that's better?
Well placed print statements. I print only a few things. Of course, in Java & eclipse, it is hard to see the result because so much stuff gets printed (The stack trace, Maven showing useless details, tomcat doing the same, etc.). In C/C++/rust/JavaScript/Python, the last things you see on a failed build/run is usually the detail that will help you fix the problem. The information is organized to be read by someone.
You can easily control logging level with slf4j etc, you can run maven in quiet mode if you want to see only errors. I don't think these are java lang issues, its more of a people problem that they don't quite understand the language and the tools they use in depth.
Re: Show HN: Java Bullshifier
#69I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you are seeking between 200 lines of call stack prints.
As an experienced Java developer I love long Java stacktraces and I miss them in most languages. In 90% cases stacktrace allows to find a bug without any debugging, because it's just very obvious where it is. Of course if someone doesn't care about exceptions, it's just a bad style. Exception in the production log is like red light and alarm sound, BUG-BUG-BUG. I saw projects, which throw stacktrace after stacktrace,…
This, and also the fact that once you've been maintaining an application for a short period of time, you quickly learn to recognize those "framework classes that are always there" in the stack trace and skip over them quickly. They are not really a burden, and as long as you're viewing the stack trace in an editor that responds to your mouse's scroll wheel it's no big deal.
I will agree with vbezhenar that Java stack traces are extremely useful. When something has gone wrong with an application in production, it is useful to know the call stack that led to the problem. I know that I didn't just fail in the method `Foo.doFoo()`, I failed in that method which was called by `Baz.doBaz()`. I know these two pieces of code are interacting which is a big clue as to the problem.
vbezhenar also offers good advice that logs of production software should be empty of exceptions and stack traces -- that the presence of anything is the sign of a problem, and thus rare in well-maintained software. Honestly, well-operating production software shouldn't emit any logs at all. Metrics and activity records if you need them, sure, but there's no need for logs. Logs can consequently be used to quickly pinpoint unexpected things happening.
Re: Show HN: Java Bullshifier
#70What does the generated code actually do when run, besides heavily exercising the JVM? Does it eventually print "Hello world" or something?