Slashdot Mirror
A First Look At Red Hat Developer Studio
juanignaciosl writes "The first beta of Red Hat Developer Studio was published yesterday. RHDS seems promising. This IDE is a bunch of Eclipse plugins that comes from the fusion of JBoss IDE and Exadel Studio. The main advantages it offers are: JSF development improved, in particular integrating RichFaces and Ajax4JSF libraries; Seam (next J2EE middleware standard?) integration; and plugins for JBoss, Hibernate... Here are my first impressions."
Your confusing Red Hat with SCO.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
If you don't know what was said there, you probably don't need to know.
I have yet to see an IDE that has a text editor that compares to TextMate. The fonts are ugly, color/theme management is poor, integration with the PC is poor or non-existent, and macros and custom code are much more difficult than TextMate.
These may be good when you need to manage massive projects, but I can't stand to use them for actually writing code. If there was only some way to replace the text editor in these IDEs with TextMate but keep all the trappings that make compiling and deploying these apps easy.
I'm in the hole of the broadband donut.
Jesus Christ, will someone please rip off ASP.NET? I've looked at all the crazy proliferation of Java web frameworks and they all pretty much suck. You have to maintain a bunch of XML files for things that ASP.NET just figures out on its own, docs suck, architecture is bizarre. It's all just a giant, productivity draining mess. Why can't I just have transparent interaction between the page and code? Why do I have to "register" crap (through XML file) that should just be available transparently from page code? Why do I have to create "navigation rules"? Why do I have to "declare beans"?
No wonder turds like Ruby on Rails are so popular. I'd rather shoot myself than use Java for web development.
Well put.
I have to say that the place I use to work standardized in Java and Linux on the servers and everything worked well. Then I left and they hired a new kid out of college that couldn't believe how "long" it took to code stuff using JSF/Java. He pushed and pushed to do a project in PHP. He quoted around one fifth the time to do a project that another developer had quoted to do in Java, saying that the time using PHP would more than make up the difference. In short, the project took around 2X as long as the original Java quote (~10X as long as he had quoted) and thus they are back to working with Java again. I am not about to say that any language is bad, but when you focus 70+% of your effort on business logic, (most of our work), then it is a little hard to believe someone when they say that language X is 5X faster than language Y.
My question about this new IDE from RedHat is this:
Can I do visual JSF development in a true WYSIWYG environment like Netbeans?
Can I do Swing development in a WYSIWYG environemnt like Netbeans?
Can I easily choose not to use the custom components that you include? I would assume so, but my fear is that RedHat focused on this product working with JBOSS and getting it to work with other application servers may be a pain.
I like Eclipse, but I have found Netbeans 5.5 to be better for what I do so migrating back to Eclipse would take some great features, and would be interested to see how far this has come. Oh yeah, and one last, but very important thing. You still don't hack Eclipse on Linux to run under the GCJ crap do you? If you did that then I can only imagine all the problems I had using your product before would be back again. I hope now that Java is under the GPL that you don't mess with that abomination (GCJ) and have included the real JVM with your Linux and more specifically don't have any of your tools reliant on the GCJ.
The more I learn about science, the more my faith in God increases.
I'm not convinced that this is entirely Java/J2EE's fault as much as it is that big corporations love Java and hate Python (and Perl) and have "big-corporatized" Java. Java was actually pretty cool when it first came out... if big industry embraced Python today, by tomorrow you'd see an explosion of PBPEL, P2EE, PDBC, PFaces, PSF and PMS applications and by the next day you'd be assigned to a committee to evaluate the product vendors to find the scalable enterprise solution that was the best fit for your business integration challenges. After a month of vendor selections, you'd narrow the candidates down to the top two contenders, and they'd pitch their expertise in the field, and then your company would sign a multi-million dollar contract with one of them. Then you'd start the process of trying to figure out how to get around the inherent limitations of the "solution" and do plain-old Python programming inside the "container" without it being too obvious to the higher-ups that that's what you're doing...
Proud neuron in the Slashdot hivemind since 2002.
While I agree that complex configuration files are a bane to development, I disagree with the assertion that J2EE requires them. ORM technologies like JPA are utilizing Java 5 annotations to declare configuration inline with code instead of XML. Frameworks like Wicket and GWT are providing developers with Java solutions to UI that are devoid of XML configuration, JSP, and markup-heavy implementations. IMHO, Wicket deserves to be called a breath of fresh air.
I do think it's a mistake for J2EE to include a particular view framework in its specification. JSF, while an innovation in the 90's, is simply a pig wearing lipstick compared to some of the new frameworks out there. Frameworks that, for example, are built on AJAX instead of including it as an afterthought.
I suppose the bewildering set of choices may be the root of the problem here. But if you make the effort to do your research, you'll find that many of your assumptions are incorrect.