This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-19
Channels
- # admin-announcements (2)
- # beginners (24)
- # boot (36)
- # business (1)
- # cbus (3)
- # cider (22)
- # cljs-dev (91)
- # clojure (101)
- # clojure-canada (9)
- # clojure-china (3)
- # clojure-czech (21)
- # clojure-nl (3)
- # clojure-russia (131)
- # clojure-sg (5)
- # clojure-uk (9)
- # clojure-ukraine (4)
- # clojure-za (2)
- # clojurebridge (18)
- # clojurescript (333)
- # clojurex (6)
- # devcards (1)
- # events (37)
- # hoplon (15)
- # ldnclj (23)
- # luminus (3)
- # off-topic (41)
- # om (258)
- # onyx (20)
- # re-frame (46)
- # reagent (7)
- # spacemacs (2)
@agile_geek: don't know, I was hoping for something nice like linq2sql in C#
@borkdude: yeah, seen linq, quite nice. Haven’t directly parsed XML for a while in Java but it was painful when I did.
@borkdude: I’m afraid I haven’t done that for even longer!
@agile_geek: me neither
@borkdude: The Java community has pretty much embraced annotation-based XML serialization, and in that space Jackson is the most common (and fastest).
I've done it two other ways: hand-written .toXml()
methods and also Velocity template-based (this last is very nice IMO, and separates all knowledge of XML outside of the Java code).
@borkdude: I’ve used JAXB in the past, but not sure if I can recommend it https://jaxb.java.net/ & https://en.wikipedia.org/wiki/Java_Architecture_for_XML_Binding the use of Schema’s and XSLT for forward/backward compatibility was nice though. Other than it was a pain and not sure if it’s maintained anymore
@joelkuiper: Yeah, JAXB is what we have and I tried working around a stupid problem. But I already solved it the other way by going from @XmlAccessorType(XmlAccessor.FIELD) -> @XmlAccessorType(XmlAccessor.NONE) and explicitly annotating every field I want to pull in the xml
I came across this today (during a lecture about DDD): http://martinfowler.com/ieeeSoftware/whenType.pdf The guy presenting advocated for replacing simple string by specialized classes and cited that article by Fowler. It goes so against the Clojure way of just writing hashmaps. I wonder if some people are trying the (immutable) hashmap way in Java and get away with it.
It's not whether you can, since it all boils down to JVM bytecode, it's how painful is it?
@kirked: yeah, obviously you can. I am updating a legacy Java code base now. The 'domain' is so huge. Every little 'thing' has its own class. Still can't believe how people can be productive that way.
The app imports json. In json it all looks so small and clear. Until it's unmarshalled into Java objects. Huge bloat.
I really don’t miss the incredibly low signal->noise ratio in Java. There is just so much stuff that finding your domain logic is sometimes harder than where’s Wally
Probably the folks who started the project could better have dumped the JSON straight into MongoDB or Elasticsearch without writing one domain class.
@kirked: if it was up to me, I would rewrite in Clojure, but it's not the reality. I don't even think this is goofy, it's just the way it's usually done in Java + mapping to relational databases (as far as I'm aware).
That's always been the problem with object-relational mapping: you need a compiler to tell you where you screwed it up, unless you wanna just wait until runtime
I wonder if Clojure style (domain in 'just' hashmaps) catches on in other languages in the future.
Scala case classes are essentially named tuples with compiler-provided methods for equality, hashing, and copying ("modifying")
I used regular Java HashMaps in an immutable way for one project. It worked well, but it would also have been nice to have compiler guarantees since others eventually took up the codebase.
@borkdude You might also check out Apache Camel. It's a data flow toolkit essentially.
@kirked: I share my office with an entire team of integration specialists working with Camel, Fuse, etc.
@joelkuiper: btw, I'm pretty sure JAXB is maintained, it's part of the JDK: https://jaxb.java.net/guide/Which_JAXB_RI_is_included_in_which_JDK_.html