Java vs C# for Java newbies
-
Re-read it. You said it's the best IDE you've used. Then you said you're not qualified to speak about nay other IDEs.
-
Any of the other java IDEs.
OK, fine, that was ambiguous. I have now fixed it. I thought that would be implied, but from context it doesn't appear as obvious.
-
Any of the other java IDEs.
If that is what you meant, maybe, just maybe, that should have been what you typed.
-
Thank you for the feedback.
Your comment has already been covered by a prior post. If you feel this was not sufficient, please feel free to open a new ticket.
Thank youfor using Discourse, and have a nice day!
-
-
To elaborate:
I prefer the way IntelliJ does its autocomplete/IntelliSense. I like the small features it provides like postfix completion. I like the potential error detection features. It feels more complete and better than Visual Studio, personally.
That's what ReSharper is for. It brings all the IntelliJ goodness to Visual Studio. Postfix stuff is available through a plugin for R#.
-
It was pretty clear, ignore the rat. Everybody understood.
-
We'll be using Spring
I've played with Android dev
Not even close, try again.
please tell me what I should be wary of
Well, I can only give you some advice since I haven't worked with C# in a long time:
- Use Maven from day 1 from the CLI.
- Use jUnit and Mockito with Spring DI.
- For REST there's Jersey and Spring.
- Use Java8 or later. Very different experience.
- KISS and use Apache commons (lang, beans, etc) from the beginning.
- Keep your WAR code separate from your application code.
- Don't use Spring XML but with annotations.
- Don't freak out with Spring stack traces. They're amazingly long and useless.
- Spring Data is quite good abstracting yourself from mangling with Mongo, so maybe use that.
- Spring != JEE so don't mix both stacks or you'll be in trouble unless you know what you're doing.
- For Spring you don't need a JEE container (JBoss, WebLogic, etc) just a "web" server (Jetty, Tomcat, etc).
- Jackson is quite good for JSON parsing, but if you require XML too, use XStream.
About classpath hell, if you use Maven it won't be that bad, just remember to encapsulate all your code in separate JAR files and that they're accessible to all other classes. The best thing to do is to have Maven build a
lib/folder so you can use-cp lib/**/*but since this sounds like a web application all your files will be in a WAR file, which is another ring of hell you'll have to deal with, but usually, Maven works quite fine on generating those.About #6, you don't want all your code in a single Maven project. Take this for example. A parent Maven project and a single module with a few files for the WAR, everything else goes in modules like core, utils, etc. I guess this is like C# DLL's. Feel free to check on that project which is quite close to what your initial setup will require.
One thing I like is to use an embedded web servers like Jetty or Netty and encapsulate all of the application in a single ZIP file, unzip it and the run something like
"${JAVA_HOME}/bin/java" ${opts} -cp "${path}" jongo.JongoJetty. This way you only need Java to run the application on any server.This brings another advice. In *nix you don't have to install Java, simply download the JDK and unzip it somewhere, set up your $PATH (or use the JAVA_HOME path) and you're ready to go.
From your description of the project (Spring + Mongo + REST + RabbitMQ), with Spring Roo you could have the whole thing set up in 10 minutes, but you would have to know what Spring Roo is and how it works.
-
Use Java8 or later. Very different experience.
+1
@Eldelshell said:Apache commons (lang, beans, etc) from the beginning.
+1Spring stack traces
Yeah, but if you know how to follow stack traces they shouldn't be that bad anyways. Just find where your code is and go from there...
-
Yeah, but if you know how to follow stack traces they shouldn't be that bad anyways. Just find where your code is and go from there...
99% of the time, you can just find where the trace leaves your code and ignore everything from there on out. And the traces are actually shorter than the typical ones you get out of a Rails app…
-
About classpath hell, if you use Maven it won't be that bad, just remember to encapsulate all your code in separate JAR files and that they're accessible to all other classes. The best thing to do is to have Maven build a lib/ folder so you can use -cp lib/**/* but since this sounds like a web application all your files will be in a WAR file, which is another ring of hell you'll have to deal with, but usually, Maven works quite fine on generating those.
It's pretty straight-forward to build executable JARs with dependencies embedded in them with Maven, and WARs are done that way anyway. But it's best if you avoid anything with native code in it; those things tend to be quite a lot more troublesome. The only libraries worth ignoring that recommendation for (except for system classpath stuff) are some embedded databases and JDBC drivers.
-
I read... Top to bottom usually
-
99% of the time, you can just find where the trace leaves your code and ignore everything from there on out. And the traces are actually shorter than the typical ones you get out of a Rails app…
Indeed. I just search for part of my code's package path when I'm reading that stuff.
-
The only libraries worth ignoring that recommendation for (except for system classpath stuff) are some embedded databases and JDBC drivers
As for JDBC drivers, if you're lucky your database has a type 4 (pure Java) driver.
-
If you're unlucky, your database is Derby and sucks mightily “despite being pure Java”.
-
Wow, that's a lot of pretty good info. Thanks!
-
I was talking about the driver, not the database itself.
-
There's no difference with Derby. The driver and the DB are packaged in the same JAR, and Derby sucks in server mode just as much in embedded mode.
