4 ms·

Java EE is not that bad. The problem is that it is for enterprise and you have tons of frameworks for interfacing with legacy mainframes and such. Go for for E

by UK-AL 14y ago

Java EE is not that bad. The problem is that it is for enterprise and you have tons of frameworks for interfacing with legacy mainframes and such. Go for for EE web profile, which the lean version for pure web stuff. All you really need is JPA, some ejbs and a front end(mvc framework or something) and that's it. Add in jax-rs, add some annotions to your ejb and you will have a rest api for you application for free basically.

eropple 14y ago
IMO, JPA (and ORMs in general) is one of the bigger crimes-in-progress in Java. One of the things about Play I do like is that the Scala API eschews JPA. EJB, however, manages to be even a bigger crime-in-progress than JPA. Which is a feat. Making immutable bean classes, and then providing a pleasing API for using them, is an exercise in futility. (And this may sound dogmatic, but I don't really care: immutable-by-default is the only acceptable practice. Embracing EJBs means you probably don't care about that, and that I want nothing to do with your code.)
- jabits 14y ago
  You're right. It is dogmatic. Anybody who says, "...only acceptable practice.", hasn't been around enough.
  - eropple 14y ago
    Ad hominems are cute, huh? If you have a reason to use mutability in a specific case, then do it. If you default to mutability, then you are almost certainly writing poor code. And EJBs (bean classes in general) basically demand mutability to actually be usable. I'm pretty sure "mutable-by-default is a major code smell" is not a very contentious statement in 2012.
- UK-AL 14y ago
  Dude stuff goes in and out fashion faster than anything in tech. Orms went in, Orms went out, then in again(Django, rails) then out. Just need to stop being zealots following the latest trend and get things working. People take the immutable route, then some other guy tells you your being silly. Trust me I've been programming long enough. Besides you don't need Mutability for ejb. The majority of ejbs are just used to access the db.
  - eropple 14y ago
    No, thank you, I won't trust you on this. I've been a fairly loud critic of ORMs since the first time I was exposed to them (Hibernate, as it happens)--having seen them in practice hasn't changed that a bit. The conventional opinion on them may have changed, but mine never has; mutable data structures increase code complexity and greatly increase the surface area for state changes in places it wasn't (or shouldn't have been) intended. And you may not need mutability for EJB, but it's almost always the case that you have it--it's partly a side effect of having to deal with people like you who consider it "not a big deal" and partly because JavaBeans are completely misused[1]. (For those following along at home, who might not be familiar with the culture of Java programmers, mutability in absolutely bizarre places eventually ruins your day at least once. See, for example, the Date[2] class, which for some very Java-y reason is completely and totally mutable. Questions related to the Date class are among my favorites for determining whether a Java programmer has any concept of mutability, and why "do you use Joda Time?" is a decent barometer of basic not-going-to-kill-your-project competence.) . Seriously, though: is "just get it working" the entirety of your defense for diverging from good practices? This isn't just me calling it "good practices," this is what Bloch says in head-shrinking detail in Effective Java and what pretty much everybody else who's had to write Java in anger eventually agrees with. This[3] isn't the best thing in the world on the topic, because I'm not going to quote Effective Java at length, but if you can read that and then come back with "just get it working," I'm gonna have to go light a candle for whoever inherits your code down the line because I've been there (still am there, in the day job) and it's hell. [1] http://www.javapractices.com/topic/TopicAction.do?Id=84 http://www.javapractices.com/topic/TopicAction.do?Id=84 [2] http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date.html http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date.... [3] http://www.javapractices.com/topic/TopicAction.do?Id=29 http://www.javapractices.com/topic/TopicAction.do?Id=29
    - UK-AL 14y ago
      I'm a functional programmer I know what immutable is. However if you've programmed a game in a functional programming language you know it also requires the code to become more complex in various situations. You have to introduce reactive programming to do it properly. No longer can you simply change to coords of an entity to change a position. In that situation I would recommend introducing mutability, trying avoid mutability would make it more complex. Date api is one broken things about java. Everyone knows it is broken. There about ten billion versions of good practise, I could quote them and say you are diverging from good practise? I also recommend you keep things immutable, but not if it makes things difficult.

by UK-AL 14y ago

eropple 14y ago

IMO, JPA (and ORMs in general) is one of the bigger crimes-in-progress in Java. One of the things about Play I do like is that the Scala API eschews JPA. EJB, however, manages to be even a bigger crime-in-progress than JPA. Which is a feat. Making immutable bean classes, and then providing a pleasing API for using them, is an exercise in futility. (And this may sound dogmatic, but I don't really care: immutable-by-default is the only acceptable practice. Embracing EJBs means you probably don't care about that, and that I want nothing to do with your code.)

jabits 14y ago
You're right. It is dogmatic. Anybody who says, "...only acceptable practice.", hasn't been around enough.
- eropple 14y ago
  Ad hominems are cute, huh? If you have a reason to use mutability in a specific case, then do it. If you default to mutability, then you are almost certainly writing poor code. And EJBs (bean classes in general) basically demand mutability to actually be usable. I'm pretty sure "mutable-by-default is a major code smell" is not a very contentious statement in 2012.
UK-AL 14y ago
Dude stuff goes in and out fashion faster than anything in tech. Orms went in, Orms went out, then in again(Django, rails) then out. Just need to stop being zealots following the latest trend and get things working. People take the immutable route, then some other guy tells you your being silly. Trust me I've been programming long enough. Besides you don't need Mutability for ejb. The majority of ejbs are just used to access the db.
- eropple 14y ago
  No, thank you, I won't trust you on this. I've been a fairly loud critic of ORMs since the first time I was exposed to them (Hibernate, as it happens)--having seen them in practice hasn't changed that a bit. The conventional opinion on them may have changed, but mine never has; mutable data structures increase code complexity and greatly increase the surface area for state changes in places it wasn't (or shouldn't have been) intended. And you may not need mutability for EJB, but it's almost always the case that you have it--it's partly a side effect of having to deal with people like you who consider it "not a big deal" and partly because JavaBeans are completely misused[1]. (For those following along at home, who might not be familiar with the culture of Java programmers, mutability in absolutely bizarre places eventually ruins your day at least once. See, for example, the Date[2] class, which for some very Java-y reason is completely and totally mutable. Questions related to the Date class are among my favorites for determining whether a Java programmer has any concept of mutability, and why "do you use Joda Time?" is a decent barometer of basic not-going-to-kill-your-project competence.) . Seriously, though: is "just get it working" the entirety of your defense for diverging from good practices? This isn't just me calling it "good practices," this is what Bloch says in head-shrinking detail in Effective Java and what pretty much everybody else who's had to write Java in anger eventually agrees with. This[3] isn't the best thing in the world on the topic, because I'm not going to quote Effective Java at length, but if you can read that and then come back with "just get it working," I'm gonna have to go light a candle for whoever inherits your code down the line because I've been there (still am there, in the day job) and it's hell. [1] http://www.javapractices.com/topic/TopicAction.do?Id=84 http://www.javapractices.com/topic/TopicAction.do?Id=84 [2] http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date.html http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Date.... [3] http://www.javapractices.com/topic/TopicAction.do?Id=29 http://www.javapractices.com/topic/TopicAction.do?Id=29
  - UK-AL 14y ago
    I'm a functional programmer I know what immutable is. However if you've programmed a game in a functional programming language you know it also requires the code to become more complex in various situations. You have to introduce reactive programming to do it properly. No longer can you simply change to coords of an entity to change a position. In that situation I would recommend introducing mutability, trying avoid mutability would make it more complex. Date api is one broken things about java. Everyone knows it is broken. There about ten billion versions of good practise, I could quote them and say you are diverging from good practise? I also recommend you keep things immutable, but not if it makes things difficult.