Earlier quoted context omitted.
joda-time + java.util.delorean
You should be using the Java 8 time APIs if you want to do it right.
Personally, I find Java 11 makes this much easier.
Show HN: Java Bullshifier
81–84 of 84 posts
Re: Show HN: Java Bullshifier
#82Earlier 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,…
The problem has historically been that most J2EE frameworks overly rely on delegation, because of GoF. I don't like seeing the same 5 stack frames in the same class appear three separate times in a single stack trace. Because what does that stack trace say? It says it took Foo five function calls -on itself- to figure out it's not responsible for an operation. So Foo asks Bar to do it, and after half a dozen more fun…
Your concern is right, but how could we have solved it? I think it's a composition of the Reflection API, the Java style of not accepting optional function parameters, and the pluggable systems.
We call the first framework function, which calls the second function with the default values for the arguments that were optional. The second function looks up the application's method using Reflection. Because Reflection code is verbose and has a lot of tricky cases, we want to share code between all places where we call it, so it delegates calling the API in 4 different methods.
Then come up the ServletFilters in an HTTP application, which is an example of pluggable system. If we declare 10 filters, they all do something like check the authentication, gzip the response, check the XSRF token, transform a WebApplicationException into a 404/500 reaponse. Unfortunately they all appear as "ServletFilters" in the stacktrace, until they delegate to the final HTTPServlet itself. Another example of pluggable system is OSGi: Each method call is wrapped in 5 function calls if the method is in another classloader.
There's only one improvement I'm able to imagine: Java could define a pluggable system at the language level, so we don't have to implement them using function calls. This pluggable system stretches for all delegation needs, from OSGi to ServletFilters to apps where the list of delegates were defined by a REST api, etc. Sounds like a big JSR...
Re: Show HN: Java Bullshifier
#83Earlier quoted context omitted.
The problem has historically been that most J2EE frameworks overly rely on delegation, because of GoF. I don't like seeing the same 5 stack frames in the same class appear three separate times in a single stack trace. Because what does that stack trace say? It says it took Foo five function calls -on itself- to figure out it's not responsible for an operation. So Foo asks Bar to do it, and after half a dozen more fun…
Your concern is right, but how could we have solved it? I think it's a composition of the Reflection API, the Java style of not accepting optional function parameters, and the pluggable systems. We call the first framework function, which calls the second function with the default values for the arguments that were optional. The second function looks up the application's method using Reflection. Because Reflection co…
Barbara Liskov and Bertrand Meyer both have talked about separating decision making from execution. And though there work predates widespread adoption, I find this happens to work remarkably well for unit testing as well.
The thing to remember is that when Java was young, the pool of people who grasped OOAD was very small. Nearly all of us were making it up as we went along. So Design Patterns came out and everyone glommed onto that book, and then went out and wrote code so awful and convoluted that it's now a joke.
J2EE was built up in that space, on a foundation of bad assumptions and unfounded theories. I was simply amazed that the same company that brought us the Eight Fallacies of Distributed Computing brought us the J2EE 1.0 spec. I was so appalled at its quality that I switched to UI development until well after the 2.0 spec was out and implemented.
It says something profound that every vendor that had any succes with those versions of the spec did it by defying the spec and supporting local dispatch. A lot of people couldn't scale their app past two machines, but load balancer eventually came around and fixed that.
Anyway, my point is you have a bunch of APIs written by newly minted experts, many of the foundational ones by people with absolutely no awareness of the physics of distributed computing, it's going to take a lot to spackle to cover those sins. Some did, others doubled down, but overall every problem was solved by another layer of indirection.
When refactoring came to the fore I hoped the industry would hastily reverse course. Spring was supposed to fix a lot of this but from my view, Spring became the thing is sought to replace. Full of cryptic levers and dials and massive indirection.
I think it was Mike Feathers who attributed this to cowardice. People afraid to make decisions put all the decisions behind a layer or two of indirection so they can "cheaply" change their minds later. But again we are back to Meyer and Liskov here.
If A then B (where A is the decision and B the action) allows you to change A without adding much if anything to B, or add to B without changing A. If this shows up in an inheritance hierarchy then you need about half as many overridden methods for the same call tree. Which means a shallower call tree, and code you can speak out loud.
Re: Show HN: Java Bullshifier
#84Earlier quoted context omitted.
How were you able to go back in time to create Spring?
joda-time + java.util.delorean
I did once work on a project that had a class FluxCapacitor. It was used in testing to set the time. It worked, but had about as many zany unexpected consequences as its fictional namesake.