Почему Sun не делает C# к компилятору Байт-кода Java?
Вы передаете данные в массив по ссылке, и в каждом цикле вы меняете значение ссылки:
self.aUser.username = object["username"] as! String
self.usersAvailableArray.append(self.aUser)
Попробуйте каждый раз создавать нового пользователя:
var newUser = usersAvailable()
newUser.username = object["username"] as! String
self.usersAvailableArray.append(newUser)
Это происходит потому, что объект, который вы добавляете, приходит из класса из документации к присяге :
Классы являются ссылочными типами
В отличие от типов значений ссылочные типы не копируются, когда они назначаются переменной или константе или когда они передаются функции. Вместо копии вместо этого используется ссылка на один и тот же существующий экземпляр. Вы можете увидеть больше о значениях и ссылках в Swift
blockquote>. Еще одно решение - изменить ваш класс на структуру, как показано ниже, structs different, если классы делают копию значения, когда оно передается вместо передать ссылку.
struct usersAvailable { var username = String() var userAvatar = UIImage() }
16 ответов
Во-первых Sun имеет нулевой стимул реализовать компилятор C# на JVM, потому что у них есть что-то очень похожее, названное языком программирования Java.
также не действительно столь же простой так просто реализация компилятора, как библиотеки стандартного класса Java не являются тем же как .net Base Class Libraries. Вы закончили бы тем, что имели необходимость изменить все вызовы API.NET вызовов API Java.
Micrsoft имел продукт по имени J#, который был предназначен, чтобы быть для Java к преобразованию.NET, но в конце никто не использовал его, поскольку API был ограничен пред Java 2 API, таким образом, это было главным образом бесполезно. Это было бы то же, если бы Sun реализовал части BCL.NET, поскольку только базовые части его стандартизированы и единожды оплачиваемые. Части как ASP.NET и WPF, WCF и т.д. не являются частью стандартов ECMA и таким образом, Sun было бы нужно разрешение Microsofts реализовать их API.
, Если достаточно клиентов хочет, чтобы версия Java принесла выгоду для портирования приложения на Java затем, делают это, Вы просто, привычка когда-либо получает любую справку от Sun через C# к компилятору JVM.
Весело провести время.
- Должен повредить контролируемые исключительные ситуации.
- Должен найти способ реализовать делегатов (которые похожи на интерфейсы отдельного метода, добавил не ранее, чем время загрузки).
Вы можете выполнять свой код.NET и код Java в том же интерпретаторе! Посмотрите IKVM основанная на.NET JVM, и эти Шиканье и страница Java wiki для варианта использования в качестве примера (использующий основанный на.NET язык Шиканья для записи приложений, пользующихся библиотеками Java).
я думаю, что Вы найдете, что Mainsoft, инструмент Enterprise Edition позволяет Вам выполнять больше всего/возможно весь свой код.NET под Java JVM... Кажется, фокусируется больше на ASP.NET, но позволит C#. Это было доступно в течение некоторого времени, пожалейте, они не предают гласности его лучше!
Предупреждение аннотации следует....
MainsoftВ® является программным обеспечением совместимости.NET Java, которое позволяет IT-организациям переместиться в поддерживающие Java платформы, такие как Linux при сохранении существующих инвестиций в код.NET и навыки. Программное обеспечение интегрируется беспрепятственно в Визуальную среду разработки StudioВ®, позволяя C# и разработчикам Visual Basic быстро разработать и поддержать сервер и веб-приложения, которые работают на Windows, Java платформы EE или оба, таким образом, уменьшая разработку приложений и затраты на обслуживание, время к производству и общая стоимость владения.
Joe, я предлагаю, чтобы Вы исследовали IKVM. Вы могли бы найти что-то там, которое царапает Ваш зуд
"Так, мы хотели бы создать версию Java нашего базового механизма, идеально не поддерживая отдельную основу исходного кода Java".
В основном, Вы хотите скомпилировать свой код C#, неизмененный и иметь выполненный в среде только для Java.
IKVM не , что Вы хотите. IKVM три главного .
a. ikvm - реализация CLI виртуальной машины Java (отмечают, что это использует путь к классу (теперь OpenJDK) для Библиотеки классов Java).
b. ikvmc - байт-код Java Компиляций к байт-коду CLI.
c. ikvmstub - Генерирует классы тупика Java тот вызов код CLI.
Примечание, что все эти инструменты зависят от CLI во времени выполнения. То, что Вы хотите, является точно противоположностью IKVM, который является, конечно, MVKI (Самый Почтенный Посредник Kompiler) :):
a. mvki - реализация Java виртуальной машины CLI (по-видимому, это использовало бы Моно или DotGNU для библиотеки классов).
b. mvkic - Компиляции байт-код CLI к байт-коду Java.
c. mvkistub - Генерирует классы тупика CLI, которые называют Примечание Java
, что ни один из них не потребовал бы существующей реализации Платформы.NET во времени выполнения, таким образом, они должны быть удовлетворительными для Ваших клиентов только для Java.
, К сожалению, насколько я знаю, MVKI не существует, таким образом, Вы являетесь лучшими от выполнения ручного порта (который неизбежно был бы более чистым, хотя больше работы).
Редактирование: На основе описание Mainsoft, это, кажется, подобно MVKI, хотя я не уверен, что они делают для библиотеки классов, и в отличие от IKVM это не FOSS.
Почему Microsoft не делает C# к компилятору байт-кода Java? Почему не делают , Вы делаете это? На каждой стороне существуют открытые спецификации...
Joe Erickson записал:
Помощь выполнить код C# платформы Java означает больше разработчиков и больше программного обеспечения для платформы.
Это - несоответствующий оператор. Выполнение кода C# JVM не создает программистов Java, это создает программистов C#, которые могут выполниться на JVM. Это только разворачивает досягаемость C#, предполагая, что JVM также переводит любую Microsoft определенные вызовы (т.е. win32) во что-то, что независимо от платформы. Таким образом, если Sun переводит IL в байт-код Java, единственная группа, которой он помогает: Microsoft. И, учитывая историю Sun с Microsoft во время исходных судебных процессов Ереси/Visual J++ C#-Java...
Плюс, необходимо столкнуться с техническим infeasibility, хотите ли Вы или нет. Существуют принципиальные различия в способе, которым байт-коды выполняются, которые намного более важные проблемы чем то, существует ли неподписанный длинный тип данных.
, Если у Вас должен быть C# на платформе не-Microsoft, используйте Моно
Выставьте свой API.NET как веб-сервисы ASMX, и необходимо быть хорошими для движения.
РЕДАКТИРОВАНИЕ: Для большего количества сценариев тяжелого использования стоило бы изучить Windows Communication Foundation (WCF). Это имеет встроенную, настраиваемую поддержку безопасности, потоковой передачи, различные транспортные сценарии (HTTP, TCP/IP, локальные именованные каналы). Вы не ограничиваетесь кодированием сообщения SOAP, но это, вероятно, было бы самым легким путем к interop с Java.
я не слишком уверен в Вашем точном сценарии, но если Вы имеете дело с большими файлами, и код.NET и код Java оба работают локально, можно просто сохранить файл к жесткому диску пользователя с помощью.NET и затем выбрать его из приложения Java.
Простой. Поскольку Sun не предъявила бы иск Microsoft. И в то время как мы как программисты не могли бы видеть жизнеспособные основания для иска, иметь в виду, что Microsoft является вполне более крупной компанией, чем Sun и имеет право управлять ими вокруг.
Sun, к счастью, находится в положении того, чтобы быть вполне более открытым, чем Microsoft как бы то ни было. Если бы такой спрос существует, или открытый исходный код или третье лицо могли бы сделать этот компилятор для Java, и Sun не должен был бы брать тепло.
Должно быть серьезное основание. Я просто не могу ни за что в жизни выяснить, каково это...
Легко полагать, что компании являются некоммерческими организациями, которые принимают близко к сердцу Ваши интересы. Легко забыть, что единственная цель для листинговой компании состоит в том, чтобы делать деньги для него, совместно используют держателей. Это - юридическое обязательство, и директора/руководители были уволены/предъявлены иск, если держатели доли не полагают, что им не удалось сделать это.
Sun делает Java свободным, потому что он помогает продать их аппаратные средства который, как он делает деньги от Java. IBM делает Java свободным, потому что она помогает им сделать больше денег на своем консалтинге.
Если бы Sun должен был потратить деньги на преобразователь C#, как он сделал бы те деньги назад и получил бы прибыль. Предположите, что необходимо убедить держателей доли Sun. Если Вы можете, Sun сделать преобразователь C#.
Если бы я делал что-то как кросс-платформенная межъязыковая поддержка, то я создал бы 'общий API', так как языки подобны в синтаксисе, Вы могли сделать переводчика достаточно легким. Затем вместо того, чтобы назвать Java или пчелу .NET непосредственно от ядра, Вы назвали бы свой 'общий API', который будет реализация ре Java и пчела .NET, в которой Вы нуждались бы. Таким образом Вы могли создать межъязыковую песочницу, если Вы будете. Так как основными отличиями в Java и c# являются определения объектов, я получил бы тех, которые путем отражения C# dlls, и затем восстановил бы конструкции, затем будет легко пробежать интерпретатор и реализовать тела функции и преобразовать свойства в методы set методов считывания, уже зная структуру файлов. Это, конечно, принимает .net 2.0, некоторые функции в 3,0 и 3.5 становятся очень трудными 'интерпретировать'
Это было бы сложно, но вероятно не так сложно как восстановление ядра в Java вручную и необходимости иметь 2 команды, работающие над ними seperatly. Если эта идея зажигает некоторое вдохновение, я мог бы создать тот. Я действительно видел бы более простую стабильную моно установку для Mac.
В основном я думаю, что интерпретатор уровня кода на основе ряда общих классов API является чем-то очень возможным для записи с командой за неделю или два.
JACIL - очевидно мертвый проект, который пытается сделать обратное IKVM. Возможно, некоторые мотивированные люди могли бы использовать его в качестве отправной точки для жизнеспособного компилятора .Net в JVM.
Думаю, лучший вопрос - почему бы вы не написать компилятор байтового кода C # в Java, если вы хотите, чтобы он существовал. Дождаться, пока корпоративные повелители что-то сделают, - плохая идея.
Предложение для создания такой реализации: возьмите клиентскую часть C # от Mono или .GNU. Не трудитесь писать свои собственные.
http://jsc.sourceforge.net/ - кросс-компилятор c #, который может преобразовывать код .NET в Java (помимо прочего).
Интересно, может ли проект моно-проекта заставить меньше работать сами по себе, нацеливаясь на JVM вместо того, чтобы развивать и поддерживать собственную виртуальную машину с нуля. Усилия по развитию можно было сосредоточиться на кросс-компиляторе C # и портировать реализацию чистых номеров .NET библиотек к JVM. Вроде как версия с открытым исходным кодом о том, что сделал Mainsoft. Затем вы можете включить межвизначные вызовы между кодом Java и C # в одном и том же JVM, а развертывание апплетов и приложений Java Web Start, написанные в C #.