Java Blog

Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …

Hallo, das Schlüsselwort new in Java ist es dasselbe wie new in C++. Mit new wird ein neuer Speicher auf dem heap angelegt. Und man muss ihn dann.

Also, ich weiss, dass Java Plattformunabhänig ist, aber inwifern unterscheidet sich Javasprache von c++? Ich kann nämlich schon ansatzweise ein wenig.

Also, ich weiss, dass Java Plattformunabhänig ist, aber inwifern unterscheidet sich Javasprache von c++? Ich kann nämlich schon ansatzweise ein wenig.

Geht es zum Beispiel um Java innerhalb von Tomcat, hat das für eine Anwendung mit Oberfläche natürlich Auswirkungen. Prinzipiell wird Tomcat als Dienst laufen, ob das jetzt unter Linux oder Windows ist, dürfte für das grundsätzliche …

I am a professor in Rey Juan Carlos university, at Madrid. There, I was teaching compiler construction for several years. I felt comfortable with this subject, so everything was OK. Then, in 2007 I was faced with a new subject that needed to be taught in a new degree in Computer Science. The subject was all about programming paradigms and languages, and someone proposed me to leave the old, comfortable one, to take on this new one. It was then when I started to run into trouble.

I was the responsible to detail the contents of the subject, which consisted on teaching three different modules of one paradigm each: functional programming, concurrent programming, and (well it is not really a paradigm, or is it?) dynamic languages. I had to decide which language to use within each paradigm. Obviously, given that we had one semester, I didn’t like to spend one session per module to teach a new, different, development environment. So, as an Eclipse user, I started thinking of using Eclipse as the single IDE for all languages.

This could have been all, if I had some degrees of freedom. I chose Haskell for functional programming, Ruby for dynamic languages and Java for concurrent programming. All of them have great support within Eclipse. Haskell is supported by means of the EclipseFP project, Java has the great JDT community, and there was also the great job from the DLTK project team.

However, I had very few sessions to teach each one, and my students didn’t knew Java (neither Haskell nor Ruby). Ok, let’s see if we can use at least some language that is closer to what they are used to so that they don’t need to learn all three languages. And I came over PascalFC. PascalFC is a Pascal-like language focused on learning concurrent programming. And my students already knew Pascal. Nice.

Wait. There’s no PascalFC support in the Eclipse ecosystem. Oh… Even worst, some colleagues were supposed to teach a similar subject on other degrees. But their subjects were focused on object orientation with Pascal (due to same constraints) rather than dynamic languages. And they were asking also for a Pascal plug-in.

When looking for a Pascal Eclipse plug-in I came over two options: Pasclipse and EclipseColorer. The Pasclipse project seemed to be abandoned (and looking back to its page, it is). And the EclipseColorer was just a colorer. And obviously, there weren’t any PascalFC Eclipse tools.

It seemed that it was a lost battle… But we wanted to have a single IDE for all these languages, and that IDE had to be Eclipse. So we take on building these two development tools. Me and another colleage worked hard during part of the summer and the first semester of 2006 in order to release a first version of two tools for Eclipse: Pascaline and PascalFC Development Tools.

When we finished we were half way where we want to be. Next step was to release an Eclipse distribution that contained these two tools, among the others (JDT, DLTK Ruby, and EclipseFP). We called it EclipseGavab 0.5 (starting numbers for versions are a funny thing to play with). We were finished by February 2007. We did it. We even included in the Windows version all the tools (compilers, JRE, interpreters) needed by the different plug-ins.

Nowadays, EclipseGavab is in its third version (EclipseGavab 2.0) which is based on Eclipse Ganymede (3.4), and now contains more tools, like CDT (which is used in a subject about C/C++ programming), and Subversive, Mylyn and ECF. These three last ones were included to enable collaborative development. I’m looking for some screenshots of the older versions, but I can’t find them, I have to look in the backups. So here you have some of the latest version:

The splash

The Pascaline tool supports Pascal development with the aid of the CDT language extensions, which is very helpfull for instance to provide debug capabilities.

There is also help available.

The PascalFC Development Tool links the deadlocks shown in the console to take you to your “dead” code.

Shared editing may allow students to share ideas and resolve problems.

We now also detect installation changes and re-configure your workspace configuration so that compilers are found by tools.

While our team here at Nokia has been developing the Eclipse Debugger for C/C++ (EDC) as a component of the CDT project we wanted to do it in the open as much as possible. But we still had quite a bit of initial work to do before the community would be able to evaluate what we were doing. Now that the initial contribution is in CDT we’re going to start working on changing our habits to bring more openness and transparency to the effort:

We’re going to start moving our discussions about EDC to the cdt-dev mailing list. This may seem simple but we also don’t want to bore the CDT community with issues related to Carbide, Symbian, on-device debugging etc. so we’ll need to be a little selective.

New issues with EDC will be logged in the Eclipse bugzilla instead of our Carbide bugzilla. We’ll need to be a little selective here too and probably won’t log every minor issue, but anything that merits any sort of discussion will be public.

Currently our team has two committers on the CDT project, Warren Paul and myself. I’ve been syncing the EDC sources in CDT with our internal copy. This has done wonders for my committer stats, it looks like I wrote all of the EDC code, but has masked the contributions of our team members. So we’re going to start nominating additional people as CDT committers, starting with the ones who already have a track record of contributions to other components in addition to their work on EDC.

Entwickeln nur so zum Spaß – C#/XNA, Ruby, Java, C/C++ usw. Wer kennt nicht die unbändige Freude etwas Neues zu schaffen? Diesem erhebenden Gefühl widme ich mich hier nicht ganz, sondern nur den Auslösern: den Projekten! …

Ich beschäftige mich beruflich seit einigen Jahren mit PHP, JAva Script , VB, C++ . Da ich ständig am Wochenende und abends Zeit habe (manchmal…

NET, C#, C++, PHP, Python, Java – It’s all here! Resources for developers in C, C++, C#, .Net, Visual Basic, Java, Ruby, PHP, Perl, Python and more. Featuring forums, tens of thousands of resources, blogs, jobs and more! …

Das erste offizielle Entwicklerforum für die Apple Macintosh Plattform. Unabhängig und auf Deutsch.

Moin moin, alle Hacks, die ich bisher gesehen habe (für S4) auf diesem Forum sind in C++ geschrieben. Da ich C++ lernen wollte hab ich gesucht und.

Entwickler des Social Networks haben mit HipHop for PHP einen Code-Umwandler veröffentlicht, der die besten Seiten von PHP mit den Performancevorteilen von C++ verbinden soll. Facebook verspricht eine Reduzierung der CPU-Ausnutzung um die Hälfte.

Die GNU Compiler Collection (GCC) ist in Version 4.4.3 erschienen. Sie beinhaltet Frontends und Libraries für Java und andere Sprachen wie zum Beispiel C++. GCC’s Java ist eine Implementierung, die ohne Sun-Code auskommt. Seit Version 4.4 …

Die GNU Compiler Collection (GCC) ist in Version 4.4.3 erschienen. Sie beinhaltet Frontends und Libraries für Java und andere Sprachen wie zum Beispiel C++. GCC’s Java ist eine Implementierung, die ohne Sun-Code auskommt. Seit Version 4.4 …

Writing code for multiple platforms is a challenge. It not only increases the complexity of your code and tests, but it also increases the complexity of your build process. The build process is what I have had trouble with as of late. So, I’m logging my struggles so that I, and you, might have some place to go the next time multi-platform deployment causes headaches.

So, here is my problem. I have a plug-in that has a little bit of platform-specific code in it. The code works on both windows and linux, and I have precompiled binaries for them. In other words, the build of the (C++) native code doesn’t need to be part of my build process. I do that separately just because it is easier. Setting up cross-compilers is a nightmare, and takes more time than I have.

So, here is what I do: I separate my native code into plug-in fragments for windows and for linux. After that, I have to go through all of my different manifests to make sure that P2 knows what to do with the the fragments. First, a p2.inf file has to be made for each fragment and the host plug-in, so that P2 knows the fragments are installable units that should be downloaded. OK, that’s fine. Then, I have to the feature.xml for the feature that contains my plugins and fragments to make sure that I specify the supporting environments:

OK, then I have to set up my fragments to make sure that the platform filters match their target environment:

Platform filters are basically read as a functional notation, where sets of attributes are bound to operators. For example, (|(osgi.arch=x86)(osgi.arch=x86_64)) binds the selection of the attributes (osgi.arch=x86 and osgi.arch=x86_64) to the logical OR operator (|), so that it reads, “the osgi architecture can be either x86 or x86_64.” So, I’ve got that down. I also had to set up the Bundle-NativeCode attribute in the manifest for the fragment so that my application knows where to find the binaries, but I’ll get back to that later.

OK, now one might expect that everything is ready to export. After all, the binaries don’t depend on any native Eclipse fragments (they don’t reference SWT or anything). So, it seems that my fragments should be able to be packaged up just like anything else.

That’s not the case however. When you run a build in PDE, and you put a platform filter on a fragment, Eclipse checks your current target platform and builds only for what you currently have. I, for example, have a machine with Windows XP on it, and that is the version of Eclipse that I downloaded. So, Eclipse will build only the windows fragment for me. There is no option to build for other platforms. If I use the Export Deployable Features wizard, this is what I get:

Even though my fragments don’t have any dependencies on any other platform-specific code and all I really need is a jar with my binaries in it, the PDE says, “No! I can’t build that for you.” OK, that’s fine. I know that it is possible to build for multiple platforms (the SWT guys do it), so I did some searching.

It turns out that what I need is something called the Eclipse Delta Pack. The Delta Pack is basically a bunch of fragments for different platforms which include native code for user interfaces and other i/o such as file manipulation. Getting the Delta Pack can transform your Eclipse workbench into a catch-all platform which targets everything that Eclipse can manage.

The unfortunate thing is that the Delta Pack isn’t that easy to find. If you go to the Eclipse Download page, you won’t find any reference to it. You have to go down to the bottom of the page, and find the Classic Eclipse distribution. And select Other Downloads:

Once there, you will want to get the release that you are targeting (probably somewhere in the 3.5.1 stream or later), and look to the left-hand menu. You will find the Delta Pack there:

Or, you can follow this link for the 3.5.1 drop.

When you download the Delta Pack, you have to unpack it. Make sure that you don’t unpack it over your current Eclipse install. That could make things go bad. Instead, unpack it somewhere else and you can tell Eclipse to add it to your target platform.

To do that, go to your Eclipse Preferences, and find the page for Target Platform, select the running platform, and Add the Delta Pack to it as an Eclipse Install:

After that’s done, you will have a new magic option in your Export Deployable Features wizard called Export for multiple platforms. That’s exactly what I was looking for!

So, one would think at this point that one could simply export all of the features, upload them to a P2 repository, and release the new version. Not so fast. If you are me and you do that, you get this bug report.

It was silly of me. I shouldn’t have assumed that the build would work flawlessly without testing. So, I checked my P2 repository, and low-and-behold, the Linux fragment was missing. That seemed strange. After all I did export for Linux. There’s no rocket science here. It’s just a pre-compiled binary after all.

So, after hours of fighting with trying different combinations of platform filters, and different ways of building, there were no warnings and no errors in the build. Unfortunately, there was also no Linux fragment. It just would not get created on my windows box. I was about to go and file a bug on P2, when I decided that maybe I should just try to get the build on Linux. So, I went through all the above steps again on a fresh install of Eclipse on a Linux machine. What I expected to happen was that it would build fine on the Linux machine, but instead of not having a Linux fragment, I would be left without a windows fragment.

That isn’t what happened. I did get a windows fragment. What was missing? You guessed it: the Linux fragment! My Linux machine failed to build the Linux fragment. But, at least I got an error this time:

It looks like there was something about my Bundle-NativeCode property in the Linux fragment which the PDE build system didn’t like. So, I went to investigate it.

I had used native code previously in an RCP toy application in which I was experimenting with OpenGL. When I looked up how to do it at that time, I learnt that I was supposed to use various keys such as processor= and os= to tell the plug-in when to use different compiled libraries. In fact, that is what I used in previous versions of Diver. When both the Windows and Linux binaries were in one fragment, it worked fine. But apparently, now that I had them in two fragments, that was very, very wrong:

I didn’t really know what to do, though since this is what I had read was correct, and it was previously working. In fact it still works for the different Windows versions. Not for Linux, though. I don’t know why. So, after another hour or so on Google, I learned about the key selection-filter which works in the same way that the Eclipse-PlatformFilter does. So, I copied my platform filter into the Bundle-NativeCode like this:

And it works! So, I learned a few things from this whole process:

1. You Need The Delta Pack. Why you need it for all multi-platform builds, I don’t know. In my example, all I needed was to package up pre-compiled binaries into jar files. There doesn’t need to be any dependency resolution for that, but the PDE needs the Delta Pack to do the build. That is relatively painless, so I don’t mind.
2. Pay Attention to the Bundle-NativeCode Format. Eclipse won’t necessarily tell you what is wrong. It might just fail to build a fragment or two without you even noticing. The safest way to get it to work just seems to be to copy your Eclipse-PlatformFilter directly into the Bundle-NativeCode property. At least you don’t have to manage multiple different syntaxes that way.

Anyway, that is all for now. I hope this can be helpful to anyone who is doing builds for multiple platforms. It isn’t an easy problem to solve, so there are bound to be pain points. This post will hopefully get you (and me) through them quickly next time.

CTR Concept präsentiert \”Quechua Web Script Editor\” Der Editor für einfachste Erstellung und Bearbeitung Ihrer Webdateien. HTML, HTM, XML, PHP, SQL, Java, Pascal, C++, uvm. können hier mit einfachsten Mitteln erstellt und bearbeitet werden. Quechua wird in zwei Versionen angeboten. Die \”Light\” Version ohne Datenbank und die \”Full\” Version mit Datenbankverknüpfung.

23. Januar 2010, Zip pool der Universität Erlangen. 24 Teams mit je bis zu drei Personen versuchten zehn unterschiedliche mathematische Probleme mittels Programmierung zu lösen. Erlaubt waren in der Regel C, C++ und Java. Fotos des International Collegiate Programming Wintercontests 2010 findet ihr nun in der Galerie

Time for an update from our team here at Nokia working on Carbide 3.0, Eclipse CDT 7.0, and the new Eclipse Debugger for C/C++ (EDC):

EDC is now part of the regular CDT build. Many thanks to Doug Schaefer for getting this done. I hadn’t done much with the CDT build before and wasn’t making much progress, but Doug resolved a couple tricky issues, like pulling the TCF source in from Subversion. We still have a version of EDC in our CVS so the Carbide team can easily commit stuff, but I’m syncing it every few days.

Custom Variable Formatting in EDC: David committed the first phase of support for custom variable formatting. Using a new extension point a plug-in can alter the way data is shown in the Variables view during an EDC debug session. An extension can provide an alternative to the standard structure and content of any variable type.

We intend to provide formatters for some STL, Qt & Symbian data types. Also there are general purpose formatters for arrays and structs:

 
Unformatted C/C++ struct

Formatted C/C++ struct

Debug Snapshot Albums: A new feature in EDC is the ability to capture a snapshot of the state of your debug session for later review. A new Snapshot Album view shows the available albums of snapshots from prior debug sessions and lets you annotate their contents. Snapshot Albums can be launched to show a re-creation of the original debug session. Tim and I have been overhauling some of the initial work and getting the UI far enough along so that we can start usability testing soon. I’ll write more about this when the work settles down a bit.

Plug & Play Debug Connectivity: We’ve made a lot of improvements in usability when starting a debug session on a phone. We started with a detailed analysis of all the options available when connecting to a phone, then narrowed them down into a new launch wizard that can start a debug session in just a few steps. This will make on-device debugging in Carbide a lot easier and I hope to apply some of the lessons learned when we overhaul the launch experience in CDT.

EDC Symbol Reader Overhaul: Ed & Steve are in the midst of an overhaul of the Dwarf reader in EDC. We originally wrote it for completeness and to have something to build the rest of the debugger around, but knew more work was required to get better performance and memory usage. This effort will likely be continuing for the next several weeks.

Community Contributions to EDC: People are starting to review the code, report bugs, and contribute patches. In particular John Cortell at Freescale has been improving the way EDC connects to TCF agents and providing a fresh perspective on everything from naming to API visibility.

That’s it for now, I’m diving back into the code…

Notepad++, eine kostenlose OpenSource Software, ist ein kleiner Texteditor ähnlich dem Windows Notepad, der jedoch wesentlich mehr Funktionen anbietet und auch mit den Syntaxen aller gängigen Programmiersprachen (C++, Java, XML, HTML, SQL und PHP und weitere) kein Probleme hat. Das Programm ist dabei sehr sparsam im Verbrauch der Ressourcen. Daneben gibt es mittlerweile eine [...]

In our day to day work we often use the term backward compatible. We use this term as if it is a binary: something is backward compatible or it is not backward compatible. And yes, this is true if a client directly works with a provider. If the provider can work with clients that were compiled against a previous version then the provider can be said to be backward compatible with that previous version.

So is this always binary? Nope. The reason is the design by contract rule that we all follow, or should follow. In Java, we have this rule embodied in the interface, in C++ we used abstract classes. The primary advantage of design by contract is that now the client depends on the contract and the implementation depends on the contract but the client no longer depends on the implementation. Not only allows this model to have multiple implementations for the same contract, it also makes the dependencies smaller, more concise, and most important of all explicit. This model is depicted in the next figure.

In the OSGi service specifications clients and implementers are bundles. The contract is defined in a package that is imported by both the client and the implementer. The implementation is (normally) registered as a service under the interface defined in the contract package.

Instead of having two parties, where the backward compatibility was binary, we now have three parties making the situation a tad more convoluted. The compatibility is now expressed against the contract package because client and implementer have no longer any dependency on each other. What kind of changes can we make that do not affect the client? Well, these are the same changes we could make to the implementer in the simple case. Adding members to classes and adding fields to interfaces is harmless for clients of these classes and interfaces, they never know the difference. Even semantic changes are ok as long as we specify the evolution rules in the new contract.

However, the situation is different for an implementer of a contract; an implementer is semantically much closer bound to the contract than the client. A client compiled against version 1 of the contract can be bound to a backward compatible implementer that is bound to version 2 of the contract. However, a client compiled against version 2 of a contract must never be bound to a version 1 implementation because such an implementer has no knowledge of the changes in the contract and can therefore not faithfully implement it.

Interestingly, some of these incompatibility semantics show up in the way Java works. Implementers usually implement a number of Java interfaces; not implementing all the methods in such an interface will throw a No Such Method Error when called, clearly a violation of the new contract. In this article I talk about implementing the contract, however. There are many OSGi specifications where the client is also required to implement interfaces for callbacks but they are still considered clients. For example, in the Event Admin specification the client must implement the Event Listener service. These interfaces are called client interfaces and any change in them is incompatible for a client.

Using the contract model, we must take this asymmetric situation between clients and implementers into account when discussing backward compatibility. Almost any change in the contract will require the implementer to be aware of this change. However, there are a few cases where you can change the contract without requiring the implementer’s awareness. We had such an instance in the upcoming enterprise release. In the previous release, the Blueprint API had no generics, in this release the generic signatures are added. Generics are erased in runtime, therefore existing Blueprint implementations cannot detect the difference in API and there are no additional responsibilities. Such a change is backward compatible for implementers.

I hope it is clear that backward compatibility has 2 dimensions: clients and implementers. When we make a change to the contract we must ask ourselves if this change is compatible with clients and implementers. Theoretically there are four cases, however, in practice any client backward incompatible change is very likely to be implementation incompatible as well, so there are only three cases left. The remaining question is now how to handle these three cases in OSGi. Obviously, the version attribute is the most applicable place to start.

The only party that knows about the change is the person changing contract. This person must somehow must convey its backward compatibility rules to the client and to the implementer. Surprisingly (well not really), these three cases map very well to the three parts of the OSGi version scheme:

• major change – Incompatible for implementers and clients
• minor change – Incompatible for implementers, compatible for clients.
• micro change – Compatible for implementers and clients

Using OSGi version ranges, implementers can import all versions where the major and minor part is fixed and ignore micro changes. For example, when the package that is compiled against has version 2.3.6, then the implementer should import [2.3,2.4). Clients can import all versions where the major part is fixed. For example: [2.3,3). I call this model of importing different ranges based on the version that is compiled against the version policy. There is an implementation policy and a client policy.

This model works very well but it has one huge disadvantage: it requires that exporters follow the OSGi version semantics and not just the syntax. Unfortunately, we punted on the semantics when we had to specify the version attribute. We did recommend a good strategy but we did not mandate it nor was it complete. In practice, this means that people are not carefully versioning their packages (if at all!). It is always tempting to put the specification version on the package because this makes it clear which version of the specification you’re getting when you have to select a package. However, this is the so called marketing version. Netscape Navigator came out as version 4.0 because it had to compete with Internet Explorer 3.0, there never was a version 3.0. In OSGi, we are currently at release 4.2 but if you look at the framework package version you’ll find we’re at 1.5.1, telling you it had 5 client backward compatible changes and since then one implementation backward compatible change. In contrast Wireadmin is still at 1.0. There are valid reasons for marketing versions but they unfortunately do not encode the evolution path the package has taken. It means that clients and implementers can no longer use a version policy to specify their compatibility requirements and must treat the version as an opaque identifier. The dire consequence of this model is that you basically have to rebuild all dependencies for any tiny change because clients and implementers can no longer reason about backward compatibility.

One solution that I proposed many years ago is to export a package under multiple versions. The exporter knows much more about its compatibility with prior versions, being able to specify the compatibility saves the importer from having to make assumptions. However, exporting a package under multiple versions only supports 2 cases for backward compatibility. If it is listed, it is backward compatible, if not, it is not compatible. As I hope this blog has demonstrated, treating backward compatibility as black and white is not sufficient.

I therefore hope it is clear that the exporter must provide different bits of information for the implementers and the clients. This could be a new version like attribute or it could use something like exporting three independent numbers:

• An implementation compatibility number
• A client compatibility number
• A revision number

The author of the contract package would maintain these numbers and incrementing them when the corresponding compatibility broke. This model seems to combine the best of both worlds. It exposes the different compatibilities without any required knowledge on the importer’s side. However, my personal position is that the current version policy works today if people are willing to follow the rules. Anything else will require spec changes. The OSGi has been accurately versioning their packages correctly since 1998. The thousand dollar question is, will others follow these semantics?

Peter Kriens

P.S. In the past year I’ve done some experimenting with automatically generating import ranges based on the exported version in bnd and an implementation and client version policy. You can read about these experiments here.

Ich habe mir das Online-Learning Tool Game Scripts http://home.eduhi.at/teacher/wuerthinger/gamescript/index.php?n1=index angeschaut, dass von einem 16-jährigen entwickelt wurde, damit Anwender „ohne Vorkenntnisse in Java, Java Script, C, C++” mittels der von ihm erfundenen, einfachen Programmiersprache Game Script und einem dazu gestalteten Tutorial das „Programmieren erlernen. Eigentlich fehlen…