Why do people seem to think "opinionated" is a virtue these days?
An Opinionated Guide to Modern Java Development, Part 1
141–150 of 402 posts
Re: An Opinionated Guide to Modern Java Development, Part 1
#142What about dependency injection in modern java - is Guice or spring still the de facto standard?
I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.
The more complex the data model, the more one needs to know the inner working of JPA. I've shared my struggle understanding how JPA works even for a medium-level complexity of the JPA entities.
Some of the problems I've encountered using JPA:
- The whole EntityManager act as L1 cache occasionally tripped me when writing Integration-Tests
- The relationship direction (owning, etc) can be confusing to learn
- Reference vs Lazy vs Eager load
Having said that, HBM2DDL is a nice tool that can work as maven plugin such that changes on the JPA entities can resulted the DDL to be updated properly thus maintaining consistency between Java Data Model and the DB schema.
Re: An Opinionated Guide to Modern Java Development, Part 1
#143Earlier quoted context omitted.
I also did some J2ME stuff back in 2003, most with Sharp and Nokia devices. I read somewhere that some in the Android team are C converts doing their first Java gig. Have you seen how broken are the generated Renderscript bindings? They don't have anything to do with Java conventions and feel completely out of place.
Haven't looked at render script yet. Still scratching head on the layout engine stuff and View infrastructure. It's fugly. I usually write C#+WPF and C++/Qt and HTML/Java EE and all of those are massively nicer to deal with.
From my experience once you get past the initial hump of learning their basic APIs and conventions its a very easy to work with platform. Maybe I am biased because I spend a lot of time with it. I also really like the tooling. How is it acting unstable for you?
Re: An Opinionated Guide to Modern Java Development, Part 1
#144Earlier quoted context omitted.
There are no winners in the build war despite the overwhelming online support for Gradle. Personally I'm not a fan of it. I find it on the slow side even compared to maven. I'd rather have declarative builds like Ant but therefore support better tooling than super freeform tools like Gradle that force you to drop into a language with about as much type safety as Javascript. Multi-project builds are also annoying, as…
> I'd rather have declarative builds like Ant Is that a typo? I'd say Ant is the opposite of declarative.
If you stay within the bounds of that the Gradle DSL can do, rather than throwing Groovy around (which is possible - i write a lot of Gradle, and very rarely write raw Groovy), then Gradle is rather nice and easy to reason about. But if you don't, well, you're going to have a bad time.
Re: An Opinionated Guide to Modern Java Development, Part 1
#145>But the modern Java developer uses Gradle...there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy. This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project. I find a lot of development tools/frameworks make m…
I wouldn't say you need to actually learn Groovy to get going with Gradle. The example build.gradle files are fairly self-documenting, and you'll be modifying them more than writing them from scratch. Easier to read than a pom.xml, for sure.
In that case I will have to check in out on a side project. My current projects at work are using Ant or Maven and I dont really like sorting through the pom.xml especially if someone else set it up.
Re: An Opinionated Guide to Modern Java Development, Part 1
#146> But the modern Java developer uses Gradle I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.
Gradle is mainly being pushed by Grails and Android development. I don't know of any other project using it. We are always doing Maven or Ant. If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.
Re: An Opinionated Guide to Modern Java Development, Part 1
#147The position of things like Netty and Undertow at the top of the techempower benchmarks has me a little intrigued. How much hassle is it to write websites with servlets like that?
In terms of actual websites I understand Play is migrating to run on top of Spray, but I'm not aware of any mature frameworks for doing it right now.
Re: An Opinionated Guide to Modern Java Development, Part 1
#148Earlier quoted context omitted.
Gradle is mainly being pushed by Grails and Android development. I don't know of any other project using it. We are always doing Maven or Ant. If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.
Is Grails really pushing Gradle adoption? My experience has always been that the integration between the two is pretty bad. Are things better now that they finally... released a real Gradle plugin to support Grails 2?
Re: An Opinionated Guide to Modern Java Development, Part 1
#149Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (LifecycleEvent marker interface with ExitEvent subtype containing onExitEvent(ExitMessage m), etc), or ... or ...
Writing an intro to Java + touting your company's API + blaming Java for yourco's API problems: seems like bad form.
Which reminds me: can someone explain how actors is any different than using messages and queues for concurrent programming? Unless it also implies "magic translation of messages to method calls" which makes me uncomfortable (bad memories of CORBA/Web services)
Re: An Opinionated Guide to Modern Java Development, Part 1
#150Good article, lots of opinions but the title forewarns. For me, Eclipse is still very good and if anything, more stable than in earlier years. I've tried NetBeans and the free IntelliJ but though those are fine, Eclipse is better for me. The real trick is to _not_ store your code in the workspace (which is ironically where the project wizards default to unless you change it). Store your code in as an example, svn for…
One of the things I liked was how easy it made things by allowing eclipse keybindings to be used. Ever since I enabled those, things have worked exactly the way I would expect.
I also like the work flow with git. A common example I like is the prompt for adding files to your repo automatically upon creation, this way I don't have to think too much about it.
Just my 2c as an eclipse user converted.