28 ms·
Show HN: Java Bullshifier
- sedlich 10y agoDoes this remind me legendary paper generator SCIgen... Good to know as a CS teacher ;-)
- agentgt 10y agoAt first I thought this another one of the several Java shaming projects that have been posted in the past on HN (usually in regards to the ridiculous class names of some projects ... aka Spring). But this project actually has some serious utility particularly for byte code manipulators are just alternative compilers like AspectJ. Particularly AspectJ as I have seen it fail on things that neither the Eclipse compiler (JDT) or Open JDK fail on.
- igt0 10y agoIn fact, it is a kind of common practice to generate tons of code. For C language, we have Csmith[1]. It is used to find bugs in llvm and GCC. [1] https://embed.cs.utah.edu/csmith/ https://embed.cs.utah.edu/csmith/
- antoineMoPa 10y agoI'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.
- hota_mazi 10y agoYou can accuse Java stack traces of a bunch of things but they do the exact opposite of hiding the information you are seeking.
- frugalmail 10y agoTwo 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?
- antoineMoPa 10y agoWell 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.
- whitenoice 10y agoYou 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.
- frugalmail 10y agoI'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
- brimstedt 10y agoWhen 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?
- antoineMoPa 10y agoI 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[...]
- Sharlin 10y agoIn my experience the direct caller usually tells me very little about the root cause of the exception. The interesting context is often at least ten frames separate from the proximate cause in even moderately complex Java programs. Of course, often there's an additional couple dozen lines in the trace that aren't very useful...
- deleted 10y ago[deleted]
- frugalmail 10y agoThat'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.
- CSDude 10y agoThe 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-NakshatriHegdeThandra-report.pdf http://plg.uwaterloo.ca/~migod/846/current/projects/09-Naksh...
- tkfx 10y agoIt'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.
- orf 10y agoYou mean like Sentry? That's been around for ages.
- tkfx 10y agoSentry 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 that caused them. With OverOps, you go deep on Java, with every variable value, overlaid on the code across the call stack. Without looking at / relying on logs. There's a short video here (http://www.overops.com/ http://www.overops.com/) and you can see some more samples after you sign up.
- MaulingMonkey 10y ago> Sentry doesn't give you the local variable state at the moment of error. I noticed the sentry json API at least supports them, so this may be a limitation of the specific language SDK as currently stands: https://docs.sentry.io/clientdev/interfaces/stacktrace/ https://docs.sentry.io/clientdev/interfaces/stacktrace/ (see "vars") (I'm fiddling around with writing a Windows C++ SDK for sentry with a C ABI...)
- LewisJEllis 10y agoHey, 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.
- vbezhenar 10y agoAs 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, gigabytes of stacktraces (and then archived those teralogs and noone ever watched them). But those projects have much more problems, verbose logs is the least of them. Yes, with heavy framework usage, especially when those frameworks generate proxy classes and wrappers and god knows what, it's often 2-3 lines of useful information between 90 lines of not-so-useful library or even autogenerated code. But only developer can judge it, environment should preserve anything.
- tkfx 10y agoI think the tool that we're building (http://www.overops.com 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.
- mdaniel 10y agoand 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
- smw 10y agoSentry is outstanding for this! There's an open source self hosted version available too.
- 10y ago
- aikah 10y agoJava stack traces are verbose because Java devs write verbose code. Java stack traces are nice and readable. Just look at a Go stack trace, it'll make you want to vomit.
- bborud 10y agoJava's exceptions are not overly verbose. Blame bad developers and worse architects for insane stack depths.
- Terr_ 10y ago> overly verbose exception outputs I would love to have that problem. I work with old PHP where frequently it just barfs a fatal error with no stack-trace at all.
- paulddraper 10y agoJava'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 10y ago[deleted]
- btbuildem 10y agoWe have folks on-site doing just this, but thanks for the thought!
- imode 10y agodevelopers as a service is looking like a more realistic idea by the second!
- guard-of-terra 10y agoI wonder if you could use genetic algorithms on codebases like these to make them do something useful.
- bigiain 10y agoI wonder how much I'd have to spend on AWS if I just wrote the acceptance tests for our next project, then ran this in a loop/cluster until it wrote something that passed UAT... :)
- MaxfordAndSons 10y agoObligatory reference to https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- tkfx 10y agoHi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool (http://www.overops.com 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 stacks that can go thousands of frames deep and other quirky behaviors. This helps us make sure the overhead is unnoticed, even in the most extreme cases. Would be happy to answer any questions.
- CocaKoala 10y agoI don't know why, but the fact that this is an actual tool that's been designed to solve a real problem that you guys faced (as opposed to being a random project that somebody dreamed up to make fun of Java or to see if they could do it) makes me really happy.
- tkfx 10y agoJava is alive and kicking. It's the most popular programming language in the world. As such, it also attracts most of the fire. We hope to see more colorful projects like these go open source. Thanks for the comment! :)
- zitterbewegung 10y agoHow did you design this ? Do you have an interest in porting this to other languages ?
- tkfx 10y agoHey, at the moment we're only interested in JVM languages, so Java was the best fit for this project. We'll be adding .NET support for OverOps in the future so that might be something we'll be looking at for Bullshifier as well. There are a bit more details about the design on our blog: http://blog.takipi.com/java-bullshifier-generate-massive-random-code-bases/ http://blog.takipi.com/java-bullshifier-generate-massive-ran... And the full source code is available on Github: https://github.com/takipi/java-bullshifier https://github.com/takipi/java-bullshifier Basically, the tool is built with Groovy (many projects use it as a scripting language for Java), and there are 4 sections to each randomly generated class: 1. Variable definition, with random types, random names, and values. 2. A section that throws exceptions, or prints to the log, according to the config settings for the rate of events. This also includes a “suicide” function that stops the execution of the program. 3. Calls the next method. 4. Random code that never runs. There are some advanced config settings described in the Github README.md
- desireco42 10y agoIt 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.
- tkfx 10y agoWe've actually thought of using a random pool of Star Wars related names, will have to wait for the next version. Pull requests are welcome though :P
- GFischer 10y agoIf you have the time (probably not :) ), there was a really cool project that took names from GitHub and generated random names using Markov Chains... maybe use the same for the class names :) .
- tkfx 10y agoCool, sounds similar to the site on the other comment here: http://projects.haykranen.nl/java/ http://projects.haykranen.nl/java/
- leeoniya 10y agofor some reason when I first saw the OP I wondered if it was http://projects.haykranen.nl/java/ http://projects.haykranen.nl/java/
- tomcam 10y agoWonder if people will use this to post bullshified apps to Github to impress potential employers
- jodrellblank 10y agoA world where Paula could have gotten away with it.
- guessmyname 10y agoThat 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. [1] https://github.com/avinassh/rockstar#testimonials https://github.com/avinassh/rockstar#testimonials [2] https://en.wikipedia.org/wiki/Applicant_tracking_system https://en.wikipedia.org/wiki/Applicant_tracking_system
- iLoch 10y agoDo you have a De-bullshifier for existing Java codebases?
- tkfx 10y agoWorking on it as we speak ;)
- vortico 10y agoFeatures: Generates TONS OF CODE!! I love it.
- ryanmccullagh 10y agoKind 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.
- sappapp 10y agoThen stop using spring. Don't get sucked into the vortex of using overhyped tools that require consultant engagements to fix production bugs.
- retbull 10y agoYou could also not use xml. Because spring supports java configuration and the stacktraces are easy to see.
- ryanmccullagh 10y agoUnfortunately, I wasn't in any position to make that call. Else, I would have ditched it.
- qwertyuiop924 10y agoIf you use the right random word combinations for the class name generation, and the code actually does something, this may be near-indistinguishable from a real Java codebase.
- wstrange 10y agoNice, but this should be refactored to generate microservices.
- userbinator 10y agoWhat does the generated code actually do when run, besides heavily exercising the JVM? Does it eventually print "Hello world" or something?
- Slartie 10y agoNeat 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 ;-)
- self_awareness 10y agoActually 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.