Is it possible to replace any java coding which I use daily with groovy or scala? E.g. writing small webapps which include servlets/portlets etc.
I've completely replaced my server side processing/data crunching that would previously be written in Java with Scala. It's made life a lot easier, and a lot more fun.
Small servlets for REST webservices written on top of Step (web pico "framework", it's a single code file, comically small servlet wrapper) http://github.com/alandipert/step. Scala's xml handling combined with a simple json outputter (I use Twitter's) makes this completely painless.
Hibernate + Annotations as my persistence layer (very painless once you've cleaned up the Hibernate's collection handling/types)
Various data crunching background tasks.
It's certainly possible, and a really simple transition to make. Just start writing Scala as if you were writing Java, at it's worst it's just Java but much less verbose. From there you can gradually pick up the Scala concepts over time: Options, functional concepts, closures etc.
I have been using Groovy for a few months now and find that it addresses a lot of the things that have been bothering me about Java for a number of years (handling collections, null pointers, verbosity). The principal is that you should be able to take your Java source file, rename it to .groovy and start converting gradually ... that isn't quite true because Groovy doesn't support inner classes, for loops with multiple loop variables, do..while, and character literals, but these are easy to fix.
Scala is the statically-typed alternative ... Bill Venners reckons it allows you to achieve the same as Java (with compile-time checking) in about half the number of lines of code. And Scala has the LIFT framework, which is less mature than Grails but still promising.
Both Groovy and Scala are worth exploring, and will (eventually) make you more productive.
I use Groovy all the time for utilities, both on the command line and on the web. Often, the utilities use jars/class files from my project, since it is all on the JVM.
For web utils, take a look at Groovlets. You can come up to speed with Groovlets in a couple of hours. A groovlet is simply a servlet distilled down to its essence.
If you need to persist state, Grails is a leading web framework (with a higher learning curve).
I don't know about portlets per se, as that is its own beast.
yes. both are compiled for the same VM, you can use Java classes in them. the programming language syntax is just sugar coating on the JVM bytecode, which is the same no matter what.
Related
What are the differences using spring boot with Kotlin and with Java?
Kotlin is among the three languages you could choose to start your app with https://start.spring.io. So it's supported by the spring boot team. I used it to develop some microservices and as far as I know everything went fine at the end but I would like to have some feedback from other developers because I try to convince my new team to start our new microservices in Kotlin.
Pros:
Null safety
Clearer code
Val over var
Cons:
Mockito not Kotlin friendly (I switched to mockk)
Code coverage was not out of the box (we had to develop our own plugin)
Risk to have Java moving faster than Kotlin
Since Kotlin is simply a dependency and plugin for Maven (that's it!). It's such a nice, compact, easy-to-grok language that removes all the syntactic fat (opposed to syntactic sugar) that Java provides.
From 5.0.0 onward Kotlin has first-class support from Spring, which effectively means it has all the same guarantees as Java in terms of code working correctly.
Kotlin itself has a ton of interoperability features to smoothly integrate with any already existing Java library, which means you have the same freedom of choice.
Kotlin's Java interop is amazing, and was by no means an afterthought by Jet Brains. Thus Kotlin works nicely with Spring, which provides a lot of the boilerplate functionality for web applications, especially Spring Boot.
These are some points which You already mentioned but I will still have a say about it. Kotlin has a much more compact syntax and its type system allows for much more robust code through null-safety, sealed classes, and immutable/mutable collection distinction, which together significantly reduce development time on any project.
The main difference is: with Kotlin, you're programming in Kotlin...with Java, you're programming in Java. Spring makes use of some languages features exclusive to Kotlin to streamline certain operations, but I wouldn't think you'd want to choose one language over the other just because of those few additional benefits. For the most part, there is no difference. Spring supports both languages well.
UPDATE: I guess I should add that Kotlin does introduce a few minor problems into the whole Spring thing, just because Spring is actually written in Java and was originally designed to be utilized via Java. But just like the pros you get with Spring and Kotlin, these minor negatives should likewise not dictate your choice as to which language to use.
I think what you should be asking is "which language should I use leaving Spring out of it?". My company is coding new modules in Kotlin because we consider it a significantly better language than Java. But we have lots of legacy Java code, and we've chosen to for the most part not mix languages within a single module, so we still code in Java too. You have to make your own decision. Decide what language you want to program in based on the language itself, and on your existing codebase, but not on how Spring works with it. Spring will work great with either.
There are many articles and blogs out there comparing the two languages, listing their relative pros and cons. I'd suggest that you read everything you can. There's no "right" answer here. (...which is why I know this question is going to be closed as being opinion-based). Try Kotlin. Heck, try Groovy and Scala too. "live" the pros and cons for yourself, and then decide what will work best for you.
BTW, you list "Risk to have Java moving faster than Kotlin" as a Con of Kotlin. I think the risk is in the other direction. Java moves very slowly compared to Kotlin and other alternative languages. That's why you see it playing catch-up...finally introducing features into the language that have been in the alternative languages for many years.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been a C++ developer for about 10 years. I need to pick up Java just for Hadoop. I doubt I will be doing any thing else in Java. So, I would like a list of things I would need to pick up. Of course, I would need to learn the core language, but what else?
I did Google around for this and this could be seen as a possible duplicate of "I want to learn Java. Show me how?" but it's not. Java is a huge programming language with lots, of libraries and what I need to learn will depend largely on what I am using Hadoop for. But I suppose it is possible to say something like don't bother learning this. This will be quite useful too.
In my day job, I've just spent some time helping a C++ person to pick up enough Java to use some Java libraries via JNI (Java Native Interface) and then shared memory into their primarily C++ application. Here are some of the key things I noticed:
You cannot manage for anything beyond a toy project without an IDE. The very first thing you should do is download a popular Java IDE (Eclipse is a fine choice, but there are also alternatives including Netbeans and IntelliJ). Do not be tempted to try and manage with vi / emacs and javac / make. You will be living in a cave and not realising it. Once you're up to speed with even basic IDE functions you will be literally dozens of times more poductive than without an IDE.
Learn how to layout a simple project structure and packages. There will be simple walkthroughs of how to do this on the Eclipse site or elsewhere. Never put anything into the default package.
Java has a type system whereby the reference and primitive types are relatively separate for historic / performance reasons.
Java's generics are not the same as C++ templates. Read up on "type erasure".
You may wish to understand how Java's GC works. Just google "mark and sweep" - at first, you can just settle for the naivest mental model and then learn the details of how a modern production GC would do it later.
The core of the Collections API should be learned without delay. Map / HashMap, List / ArrayList & LinkedList and Set should be enough to get going.
Learn modern Java concurrency. Thread is an assembly-language level primitive compared to some of the cool stuff in java.util.concurrent. Learn ConcurrentHashMap, Atomic*, Lock, Condition, CountDownLatch, BlockingQueue and the threadpools from Executors. Good books here are those by Brian Goetz and Doug Lea.
As soon as you want to use 3rd party libraries, you'll need to learn how the classpath works. It's not rocket science, but it is a bit verbose.
If you're a low-level C++ guy, then you may find some of this interesting also:
Java has virtual dispatch by default. The keyword static on a Java method is used to indicate a class method. private Java methods use invokespecial dispatch, which is a dispatch onto the exact type in use.
On an Oracle VM at least, objects comprise two machine words of header (the mark word and the class word). The mark word is a bunch of flags the VM uses - notably for thread synchronization. The class word you can think of as a pointer to the VM's representation of the Class object (which is where the vtables for methods live). Following the class word are the member fields of the instance of the object.
Java .class files are an intermediate language, and not really that similar to x86 object code. In particular there are lots more useful tools for .class files (including the javap disassembler which ships with the JVM)
The Java equivalent of the symbol table is called the Constant Pool. It's typed and it has a lot of information in it - arguably more than the x86 object code equivalent.
Java virtual method dispatch consists of looking up the correct method to be called in the Constant Pool and then converting that to an offset into a vtable. Then walking up the class hierarchy until a not-null value is found at that vtable offset.
Java starts off interpreted and then goes compiled (for Oracle and some other VMs anyway). The switch to compiled mode is done method-by-method on a as-need basis. When benchmarking and perf tuning you need to make sure that you've warmed the system up before you start, and that you should typically profile at the method level to start with. The optimizations that are made can be quite aggressive / optimistic (with a check and a fallback if the assumptions are violated) - so perf tuning is a bit of an art.
Hopefully there's some useful stuff in there to be going on with - please comment / ask followup questions.
Learning "just enough" Java is learning Java. Either you learn all the core principles and language design decisions, or you suffer along making easily avoidable mistakes. Considering that you already know how to program, a lot of the information can be skimmed (with an eye for where it differs from other languages you are intimately familiar).
so you need to learn:
How to get started
The language itself
The core, essential classes
The major Collections
And if you don't have a build framework in place, how to package your compiled code.
Beyond that, nearly every other item you might need to learn depends heavily on what you intend to do. Don't discount the on-line tutorials from Oracle/Sun, they are quite good (compared to other online tutorials).
Hadoop can use C++ : WordCount example in C++
You can't really use Java without knowing these packages in the standard API:
java.lang
java.util
java.io
And, to a lesser degree:
java.text
java.math
java.net
java.lang.reflect
java.util.concurrent
They contain a lot of classes you'll need to use constantly for pretty much any application, and it's a good idea to look through them until you know which classes they contain and what those are good for, lest you end up reinventing wheels.
Take it easy, learning Java could be
pleasant and fast if you already know
C++
Buy these two books:
The JavaTM Programming Language, (4th Edition) Ken Arnold, James
Gosling, Davis Holmes
Effective Java (2nd Edition), Joshua Bosh
You will soon be mastering Java, You will not regret. Good Luck.
Since C++ and Java share common roots, the core language shouldn't give you too much trouble. You will need to become familar with the java SDK, particularly java.lang and the Collections framework (java.util.)
But perhaps learning java is overkill if you don't see yourself using it elsewhere. Hadoop also has bindings to Python - perhaps learning python would be a better alternative? See Java vs Python on Hadoop.
Here is the quickstart for all you will need
I suggest Eclipse (java) to start working, see this for that
Maybe you don't even need to know Java to use Hadoop.
Pig is far enough from simple to advanced usage of Hadoop.
I don't know how familiar are you with other higher level programming languages. Garbage collection is an important function in Java. It would be important to read a bit about the GC in your VM of choice.
Besides the obvious packages, check out the java.util packages for the collection framework. You might want to check out the source of some classes. I suggest HashMap to get the idea of the computing/memory cost of these operations.
Java likes to use streams instead of buffers when processing large amounts of data. That may take some time getting used to.
Java has no unsigned types. Depending on the packets of data you need to process at once you can either use larger variables and streight arythetics (if we're talking about relatively small packets), or you have to (b[i] & 0xff) every time you read for example unsigned bytes. Also note that Java uses network byte order (msbf) when serializing multibyte numbers.
The most beloved design patterns by the API are Singleton, Decorator and Factory. Check the source of JFC itself for best practices, how these patterns are achieved in the language.
... and you can still post more concrete questions on SO :)
Answer 1 :
It is very desirable to know Java. Hadoop is written in Java. Its popular Sequence File format is dependent on Java.
Even if you use Hive or Pig, you'll probably need to write your own UDF someday. Some people still try to write them in other languages, but I guess that Java has more robust and primary support for them.
Most Hadoop tools are not mature enough (like Sqoop, HCatalog and so on), so you'll see many Java error stack traces and probably you'll want to hack the source code someday
Answer 2
It is not required for you to know Java.
As the others said, it would be very helpful depending on how complex your processing may be. However, there is an incredible amount you can do with just Pig and say Hive.
I would agree that it is fairly likely you will eventually need to write a user defined function (UDF), however, I've written those in Python, and it is very easy to write UDFs in Python.
Granted, if you have very stringent performance requirements, then a Java based MapReduce program would be the way to go. However, great advancements in performance are being made all of the time in both Pig and Hive.
So, the short answer to your question is, "No", it is not required for you to know Java in order to perform Hadoop development.
Source :
http://www.linkedin.com/groups/Is-it-must-Hadoop-Developer-988957.S.141072851
Most of the stuff should be pretty familiar to you. I'd just download eclipse and google a tutorial site. Familiarize yourself with classloading, keywords. One tricky thing a lot of C++ guys run into is how to run a java app so that it finds its library classes(sort of analogous to dynamic linking). Learn the difference between the JRE and JDK. If you can get a few hello world type apps working you ought to be able to get a start on hadoop if you follow the tutorials.
You dont need to learn java to use hadoop.
You need to know linux to installand configure hadoop
then you can write your map reduce jobs using the stream line api on any language which understand standard input/output
further you can do more complex map reduce using other libraries like hive etc
even other components of hadoop like hbase/ cassandra also has clients on most of the languages
I have some batch data-manipulation scripts which support a small business website.
The scripts are a "rat's nest" of Perl, Java, and Stored Procedures, which run on a scheduled basis to update data based on various sources and algorithms.
I want to get rid of the Perl so that I can at least take advantage of transaction management by containing the entire process in a JVM-managed database connection from start to finish.
Which of the various Java dynamic/scripting language should I leverage which will meet the following criteria:
Straightfoward to migrate Perl code by providing similar expressive power, I/O, regex's, etc.
Good IDE support, including code completion and debugging preferably in Eclipse
Easy to install. Preferably the entire scripting engine should be in a single jar file.
Not an orphaned technology. I want to pick something that will still be around in 5 years.
Of course - clean integration with the rest of the Java code that I already have.
I hope my criteria are clear enough that this does not get tagged as a subjective question.
For me this is definitely a programming question. I see all those languages as just "useful java libraries".
Thanks!
To be fair, Jython, JRuby, Groovy would all be good choices. They all have the decent IDE support, and the syntax is as expressive, and more succinct than Perl. (Python and Ruby both owe a debt to Perl in their conception, so porting from Perl isn't too much of a headache)
Of course, Beanshell and Javascript (in the form of Rhino) will be adequate too, although I'd say that both their syntaxes are less expressive.
Judging on current usage trends, I'd say Jython and then JRuby would probably be the two with the most general support / longevity, in relation to the others.
Really the choice comes down to your level with each of these languages, but of all of them I'd suggest you use Jython, but if your more comfortable with Ruby, JRuby.
I vote Jython since it can interact with existing Java code and it's got a strong support base. Not mention its Python which is easy to learn and use. Eclipse has pretty good support for syntax highlighting, debugging, and auto-complete. Finally the install is super easy since it's a stand alone folder (no real "install").
I'll admit bias since I have used the other tools you mentioned much less than I have Jython but I have not needed to since Jython has fit the needs so well.
I should say that that several benchmarks indicate that Groovy is wins in speed, compared to Jython and BeanShell. The test was performed using DMelt (http://jwork.org/dmelt) framework where you can jump from one language to another, calling same Java libraries.
I want to move a legacy Java web application (J2EE) to a scripting language - any scripting language - in order to improve programming efficiency.
What is the easiest way to do this? Are there any automated tools that can convert the bulk of the business logic?
Here's what you have to do.
First, be sure you can walk before you run. Build something simple, possibly tangentially related to your main project.
DO NOT build a piece of the final project and hope it will "evolve" into the final project. This never works out well. Why? You'll make dumb mistakes. But you can't delete or rework them because you're supposed to evolve that mistake into the final project.
Next, pick a a framework. What? Second? Yes. Second. Until you actually do something with some scripting languages and frameworks, you have no real useful concept of what you're doing. Once you've built something, you now have an informed opinion.
"Wait," you say. "To do step 1 I had to pick a framework." True. Step 1, however, contains decisions you're allowed to revoke. Pick the wrong framework for step 1 has no long-term bad effects. It was just learning.
Third, with your strategic framework, and some experience, break down your existing site into pieces you can build with your new framework. Prioritize those pieces from most important to least important.
DO NOT plan the entire conversion as one massive project. It never works. It makes a big job more complex than necessary.
We'll use Django as the example framework. You'll have templates, view functions, model definitions, URL mapping and other details.
For each build, do the following:
Convert your existing model to a Django model. This won't ever fit your legacy SQL. You'll have to rethink your model, fix old mistakes, correct old bugs that you've always wanted to correct.
Write unit tests.
Build a conversion utility to export old data and import into the new model.
Build Django admin pages to touch and feel the new data.
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
Plan your URL's and view functions. Sometimes, these view functions will leverage legacy action classes. Don't "convert". Rewrite from scratch. Use your new language and framework.
The only thing that's worth preserving is the data and the operational concept. Don't try to preserve or convert the code. It's misleading. You might convert unittests from JUnit to Python unittest.
I gave this advice a few months ago. I had to do some coaching and review during the processing. The revised site is up and running. No conversion from the old technology; they did the suggested rewrite from scratch. Developer happy. Site works well.
If you already have a large amount of business logic implemented in Java, then I see two possibilities for you.
The first is to use a high level language that runs within the JVM and has a web framework, such as Groovy/Grails or JRuby and Rails. This allows you to directly leverage all of the business logic you've implemented in Java without having to re-architect the entire site. You should be able to take advantage of the framework's improved productivity with respect to the web development and still leverage your existing business logic.
An alternative approach is to turn your business logic layer into a set of services available over a standard RPC mechanisim - REST, SOAP, XML-RPC or some other simple XML (YAML or JSON) over HTTP protocol (see also DWR) so that the front end can make these RPC calls to your business logic.
The first approach, using a high level language on the JVM is probably less re-architecture than the second.
If your goal is a complete migration off of Java, then either of these approaches allow you to do so in smaller steps - you may find that this kind of hybrid is better than whole sale deprecation - the JVM has a lot of libraries and integrates well into a lot of other systems.
Using an automated tool to "port" the web application will almost certainly guarantee that future programming efficiency will be minimised -- not improved.
A good scripting language can help programming efficiency when used by good programmers who understand good coding practices in that language. Automated tools are usually not designed to output code that is elegent or well-written, only code that works.
You'll only get an improvement in programming efficiency after you've put in the effort to re-implement the web app -- which, due to the time required for the reimplementation, may or may not result in an improvement overall.
A lot of the recommendations being given here are assuming you -- and just you -- are doing a full rewrite of the application. This is probably not the case, and it changes the answer quite a bit
If you've already got J2EE kicking around, the correct answer is Grails. It simply is: you probably already have Hibernate and Spring kicking around, and you're going to want the ability to flip back and forth between your old code and your new with a minimum amount of pain. That's exactly Groovy's forte, and it is even smoother than JRuby in this regards.
Also, if you've already got a J2EE app kicking around, you've already got Java developers kicking around. In that case, learning Groovy is like falling off a ladder -- literally. With the exception of anonymous inner classes, Groovy is a pure superset of Java, which means that you can write Java code, call it Groovy, and be done with it. As you become increasingly comfortable with the nicities of Groovy, you can integrate them into your Java-ish Groovy code. Before too long, you'll be writing very Groovy code, and not even really have realized the transition.
After discovering Clojure I have spent the last few days immersed in it.
What project types lend themselves to Java over Clojure, vice versa, and in combination?
What are examples of programs which you would have never attempted before Clojure?
Clojure lends itself well to concurrent programming. It provides such wonderful tools for dealing with threading as Software Transactional Memory and mutable references.
As a demo for the Western Mass Developer's Group, Rich Hickey made an ant colony simulation in which each ant was its own thread and all of the variables were immutable. Even with a very large number of threads things worked great. This is not only because Rich is an amazing programmer, it's also because he didn't have to worry about locking while writing his code. You can check out his presentation on the ant colony here.
If you are going to try concurrent programming, then I think clojure is much better than what you get from Java out of the box. Take a look at this presentation to see why:
http://blip.tv/file/812787
I documented my first 20 days with Clojure on my blog
http://loufranco.com/blog/files/category-20-days-of-clojure.html
I started with the SICP lectures and then built a parallel prime number sieve. I also played around with macros.
What project types lend themselves to using Java over Clojure, vice
versa, or in combination?
A project where a GUI-building tool
(such as Matisse in Netbeans) is
needed would be a case where Java may
still be required. Anything done in
Java can be done in Clojure quite
readily, with proxy and gen-class if
needed, or just accessing Java as
needed (., doto, new, etc.). This
allows Clojure projects to easily use
Java libraries or legacy Java code.
Which programs which you would have never attempted before Clojure ?
Before I found Clojure, I was
contemplating a project that required
JDBC, would run in a servlet
container, and I anticipated doing a
lot of iterative development because
it wasn't clear what methods would
work for the data I needed to analyze.
I put it on the back burner because I
didn't have the time or patience for
the compile-debug- deploy-validation
cycling that Java requires. I've now
written the application in Clojure,
and I'm very pleased at the ease of
making changes on the fly and being
able to examine the results
immediately. Not to mention the joy
of lock-free programming and being
liberated from having to develop (and
refactor) class hierarchies.
- "MikeM" via the clojure#googlegroups.com mailinglist
What project types lend themselves to Java over Clojure, vice versa, and in combination?
If you want to develop a framework that is to be consumed by Java and Clojure, I've found writing the main abstractions (interfaces ad base classes) in Java to be preferable over writing them in Clojure (I find Clojure's gen-class to be somewhat tedious and rather use proxy).
If you're a user of Hibernate or any other framework that makes heavy use of Java-annotations without offering a programmatic alternative, you'll have some trouble, since it's not trivial to emulate annotated POJOs with Clojure's data structures.
Apart from that, I've experienced no use cases for which Clojure is less appropriate than Java; you have to cope with the loss of static typing, of course, which feels somewhat disconcerting at first, but tends to go away.