Fontos linkek Fontos linkek

  • WEB mail
  • Telefonkönyv
  • PTE
  • PMMK
  • ETR

Állásajánlatok Állásajánlatok

A <em>java</em> cimkéjű tartalom.

Nincs eredmény.

Kiemelt hírek Kiemelt hírek

A <em>java</em> cimkéjű tartalom.

Nincs eredmény.

Hírek Hírek

A <em>java</em> cimkéjű tartalom.

Kész a Java 9

Hosszú-hosszú csúszás után immár elérhetőek a Java platform újdonságai. A jövőben gyorsított fejlesztés, erőre kapó innováció várható - legalábbis az Oracle ígérete szerint.

Megjelent immár hivatalosan is a hosszú ideje készülő Java 9 - jelentette be az Oracle csütörtök délután. A hosszú éveket csúszó megjelenés már nem meglepetés, a szoftver készülő verziói az elmúlt hónapokban széles körben elérhetőek voltak, így már az újdonságokról is viszonylag pontos képe van a szakmának - azért érdemes felemlegetni, milyen irányba is fejlődik a platform.

Java SE 9

A legnehezebb szülés egyértelműen a Java Platform Module System (JPMS). Ahogy korábban írtuk: ez igazi áttörés a Java történetében, amely egy alapoktól újragondolt, szabványos modularitást hoz az ökoszisztémának. A Jigsaw szülése azonban elképesztően nehezen ment, a Javát átvevő Oracle még 2010-ben (!), a Java 7 kapcsán helyezte kilátásba annak implementációját, ehhez képest most, hét évvel később is csak nagyon nehezen sikerült betolni a technológiát a hivatalos szabványba.

A modularitás meglehetősen általános fogalom a programozásban, a Java jelenleg is tartalmazza ezt bizonyos formában, például a JAR állományokkal, az OSGi-n keresztül vagy külső keretrendszerekkel, mint a Spring. A JPMS ezekhez képest azonban jelentős és átfogó ugrást ígér, amit maga a nyelv és a JDK kap meg, nem kell majd hozzá külön frameworköt használni.

A JPMS olyan fejlett képességeket ígér, mint a modulok dinamikus töltése és ürítése memóriából, azok verzióinak kezelése (sőt: ugyanazon modul több verziójának párhuzamos futtatása), az explicit függőségkezelés, stb. A fejlesztés két fő irányelvet követett: megbízható konfiguráció és erős tokozás. Előbbi a class-path mechanizmust cseréli egy modern függőségkezelésre, utóbbi egyértelművé teszi, hogy mely publikus típusok érhetőek el más komponensek számára és melyek nem.

A modularitásra egyébként a Java skálázódása miatt lett égető szükség: a nyelv ugyanis nem tudott hatékony választ adni a modern szerveroldali alkalmazások által támasztott követelményekre, amire rásegített az is, hogy a fejlesztést de facto ma is irányító Oracle évekig tétlenségre kényszerítette az ökoszisztémát. Ez lehetővé tette az olyan nyelvek szerveroldali térnyerését mint a JavaScript (Node.js), a Java 9 így egyértelműen erre jön válaszcsapásként. A JPMS/Jigsaw egyébként a JDK-ban is tiszteletét teszi, tehát a jövőben az alkalmazások mellé elegendő csak a felhasznált modulokat csomagolni, nincs szükség a teljes keretrendszerre.

Egy másik említésre méltó újdonság a JShell, amely REPL-t (read-eval-print loop) hoz a Javának. A gyakorlatban ez egy "parancssor", amelyet azonnal végrehajt a futtatókörnyezet és visszaadja az eredményt, ilyen eddig csak külső termékek részeként volt elérhető, a JDK-ban nem. A JShell például a nyelv tanulását is könnyebbé teszi, az egyes sorokat egyenként is ki lehet próbálni benne.

A Java 9 immár alapból támogatja a HTTP/2-t, az új generációs internetes/webes protokollt, így immár ehhez sem kell külső könyvtárakra támaszkodni például a webes alkalmazások fejlesztésénél. Az újdonság nem elhanyagolható, az új protokoll lényegesen gyorsabb, alacsonyabb késleltetés mellett és a JDK részeként immár minden Java-fejlesztő számára elérhetővé vált.

Apró újdonság a JEP 254, amely a stringek hatékonyabb reprezentációját hozza. Eddig ugyanis ezek az értékek kétbájtos char elemekből alkotott tömbként jelentek meg a Java legelső kiadása óta, ez viszont sokszor pazarló, nem minden karakterhez van szükség a két bájtra. A string osztály új implementációja már byte tömböt használ, ezt egészíti ki egy kódolást végző mező, ez mondja meg, hogy a stringben a kétbájtos UTF-16 karakterek vannak-e vagy egybájtos Latin-1 karakterek. A jó hír, hogy annak ellenére, hogy egy nagyon alapvető osztályhoz nyúl hozzá, a változás teljes visszafelé kompatibilitással rendelkezik, a sok stringet használó alkalmazások pedig automatikusan profitálnak az előnyből, például a kisebb memóriafoglalásból - és a kisebb memóriafoglalásból eredő ritkább szemétgyűjtésből.

A JEP 263 az asztali alkalmazások számára lesz fontos, ez végre elhozza a JDK-ba a skálázódást Linux és Windows platformokon is - erre a nagy pixelsűrűségű kijelzők terjedése miatt volt szükség. A maces kiadás korábban megkapta a "retina" kijelzők támogatását, mostantól azonban a valamivel népszerűbb Microsoft-féle operációs rendszeren is működik az alkalmazások skálázása.

További érdekességekért érdemes a változások hivatalos listáját végignyálazni. És érdemes ehhez a gesztushoz hozzá is szokni, a jövőben ugyanis a Java SE hathónapos kiadási ciklusra áll át, így az eddigiekhez képest sokkal sűrűbben kell olvasni a változások listáját. Hogy azért ne legyen túl erős a változás tempója, bizonyos kiadások "hosszanfriss" státuszt kapnak és minimum 3 éves támogatási periódust élveznek majd.

Java EE 8

A Java SE 9 mellett szintén megjelent a (hasonló türelmetlenséggel várt) Java Enteprise Edition 8 kiadása is. A kiadás egy adott pillanatban még veszélybe is került, de a megfelelő pillanatban gyakorolt iparági nyomásra az Oracle végül csak úgy döntött, hogy elkészíti a Java EE 8-at, a következő verziókról azonban már a közösségnek kell gondoskodnia - ezért a csomagot át is adta az Eclipse Foundationnek.

A Java EE 8 szintén rengeteg fontos újdonságot hoz a platform számára. Ezek között megemlíthető a Servlet 4.0-ba érkező HTTP/2 támogatás, egy új biztonsági API felhős és PaaS-on futó alkalmazások számára, az aszinkron események jobb támogatása a CDI 2.0-ban, illetve a JSON-B és JSON-P is funkcionálisan bővült. Az EE 8 részeként érkezik a JAX-RS 2.1 kiadása is. Izgalmas kérdés a jövőre nézve, hogy a MicroProfile, az Oracle-től független kezdeményezés a javás microservice-ek fejlesztésére hogyan épül majd vissza az EE-be - korábban a MicroProfile is az Eclipse Foundationhöz került, így logikus lépés lesz a két projekt egyesítése.

A Java EE 8-cal egyidőben az ingyenes futtatóplatform, a Glassfish 5.0-s kiadása is megérkezett, amely már értelemszerűen támogatja az EE 8 újdonságait is. A szerver már letölthető a projekt oldaláról.

 

forrás: hwsw.hu

A közösségnek adja a Java EE-t az Oracle

Átengedi a vállalati Java-platform irányítását az Oracle a közösségnek. Egyelőre nincs meg az új irányító szerv, folynak a tárgyalások a jelölt szabad szoftveres alapítványokkal.

Független közösség gondoskodik a jövőben a Java Enterprise Edition (EE) fejlesztéséről - jelentette be az Oracle. A vállalati Java-platform fejlesztéséből a cég hamarosan, a Java EE 8 érkezését követően kiszáll, a projekt irányítását pedig egy alapítvány kezébe helyezi majd, amely gondoskodik majd a fejlesztésről. Egyelőre nem tiszta, hogy melyik szabad szoftveres alapítvány viszi majd tovább a fejlesztést, a tárgyalások ebben a kérdésben még zajlanak a jelöltekkel.

A Java EE referencia implementációja illetve a kompatibilitási tesztcsomag jelenleg is nyílt forráskódú, a fejlesztés irányítását pedig elvben a Java Community Process végezte - a gyakorlatban viszont az Oracle kézben tartotta a döntési folyamat egészét, nagyjából hasonló módon, ahogy a szintén nyílt forráskódú Chromium projektet a Google, a Swiftet pedig az Apple tartja markában. A változás első körben tehát a vezetést érinti, az Oracle lemond erről a privilegizált helyzetéről és a Java EE fejlődési irányának meghatározását egy testületre bízná. Ez az irányítási modell egészen elfogadottnak számít, jellemzően a projekt legnagyobb támogatói neveznek ki tagokat egy bizottságba, amely a fontosabb döntéseket hozza, a mindennapi teendőket pedig egy kis ügyvezető csapat végzi el.

Ennél valamivel fontosabb kérdés az Oracle jövőbeni szerepvállalása: a cég ugyanis nem csak az irányítást, hanem a fejlesztés finanszírozását is magára vállalta eddig. A közösségi fejlesztéstől az Oracle egészen biztosan azt várja, hogy más, a Java EE sikerében érdekelt szereplők is beszállnak erőforrásokkal a fejlesztésbe, legyen az készpénz, infrastruktúra, vagy fejlesztőmérnökök munkaideje. A bejelentés annyit leszögez, hogy az Oracle "szerepet vállal a Java EE technológiák jövőbeni fejlődésében", vagyis arról azért nincs szó, hogy a cég hátat fordítana a platformnak.

Az Oracle igyekszik is megnyugtatni partnereit, hogy a bejelentés nem hoz változást a cég elkötelezettségeit illetően, a fejlesztők, felhasználók, vásárlók, partnerek és licencvásárlók felé sem. "Támogatni fogjuk a jelenlegi Java EE implementációkat és a Java EE 8 jövőbeni implementációit" - ígéri a cég. Ugyanakkor hasonló vállalás nem hangzik el a 8-as utáni, immár közösségi irányítás alatt készülő implementációk kapcsán, de a cég nem is zárkózik el ettől.

WebLogic - mit jelent ez?

Az Oracle külön blogposztban igyekezett oszlatni a félelmeket a WebLogic-vásárlók számára. A WebLogic Server ugyanis tartalmaz szabványos Java EE-implementációt, így nyilván érinti a bejelentés ezt a szoftvercsomagot is. Az Oracle szerint a bejelentésnek "nincs rövid távú hatása" a szoftverre, a kiadott termékekre áll a korábban megadott támogatás, marad a WebLogic Server elérhetősége az Oracle Cloudon és jönnek a szoftverből új kiadások is a jövőben.

A fentiekkel együtt ugyanakkor csak a Java EE 8 támogatására tesz ígéretet a cég a WebLogic Server kapcsán is, a várhatóan 2018 folyamán érkező friss verzió kapja meg a teljes kompatibilitást "HTTP/2 támogatással, JSON-feldolgozással és a REST-hívások kiterjesztett támogatásával". Ez a gyakorlatban azt jelenti, hogy a WebLogic Server még hosszú-hosszú évekig nyújtana platformot a vállalati felhasználóknak még abban az esetben is, ha az Oracle a Java EE 8 után teljesen kiszállna ebből az ökoszisztémából.

Java EE 8 - hamarosan készen

A fenti döntés kontextusát a tavalyi vita adja. Ahogy arról akkor részletesen beszámoltunk, az Oracle valamikor 2015 második felében de facto leállította a Java EE fejlesztését és a fejlesztőket más, stratégiailag fontosabb projektekre csoportosította át. A cég mindezt teljes csendben, a közösség tájékoztatása nélkül tette, és az egyre hangosabban feltett kérdésekre is csak sokatmondó csenddel válaszolt a vállalat.

A kipattanó sztori végül döntéskényszerbe hozta az Oracle-t és végül a Java EE további fejlesztése mellett lándzsát törő csapat kerekedett felül, a cég pedig bejelentette, hogy elkezd újra aktívan dolgozni a Java EE 8 kiadásán. Ennek eredménye idén október elején esedékes, a cég ígérete szerint a San Franciscói JavaOne konferencián ez is bemutatkozik majd. A friss bejelentés fényében már úgy tűnik, hogy a cég elköteleződése erre az egy verzióra szólt, és már korábban megszülethetett a döntés, hogy a fejlesztés lezárásával teljesen közösségi irányítás alá helyezi a szoftvert a cég.

A közösségi szoftverfejlesztés egyébként pont a szélesebb platformok esetében szokott jól működni, az úttörő Linux kernel mellett a Node.js vagy az OpenStack is jó példa arra, hogy virágozni tud az a szabad szoftveres projekt, amelynek sikerében sok-sok szereplő érdekelt, és e szereplők hajlandóak a közösbe bedobni saját erőforrásaikat. A Java EE-ből több szereplő is készít saját implementációt, az Oracle saját WebLogic és GlassFish megoldásán túl az IBM WebSphere, a Red Hat JBoss és a Fujitsu Interstage is ezek közé tartozik - a gyakorlatban nekik kell majd a jövőben együtt fenntartani ezt a platformot.

Red Hat: ez egy jó ötlet!

Tegnap már a Red Hat is blogbejegyzésben reagált az Oracle-féle bejelentésre, amelyben üdvözölte a vállalat döntését. "Úgy gondoljuk, hogy a Java EE átköltöztetése egy nyílt forráskódú alapítványhoz nagyon pozitív lesz és a teljes vállalati Java közösségnek javára válik majd." - fogalmaz a cég. A Red Hat várakozása szerint a lépés segít majd erősíteni a Java nyílt forráskódú kultúráját és növelni tudja majd a közösséget. Szintén fontos lesz, ha a Java EE egy megengedőbb szabad szoftveres licencet kap, ami segít majd bevonzani más fejlesztőket és implementálókat.

forrás:hwsw.hu

Java EE-botrány: megszólal az Oracle

Meghajolt a nyomás alatt az Oracle és immár nyilvánosan is színt vallott a Java, azon belül pedig a nagyvállalati felhasználásra szánt Java Enterprise Editionról is. Egyelőre csak nyugtató szavak vannak, részletek a szeptemberi JavaOne fejlesztői konferencián jönnek.

Fokozatosan pánikszerű hangulatot eredményezett a Java ökoszisztéma szereplői körében, hogy az Oracle hosszú hónapok óta mélyen hallgat a Javával, azon belül pedig a Java EE-vel kapcsolatos terveiről. A nyomást végül a Java EE Guardians néven a platform megmentésére csapat fokozta elviselhetetlenné, a Java-prominensek mellett az IBM és a Red Hat is a kezdeményezés mögé állt, és végül a a Java Community Process (JCP), a legfőbb független Java-testület is felhívta az Oracle-t a színvallásra.

Az egyre nagyobb sajtóvisszhangot kapó konfliktust végül tegnap azzal zárta le az Oracle, hogy az angol Registernek (egyelőre) exkluzív nyilatkozatot adott, Mike Moeller szóvivőn keresztül. Eszerint "az Oracle elkötelezett a Java mellett és egy jól kidolgozott javaslattal rendelkezik a a Java EE következő verziójának, a Java EE 8 specifikációját illetően. Ez támogatni fogja a fejlesztőket abban, hogy új, mikroszolgáltatásokat (microservice) vagy nagyméretű, elosztott rendszereket, konténerekalapú környezeteket építsenek a felhőben." Hozzátette: "az Oracle szorosan együttműködik a kulcs partnerekkel abban, hogy a javaslatot véglegesítse és a szeptemberi JavaOne konferencián megossza azt a szélesebb Java-közösségel is."

A Register információi szerint az Oracle nagyjából egy éve döntött úgy, hogy lezárja a  nyílt Java EE fejlesztésére tett erőfeszítéseket, helyette pedig egy zárt, tulajdonosi (proprietary) Java runtime és API fejlesztésére fókuszál, amely nagyvállalati környezetben ki tudja váltani a Java EE-t. Az új platform nagyban épít a Java EE-re, de túlnyomórészt az Oracle zárt fejlesztéseire épül, és kizárólagosságot biztosít a cég számára annak használatában. A tavaly erre az új projektre irányította át a Java EE-n dolgozó munkatársakat, ez az irányváltás pedig nagyon jól látszik a nyílt platformon végzett munka drasztikus visszaeséséből is.

A belsős információk szerint ebben a döntésben sok minden közrejátszhatott, leginkább a Google-Oracle per fordulatai befolyásolhatták a cég üzleti döntéshozóit. A bíróság abban ugyanis úgy döntött, hogy az API-kat nem védi szerzői jog, azokat bárki tetszés szerint újraimplementálhatja, ha akarja. Ugyan ezt a döntést az Oracle megfellebbezte és nyert is (tehát az API-t igenis védi a szerzői jog az Egyesült Államokban), annak újraimplementációja azonban végülis fair use-nak bizonyult, vagyis kivételt képez a szerzői jog alól.

Ilyen körülmények között az Oracle úgy döntött, hogy a Java API-val követett nyitottság politikája már inkább hátrány, mint előny, így érdemesebb azt egy zárt alternatívára cserélni. Mivel a cég saját termékcsaládjai közül is rengeteg épít közvetve vagy közvetlenül a Java EE-re, a teljes, utód nélküli bezárás nyilván fel sem merült, azzal a cég saját maga alatt vágná a fát.

És mégis: Java EE

Ezt a hivatalosan be nem jelentett, de a statisztikákból és a cég mély-mély hallgatásából fokozatosan egyértelműbbé váló döntés okozott pánikot a Java EE-re fogadó partnerek és szereplők körében. A nyílt platform nélkül ugyanis rengetegen maradnának hoppon, még akkor is, ha alternatívaképp az Oracle azért kínálna egy fizetős alternatívát.

A Register belsős információi szerint azonban nemrég az Oracle-ön belül az a csapat kerekedett felül, amely nyílt Java EE fejlesztése mellett tört lándzsát, és a cég vezetése végül úgy döntött, hogy visszatér az eredeti koncepcióhoz és megtartja, illetve tovább fejleszti a platformot. "Túl sok kárt okozna az ökoszisztémának és nincs garancia arra, hogy a partnerek használnák is az új, immár zárt API-t"- ismerteti az érvelést belsős információkra hivatkozva a Register.

A döntés értelmében tehát újra él az eredeti terv, érkezik a Java EE 8, amely megkapja az égetően szükséges fejlesztéseket a microservice-ek, a konténerek és a nagyméretű, elosztott rendszerek támogatásához, ezzel például a nagy rivális Microsoft .NET Core előnyét is igyekszik majd behozni (hogy a modernebb, feltörekvő alternatívákról ne is beszéljünk).

Az Oracle bejelentését Reza Rahman, Java EE Guardians alapítója, volt Oracle-alkalmazott is örömmel fogadta: "Ez nagyon jó hír és egy pozitív meglepetés" - nyilatkozta. "Örvendünk, hogy az Oracle immár hallgat a közösségre és dolgozik azon, hogy megoldást találjon. Reméljük, hogy a jövőben az Oracle a Java EE-t szabványként, és nem egy egyszerű termékként kezeli majd" - tette hozzá. A bejelentést a Java EE Guardians is üdvözölte, de a győzelmi köröket majd csak a JavaOne-ra ígért hivatalos bejelentés után fogják megfutni.

forrás: hwsw.hu

Az Android N nem tartalmaz majd proprietary Oracle-ös Java API-kat

Szemfülesek észrevették, hogy nemrég egy érdekes commit született a Google alkalmazásában álló Piotr Jastrzebski és Narayan Kamat páros munkája nyomán "Initial import of OpenJdk files" leírással az Android platform git tárolójában. Elindult a találgatás a commit-tel kapcsolatban.

A Google megerősítette a VentureBeat-nek, hogy az Android következő major verziója, az Android N már nem fog tartalmazni proprietary Oracle Java API-kat. Helyette az Android N kizárólag a szabad, nyílt forrású OpenJDK-ra fog támaszkodni.

A változtatás mindenképpen érdekes a Google és az Oracle közt húzódó, folyamatban levő per miatt. Egyesek szerint lehetséges, hogy a változtatás annak köszönhető, hogy a Google és az Oracle peren kívül megegyeztek, mások szerint az sem kizárt, hogy a Google ezzel a lépéssel akarja biztosítani az Android jövőjét arra az esetre, ha vesztene a perben.

Mivel folyamatban levő perről van szó, a Google ezt a kérdéskört nem kommentálta.

A részletek itt olvashatók.

forrás:hup.hu

SI Java és SAP Academy - Jelentkezz most!

A Pécsi Tudományegyetem Pollack Mihály Műszaki és Informatikai Kara
2014. szeptemberétől az IT-Services Hungary Kft. System Integrations Ágazatának megbízásából SI Java Academy és SI SAP Academy oktatási programokat szervez. A képzések indulásának várható időpontja:  2014.szeptember 8.

Mindkét szakmai kurzus igen kurrens, a munkaerőpiacon keresett ismeretek megszerzésére ad lehetőséget a résztvevők számára anyagi befektetés nélkül.
A képzések további előnye, hogy a tanfolyam sikeres befejezése után az IT Services Hungary Kft. azonnal állást is biztosít a legjobb eredménnyel záró hallgatók számára.

Ki jelentkezhet a képzésre?

A programok célközönsége elsősorban A PTE PMMIK német nyelven beszélő hallgatói, de a képzésre jelentkezhetnek a PTE bármely karán hallgatói jogviszonnyal rendelkező diákok, illetve hallgatói jogviszonnyal nem rendelkező külső érdeklődők is. 

Mindkét tanfolyamon maximum 25-25 fő vehet részt. A megrendelő elvárása a német nyelv ismerete, ezért a jelentkezők között előnyt élvez, aki nyelvtudását B2 – vagy azzal megegyező szintű nyelvvizsgával tudja igazolni. (A jelentkezésnek nem feltétele a nyelvvizsga, viszont előnyt jelent.)

Az oktatás formája, helye, időbeosztása

Mind a Java Academy, mind az SAP Academy kurzus az IT Services Hungary Kft. által támogatott 1 féléves órarenden kívüli 208 órás képzést jelent. A képzések hétfőtől péntekig 15:30-19:30 idősávban a PTE PMMIK Boszorkány úti számítógépes laborjaiban kerülnek megtartásra. (Az órarend összeállításánál figyelemmel voltunk a tanfolyam időbeosztására, ezért várhatólag órarendi ütközést nem jelent a tanfolyami részvétel.)

A tanfolyamokhoz egy német szaknyelvi kurzus is tartozik, melynek időbeosztása péntek 9:30-12:45. A német szaknyelvi kurzus célja a német nyelvismeret felfrissítése, elmélyítése, alkalmazás szintű elsajátítása.

Mit várunk el a kurzusra jelentkező hallgatóktól?

A kurzusra felvételt nyert hallgató köteles 

  • mind a szakmai, mind a német szaknyelvi tanórákon megjelenni, 
  • az oktatók által kiadott feladatokat határidőre elkészíteni,
  • a rendszeres számonkérésekre felkészülni, azokat 50%-ot meghaladó eredménnyel teljesíteni 
  • a kurzus végén megszervezésre kerülő vizsgán részt venni, ott a megszerzett tudásának legjavát nyújtani.

Amennyiben a fenti ajánlat felkeltette érdeklődését, a mellékelt jelentkezési lap visszaküldésével jelezze részvételi szándékát az Ön által választott képzésre vonatkozóan.

A kitöltött jelentkezési lapot kérem a horvath pont ildiko kukac pmmik pont pte pont hu címre mielőbb eljuttatni szíveskedjen!

A képzésekkel kapcsolatban személyes tájékoztatót tartunk
2014. szeptember 3-án 16:30-kor
a Boszorkány úti épület  201-es termében

JAVAPOCALYPSE

Egy érdekes vírusreklám azt feszegeti, hogy mi történne, ha egy csapásra eltűnne a Java mindenhonnan.

Oracle vs. Google: az Oracle Java API-jai nem copyrightolhatók

Újabb vereségek az Oracle oldalán a Google ellen indított Java/Android perben. Azután, hogy a múlt héten az esküdtek úgy döntöttek, hogy a Google nem sértett Oracle szabadalmakat, az Oracle arra kérte az ügyben eljáró bírót, hogy az hatálytalanítsa az esküdtek döntését és hozza meg a döntést maga. Az Oracle az ún. "Judgment as a matter of law" indítvánnyal a döntést a bíró kezébe helyezte volna. William Alsup bíró szerdán elutasította az Oracle kérését.
Ha ez nem lenne elég, Alsup - a Groklaw-os Pamela Jones szerint - úgy döntött, hogy az Oracle Java API-jai nem copyrightolhatók.

 

Idézet:

Therefore, Oracle’s claim based on Google’s copying of the 37 API packages, including their structure, sequence and organization is DISMISSED

PJ szerint ez azt jelenti - az ő olvasatában legalábbis -, hogy nem lesz újabb tárgyalás a copyrightolhatóság témában. Az Oracle számára a bukta elkönyvelése mellett egyetlen opció a fellebbezés, de PJ szerint hülyék lennének, ha ezt az utat választanák.

Részletek a Groklaw oldalán.

Fedora Developer Conference Brno-ban

an Open conference for all Linux and JBoss Developers, Admins and Linux users organized by Red Hat Czech Republic

Az esemény honlapja

Naptár Naptár

szombat

21

2017.10.21.
H K Sze Cs P Szo V
25 26 27 28 29 30 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
Ezen a napon nincsenek események.
Idő Cím Típus  
Ezen a napon nincsenek események.
0 tétel megjelenítése.

Cimkefelhő Cimkefelhő