# Umstellung eines(riesen)Programmes auf Java:Was bietet Java



## Adventstee (11. Mrz 2008)

Hallo Community.

Wir sind eine Hard/Softwarefirma und haben ein Programm in dem 20 Mannjahre drinstecken.
Da dieses nun etwas betagt ist und langsam unübersichtlich und einfach veraltet wollen wir uns auf neue Wege begeben.
Bisher ein reines Windows Programm.

Wir machen folgendes:
Zeiterfassung und Zutrittskontrolle.
Wir haben also unsere Hardwareterminals die an der Wand hängen und per TCP/IP, Rs232, Rs 485 oder USB angesprochen werden.
Die Daten der Terminals werden per Software abgeholt und darin verrechnet.
Es gibt natürlich auch reine Software Lösungen für die Erfassung.
Wir haben auch Karten die per USB-Leser gelesen und beschrieben werden können.

Wir haben auch ein "Webprojekt" welches per Berkeley Socket an die Software anfragt und die Daten im Browser darstellt.
Das Problem hierbei ist, daß immer eine Verbindung zum Server bestehen muss. Gibt es keine Verbindung kann auch nicht gebucht werden.

Wir wollen nun folgenes:

Gänzlich neue Oberfläche. Bunt, übersichtlich und modern.
Der Code der alles berechnet soll gleich bleiben, bzw. soll dann irgendwie in Java implementiert werden können.
(Ist ein (ANSI)reiner C-Code.)
Es dreht sich also rein um die Oberfläche.

Die Frage ist nun was Java alles kann.
Hier die anforderungen:

- Oberfläche soll grafisch modern sein (kein Einheitsgrau)
- Menü soll dem User entsprechen angepasst werden können. Also Menüpunkte hinzufügen/entfernen.
- Multi User und Multithreading fähigkeit
- Es sollen die *gleichen Klassen *für ein Java Applet und Java Anwendung benutzt werden können.
- Ansprechen der Seriellen und USB Schnittstellen auf allen Plattformen.
- Einbinden und verwenden der *vorhandenen C-Funktionen *(ca. 600 C- Dateien mit 500-3000 Codezeilen)
- Nutzen von Airport unter Mac OSX (iMAc)


Es sollen viele Funktionen aus der jetzigen Software rausfliegen und nur auf das meist gebrauchte beschränkt werden.
Wir werden und dafür 2 Jahre Zeit lassen und unsere Vorhandenen Produkte weiterhin verbessern und supporten.

Es soll eine Software geben die also Applikation läuft also auch verteilt im Webbrowser.
wenn jetzt der Kollege Klassen schreibt für die Applikation, zb. Datenzugriff und bereitstellung dieser, kann ich dann diesselbe  als Applet für den Webbrowser einbinden?

Mit Asp.net/C# geht das, das hab ich schon getestet.

Daß man USB Schnittstellen nicht ansprechen kann, weiß ich bereits, die Frage ich jedoch, geht das wenigestens unter *Windows*?
Kann ich da vorhandene C/C++ Bibiotheken einbinden?

Wie sieht es mit Linux und vor allem Mac OSX aus?
Gibts dafür vorhandene Bibiotheken? (jUSB, was taucht das?)

Die Software wird von 5-1000 Mitarbeiter, je nach Anforderung *gleichzeitig* genutzt.
Eignet sich Java dafür?

So, das wars erstmal.
Danke fürs lesen und antworten...
Grüße Adventstee


----------



## The_S (11. Mrz 2008)

Hi Advenstee,

bist du dir sicher, dass für eine derartige "Planung" ein öffentliches Forum die richtige Ansprechstelle ist? Sollte das nicht evtl. druch einen/mehreren professionellen Consultants erledigt werden? Also ich als Chef, würde mich nicht nach den Beiträgen eines Forums richten, aber ok ...



			
				Adventstee hat gesagt.:
			
		

> - Oberfläche soll grafisch modern sein (kein Einheitsgrau)



Durch die Unterschiedlichen Look and Feels ist das sehr einfach in Java zu realisieren



			
				Adventstee hat gesagt.:
			
		

> - Menü soll dem User entsprechen angepasst werden können. Also Menüpunkte hinzufügen/entfernen.



kein Problem



			
				Adventstee hat gesagt.:
			
		

> - Multi User und Multithreading fähigkeit



kein Problem



			
				Adventstee hat gesagt.:
			
		

> - Es sollen die *gleichen Klassen *für ein Java Applet und Java Anwendung benutzt werden können.



Es muss irgendwo natürlich angegeben werden, ob ein JFrame (Anwendung) oder ein JApplet (Applet) verwendet werden soll. Aber Wenn das Applet dann signiert wird, sollte das auch ohne größere Probleme möglich sein.



			
				Adventstee hat gesagt.:
			
		

> - Ansprechen der Seriellen und USB Schnittstellen auf allen Plattformen.



Für diese Schnittstellen gibt es einige gute Libs - aber inwieweit diese plattformabhängig sind, kann ich nicht beurteilen, da ich noch nicht mit diesen Libs gearbeitet habe. Ich denke aber mal, dass man das auch Plattfromunabhängig hinbekommen sollte



			
				Adventstee hat gesagt.:
			
		

> - Einbinden und verwenden der *vorhandenen C-Funktionen *(ca. 600 C- Dateien mit 500-3000 Codezeilen)



Über JNI ist es möglich C(++) Code in Java einzubinden



			
				Adventstee hat gesagt.:
			
		

> - Nutzen von Airport unter Mac OSX (iMAc)



Uff ... kA was das ist. Ich war noch nie vor einem MAC gesessen


----------



## Adventstee (11. Mrz 2008)

Hobbit_Im_Blutrausch hat gesagt.:
			
		

> Hi Advenstee,
> 
> bist du dir sicher, dass für eine derartige "Planung" ein öffentliches Forum die richtige Ansprechstelle ist? Sollte das nicht evtl. druch einen/mehreren professionellen Consultants erledigt werden? Also ich als Chef, würde mich nicht nach den Beiträgen eines Forums richten, aber ok ...



Hallo Hobbit.
Ja das ist schon klar und das werden wir auch tun.
Es ist nur so, daß in einem Forum indem viele Erfahrene Leute zusammenkommen es viele verschiedene Meinungen gibt und genau diese Interessieren mich 

Deine Antworten klingen schonmal gut, die (schmerzliche) Erfahrung werden wir dann schon selbst machen müssen
Airport für Mac ist nichts anderes als eine eingebaute WLAN Karte


----------



## neumi (11. Mrz 2008)

Also zum Thema RS232 Schnittstellen und verschiedenen OS

Grundsätzlich kann java nicht auf die Schnittstellen zugreifen, aber nätürlich hat SUN eingigen Lösungen einfallen lassen.

In Windows muss dazu eine DLL eingebunden werden, welche natürlich unter UNIX nicht funktioniert.

Aber auch dafür gibt es einige Lösungen. Aber ich habe da meine Zweifel das dieser Zugriff auf die RS232 Schnittstelle Betriebssystem unabhängig ist. [lasse mich gerne verbessern]


----------



## Adventstee (11. Mrz 2008)

Naja vielleicht weiß das der eine oder andere hier.

Da es die Serielle Schnittstelle immer weniger gibt, denke ich ist das nahezu vernachlässigbar und wir sollten verstärkt auf USB 2.0/3.0 setzen.

Das Problem hierbei ist: Es geht immer mehr richtung Web-Applikation.
Also es soll eine Web-Desktop Anwendung werden.
Der Abgleich mit einer Java anwendung auf einem Webhoster im Internet (Java läuft ja überall, im Browser oder)
usw usf...

Die Alternative wäre eben asp.net/c# wobei wir dann Plattform gebunden wären...


----------



## J.C. (11. Mrz 2008)

Hallo,

die frage die sich heut zu tage stellt ist doch: Java oder .Net... und da tendiere ich doch klar zu Java. Warum? Kostengünstig, moderne Techniken und Frameworks (OSGi, EJB) gute Applikationsserver (JBoss) einfache realisierung von Fontends (JSP). 

Soll das Frontend nur im Browser "erscheinen" dann könnte man auch mit anderen Programmiersprachen arbeiten. Will man aber anwendungen auf verschiedenen BS laufen lassen dann bleibt "nur" Java als alternative. .Net anwendungen auf einem Linux oder Mac rechner laufen zu lassen ist quasi nicht möglich. Es gibt bereits erste ansätze, die das realisieren >wollen< ist aber auf keinen Fall für professionelle Software empfehlenswert.

Wie von Hobbit im Blutrausch erwähnt, lassen sich Bibliotheken anderer Programmiersprachen mit dem Native Interface einbinden.

Das wars was mir dazu einfällt 


MfG,
J.C.


----------



## Adventstee (11. Mrz 2008)

Das hieße also, ich könnte irgendwelche unix Bibliotheken nehmen und damit die USB Schnittstelle ansprechen?
Das Problem bei Java und Mac OS ist eben, daß Apple immer hinterher ist.
FÜr JAva 6 müsste jeder Anwender das neueste Mac OX (Leopard) haben...das wird auch nicht jeder wollen...

Die Anwendung soll dann eben auf allen möglichen Ebenen laufen. Vom Handheld über den Tablet PC bis zum handy...(eingeschränkt natürlich)


----------



## Gast (11. Mrz 2008)

Hallo,

Wieviel Erfahrung habt ihr eigentlich mit Java allgemein bzw. in der objectorientierten Softwareentwicklung ?

Also mittlere bis groesere JavaProjekte benoetigen eine Architektur. Insbesondere, wenn man eine Mulitchannelfaehigkeit (Desktop + Weboberflaeche) herstellen moechte. 

Desweiteren ist Java ein sehr sehr weites Feld angefangen von Spring, JPA, Hibernate bis zu JSF, Struts, Eclipse RCP etc.. Uebrigens ganz zu schweigen von MDA etc... 

Mal ein Skizze was auf euch zukommt um SINNVOLL Java Projekte abwickeln zu koennen.

Definition eines passenden Entwicklungsprozesses 
 - Anforderungsanalyse
 - Formalisierung der Anforderungen
 - Dokumentation der Anforderungen

Erstellung einer ReferenzArchitektur
    - DB Anbindung (JPA ...) 
    - Interaktion der einzelnen Schichten und "Module" (Spring, WebServices ...)
    - Frontendentwicklung (JSF, Swing, RCP ...)
    - "Verbindung mit der Hardware"
    - Transformation der Doku in Code ("Transformaionsmodell")

Erstellung eines BuildManagement  (z.B. mit maven)

Erstellung Testmanagement

Werkzeugauswahl etc. etc. etc.

Die Liste duerfte noch weitaus laenger sein...

Am Ende eine Schlussbemerkung:

Du stellst hier grundlegende technische Fragen, ihr habt wenig oder keine Erfahrung mit Java Projekten und ohne euch zu nahe tretten zu wollen: Ihr habt vermutlich die technische Entwicklung der letzten zwei bis vier Jahre verpennt... (Spring, JPA, Hibernate, JSF, MDA, Flex...)

aber ihr habt bereits einen Rahmenterminplan:



> Es sollen viele Funktionen aus der jetzigen Software rausfliegen und nur auf das meist gebrauchte beschränkt werden.
> Wir werden und dafür 2 Jahre Zeit lassen und unsere Vorhandenen Produkte weiterhin verbessern und supporten.



DAS KANN SO NICHT FUNKTIONIEREN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

weitere Anmerkung:

Sagen euch Begriffe wie Ajax ,Flex oder auch JavaWebStart eigentlich etwas ? 



Ich hoffe ich war nicht zu direkt, falls ja moechte ich mich dafuer entschuldigen...

Es ist zwar eine etwas komische Art der Kundengewinnung aber einige Dinge muessen einfach ausgesprochen werden... Falls du dennoch ein Interesse an einer Zusammenarbeit hast wuerde ich mich freuen, wenn du an folgenden E-Mail Adresse ein Nachricht schicken koenntest. "klarkimming@gmx.net" (dies ist nicht meine "normale" Geschaeftsemailadresse!, die moechte ich hier nicht veroeffentlichen).

KurzProfil:

- Teil eines Zwei Personenteams
- Spezialisiert auf Java-Softwareentwicklung. Als Basis dienen modere Technologien und Ansaetze
- meine Berufserfahrung mehr als zwei Jahre
- Berufserfahrung meines Teammitglieds (ueber 15 Jahre...)

Fazit wir haben eine gute Mischung aus Innovationsfreude und sehr viel Erfahrung... Der Bereich Hardwareanbindung gehoert allerdings nicht zu unseren Kernkompetenzen. 

Gruesse

Gast


----------



## byte (11. Mrz 2008)

Gast hat gesagt.:
			
		

> Uebrigens ganz zu schweigen von MDA
> 
> [...]
> 
> ...



Das klingt aber sehr akademisch... erinnert mich an meine Studienzeit. :roll:


----------



## tfa (11. Mrz 2008)

> DAS KANN SO NICHT FUNKTIONIEREN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Unser anonymer Gast hat in seinen mehr als zwei Jahren Berufserfahrung wohl noch nicht so viel gesehen, was in der realen Welt alles möglich ist.  :lol:


----------



## Janus (11. Mrz 2008)

2 jahre für die portierung einer ansi c anwendung mit ca. 1 mio zeilen code nach java sind aber schon recht sportlich angesetzt.


----------



## Gast (14. Mrz 2008)

Janus hat gesagt.:
			
		

> 2 jahre für die portierung einer ansi c anwendung mit ca. 1 mio zeilen code nach java sind aber schon recht sportlich angesetzt.



1 mio Zeilen? Geht aber aus den Anforderung nicht hervor. Bestehender c Code soll ja nach Möglichkeit wiederverwendet werden. (JNI)

Wenn es nur um eine neue Oberfläche geht, ist es auf jeden fall realistisch. Dazu kommt der Austausch der Hardwareanbindungsschicht, die aber sicherlich getrennt davon betrachtet werden kann. Somit könnte man mit und mit einzelne Komponenten der Anwendung auf Java migrieren.

Wobei die Modernisierung der Oberfläche eventuell die Kernaufgabe darstellt. Wenn alles andere weiterverwendet kann muss es nicht ausgetauscht werden ?!


----------



## quippy (14. Mrz 2008)

Bei JNI aus einem Servlet im JBoss (oder anderem Applikationserver) habe ich immer etwas Bauchschmerzen  - die vor allem daher rühren, daß wir damit schon mal gut auf die Klappe gefallen sind.

Grundsätzlich funktionert das JNI super. Dummerweise reißt ein Fehler in den angesprochenen NativeBibliotheken gerne die gesamte Virtuelle Maschine mit runter - d.h. in diesem Fall den ganzen Applikation-Server!

Das bedeutet, ein kleiner Fehler wie ein Memory-Leak in einer der Bibliotheken, welches so nicht auffällt, würde nun nicht in einem Käfig explodieren, sondern alle Anwendungen, die im Web hängen, mit betreffen und stoppen.

Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.


----------



## maki (14. Mrz 2008)

> Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.


Gehört JNI nicht zu den Dingen, die man in einem App Server nicht machen darf/soll, wie zB Dateien direkt mit java.io.File lesen/ändern?


----------



## quippy (14. Mrz 2008)

maki hat gesagt.:
			
		

> > Wie gesagt, wenn das Zeuch läuft, dann ist das eine gute Idee - aber vielleicht sollte man darüber nachdenken, die C-Calls und den JBoss zu entkoppeln.
> 
> 
> Gehört JNI nicht zu den Dingen, die man in einem App Server nicht machen darf/soll, wie zB Dateien direkt mit java.io.File lesen/ändern?



Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.

Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?


----------



## maki (14. Mrz 2008)

> Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.
> 
> Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?


File ist nicht transaktional(!), ausserdem kann eine EJB einfach mal so auf einem anderen Server laufen als noch vor 30 Sekunden( darum geht es doch bei EJBs ), also ist java.io.File :noe: ein im AppServer.  

Sage nicht das es nicht geht, aber es ist halt prinzipiell falsch 
Genauso wie eigene Threads im AppServer starten.


----------



## sliwalker (14. Mrz 2008)

maki hat gesagt.:
			
		

> > Klar darfst Du JNI machen - wie gesagt, es ist gefährlich, aus beschriebenem Grund. Darum wird es nicht empfohlen.
> >
> > Aber warum sollte man denn nicht mit java.io.File-Objekten arbeiten?
> 
> ...



Hi,

finde ich interessant...
Kann man das irgendwo genauer lesen?
Wir haben eine Schnittstelle die verschiedene Dateien einliest und dawird mit java.io.File Objekten gearbeitet.
Das würde ich dann natürlich gerne ändern wollen, wenn es wirklich so schlimm ist.

Kannst Du mir mehr darüber sagen oder eine Quelle geben wo ich was nachlesen kann?

Danke, 

SLi


----------



## maki (14. Mrz 2008)

> Kann man das irgendwo genauer lesen?


Servus,

aus der EJB 3.0 SPek:


> 21.1.2 Programming Restrictions
> This section describes the programming restrictions that a Bean Provider must follow to ensure that the
> enterprise bean is portable and can be deployed in any compliant EJB 3.0 container. The restrictions
> apply to the implementation of the business methods. Section 21.2, which describes the container’s
> ...


"Schlimm" ist relativ, in manchen Containern funktoniert das trotzdem (zumindest bis zu einem bestimmten Grad), aber der Standard sagt es ist "schlimm".


----------



## sliwalker (14. Mrz 2008)

Hoi,

danke für Deine Mühe!
Hat mir sehr geholfen. (Hätt ich aber wohl auch selbst finden können  ) Deshalb doppeltes Danke.

greetz
SLi


----------

