Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm versed in Java, and starting to experiment with Groovy.
Because the two are integrated so well, I find myself writing in Java whatever I can because it's so easy. What specific tips can you offer that would speedup my work with Groovy?
Meaning - in what areas do groovy excel over java, and where should I stick to Java?
Some of the main things I like groovy for:
testing is probably the biggest win. The ability to change behavior at runtime and mock out methods is one of the greatest things about groovy. Convert your test suites to groovy now!
use the builders. Groovy builders have so much more expressiveness than traditional java. In particular, the MarkupBuilder for embedded snippets of XML or HTML is 1000s of times nicer to use than vanilla java
GPars if you're doing any sort of concurrent programming or threading
Also see Hidden features of Groovy and Why would one use Groovy over Java (note: was "removed from Stack Overflow for reasons of moderation").
Where I'd stick with java:
any place where speed really matters, stick with java. You still pay a high cost in performance for groovy's dynamic nature.
The problem with Groovy.
Groovy is a write-easy, but maintenance-nightmare. In my opinion, it should not be used in large projects. Inheriting somebody else's (or your own) code can be problematic, because very often you have no clue of the type of a variable, so you have your due diligence to find out, or use assertions to guarantee the incoming type to a method.
Groovy is a weak-typed language. The type of a variable is frequently ignored, or "conveniently" cast automatically, which leads to many bugs and slower performance.
Even the bests IDE's are lacking, because the practically typeless variables of the language. In many cases the compile just can't know what is the type of a variable. Even if you declare the type of a variable (which helps the editor to make suggestions), many programmers forget to define the variables type.
It has interesting ideas that I would love to see in Java, but stay away from it if your Groovy code will require more than a thousand lines.
* The answers in a nutshell *
Summarizing, here are the answers to both questions:
What specific tips can you offer that
would speedup my work with Groovy?
Use it only for small stuff. Otherwise, you will incur in technical-debt (see the Wikipedia). So far I'm in similar situation. Unit testing, using the console to test pieces of code, etc., are things that will speed up your development, since it's so easy to learn and use. Be sure to master closures, collections, and looping, and to understand what Java features are not available in Groovy.
Don't use pure Groovy for complex or large applications. In the long term the maintenance will slow you down.
Meaning - in what areas do groovy
excel over java, and where should I
stick to Java?
In a large or critical project you need to keep yourself disciplined and use dependable tools. It's like building a house: I are build a doll house, Groovy is fine :-) ... if it's not perfect, it's no biggie. If you build your own house or something bigger with little tolerance for error, you need to use quality tools and materials of better quality that don't let you oversee potential problems (Java, for example).
In any case, Groovy is like duck tape: some here and there may do no harm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been doing web application development for the last 3 years in PHP. I'm now on the verge to give Java a go. My last use of the language was nearly 8 years ago and was mostly academic.
I'm reasonably well acquainted with PHP's object model (version 5) and I have almost exclusively been coding in OO. I would now like to transport that experience and use it to develop in Java.
Where I'm coming from:
linux as a desktop and server
Vim/gVim + plugins as an editor
MySql for db
apache httpd
experience with a bunch of PHP frameworks, Zend+Doctrine being the ones I use most
What I've garnered so far about a move to Java:
I need an IDE: IntellijIDEA, NetBeans or Eclipse
I need to pick a development framework. Some recurrent names: Spring MVC, stripes, wicket.
Now I need some insight that could help make this transition smoother. But from the way people talk about it, Java seems to be an entirely new beast with its own ecosystem. It sounds as though moving to Ruby or Python would actually be easier, which is curious since, when I look at it, Java conceptually seems the closest to PHP, albeit stricter and precompiled.
As weird as this may sound, very few people have publicly documented their experience of such moves. I have searched google, amazon and stackoverflow for similar questions and the results leave to desire. I just can't believe that I would need to start the same as a newbie if I wanted to be productive as a web developer in Java fast.
Anybody is welcome to respond, but I somewhat think that people with some valuable experience in both languages would enrich this discussion the most.
What helped you get going quickly in Java?
What concepts are omnipresent in Java and absent from PHP and vice versa?
Some gotchas for PHP developers going Java.
How long before you felt the transition was complete?
I wouldn't try to learn an IDE at the same time as learning a language. An easier transition would be to stick to your shell and habitual text editor, and use the following shell-friendly tools:
ant, for organising your project, running automated test suites, incremental compiles
BeanShell for interactive testing, trying things out quickly
A quick trick: javap from the commandline will give method signatures for any class in the standard library. Similar to php -r but gives more information since Java is typed.
The online documentation for Java is precise, professional, and consistent in tone and format. Unlike in PHP where all of the functions are in one flat namespace, the standard libraries in Java are class hierarchies. You've got to know your way around that standard library, which means knowing hierarchies + responsibilities: for example you've got to know that java.util.List is a subinterface of java.util.Collection with the addition of a concept of ordered entries. With that information in your head, a google search for java.util.List will take you to the Javadoc for the class, and the Javadoc will tell you exact method signatures and link you to a selection of concrete implementations.
Some miscellaneous distinctions:
Strings are sequences of characters rather than sequences of bytes. Absolutely the right way of doing it.
Systems produce and consume streams (of bytes or characters) rather than byte buffers. For example, if you wanted to filter the output in PHP, a standard practice is to ask ob_get_contents for a byte buffer then to transform the whole buffer. In Java, you add a filter to your servlet that transforms the output a byte or a character at a time. It's a bit imposing to work with initially but it's simpler and more Lego-like when you get used to it - your stream processor doesn't have to know where things come from and where they go.
Almost everything useful is an interface, and creating an instance of an interface can be tricky, non-standardised, and not always well-documented. In PHP, you can get up and running with XML with new DOMDocument(). In Java, org.w3c.dom.Document is an interface, so new() won't work. Javadoc is very precise about how interface instances behave once they come into existence, but it can be quite coy and prudish when you're trying to find out how an object is actually born. Very often, you'll have to look for tutorials and code examples and copy-paste a piece of boilerplate that gives you an instance of DOMDocument or java.sql.Connection or whatever. One reason frameworks like Spring are popular is that they separate out the ugly object-creation code and present you with a world where interface implementations are just magically there.
I actually switched in the opposite direction. I found that Java works very well in a large company where you might be working on a single component, handing it off to someone else who integrates that component into a larger system, which is then packaged and handed off to a separate operations team - that's where all this indirection and configurability (FactoryBuilderFactory type abstractions, web.xml files, etc) makes sense and does something useful. In a small company where the programmers are the ops personnel, Java is a lot more work. With Java, you'll have to get used to concepts like starting up the Java process, monitoring the Java process to make sure it stays up, monitoring the Java process to make sure that it doesn't go into a coma where it's alive but not responding, shutting down and restarting the Java process with minimal disruption when you're updating code, etc, etc. If you have separate ops personnel, that's fine, it's their job, they're very good at it. If you're a programmer, babysitting a Java process can be distracting and difficult to do well.
Start with the Java Tutorial
http://java.sun.com/docs/books/tutorial/getStarted/index.html
Then go buy Head First Java
http://oreilly.com/catalog/9780596004651
It will get you going pretty quickly in the language which is essential regardless of what you want to do.
Strictly speaking, you don't need an IDE to work in Java. I've been coding heavily in Java for well over a decade (and heavily on other stuff for over 25 years), and I don't much like IDEs. Perhaps that implicit indicator of my age is part of the issue :-) It's a trade-off, like anything else.
I'll plug Stripes as a nice simple framework, but mostly that's because it's relatively small and limited in scope. The large frameworks like Spring are "kitchen sink" ecosystems, and learning Java with one of those frameworks may smooth some of the difficult parts but leave other basic aspects mysterious. Again, it's a matter of personal preference.
It's good to have somebody around who knows the language. Oh, and to that point, make a friend of the Java API documentation. As platforms go, the Java API has its ups and downs but for the most part the documentation is at least pretty thorough and pretty accurate.
You'll also want to get really familiar with JSP and its relationship to Java and Java web service architectures, because that'll be what you'll relate to your PHP experience most directly (I'd think).
The best move I made was from Java to PHP.
Beware of complexity. Primarily, the key to great software is simplicity, and that is why PHP combined with a good framework kills Java.
With Java, you risk becoming a slave to your servlet container and framework. Choose the simplest most flexible framework. Controls and custom tags are the devil. You'll waste days learning things that were designed to make development quicker, but are ultimately too complex and inflexible. Java will slow development due to: complexity, compilation, and static types. You'll come to loathe null pointer exceptions.
Edit: Tools aside, Java and PHP are very similarly structured "C" style languages. Much more so than Python or Ruby. It is the static typing and complex tools that make Java so foreign.
I recommend hitting up JavaBat at here
It will give you some good ideas. It took me 1 solid year in a professional setting to get a very firm grasp on Java and I have been able to move into other OO languages quite easily once I had the thoughts beaten into me.
This appears to be a bit of an old post, but hey...
I moved from C# to Java and I've just started a role and am moving from Java to PHP...
First off: Java is awesome :)
for your IDE get Eclipse, once you get used to it, you never have to leave the IDE (apart from SQL bits). It manages projects really well, you can download alsorts of plugins, such as SVN plugins. It allows you to run a Tomcat server within Eclipse and it will output errors straight to the Eclipse console.
for the framework, I used Struts and Tiles and Torque for the ORM, took me a while to get my head around them, but once we made friends, I can't imagine any other way of developing. Although I imagine for a small project it would be a lot of overhead!
agreed with an above post - get HEADFIRST JAVA, thats how I learnt and I used it for lots of other languages, they have a visual method of learning thats alot easier than pure textbooks - well for me anyway. I was up and running with in a day and confident within a couple of weeks I guess - but always learning :)
yip Java is strict, but you come to love it, for me moving to loose 'ol PHP is a bit wierd.
you will also need to download Tomcat to run your Java bits, its easy as to get running.
Java organises all your classes very nicely, none of this 'require_once(some_text_file.php)' rubbish, just 'import myClass' and off you go.
one of the things that annoys me is, there is no way of telling which JAR libraries you are NOT using, so after a couple of years working on a site, your lib folder can get a bit messy - specially if mulitple people are removing and adding functionality.
I could go on.
Paul
For my case, I only dealt with lot of procedural coding on the php, so jumping to Java, not only did I find everything to be more verbose and less forgiving than php (but now I know why it must be this way, and I love Java a lot) but learning to organizing my code in classes and also learning the eclipse IDE took about 1.5 years of just tinkering, trial & error, making stuff on my own (mainly swing applications).
I guess just creating stuff on your own, utilizing the vast amount of Java libraries out there to build your own stuff is fun is the fastest way. Also I think I could've saved more time by reading the java sun tutorials thoroughly. Even more time saving is making sure you've done a thorough search for libraries that prevent "reinventing the wheel".
Good luck!
I have an application written in C++ (makes heavy use of templates) that I need to take to the Java ME platform.
I have two questions:
Are there any good tools to convert C++ code to Java - do some basic stuff so I have a platform to start with. I found this - http://tangiblesoftwaresolutions.com/Product_Details/CPlusPlus_to_Java_Converter_Details.html. It would at least eliminate the need for simple but time-consuming stuff like moving classes to different files, namespaces to packages, etc. Has anyone tried it? Or knows of any better ones?
The bigger problem is how to deal with templates - the code makes very heavy use of them. Any suggestions on how to go about this? Are there any tools to expand templates for instance so I have a rudimentary base and then I could work on writing the modules in Java?
Any help would be appreciated.
For all of Sun's marketing, Java is not simply a better C++, and in fact does not support many of the idioms and paradigms C++ supports. This makes automated translation difficult. How should you automatically turn a multi-inheritance hierarchy into Java's single inheritance hierarchy? (Note, I am not saying that a multi-inheritance hierarchy is a good thing, only that it is explicitly allowed in C++). More fundamentally, how would you represent a pointer-to-member function in Java? Or handle the differences between Java and C++ overload resolution?
Java added generics a few years ago, but purposely made them less powerful than C++ templates. Regardless of whether that was a good idea, it limits what automated translation can do with heavily templatized code.
Aside from using some research compiler that can turn C++ into Java bytecode, I'm afraid you may be stuck doing the translation by hand.
Can you use JNI and call the old C++ code from the new Java code?
I think for your case a very simple tool would be possible and perhaps worthwhile. Might be a fun weekend-job, though! A friend of mine once did a port from C++ to Java and he just made a list of regular expression substitutions. Like, he had all occurrences of -> replaced by a dot. And so forth. This was some years ago, however, so I don't really feel like asking him.
So, you could do the same, collect some easy substitutions and perhaps publish them somewhere on github?
Generics is the Java feature that corresponds to C++ templates and they are not supported in J2ME. You can use them with the aid of a framework, which probably uses pre-processing to do the trick. (Actually Generics in Java is a compiler feature - the JVM knows nothing about them.)
Anyway, it will be difficult if not impossible to automatically port even a small portion of your code form C++ to Java Standard Edition - things are much worse with J2ME. There are many and important differences between Java Generics and C++ templates.
I don't think it's going to be possible, esp. if your original code is heavily templatized - J2ME doesn't support generics, AFAIK.
Unfortunately, it seems like this will require a lot of manual work to go through the original code and rewrite it (I'm assuming your target platform doesn't support JNI)
I'm developing a LoB application in Java after a long absence from the platform (having spent the last 8 years or so entrenched in Fortran, C, a smidgin of C++ and latterly .Net).
Java, the language, is not much changed from how I remember it. I like it's strengths and I can work around its weaknesses - the platform has grown and deciding upon the myriad of different frameworks which appear to do much the same thing as one another is a different story; but that can wait for another day - all-in-all I'm comfortable with Java. However, over the last couple of weeks I've become enamoured with Groovy, and purely from a selfish point of view: but not just because it makes development against the JVM a more succinct and entertaining (and, well, "groovy") proposition than Java (the language).
What strikes me most about Groovy is its inherent maintainability. We all (I hope!) strive to write well documented, easy to understand code. However, sometimes the languages we use themselves defeat us. An example: in 2001 I wrote a library in C to translate EDIFACT EDI messages into ANSI X12 messages. This is not a particularly complicated process, if slightly involved, and I thought at the time I had documented the code properly - and I probably had - but some six years later when I revisited the project (and after becoming acclimatised to C#) I found myself lost in so much C boilerplate (mallocs, pointers, etc. etc.) that it took three days of thoughtful analysis before I finally understood what I'd been doing six years previously.
This evening I've written about 2000 lines of Java (it is the day of rest, after all!). I've documented as best as I know how, but, but, of those 2000 lines of Java a significant proportion is Java boiler plate.
This is where I see Groovy and other dynamic languages winning through - maintainability and later comprehension. Groovy lets you concentrate on your intent without getting bogged down on the platform specific implementation; it's almost, but not quite, self documenting. I see this as being a huge boon to me when I revisit my current project (which I'll port to Groovy asap) in several years time and to my successors who will inherit it and carry on the good work.
So, are there any reasons not to use Groovy?
There are two reasons I can think of not to use Groovy (or Jython, or JRuby):
If you really, truly need performance
If you will miss static type checking
Those are both big ifs. Performance is probably less of a factor in most apps than people think, and static type checking is a religious issue. That said, one strength of all of these languages is their ability to mix and match with native Java code. Best of both worlds and all that.
Since I'm not responsible for your business, I say "Go for it".
If you use Groovy, you're basically throwing away useful information about types. This leaves your code "groovy": nice and concise.
Bird b
becomes
def b
Plus you get to play with all the meta-class stuff and dynamic method calls which are a torture in Java.
However -- and yes I have tried IntelliJ, Netbeans and Eclipse extensively -- serious automatic refactoring is not possible in Groovy. It's not IntelliJ's fault: the type information just isn't there. Developers will say, "but if you have unit tests for every single code path (hmmmm), then you can refactor more easily." But don't believe the hype: adding more code (unit tests) will add to the safety of massive refactoring, but they don't make the work easier. Now you have to hand fix the original code and the unit tests.
So this means that you don't refactor as often in Groovy, especially when a project is mature. While your code will be concise and easy to read, it will not be as brilliant as code that has been automatically refactored daily, hourly and weekly.
When you realize that a concept represented by a class in Java is no longer necessary, you can just delete it. In Eclipse or Netbeans or whatever, your project hierarchy lights up like a Christmas tree, telling you exactly what you've screwed up with this change. def thing tells the compiler (and therefore your IDE) nothing about how a variable will be used, whether the method exists, etc. And IDEs can only do so much guessing.
In the end, Java code is filled with "boilerplate," but it's been kneaded into its final form after many refactorings. And to me, that's the only way to get high-quality, readable code for future programmers, including when those future programmers are you-in-the-future.
Two reasons why Scala might be a compelling alternative to Groovy:
Performance on par with Java
Static typing without clutter
One of the biggest things you lose when you use dynamic languages, especially in a large codebase is the ability to use an IDE to re-factor. Languages that allow dynamically adding code to objects simply can't be parsed by today's IDEs to allow the kind of easy refactoring methods you can get from Eclipse, etc. for Java, C++, etc.
It's not really a case of "Dynamic languages are better than Static". Use what's best for you. The really cool thing about Groovy in particular is you can mix and match Java and Groovy in the same project, and it all runs on the VM. Yes, Scala is another example.
I think the biggest issue is lack of IDE support compared to java, however the plugins for Eclipse and Netbeans are getting better all the time. Also, if I remember correctly Groovy does not support anonymous inner classes if you really need them for some reason. I would personally choose Groovy anytime though.
I'm about to port a smallish library from Java to Python and wanted some advice (smallish ~ a few thousand lines of code). I've studied the Java code a little, and noticed some design patterns that are common in both languages. However, there were definitely some Java-only idioms (singletons, etc) present that are generally not-well-received in Python-world.
I know at least one tool (j2py) exists that will turn a .java file into a .py file by walking the AST. Some initial experimentation yielded less than favorable results.
Should I even be considering using an automated tool to generate some code, or are the languages different enough that any tool would create enough re-work to have justified writing from scratch?
If tools aren't the devil, are there any besides j2py that can at least handle same-project import management? I don't expect any tool to match 3rd party libraries from one language to a substitute in another.
If it were me, I'd consider doing the work by hand. A couple thousand lines of code isn't a lot of code, and by rewriting it yourself (rather than translating it automatically), you'll be in a position to decide how to take advantage of Python idioms appropriately. (FWIW, I worked Java almost exclusively for 9 years, and I'm now working in Python, so I know the kind of translation you'd have to do.)
Code is always better the second time you write it anyway....
Plus a few thousand lines of Java can probably be translated into a few hundred of Python.
Have a look at Jython. It can fairly seamlessly integrate Python on top of Java, and provide access to Java libraries but still let you act on them dynamically.
Automatic translators (f2c, j2py, whatever) normally emit code you wouldn't want to touch by hand. This is fine when all you need to do is use the output (for example, if you have a C compiler and no Fortran compiler, f2c allows you to compile Fortran programs), but terrible when you need to do anything to the code afterwards. If you intend to use this as anything other than a black box, translate it by hand. At that size, it won't be too hard.
I would write it again by hand. I don't know of any automated tools that would generate non-disgusting looking Python, and having ported Java code to Python myself, I found the result was both higher quality than the original and considerably shorter.
You gain quality because Python is more expressive (for example, anonymous inner class MouseAdapters and the like go away in favor of simple first class functions), and you also gain the benefit of writing it a second time.
It also is considerably shorter: for example, 99% of getters/setters can just be left out in favor of directly accessing the fields. For the other 1% which actually do something you can use property().
However as David mentioned, if you don't ever need to read or maintain the code, an automatic translator would be fine.
Jython's not what you're looking for in the final solution, but it will make the porting go much smoother.
My approach would be:
If there are existing tests (unit or otherwise), rewrite them in Jython (using Python's unittest)
Write some characterization tests in Jython (tests that record the current behavior)
Start porting class by class:
For each class, subclass it in Jython and port the methods one by one, making the method in the superclass abstract
After each change, run the tests!
You'll now have working Jython code that hopefully has minimal dependencies on Java.
Run the tests in CPython and fix whatever's left.
Refactor - you'll want to Pythonify the code, probably simplifying it a lot with Python idioms. This is safe and easy because of the tests.
I've this in the past with great success.
I've used Java2Python. It's not too bad, you still need to understand the code as it doesn't do everything correctly, but it does help.