Live data from Hacker News

Show HN: Java Bullshifier

takipi.github.io

31–40 of 84 posts

Re: Show HN: Java Bullshifier

#31

It was about time somebody creates something like this. I do have a complain, classes are named random. If you used a tool that generates human like names, it would still be random but looked much better. I will see to create a similar rails tool. I intend to test just stress of people who will look at the code and try to understand what it does.

for some reason when I first saw the OP I wondered if it was http://projects.haykranen.nl/java/

Heh, this might actually be useful for v2.0 :)

Re: Show HN: Java Bullshifier

#32

I'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,…

and then archived those teralogs and noone ever watched them

I champion Sentry wherever I go, as it has an outstanding "fold these common explosions into one event" behavior, in addition to managing the _lifecycle_ of an exception/error, from first encounter through resolved in release, to the dreaded reoccurence.

I do keep a terminal open for my curiosity but I'm much happier with computers watching logs than me having to

Re: Show HN: Java Bullshifier

#33
post #15

I'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.

It's not only that. OverOps also shows the variable state and source code of every stack frame. It's like using a debugger in production.

You mean like Sentry? That's been around for ages.

Re: Show HN: Java Bullshifier

#34

It was about time somebody creates something like this. I do have a complain, classes are named random. If you used a tool that generates human like names, it would still be random but looked much better. I will see to create a similar rails tool. I intend to test just stress of people who will look at the code and try to understand what it does.

I was thinking exactly the same thing but to stress test "fancy IDEs".

What if I took emacs and cider and helm-cider and fed it 1e6 line long namespace browser?

(edited to note, I'm not sure why I'd want to try that, but I immediately wondered what would happen...)

Re: Show HN: Java Bullshifier

#35

I'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.

You can accuse Java stack traces of a bunch of things but they do the exact opposite of hiding the information you are seeking.

Re: Show HN: Java Bullshifier

#37

I'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,…

I think the tool that we're building (http://www.overops.com) could be something that might help with the log data overload. It basically gives you everything you need to troubleshoot an error - without relying on log files, while deduping recurrences of the same event.

It gets all the required information (source, stack and variable state), through a native JVM agent that transmits everything directly to the tool.

Re: Show HN: Java Bullshifier

#38
post #13

Earlier 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?

The level of verbosity is good, however when you replace almost all your catch exceptions with ex.printStacktraces() it gets enormously large and unmaintainable across a large project when too many things prints stack taces concurrently. Not the way I like to do it, however too many people do that unfortunetaly: http://plg.uwaterloo.ca/~migod/846/current/projects/09-Naksh...

[deleted]

Re: Show HN: Java Bullshifier

#40
post #8

Hi, 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…

That is a good idea for testing out new stacks for that shiny new rewrite. One thing I've realized is most projects are not designed for 100+ developers working on it at +400kloc of code.

We adopted https://buckbuild.com/ at work for our android builds, and it has sped it up a lot compared to our previous gradle build process.

Post reply on HN