4 ms·
Some context would help, since it depends on what you already know, what your longer term goals are, and how you think learning Java will help you achieve that.
by patio11 13y ago
Some context would help, since it depends on what you already know, what your longer term goals are, and how you think learning Java will help you achieve that.
Some reasons in favor of learning Java: it's an incredibly entrenched technology in a wide variety of industries, and it will be running incredibly valuable line of business code for long after both of us are dead. The language itself is competent and C-style, and it handles memory management. The JVM is a wonderful platform. The Java ecosystem interoperates with everything, has copious developers available no matter your region/price point/industry/desired level of experience, and has a vibrant community which has libraries available for whatever you'd want to do.
Reasons against: I'll spare everyone the "Good God man, it's Java." (Though, having cut my teeth on it and used it professionally for most of my career, they're not totally wrong.) Mostly, my concerns would be directed at "Is learning a new programming language really the highest priority for you given your particular goals?" Learning the syntax will only take you a few weeks (assuming you've programmed before), but getting conversant with e.g. the J2EE stack is a multi-year project, and there are many things you could accomplish in the same time which would be more intellectually rewarding/credibly promise more career growth/etc.
- a8da6b0c91d 13y ago> The JVM is a wonderful platform. The Java ecosystem interoperates with everything I hear this over and over but it never strikes me as true. The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. There's typically some slower and less comprehensive library for Java or .Net.
- w0utert 13y agoI also don't fully agree with the statement that Java (or other JVM based languages) is the pinnacle of interoperability. Try interfacing between e.g. Python and Java some time and you know what I mean. Besides JNI or some other JVM based language, interfacing between Java and something else basically means doing some form of IPC, which isn't fun.
- huherto 13y agoFor enterprise applications usually you would use REST. And that is pretty easy, almost automatic.
- notoriousjpg 13y agoCan you expand on this? I've never seen this opinion before. I would have guessed rest is too loosely defined for the structural rigidity of most enterprise applications?
- sannysanoff 13y agoThere's no need to interface cpython and java. Looks like jython is already faster than cpython, so just use it, interface is ok.
- justincormack 13y agoThen you can't use C libraries with it.
- memracom 13y agoIf you do interoperability right, then you would use Apache Camel which interoperates effortlessly with everything including Python. The right way to interoperate between tools in different languages on different VMs, is to use something like AMQP or ZeroMQ both of which are supported in Camel and in Python. Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on.
- w0utert 13y ago>> Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on. I don't even understand what you are saying here. Are you implying that if I have a Python application and a Java library that solves some very specific part of what the application does (say, applying some very complex algorithm to a few numbers, or decode some arcane undocumented file format), that I should use something that sells itself as: Apache Camel ™ is a versatile open-source integration framework based on known Enterprise Integration Patterns. Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL. This means you get smart completion of routing rules in your IDE, whether in a Java, Scala or XML editor. Because 'the standards of software engineering have moved on'? Not everyone is building large-scale enterprise software running on clouds of servers or whatever you have in mind. I can make up a million examples of pieces of software that perform only one single one-shot task (like a command line script) that may want to call out to some external library that implements some part of what the script is supposed to solve, and for those kind of applications, 'the standards of software engineering' should not have to dictate I have to use message queues or a versatile open-source integration framework based on known Enterprise Integration Patterns, amirite? If that library I need to call is written in Java and I need to call it from Python or some other non-JVM language (or even C/C++ because JNI is a pain in the ass as well), I'm SOL :-S
- sannysanoff 13y agojava and C are strong in different areas. I would rather say that choice of C libraries for enterprise or just for any useful web backend is poorer than for java ;)
- a8da6b0c91d 13y agoThe only thing Java is tier one for is shoveling around XML/HTML and talking to databases. As soon as you leave that CRUD territory and need to work more seriously with algorithms or have high performance requirements, the available stuff is second tier. Off the top of my head, consider computational geometry. CGAL and boost.geometry are amazing. JTS is very slow and missing a lot. It's the same thing over and over with many sorts of libraries.
- pjmlp 13y agoSo why are the banks moving to Java and .NET for real time transactions? https://github.com/LMAX-Exchange/disruptor https://github.com/LMAX-Exchange/disruptor
- profquail 13y agoWell-designed libraries usually trump poorly-designed libraries, performance-wise, regardless of which language they're implemented in. C++ isn't a magic bullet; it's plenty easy to write bloated, poorly-performing software in C++, just as it is in Java, C#, Ruby, etc. Here's just one counterexample to your claims: http://stackoverflow.com/questions/4257659/c-sharp-versus-c-performance/19505716#19505716 http://stackoverflow.com/questions/4257659/c-sharp-versus-c-...
- guard-of-terra 13y agoC++ library would crash your process or ruin your threading. Java one won't. Interfaces tend to be more stable. For complex things like Excel parsing Java is the way to go.
- justincormack 13y agoThats not an answer to the question about interoperability. Java/C interop is a complete pain so the world is divided into two, C (native) libraries, which the non JVM languages can mostly interop with, and the JVM libraries that JVM languages can use. Most stuff is implemented eventually twice.
- zaphar 13y agoJava libraries can ruin your threading too. Java doesn't magically make everything you write threadsafe.
- guard-of-terra 13y agoYou can guard against that. In Java, making things thread-safe is usually straight-forward. Java libraries tend to mis-handle classloader recycling, but most projects can ignore that.
- memracom 13y agoA lot of people are using the word "interface" to mean sticking two bits of object code together with the compiler and linker. In plain English, the word "interface" covers a lot more than that specific technique. Even most Java developers make a distinction between what the "interface" keyword does, and the broader CS term "interface". Why on earth would you want to stick some C code (or God forbid, C++ code) inside the same process as the JVM? If you control the OS, there are better ways to do the same thing with two separate proceses. And even if you don't control the OS, we do have techniques (most of them implemented inside Apache Camel) for hooking up a Java process and some other kind, without sharing bodily fluids. Apache Camel is safe hex, use it!
- 13y ago
- tspike 13y agoAdditionally, Unicode is a nightmare in Java.
- pjmlp 13y agoDid you ever tried it in C and C++?
- thousande 13y agoMozilla's HTML5 parser is written in Java. One of the reasons java was chosen was the unicode support [1] The Java code is converted to C++ in build time I think [2] [1] https://news.ycombinator.com/item?id=6204760 https://news.ycombinator.com/item?id=6204760 [2] http://ejohn.org/blog/html-5-parsing/ http://ejohn.org/blog/html-5-parsing/
- pjmlp 13y ago> The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. Where are the enterprise C and C++ libraries and server stacks? The enterprise is all about Java and .NET nowadays.
- danieldk 13y agoThe best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. I think it differs hugely per case. E.g. there are not great C++ or C libraries that provide functionality of Akka, Guava, or Java persistence. On the other hand, nothing in Java-land beats Qt, Cocoa, or Eigen. But I agree on interoperability. Interoperability within JVM-land is pretty great. But it is far easier to write a good binding for a C library in e.g. Python, Ruby, Go, or Haskell, than it is in JNI.
- revetkn 13y ago> I'll spare everyone the "Good God man, it's Java." I always get a kick out of this. If someone says a language's expressiveness is one of her biggest pain points, she probably is not working on anything significant. There is a reason that so much Java is used in Google, Amazon, etc. Performance, maintainability, tooling, and ecosystem are more important than whether or not you have anonymous inner classes vs. true language support for closures. J2EE, like Applets, gave Java a bad name. And Spring has become more complex and nasty than J2EE ever was. Java sucks when you have to deal with those environments. But if you use a modern Java stack - Jersey, Jetty, Guice, Guava, etc. - it is a pleasant experience.
- iends 13y agoIs there any good material on learning the modern Java stack? I know Java SE from using it quite a bit in college, but it seems beyond that everything is geared towards JEE.
- kamaal 13y ago>> There is a reason that so much Java is used in Google, Amazon, etc. There is a reason why some companies are still running COBOL, C++ or even FORTRAN. Replacing them en masse is expensive, and often you can hire cheap labor and throw some bare minimum funding to keep those systems up and running, until there is no business case to keep them running any more. When these companies started up, Java was the latest tool that gave tremendous productivity benefits over C++. Newer tools have arrived, now and Java is in the same place as C++ was. And just like how it doesn't make business sense to re write old legacy systems in new languages. It also doesn't make business sense to write new systems in older languages. Choose where you want to be.
- revetkn 13y ago> When these companies started up, Java was the latest tool that gave tremendous productivity benefits over C++. Newer tools have arrived, now and Java is in the same place as C++ was. Which languages/tools give tremendous productivity benefits over a modern Java stack? Serious question. I have done a lot of work in a lot of different environments and IMO for the big and maintainable things it's hard to top the Java ecosystem. (edit: I do agree with you - it is ridiculous to rewrite enormous legacy systems. But I don't think there's a clear-cut order-of-magnitude-better replacement for Java yet)
- mtshadow 13y agoIt maybe more appropriate to ask, should I have a portfolio of Java applications/solutions to interesting problems. Learning the pitfalls of a language is undoubtedly useful and I would argue that learning the process of project start-up, testing, maintenance and deployment would perhaps put you in a much more valuable position for learning.
- kamaal 13y ago>>it will be running incredibly valuable line of business code for long after both of us are dead. Good for Java, bad you us as a career option. Unfortunately the more entrenched it is the more legacy projects you get to work on. The new things, the important things, sort of things which people are ready to invest big money on will happen in some other stack. I know of a few friends of mine who've so far worked mostly on COBOL their whole career so far. Through COBOL is still pretty much in use, they have problems getting into good projects, switching jobs, getting good compensation. People seem to look legacy stacks like a burden they need to carry on unwillingly. So tend to provide the bare minimum funding to keep it up and running. Most of the times they are only running, until something better is found to replace them. Learn Java if you want. You will still get a job, but you shouldn't be surprised if something like scala has more interesting projects, good money and better opportunities. This happens with all technology. As with these things, the sooner you adapt to something- the better.