Perché Java viene spesso utilizzato per le applicazioni aziendali? [chiuso]


Come principiante di Java mi chiedo: di tutte le lingue del mondo, perché Java viene spesso utilizzato per le applicazioni aziendali? Cosa lo rende così rispetto alle altre lingue? Continuerà ad essere così nei prossimi anni?

Apprezzerei le tue intuizioni. Grazie in anticipo:)

Author: alimango, 2009-07-29

11 answers

Una parola: librerie. Java ha una vasta gamma di librerie eccellenti per risolvere la maggior parte dei problemi comuni che è necessario risolvere quando si sviluppano applicazioni aziendali. In molti casi, c'è più di una buona scelta per affrontare una particolare esigenza, e spesso quelle librerie sono gratuite e open source sotto una licenza business-friendly.

Alcuni hanno sostenuto che ci sono, in realtà, troppe scelte nell'ecosistema Java e che lo sviluppo di software aziendale in Java richiede gli sviluppatori di prendere un gran numero di decisioni che possono avere un impatto di vasta portata sul prodotto finale nel bene e nel male. Questo ha probabilmente contribuito a spingere la popolarità di alternative come. NET, che ha la reputazione di offrire meno scelte, ma con i vantaggi di uno stack di applicazioni più ben integrato e set di strumenti. Quale direzione scegli dipende, immagino, dal fatto che tu attribuisca più valore alla "libertà di scelta" o alla "libertà di scelta".

 39
Author: Rob H, 2009-07-29 13:39:57

Ci sono molte ragioni per cui una grande azienda (il tipo per le soluzioni aziendali) sceglierebbe Java. Nota che non sto dicendo che tutti questi motivi siano corretti o validi. Ma il punto rilevante è che sembrano validi per un CTO di MegaCorp.

Curva di apprendimento

Java è un linguaggio semplice senza gran parte della flessibilità degli altri membri della famiglia C, questo taglia entrambi i modi, ma è visto come un linguaggio semplice per l'uso da parte di un esercito di programmatori. Progetti aziendali tendono a coinvolgere un gran numero di sviluppatori (a torto oa ragione) ed è molto più facile portare uno sviluppatore a un livello minimo di competenza in Java rispetto al C++. Hai anche un'intera generazione di laureati che probabilmente sono stati in gran parte istruiti a Java.

Scelta

Java ha una vasta gamma di librerie, framework, strumenti e IDE e provider di server. Per un'impresa è bene avere scelta, anche se questo è solo per l'uso come merce di scambio quando si negozia il prezzo. Il il linguaggio si presta a strumenti di qualità del codice che consentono l'applicazione degli standard aziendali (e come detto ci sono molti di questi strumenti).

Indipendenza della piattaforma

Java è scrivere una volta, eseguire (bene, eseguire il debug) ovunque. Sun ha attivamente incoraggiato gli standard aperti che consentono a più fornitori di implementare le loro soluzioni. Questi standard offrono al cliente la comodità di poter migrare da un fornitore all'altro se un determinato fornitore va sotto o inizia a caricare di più. Di naturalmente la realtà è che ogni fornitore fa del suo meglio per fornire alcune caratteristiche di "valore aggiunto" che legano il cliente a loro abbastanza bene.

Scadenza

È stato in giro per molto tempo, eseguendo molti server. Se la tua applicazione web deve essere "6 sigma" o simile e tu sei il CTO di MegaCorp, non guarderai gentilmente Joe lo sviluppatore che vuole farlo in RoR.

Tempistica / Commercializzazione

Java è uscito quando la programmazione era in movimento verso il web. È stato posizionato in modo intelligente e ha ottenuto una posizione di forza all'inizio dello sviluppo web. A causa degli standard aperti, ci sono alcune grandi aziende che producono queste piattaforme e commercializzano Java piuttosto difficile da vendere quelle piattaforme.

Inerzia

Le grandi aziende avanzano a un ritmo glaciale (molti stanno ancora usando Java 1.4 cinque anni dopo il rilascio di 5), quindi una volta scelto Java, ci vuole un enorme investimento per passare a un'altra piattaforma. Con ciascuno il giorno che passa stanno tirando fuori più Java che avrebbe bisogno di essere migrato. La maggior parte di queste aziende non sono principalmente negozi di codifica, quindi è una vendita molto difficile convincere il business a spendere poche decine di milioni riscrivendo la loro intera base di codice per nessun beneficio immediato di business.

 24
Author: Rich Seller, 2009-07-29 03:27:55

Un altro motivo potrebbe essere la cura che Sun ha preso per mantenere Java retrocompatibile. La stragrande maggioranza del codice Java può essere eseguito sull'ultima versione della JVM senza problemi. Questo è un bel risultato, data l'età di Java. D'altra parte si potrebbe sostenere che Java non è cambiato molto in tutti questi anni.

Alle imprese piace la stabilità in una piattaforma.

 9
Author: Jeroen van Bergen, 2009-07-29 06:10:55

Sun ha mirato a Java per parlare alle esigenze delle imprese nella fase iniziale. Spinge gli standard che promuovono l'indipendenza dei fornitori a tutti i livelli. Indipendente dalla piattaforma, indipendente dal database, indipendente dal server delle applicazioni, ecc.

Inoltre hanno promosso strumenti di livello enterprise per l'it, in termini di messaggistica, gestione delle transazioni e altre cose di cui l'enterpise si preoccupa.

Prima di Java, le cose di livello enterprise tendevano ad essere fatte in C++ (c'erano molte eccezioni (lo fa qualcuno ricorda PowerBuilder?) ma questa era la regola) e Java si adatta bene come successore di C++ per le applicazioni aziendali, dove quel tipo di gestione della memoria non è qualcosa che vale la pena pagare.

Oltre a tutto ciò, il linguaggio stesso parla alle imprese in termini di evitare costrutti difficili da ottenere che possono davvero rovinare una base di codice, come il sovraccarico dell'operatore. Le applicazioni di livello enterprise tendono ad essere gestite da molte mani diverse, non tutte al top i programmatori di linea, e avere reti safty per evitare di sparare se stessi nel piede è una cosa desiderabile.

È arrivato anche al momento giusto. Un nuovo paradigma (questo era ben prima che. NET esistesse) che prometteva di combinare più fornitori in una capacità di competere con Microsoft, che ha ottenuto artisti del calibro di IBM e Oracle a bordo, che è successo a riempire un nuovo buco, che era il requisito emergente per sviluppare applicazioni web, dove C++ non era più una scelta ovvia.

 8
Author: Yishai, 2009-07-29 03:00:19

Il business è tempo, denaro e opportunità.

L'uso di Java significa che il numero di errori nel codice diminuisce, semplicemente perché i puntatori sono difficili. Si utilizza un GC e si rimuove immediatamente un'intera classe di errori dal codice.

In secondo luogo, Java è stato uno dei primi linguaggi a essere fornito con una libreria di funzioni pre-scritta, che in realtà copriva gran parte della fase di sviluppo. Questo ha limitato il modo in cui le cose sono state fatte, ma significava che le persone potevano imparare più velocemente, aveva più strumenti a loro disposizione e aveva un grande set di librerie per fare cose come rete, GUI, web, crittografia ecc. Java da solo come linguaggio non era così speciale, ma Java più l'API Java era.

Quindi, se hai un linguaggio che ha meno errori e più infrastruttura gratuitamente, finisci con più codice in meno tempo. Certo il codice non cura il cancro, non è veloce come il codice C++ per raggiungere lo stesso compito, ma raggiungerà l'obiettivo dell'azienda di ottenere un applicazione.

Se crei più codice, per meno soldi, puoi perseguire più opportunità. Quindi porti l'inerzia al tavolo in termini di codice già implementato in Java e inizi a vedere perché l'azienda non vuole allontanarsi dalla propria zona di comfort.

 7
Author: Spence, 2009-07-29 02:56:13

Non dovrei dirlo, ma...

La vera ragione è perché prende il nome dal caffè!

 7
Author: Powerlord, 2009-07-29 13:45:32

Personalmente credo che uno dei motivi principali sia il problema multipiattaforma.

I programmi Java scritti "correttamente" (senza ipotesi del sistema operativo sottostante) possono essere eseguiti su qualsiasi JVM. Ciò significa che non sei legato a una particolare piattaforma, a differenza di.NET che ti sposa con Windows.

Ho visto il codice Java eseguito su mainframe, router Linux, all'interno del database Oracle e naturalmente su PC.

 3
Author: Thorbjørn Ravn Andersen, 2009-07-29 09:09:18

È economico, RAD, multipiattaforma e gli sviluppatori abbondano.

 2
Author: Ehtyar, 2009-07-29 02:34:00

Lo sviluppo in C++ è troppo lento e costoso e.NET non è stato in giro abbastanza a lungo. L'inerzia degli affari è enorme, ricorda.

Le aziende vogliono lingue supportate da un fornitore professionale (es. una società come Sun) e spesso stare lontano da linguaggi Open Source per il semplice motivo che non è stato scritto da una società.

 2
Author: Leonard Ehrenfried, 2009-07-29 02:41:49

Anche per le applicazioni client-server, si dispone di un'abbondanza di scelte per i server di app di qualità di produzione che hanno la stessa interfaccia J2EE (IBM WebSphere, BEA Weblogic, JBoss). In alternativa, è possibile utilizzare il framework Spring su qualsiasi server come Apache Tomcat conforme all'API Servlet se si è convinti di non aver bisogno di EJB. In contrasto con. NET, è difficile trovare scelte rispetto ai server di app.

Ci sono un'abbondanza di scelte per quanto riguarda i quadri per un dato compito che si tratti di uno strumento ORM, registrazione, raccolte, caching, interfacce utente web, ecc. Non c'è quasi nessuna necessità di reinventare la ruota.

Infine, mentre è di moda in questi giorni per lamentare le carenze molto reali di Java il linguaggio, è un linguaggio in cui la gente sa come fare le cose e come evitare certi anti-modelli.

 2
Author: Alan, 2009-07-29 02:53:04

Le altre risposte sono tutte buone. Due cose devono essere aggiunte, standard aziendali e l'effetto carrozzone. Se vuoi costruire un sistema aziendale devi avere un caso abbastanza forte per non utilizzare gli standard radicati della tua azienda e questo è principalmente JavaEE. E se hai bisogno di risorse per un progetto è molto più facile reclutare un programmatore Java di quanto non sia, ad esempio, Erlang.

 2
Author: Paul McKenzie, 2009-07-29 08:03:42