Related
We are currently using MICO to establish the communication between a server and a client, where the client is a simulator written in C++ and the server is a java program displaying an animation of what happens in the simulation. It seems that the developemt of MICO has slowed down to an almost halt and bugs that only allow us to hack around them (as we don't have the time to first figure out which parts of MICO are responsible for codegeneration and so on) keep us from making real progress.
So, does any one of you know of a good drop-in replacement? We would like to have the following:
The compiler can generate both C++ and Java-Code from the idl.
The project should still show considerable support.
The implementation should be open-sourced (GPL or BSD, or something alike), as we use our programs to teach students as well.
The migration from MICO should be as easy as possible. (This is not a hard requirement, but would be a good thing)
I found some other CORBA implementations, e.g. TAO, but I didn't find any of which I could
say that they are still supported. Correct me if I am wrong here.
The Free CORBA® Downloads page might be of interest to you.
Just naming:
orbit2 1, also pyorbit etc.
omniORB
TAO (has already been mentioned)
1 On my Ubuntu box, apt-rdepends -r liborbit2 returns 5530 lines...
I don't know where CORBA or MICO in particular has gone in the last 5 years, but back then a drop in replacement was not really possible, since differences between vendors where still there.
Not necessarily API differences (POA, etc.) but
in implementation behavior,
in custom extensions which were required to make it work in a real-world environment (threading, load balancing, security, etc.),
in how the development tools worked
and also about the whole deployment or runtime story.
We had Orbix ASP/2000/Whatever and ORBacus which were interchangeable having a small compatibility layer, some Makefile framework to hide differences in tools (e.g. the IDL compiler) and some scripts for wrapping ORB specific processes.
Unfortunately, ORBacus has long been bought by (then) IONA, which already make Orbix. IONA itself has been bought by someone else (I forgot). The original authors of ORBacus, plus some devs from IONA Orbix, changed their ways somewhat and produced Ice, which is not CORBA but somewhat alike - of course without the glitches ;-)
Concerning TOA, I think it would be the "best" choice concerning still being developed as it is driven by research on the Washington University. But last time I looked, they didn't have Java implementation but people seemed to use JacORB.
Maybe all this helps you little, unless it brings even more confusion :-)
TAO as C++ ORB is still actively supported and developed (see http://www.cs.wustl.edu/~schmidt/commercial-support.html). For Java I would propose JacORB.
On http://www.orbzone.org there is an overview of available corba implementations.
I am using Equinox, so the Equinox Aspect project seems like a no-brainer, but that project appears to be inactive and has only one page of documentation that leaves me hanging at the end.
Other than that project, I do not see many options for using AOP in OSGI. Let me know what you all think and what the possibilities are, thanks :)
I don't know of any alternative, but I didn't think Equinox Aspects was inactive. It's even receiving new features in the upcoming Helios release.
The big issue is obviously with the lack of standardized loadtime weaving; Equinox Aspects and the weaver (used by AJDT) has been the only option for now. The good news is that bytecode weaving in all its glory is actively in progress in the OSGi working group and will "soon" be standardized. If you really need something that works reliably right now, your best bet is still compile-time weaving. IMHO that is a much better approach anyway, at least for AOP as design-time activity as it was originally envisioned..
As an alternative, you could also consider using the Apache Felix Dependency Manager, which allows you to at runtime add interceptors to existing OSGi services. Of course this is in no way a full AOP replacement, but for some use cases it might be enough.
You can find more documentation and an example here:
http://felix.apache.org/site/apache-felix-dependency-manager-osgi-design-patterns.html
I am looking to start work on a brand-new project, something I've been thinking about for a while as my first independent sellable project.
It's broadly speaking a web-based service application, and my first choice, server-language is quite easy... I know Java pretty well from working on Java web-apps in the past.
However my experience doing web-apps involved JSP, Servlets and JSTL... I know the ideas behind newer technologies like Hibernate/Spring but have never used them. So we wrote our own DAOs, handled AJAX by writing special mini-JSP pages that generated XML/JSON pages, etc.
I'm not hugely into the idea that Spring/Hibernate are the 'only' or 'right' way to do any Java web-project, but they are widely used. On the other hand, not only would trying to learn these increase initial development time, but I'd be using my learning attempts to build a production system.
I remember one of Joel's early articles said (I'll paraphrase since I can't find it)
"regardless what's cool, always use
the technologies that the lead
developer (or dev team?) knows best"
I wondered what people thought about that?
ps: should this be CW?
I work as a consultant, and I've seen a lot of projects where the devs started out with servlets+JSP because that's what they knew, and it's pretty simple to get started with. However, it gives the team an opportunity/excuse to write a platform of their own, which is more fun than using someone else's and just writing an application.
As the project grows, the team reinvents more and more wheels, quite a few of which end up square. That's where I enter the picture - adding new stuff to this semi-flexible platform has become so complicated that the devs can't keep up adding features and fixing bugs without calling in reinforcements. Just to add insult to injury, the internal devs are usually the ones who get assigned to do the boring bug fixes because bug fixes require more knowledge of the gory entrails of what has become the team's proprietary persistence-and-web framework, and so those gosh-danged consultants get to do the new, fun stuff.
Now, you shouldn't use a framework just because people have been regurgitating each other's blog posts about the awesomeness of it, but you should also realize that there are very good reasons why those frameworks exist (and why they're used). If you haven't used any web frameworks at all, I'd recommend you to take Spring MVC, Wicket or whatever for a test drive. They don't solve all problems, and they do cause some of their own, but the grand total is usually a productivity increase, especially if you're making advanced user interfaces.
I have been on projects where plain JDBC has been quite sufficient for persistence, and where no more advanced web frameworks than servlets+JSP have been needed, but those projects are a minority. Without having used a framework or two, you'll never whether your project is part of that minority that doesn't need one, or if it is part of the grand majority that does.
Don't try everything all at once - take on one new technology at a time.
Beware the lure of cool new frameworks! I'm currently hacking on a tiny little web app that just has a login, a few mostly static pages, and a few forms to request some information by email. It would have taken me maybe two days to do as traditional Servlet/JSP in MVC style. Instead, since there was slack in the schedule, I decided to use this project to get up to speed in Spring, Spring MVC, and Spring WebFlow. While it's quite possible that I'm just dense, it took me several weeks to get my head around the right way of doing things, I'm still not totally confident that I'm doing everything correctly, and the application is still not done. Fortunately, due to slack, I'm not in danger of the overall project schedule slipping, but I'm always asking myself if I'm going to have to scrap it and start over.
I have learned my lesson, though: next time, I won't be the one pushing a new framework unless its one I've used for production projects before. That said, I'm glad I now understand Spring (or at least I think I do) and will not hesitate to use it again next time.
So how would I learn a new framework next time? If there's a project lead (in this case I'm a project lead of a team of one, no help there) I'd use the framework that they put in place. If there isn't, or if I want to learn a framework that the project lead isn't using, I'd use it for a side project on my own time. Learning is good. Putting company work at risk by throwing untested technology at it is not so good.
I can say for sure that Spring is worth considering. It gives you as much as you can take, but it doesn't bother you with things you don't need.
For example, at the very beginning you probably need dependency injection only. Then you'll need help with database interactions and transaction management. Then you'll decide to apply MVC patter to your web-application. After that may be you'll realize that components of your system are to send JMS to each other. And so on and so forth.
For all this cases Spring has it's own simple, intuitive, light-weight solution.
When starting a new project limit the number of unfamiliar technologies / frameworks to use. Every framework takes time to learn and every framework has issues especially if not implemented correctly.
If you can I would recommend you look into the Play framework. It is a web framework for Java that focuses on developer productivity. You can choose to use Spring / Hibernate if you want but you are not bound by that. It has a very easy to learn implementation and you should be able to get a good idea within a day of playing around with it if it is what you are looking for.
It depends what the customer wants (in the world of consultancy).
You have to learn new technologies. Does the customer wants to pay for that?
Not all the caveats of the new ones are known, whereas the older ones are proven a lot more.
Of course, if everybody thought like this we would all be stuck with VB these days. You have to look for the right balance, and learn a lot yourself too so you can get an objective view on the technologies available, their up and downsides.
i personally would definitely recommend looking into spring, i've found it's saved me countless hours. hibernate is also useful if you need an ORM layer (and spring has nice integrations with hibernate too). they're certainly not the 'only' or even the 'right' way to do things (that's quite subjective) but they have both saved me time and effort, especially spring.
There is one major trap with any unknown technology. You do not know where the dragons are, and you do not know how to rub the new technology "with the hairs".
Learning that will take time, and you need to have that in your estimates. Also your estimates will most likely be too low...
I am working on a solution that aims at solving problems that newbie programmers experience when they are "modifying code" while bug fixing / doing change requests, on code in production. Eclipse, as we all know is a great IDE. Features such as Code Completion, Open Declaration, Type Hierarchy, Package Explorer, Navigator, Finding References etc aids people in fixing things quicker compared to say using something like Textpad.
If you are a newbie java programmer and you are using Eclipse IDE, what areas of the Eclipse IDE do you think were less helpful/ less intuitive? If you are a seasoned programmer, what are the common issues that newbies look up to you to solve for them?
Please ignore issues related to : Domain Expertise (Business Knowledge), Infra( where to test your change etc), performance related (eclipse search being slow,etc), Skill level in a particular language (think of the developer as a noob) ... and think one language - Java
I did a local survey in my small team and here are some:
Newbies using Eclipse to handle code that is written to interfaces where the implementation is supplied at runtime. Doing a 'Open Declaration' will always show you an interface. This could be confusing at times.
Eclipse is not intuitive while developing EJBs. Sure, you know all you have to do to create a new bean is to right click and 'Create Bean', however, once created it shows no contextual help to what the next step should be. For instance, generating stubs.
When Data Source Mapping with entity beans, changing something screws up the entire flow of things and eclpise never complains / hints.
Developing applications that make use of Struts, eclipse doesn't tell you that when you change struts-config.xml, particular web flow would get affected.
At this point, to me, as someone who is interested in collecting opinions for my research, it appears as if Eclipse could use more 'contextual runtime hints'.
I am sure the community would have a lot more to add... Please add more of your negative experiences (just from the code change perspective).
EDIT:
I guess, my question was too lengthy and confusing. I am gonna rephrase it a bit and keep it short:
While "making a code change" (not analogous to code formatting, infra related activities, CVS etc... say something like refactoring), what feature(s) of eclipse IDE did you not like / hate the most? Here are the examples:
When modifying code that has been written to interfaces: 'Open Declaration /F3 on an object instance shows you the interface when the implementation is supplied at runtime'.
When changing apps using EJBs: No contextual help
When changing apps using MVCs(Spring / Struts) : No warnings about change impact.
Missing in Eclipse are:
Software visualization, as for example System Complexity View [Lanza 2003]
And also by Lanza, the Class Blueprint [Ducasse 2005]
Post Scriptum: Software visualization in Eclipse: X-Ray provides System Complexity View of Java projects, http://xray.inf.usi.ch/xray.php (via #anjaguzzi and Paul Lammertsma)
And then collaborative filtering "other developers that edited this method before also edited" [Zimmermann 2005]
And the collection of browsable examples, and autocompletion at the level of these examples. That is, for example if your write
ByteBuffer buf = file.
and hit autocompletion it should search the codebase and the interwebs for examples that convert files to bytebuffers and insert that 10-20 lines there.
Parseweb supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types. http://doi.acm.org/10.1145/1453101.1453129
Prospector supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types.http://doi.acm.org/10.1145/1064978.1065018
Strathcona provides source code examples and structural con-
text for the code fragment under development. http://lsmr.cpsc.ucalgary.ca/papers/holmes-icse-2005.pdf
Rascal recommends how and when to call the methods of objects from common libraries such as Java Swing, based on an analysis of existing classes. It uses collaborative filtering. http://dx.doi.org/10.1007/s10462-005-9012-8
And of course also the feature that I can write a Unit test and then the IDE searches the interwebs for classes that pass the test. Yes, this can be done!
CodeGenie is an Eclipse plugin that allows you to write unit tests and then uses the Sourcerer source code search engine to find passing classes. http://doi.acm.org/10.1145/1529282.1529384
CodeConjurer which is based on Merobase also offers that feature, see http://dx.doi.org/10.1109/MS.2008.110
This list could go on and on, good starting points for more work are the proceedings of past
Conference on Mining Software Repositories (MSR)
Workshop on Search-driven Software Engineering (SUITE)
Workshop on Recommendation Systems for Software Engineering (RSSE)
which are all under the umbrella of the ICSE conference.
"newbie issues" I've seen myself (I've used Eclipse for a good while, but it keeps "surprising" me occasionally) and helping colleagues just starting to use Eclipse:
It's large and complex enough to be very intimidating to some at first. Seems people consider netbeans easier to use initially. One colleague took refuge with the VI editor for a god while...
Installing plugins can be tricky (finding site URLs, awareness of plugins, why is "install"+"update" under the Help menu???)
Updates are still slow (but much better than before) with Eclipse 3.5/Galileo. It's difficult to understand which plugins to install just by their name sometimes.
Any platform besides Mac - preferences under the Window menu seems illogical?
Understanding how to set the project class path neatly. Setting the right project JDK version.
Lack of or unexpected interaction between ant/maven build tools' classpath and that of eclipse's (ant/maven clean causes Eclipse compiler errors when classpath is shared etc.).
Views and (large number of) perspectives are confusing/overwhelming at first. Which are useful when? How to drag views to the desired location or restoring closed ones?
Some JDK/Eclipse version combinations required too much PermGen space than available by default, took a while to diagnose.
For me, most of the newbie problems in Eclipse come from one of it's strengths, its configurability & plugin structure.
When I need to change a property in Eclipse, I always seem to have to spend a few minutes working out where to change it. Example: changing the Java editor to insert 4 spaces instead of a tab. The search bar in the properties is always welcome :-)
That and the lack of documentation for some of the plugins always makes for fun when I'm setting up a project.
EDIT: You can always show the classes that implement an interface using ctrl-T.
One thing I would add is that when I have a complex project, I tend to use Refresh & Project->Rebuild All *a lot". And I use TortoiseSVN to maniuplate stuff outside of Eclipse, because a lot of times this is easier (some refactoring for instance). However, if I'm modifying the project outside of Eclipse, I *always" quit Eclipse, and do a full refresh and build when I restart it. Otherwise Eclipse gets very confused sometimes.
I think the biggest problem I faced (and still face) with Eclipse is that it isn't particularly aware of standard technologies that surround modern Java development. If I'm developing an application, it might include the following:
Spring
Maven
JSF/Struts 2
Subversion
JUnit
I think Eclipse handles those technologies in increasing levels of awareness: (so JUnit will be fine, it works out of the box; Subversion requires Subclipse, and it's a little ropier than the CVS support; JSF needs some WTP tooling to be installed; Maven...you're probably best off setting up your own external tools commands rather than trust M2Eclipse, unless it's become dramatically better in recent times; and Spring, well, as you say, try ctrl-clicking on a method and you'll almost certainly get an interface, because the implementation is hidden away behind a Spring config file).
Getting all of that to play together and check out/compile, then later compile/run tests/check in is the difficult bit. The code change itself is probably easy :)
For me, the biggest hurdle to learning to use eclipse effectively was understanding where to set the classpath and also how to figure out exactly what is included on the classpath for various stages of development (compile, build, test). I was confused for a long time about the difference between compile time, debug configurations, and run configurations classpaths. Then if you throw ant into the mix (which automatically creates a run configuration ) it makes it even more confusing for newbies.
As a beginner, I didn't do EJB or Struts stuff. Or even data source mapping. So I think the question's title may be a little misleading.
I would have appreciated having something like JadClipse built in to "look at" library code when I hit it in debugging or such. But it should be made VERY clear that this is "reconstituted code" and not meant to be hacked around in.
Second, noobs need to be made much more aware that Shift-F2 will get them the API documentation for whatever class/method they're looking at. I know too many novice Java programmers who explore their APIs with nothing more than code completion; they're missing many valuable hints provided by the library authors.
A mindreader which generates code on the fly, so that a single click is sufficient to complete a project.
I found Visual Studio easy to pick up, I tried clicking on each button at least once, and figured out what the whole thing does. It's thought out by a single design team at the highest level, and everything follows the standards top to bottom, more or less.
Then, I play with Eclipse. In technical terms, it's janky at best. Look at the preferences dialog; it's an overwhelming trainwreck, unless you already know exactly what you're looking for, and what the developer working on that feature decided to call it.
Eclipse's configurability relies on the fact you already know how to configure it. The learning curve there is awful, and the only saving grace is that most of the defaults are okay to begin with.
I was a noob to eclipse recently, mostly doing Android and BlackBerry stuff. And one thing that eludes me to this day is the massive multitude of options and settings and various places they can be found in. For instance, if you have a plugin installed (say BlackBerry plugin), the setting might be found in the general prefs or BlackBerry prefs or the project prefs.
It's always a hunt.
Here are basic missing features as far as I know :
Show the beginning '{' when you are at the end '}' where beginning '{' is out of the view
Automatically synchronize the editor with package explorer
Go to different view (package explorer, outline, etc) with keyboard
Inline find, which does not open a dialog.
Go to next error location with keyboard
Go to next/previous structure with keyboard
More stability in general.
These features work great in IntelliJ. Especially #1 and #5 are really useful.
VCS integration - typically the developer is also new to merging changes, keeping working copies in sync, resolving conflicts and so on. There are often several ways of achieving the same thing in Eclipse and I've seen this cause confusion on several occasions (actually, I've seen this with experienced developers too; they know Subversion but not Eclipse, and the latter tries to 'hide' the underlying repository operations).
I think the issue with all IDEs for beginners is the disconnection from the tool chain: how the compiler takes some source and compiles it to bytecode which I then run using the VM with a correctly configured classpath.
As a dev I love the fact I don't need to deal with this - and I've never found myself unable to do what I want concerning more complex build configurations - but it's too important for beginners to understand what's happening when you press that Play button to be ignored.
when i first tried using eclipse i absolutely hated it's coplexity.. you had to do a whole bunch of things befor you were able to start working. furthermore you have way to many options to check and it's not always selfexplaining what each button does.
instead i started using netbeans. way more intuitive and easier to handle. check there gui.. not to much buttons and most of the time you know what the button does even if you have no clue of java (as i had at that time).
when i changed back to eclipse (due to some features not supported in netbeans) it seemed far easier to work with it. so some part of the gui might just be added in a not intuitive way and beginners will definitly have a hard time with it.
simplicity
clearness
consistency
I might write it much more in detail, but i think, that eclipse is overweight and much too much oriented on features - instead of ease of use. IMO, this concerns beginners as well as professionals.
Eclipse has no visual designer for Swing components.
Compare that to Visual Studio, where:
click 'new form'
drag buttons and text boxes onto the form, move them around, add some labels
double click on a button, add some code
done, one quick application, show it to the boss, get paid/promotion/coffee break
In Eclipse you either have to use Netbeans instead (ie not Eclipse...), or use IBM's SWT, or code the Swing forms by hand.
I feel it would be very nice to have a great wysiwyg forms designer in Eclipse for Swing forms.
The other confusing part is that for web development there is a separate version that needs to be used! Well I didn't like this at all and I know that a lot of people just don't about this.
Eclipse is missing Maven Embedded in standard distribution , Maven would help any user in getting their program all the jars and better library management .
Netbeans already has this tools.
Also eclipse misses integrated tools for hibernate , spring , xfire and tomcat deployment using maven.
Check this site http://maven.apache.org/
All of my other problems with Eclipse have already been mentioned except one: It's slooooooooow. Was their goal to prove the "Java is slow" people right? I'm guessing this is related to the "Eclipse does everything", but I stopped using it because it lags every time I click on anything. Change tabs? Lag. Open preferences? Lag. Change tabs in preferences? Lag. It's like using Photoshop with 32 Mb of memory.
Oh and it's incredibly ugly. I wish I could get it with real GTK+ integration.
The android SDK integration is full of jank. xml layouts don't render correctly. Code completion doesn't work well. IBM needs to fix the jank for sure.
I was wondering whether Scala will get the takeup it deserves without explicit corporate backing (I was thinking by Sun/Oracle but I suppose it could be someone else, such as Google).
With Sun's recent decision not to include closures in JDK7, couldn't they put their weight behind Scala as the Java alternative for those wishing to have a more expressive language? After all, it seems to me that they should care most about the JVM, not Java per se. Does anyone think this is likely?
Apart from the examples of previous languages that have succeeded without initial corporate backing, I think Microsoft's promotion of functional programming on the .NET platform may indirectly help Scala gain adoption. Since the Java and .NET ecosystems are seen as close rivals, people aware of F# and the functional additions to C# may be inclined to look for JVM analogs, and to me Scala seems best equipped to fill that role.
You need to be more specific. Thrive in what context?
I think Scala's community is near the critical mass that it needs to be a self-sustainable open source project even if its primary institutional backer, the EPFL, suddenly had a change of heart; and there is currently every sign that it will reach this critical mass. I think Scala will be with us and actively maintained for a long time.
A more pressing issue if the type of uses for which it is suited. The Scala compiler and standard library are far from perfect. When you start pushing the language or a portion of the library there is still a decent chance that you will find bugs. This is improving by leaps and bounds, but it in itself isn't the core of the problem.
The problem is in order to get fixes you pretty much have to upgrade to the next version of Scala as upgrades come out. The problem with that is that most version upgrades contain breaking changes, thus in order to obtain fixes you are likely to have to change your own code. There's also the binary incompatibility problem, which means all your Scala dependencies have to change versions, too.
This could be severe problem if you have a lot of dependencies on other Scala libraries (unlikely - there aren't many yet), if you are subject to severe infrastructure bureaucracy, or worse, you're a product-oriented company that needs to distribute fixes to customer with severe infrastructure bureaucracy.
In order for Scala to be viable in such situations long-term, someone will have to start back porting fixes to earlier versions so that people don't have to perform breaking upgrades just to get some fixes. I'm sure this will happen, because it really wouldn't be that hard, but it will probably require someone seeing a business opportunity, because let's face it, backporting changes and doing regression testing isn't exactly exiting work.
I think Scala will be fine. It has a lot of mind share now that Twitter has partially moved to it. I think it's unlikely Sun will concentrate on anything but Java, but they are probably happy that other languages are targeting the JVM.
I think the closure thing is lame, by the way. I love closures.
I think it will thrive because it doesn't have corporate bozos 'backing' them. I personally like the idea that a language is so independent, and yet very good and well planned and thought out.
I think Google is likely to pick it up, but I don't think it will be an official backing. I'm sure Google will find a cool project to use Scala with.
Corporate backing is only necessary for a language to succeed if it doesn't have a lot of support from working programmers. Perl, Python, and Ruby all grew up without support from the Man (well, Ruby had the Japanese Man, but it wasn't a lot of help in the US).
I've not used Scala, but Twitter's endorsement of it suggests that it has enough programmer support to thrive even without a corporate big brother.
Of course it will survive.
There are bundles of languages lying around, being supported by univerities, working groups, hobbiests, and programmers, up and down the world, and out in the wild. In some cases the fact their not supported by the Man, means they have some chance of survival, perhaps more to do with their cachet or maybe they server an important reserarch aspect.