Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java for Everything

teamten.com

Post reply on HN
Print view View original

331–340 of 344 posts

Re: Java for Everything

#331

Post by unclebucknasty »

lmm wrote: post #327
unclebucknasty wrote: post #315

Earlier quoted context omitted.

> If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a different language Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base. But, beyond that, if you've gone through the care of structuring it correctly such that the structure and interfaces are preservable once scalability needs arise, t…

> Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base. I have done this professionally. You don't port everything, you just port services as they become bottlenecks. By the time you need to scale like this, you already need to have multiple engineering teams and you need well-defined interfaces between components, so having parts of your system in different…

>I have done this professionally. You don't port everything, you just port services as they become bottlenecks.

Yep, been there too. Except, in the case I'm thinking of, it wasn't for performance. We went with a multi-language approach for different reasons, and we ended up with a hybrid that no-one liked. Then, we finally decided to port everything to one language.

All of this to say that a multi-language approach can have its own drawbacks, which is not to say that it's never appropriate. There should just be a really good reason for it. Generally, I'm not sure that starting with a plan to half-port a non-performant app is a good reason. But, I'd never say never.

I'd also add (again) that if you've really taken the time to structure the app so well that you have clean interfaces and modularized, easily-portable services, then it begs the question: did you really save so much time by then implementing that design in PHP vs Java? As you said, the design is the hard part, and I'm just not seeing the notion of a quick non-scaling app, somewhat hastily implemented in PHP, being compatible with the idea of a tight, service-oriented, modular design. I think you kind of have to choose one.

I don't suppose any approach is necessarily the absolute right approach per se. But, given that the article is about picking one approach/language (Java) and sticking with it, I'd have to say that I'm still convinced that it may indeed be optimal, even after reviewing your points.

Re: Java for Everything

#332

Post by koffiezet »

Everything in Java? Thanks but no thanks. I understand the author's point, but he's choosing the wrong language. Does the perfect language for this purpose exist? No - sorry. I've been charmed by Go lately and replacing python, small C/C++ and shell-scripts with small tools written in it. It has great potential for services and small tools and has a surprisingly large amount of libraries available for it given the language's age. But would I say Go is perfect for everything? Hell no - but it happens to be pretty good for what I need.

My view of Java may be a bit biased, since I also tend to look at things from the sysadmin pov nowadays. I can only tell that I never disliked Java until I had to take care of the monstrosities the Java developers bring to life, and mind you - I started out as a Java dev back in 2000.

The main issue I have with Java is the JVM and memory usage and leaks. No matter what people claim - no memory leaks in Java is a fairy-tale. We run both custom C++ and Java services (about 50/50) on a few hundred servers - and I cannot find a single issue in our ticketing system related to memory problems with any of our C++ services. Java services? Every. Single. Week. When I get an alert some JBoss unexpectedly died or became unresponsive - "java.lang.OutOfMemoryError" is most likely going to be the problem. A lot of those are permgen space errors, and yes you can try all the "fixes" like increasing the permgenspace, permgensweeping, enabling class unloading, ... but these don't always fix the problem and slow down your services. Every time this happened in our own services, this had to be fixed by our developers. It takes weeks to locate the problem, and you end up deploying new versions, upgrading JBoss, JSF, Bouncycastle, ... whatever.

Re: Java for Everything

#333

Post by sandGorgon »

koffiezet wrote: post #332

Everything in Java? Thanks but no thanks. I understand the author's point, but he's choosing the wrong language. Does the perfect language for this purpose exist? No - sorry. I've been charmed by Go lately and replacing python, small C/C++ and shell-scripts with small tools written in it. It has great potential for services and small tools and has a surprisingly large amount of libraries available for it given the la…

can you talk about your jboss configuration ? We are thinking of building our API stack in java and are considering wildfly (undertow). Honestly, you are the first person who has talked about problems in Jboss and would appreciate some more info.

Re: Java for Everything

#334

Post by lmm »

unclebucknasty wrote: post #331
lmm wrote: post #327

Earlier quoted context omitted.

> Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base. I have done this professionally. You don't port everything, you just port services as they become bottlenecks. By the time you need to scale like this, you already need to have multiple engineering teams and you need well-defined interfaces between components, so having parts of your system in different…

> I have done this professionally. You don't port everything, you just port services as they become bottlenecks. Yep, been there too. Except, in the case I'm thinking of, it wasn't for performance. We went with a multi-language approach for different reasons, and we ended up with a hybrid that no-one liked. Then, we finally decided to port everything to one language. All of this to say that a multi-language approach…

> I'm just not seeing the notion of a quick non-scaling app, somewhat hastily implemented in PHP, being compatible with the idea of a tight, service-oriented, modular design. I think you kind of have to choose one.

Oh sure, the initial code was pretty terrible. But by the time we were moving parts to Java it had all gone through a lesser or greater amount of refactoring; the best design is iterative and emergent, and we had the http://c2.com/cgi/wiki?WhatIsAnAdvancer experience several times over. In the early stages you really can iterate faster in not-java; as the correct design emerges and the codebase gets larger the interfaces tend to firm up, and at that point it becomes more reasonable to port pieces for performance.

Re: Java for Everything

#335

Post by koffiezet »

sandGorgon wrote: post #333
koffiezet wrote: post #332

Everything in Java? Thanks but no thanks. I understand the author's point, but he's choosing the wrong language. Does the perfect language for this purpose exist? No - sorry. I've been charmed by Go lately and replacing python, small C/C++ and shell-scripts with small tools written in it. It has great potential for services and small tools and has a surprisingly large amount of libraries available for it given the la…

can you talk about your jboss configuration ? We are thinking of building our API stack in java and are considering wildfly (undertow). Honestly, you are the first person who has talked about problems in Jboss and would appreciate some more info.

The problems aren't really JBoss related. I have very little problems with Wildfly itself. It is a clear improvement over previous versions, I had some problems with v7 which required me to upgrade the JSF modules, otherwise JBoss would suddenly die (in a crash & burn way) with a certain application we had.

It's mostly the "memory is not an issue" attitude most java devs have. It's not JBoss specific, we also have some services written in pure Java suffering the same problems - but the majority of the Java apps run in JBoss here. Stress tests in test/qa usually don't bring up the issues I've seen, which sometimes only occur after weeks of running flawlessly with production-grade loads.

The 'fix' is then running the critical apps twice behind a load balancer, waiting for one of the 2 instances to die (for logs/memory dumps), automatically restarting them - and hoping they won't go down simultaneously. Truth is - memory management in Java is HARD. When problems pop up, apparently finding the source of it is very difficult. I can't count the times I've heard "we think it should be fixed now", only to be confronted with another alert that the service died again a few weeks later. If it was one service we'd run, it would be fine, but we run quite a few more - resulting in weekly interruptions, tickets, sending of memory dumps to developers, convincing them - again - that it is their problem and not mine, ...

So well - I'm sick and tired of Java. The only thing worse to deploy and manage are Ruby apps. But that's a personal opinion.

Re: Java for Everything

#336

Post by edwinnathaniel »

lmm wrote: post #283
edwinnathaniel wrote: post #232

Earlier quoted context omitted.

I've been using Jersey since 2010 and I have never need to write my own annotation. Maybe I'm lucky enough that Jersey fills my need perfectly and maybe you're right that once I needed to write my own annotation, I may run into a bit of trouble (though some people do write annotation only to be consumed by reflection, hence bypassing the service file) but I guess... that's like.. what... 1-5% extreme use-cases? Like.…

> You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code). Sometimes you don't need i…

Hey, Thanks for your article. I've read that and I can see how/where Scala is useful!

I'm definitely going to learn Scala once my adventure in JavaScript world wrapped up.

Re: Java for Everything

#337

Post by markbernard »

pjmlp wrote: post #306
fsloth wrote: post #285

Earlier quoted context omitted.

"was told to "refactor" a fairly trivial 20-line method in one class into 8 separate classes each containing 1-line methods" How typical is this level of non-value adding misguided pedantism? I understand that big software consultancies would want to milk their clients for all the work they can for implementing function points. But what profitability models drive developers to this level of weirdness? Is it just a cu…

Enterprise. It is just how the enterprise world works.

No it is not. Just because you have a one bad experience, doesn't mean that is how the enterprise works. There are hundreds of thousands of enterprise shops out there. We don't do anything like the craziness you guys are talking about. We make it work with the easiest code possible. If necessary we refactor when we need to make a solution more generic.

Re: Java for Everything

#338

Post by emilburzo »

assertnotnull wrote: post #313

Sooo.. Why Paypal switched from Java to Node then? http://www.informationweek.com/cloud/software-as-a-service/p... BTW. I work with Java & GWT and I find it overkill for our needs. It took 5 months to make a 4 views, each with image or video grids and upload button. On the side. I have on my free time working with Django and have a website with Authentification, comments, categories... In the end, my personal project…

> BTW. I work with Java & GWT and I find it overkill for our needs. It took 5 months to make a 4 views, each with image or video grids and upload button.

I work with the same stack and don't understand what could have taken so much?

Or did you include time spent reading the docs?

Re: Java for Everything

#339

Post by organsnyder »

cdman wrote: post #242
x0x0 wrote: post #153

Earlier quoted context omitted.

one line is way more readable than 7 lines taking up valuable vertical and brain space it could also be accomplished with return -1 * o1.compareTo(o2);

No, you can't. In particular -1 * Integer.MIN_VALUE == Integer.MIN_VALUE.

That would probably never matter in practice, though—I've rarely seen compareTo() return anything other than -1, 0, or 1; certainly never anything approaching MAX/MIN_VALUE. Still, bravo for considering all of the edge cases.

Re: Java for Everything

#340

Post by igouy »

TheLoneWolfling wrote: post #197
waps wrote: post #158

Earlier quoted context omitted.

You forget just how much difference there is between languages. Comparing Python and Java for example, it's easy to find things that take 1-2 cpu cycles in Java (or even 0), that take thousands of cpu cycles in Python (e.g. function calls). http://benchmarksgame.alioth.debian.org/u32/python.php I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But look at those numbers we're talking 40-50 TIMES…

And yet there is a benchmark in that particular set you linked in which Python runs in 3/4 the time. Also, I don't like the CLBG - it removed PyPy and a bunch of other implementations of various languages. I would be intrigued to see the speed of PyPy on that particular set of benchmarks, for instance.

I would be pleased if you took the program source code and the measurement scripts and published your own measurements.

http://benchmarksgame.alioth.debian.org/play.html#languagex

But we all seem feel the same way about this, we all feel that we should sit on our hands and wait for someone else to do the chores we don't wish to do.

Post reply on HN