Earlier quoted context omitted.
How were you able to go back in time to create Spring?
joda-time + java.util.delorean
You should be using the Java 8 time APIs if you want to do it right.
Show HN: Java Bullshifier
71–80 of 84 posts
Re: Show HN: Java Bullshifier
#72Earlier quoted context omitted.
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.
We have a self-hosted Jira/Confluence server running on Windows that's reached end of life....I can relate to this. Fortunately no Oracle in the mix other than Java.
Re: Show HN: Java Bullshifier
#73I'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.
[deleted]
Re: Show HN: Java Bullshifier
#74Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…
I've been wanting to build a generic version of this type of tool for quite some time. When I'm waiting several minutes for our app server to startup, I often ponder what life would be like if we had chosen language X or another stack for our application. I've primarily worked on JRE-based stacks for some time and once a project reaches a certain size developer happiness begins to decline due to large compilation tim…
Why not micro-services?
Re: Show HN: Java Bullshifier
#75Earlier quoted context omitted.
When something blows, arent you just happy to get as much information as possible? I remember when developing in VB classic, youd get something lile "error -68377388484". Perhaps you prefer this?
I prefer something in between. Something like: the method that called the current method, the line number and a sentence describing the exception. No need to know the function-that-called-the-function-that-called-the-fun[...]
That's sounds like you work on very small projects. That function-that-called-the-function-that-called-the-fun could behave very differently through that path due to calling parameters, environment or data issues.
Re: Show HN: Java Bullshifier
#76Earlier 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.
I've done my fair share of work in those languages and it almost never has anything to do with the last line. Typically following back into some stupid === vs. == error or some dynamic typing issue many frames up the call stack. Even C++ is a nightmare to traceback when you use boost/STL heavily
Re: Show HN: Java Bullshifier
#77Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…
I've been wanting to build a generic version of this type of tool for quite some time. When I'm waiting several minutes for our app server to startup, I often ponder what life would be like if we had chosen language X or another stack for our application. I've primarily worked on JRE-based stacks for some time and once a project reaches a certain size developer happiness begins to decline due to large compilation tim…
Why not OSGi?
Re: Show HN: Java Bullshifier
#78Earlier quoted context omitted.
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…
agree on mostly everything apart from last part - even well-working app should have some debug/info/warn statements. ie my current app - messaging integration tool build on apache camel, I log rather more than necessary, as messages go through various components, operations made on them etc. Each component isn't aware of others, so logging current state only if exception happens will lose some good info on overall situation happening.
a bit too verbose, but the amount of info I can get from UAT/PROD envs in case of an issue is mostly enough to fix the bug. verbosity can be solved easily by proper rolling & backup of logs, that's not rocket science.
Re: Show HN: Java Bullshifier
#79Neat idea! As a mostly-Java coder (by choice), I love both the approach to testing your own tool as well as the slight side blow into the Java community regarding long stack traces full of framework-contributed delegation classes and virtual proxies.
But...not more than 20k classes? That doesn't really count as "massive Java application" these days, more like an average-sized enterprise app when including all its dependencies. You would at least triple that to reach "massive" scale ;-)
Re: Show HN: Java Bullshifier
#80Actually this could be a good platform for generating licensing algorithms that would be included in commercial software. This level of obfuscation would really be hard to crack by reverse engineers that produce cracks/keygens.